>> >I got the following on my laptop w/ 2.6.18-rc1. >> > >> >thanks >> >-john >> > >> >Stopping tasks: >> >================================================================ >> >=======================| >> >pnp: Device 00:0b disabled. >> >ACPI: PCI interrupt for device 0000:02:01.0 disabled >> >ACPI: PCI interrupt for device 0000:00:1f.5 disabled >> >ACPI: PCI interrupt for device 0000:00:1d.7 disabled >> >ACPI: PCI interrupt for device 0000:00:1d.2 disabled >> >ACPI: PCI interrupt for device 0000:00:1d.1 disabled >> >ACPI: PCI interrupt for device 0000:00:1d.0 disabled >> >Intel machine check architecture supported. >> >Intel machine check reporting enabled on CPU#0. >> >Back to C! >> >BUG: sleeping function called from invalid context at mm/slab.c:2882 >> >in_atomic():0, irqs_disabled():1 >> > [<c0103d59>] show_trace_log_lvl+0x149/0x170 >> > [<c01052ab>] show_trace+0x1b/0x20 >> > [<c01052d4>] dump_stack+0x24/0x30 >> > [<c0116e51>] __might_sleep+0xa1/0xc0 >> > [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0 >> > [<c0264b5a>] acpi_os_acquire_object+0x11/0x41 >> >> yep, the new slab for objects makes this path immune to >> the acpi_in_resume hack in acpi_os_allocate() > >hm. Linus's new suspend/resume thing seems to have a >two-phase suspend, >but not, afaict, a two-phase resume. If it did, and if the >second resume >phase were to run with IRQs enabled then we should be able to >address this >appropriately. > >> I think we need to get rid of the acpi_in_resume hack >> and use system_state != SYSTEM_RUNNING to address this. > >Well if hacks are OK it'd actually be reliable to do > > /* comment goes here */ > kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL); > >because the irqs_disabled() thing happens for well-defined reasons. >Certainly that's better than looking at system_state (and I >don't think we >leave SYSTEM_RUNNING during suspend/resume anyway). If system_state != SYSTEM_RUNNING on resume, theen __might_sleep() would not have spit out the dump_stack() above. This is exactly like boot -- we are bringing up the system and we need to configure interrupts, which runs AML, which calls kmalloc in a variety of ways, all of which call __might_sleep. It seems simplest to have resume admit that it is like boot and that the early allocations with interrupts off simply must succeed or it is game-off. -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
