RE: [BUG] sleeping function called from invalid context during resume

["Brown, Len" <len.brown@intel.com>]

>> >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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/