>> >I got the following on my laptop w/ 2.6.18-rc1.
>> >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
>but not, afaict, a two-phase resume. If it did, and if the
>phase were to run with IRQs enabled then we should be able to
>> 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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]