On Mon, 2009-08-24 at 08:10 +0800, Ming Lei wrote: > 2009/8/23 Catalin Marinas <catalin.marinas@xxxxxxx>: > > On Sun, 2009-08-23 at 10:48 +0800, Ming Lei wrote: > >> [ 0.006569] ACPI: Core revision 20090521 > >> [ 0.011476] BUG: scheduling while atomic: swapper/0/0x10000002 > >> [ 0.011558] no locks held by swapper/0. > >> [ 0.011561] Modules linked in: > >> [ 0.011566] Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #141 > >> [ 0.011569] Call Trace: > >> [ 0.011577] [<ffffffff81070bb7>] ? __debug_show_held_locks+0x22/0x24 > >> [ 0.011584] [<ffffffff8103d4ba>] __schedule_bug+0x77/0x7c > >> [ 0.011590] [<ffffffff812da32f>] schedule+0xd6/0xa3f > >> [ 0.011596] [<ffffffff810e4b9b>] ? kmem_cache_free+0xe2/0x158 > >> [ 0.011600] [<ffffffff810717e2>] ? trace_hardirqs_on_caller+0x12d/0x158 > >> [ 0.011604] [<ffffffff8107181a>] ? trace_hardirqs_on+0xd/0xf > >> [ 0.011609] [<ffffffff8103e3f0>] __cond_resched+0x29/0x47 > >> [ 0.011614] [<ffffffff812dae24>] _cond_resched+0x29/0x34 > >> [ 0.011620] [<ffffffff811da90a>] acpi_ps_complete_op+0x246/0x25c > >> [ 0.011625] [<ffffffff811db024>] acpi_ps_parse_loop+0x704/0x860 > >> [ 0.011630] [<ffffffff811da200>] acpi_ps_parse_aml+0x9f/0x2de > >> [ 0.011635] [<ffffffff811d9181>] acpi_ns_one_complete_parse+0x101/0x11c > >> [ 0.011640] [<ffffffff811d91bd>] acpi_ns_parse_table+0x21/0x3c > >> [ 0.011645] [<ffffffff811d67e3>] acpi_ns_load_table+0x4f/0x94 > >> [ 0.011650] [<ffffffff811dd14a>] acpi_load_tables+0x72/0x133 > >> [ 0.011656] [<ffffffff8153c592>] acpi_early_init+0x60/0xf5 > >> [ 0.011661] [<ffffffff81519cb0>] start_kernel+0x38b/0x3a0 > >> [ 0.011666] [<ffffffff81519140>] ? early_idt_handler+0x0/0x71 > >> [ 0.011670] [<ffffffff815192a3>] x86_64_start_reservations+0xaa/0xae > >> [ 0.011675] [<ffffffff8151939e>] x86_64_start_kernel+0xf7/0x106 > > > > I looked at the traces and there are no kmemleak calls. It's either that > > kmemleak is disabled or the error is not on a kmemleak path. It looks > > more like an ACPI bug to me. > > > > Can you try only with slab debugging enabled (without kmemleak or > > kmemcheck)? IIRC someone else reported a similar issue a few weeks ago. > > If I only disabled kmemleak, the kernel does not print the warning, so I suppose > it is related with kmemleak. I can't really see how kmemleak gets involved in here. Maybe you could just enable some of the features turned on by kmemleak like STACKTRACE and see if you still get the error. For x86-64 you may need this patch - http://lkml.org/lkml/2009/8/16/269 > Attachment is the .config, hope it is usable to help to fix the warning. Thanks but I don't have such hardware to test and I don't get this error on x86-32. Looking at the code, the acpi_ps_complete_op() function calls the ACPI_PREEMPTION_POINT() macro which expands to a cond_resched() call if IRQs aren't disabled. The IRQs are probably enabled at that point but it seems that the context is atomic. I cc'ed the ACPI people, maybe they can help with some suggestions Thanks. -- Catalin -- 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
