On Sat, 2008-03-15 at 13:47 +0100, Tilman Schmidt wrote: > > Anyway, I'm sick of too much bitching and too little coding. > Andrew, > > here's a patch for -mm that will at least shut up the spinlock > warnings. > > Sorry to say, it doesn't. That is, it does shut up the warning I > reported, but there's a new one appearing now instead, three lines > later. Here's the dmesg diff: > > @@ -216,29 +216,30 @@ > CPU0: Thermal monitoring enabled > Compat vDSO mapped to ffffe000. > Checking 'hlt' instruction... OK. > -BUG: spinlock bad magic on CPU#0, swapper/0 > - lock: c2c19380, .magic: 00000000, .owner: swapper/0, .owner_cpu: 0 > -Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #2 > - [<c01f728c>] spin_bug+0x7c/0x87 > - [<c01f72b0>] _raw_spin_unlock+0x19/0x71 > - [<c0301922>] _spin_unlock+0x1d/0x3c > - [<c01981aa>] mnt_want_write+0x62/0x88 > - [<c018c382>] sys_mkdirat+0x86/0xd6 > - [<c04260ab>] ? clean_path+0x16/0x4a > - [<c017fd6f>] ? kfree+0xd8/0xec > - [<c018c3e2>] sys_mkdir+0x10/0x12 > - [<c0426353>] do_name+0x112/0x1b3 > - [<c042558b>] write_buffer+0x1d/0x2c > - [<c04255fe>] flush_window+0x64/0xb3 > - [<c04272f5>] unpack_to_rootfs+0x62c/0x8b9 > - [<c04275a2>] populate_rootfs+0x20/0x109 > - [<c0429ed2>] ? alternative_instructions+0x153/0x158 > - [<c04248f5>] start_kernel+0x343/0x355 > - [<c0424019>] i386_start_kernel+0x8/0xa > - ======================= > Unpacking initramfs... done > -Freeing initrd memory: 8767k freed > +Freeing initrd memory: 8834k freed > ACPI: Core revision 20070126 > +INFO: trying to register non-static key. > +the code is fine but needs lockdep annotation. > +turning off the locking correctness validator. > +Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3 > + [<c014321e>] __lock_acquire+0x144/0xb6e > + [<c010b1a2>] ? native_sched_clock+0xe0/0xff > + [<c017fc57>] ? kmem_cache_alloc+0x89/0xc9 > + [<c0142ce0>] ? trace_hardirqs_on+0xe8/0x11d > + [<c014404f>] lock_acquire+0x6a/0x90 > + [<c013b460>] ? down_trylock+0xc/0x27 > + [<c03016cb>] _spin_lock_irqsave+0x42/0x72 > + [<c013b460>] ? down_trylock+0xc/0x27 > + [<c013b460>] down_trylock+0xc/0x27 > + [<c021fa65>] acpi_os_wait_semaphore+0x67/0x13d > + [<c023a39e>] acpi_ut_acquire_mutex+0x65/0xcf > + [<c0230261>] acpi_ns_root_initialize+0x1a/0x289 > + [<c043ad54>] acpi_initialize_subsystem+0x47/0x6a > + [<c043afd4>] acpi_early_init+0x57/0xf8 > + [<c04248ff>] start_kernel+0x34d/0x35a > + [<c0424019>] i386_start_kernel+0x8/0xa > + ======================= > ACPI: Checking initramfs for custom DSDT > Parsing all Control Methods: > Table [DSDT](id 0001) - 637 Objects with 63 Devices 160 Methods 41 > Regions Hi Tim, Again, thanks for the excellent bug reporting. This is actually a different problem (and not my code again, thank goodness). I think a few of these got fixed in current -mm. According to Peter Z, these mean: > It means the lock_class_key ended up in non-static storage. > > In practise it often means you initialized a on-stack structure > incorrectly. DECLARE_WAIT_QUEUE_HEAD() vs > DECLARE_WAIT_QUEUE_HEAD_ONSTACK() for example. So, this looks like an on-stack ACPI structure that got initialized wrongly. At least we already have those dudes on the cc. :) But, this might also get fixed by reverting the patch as Linus just did. It might just be best to wait for another -mm release and see how it settles out. -- Dave -- 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
