[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1205525184.12763.32.camel@nimitz.home.sr71.net>
Date: Fri, 14 Mar 2008 13:06:24 -0700
From: Dave Hansen <haveblue@...ibm.com>
To: Tilman Schmidt <tilman@...p.cc>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
Eric Piel <eric.piel@...mplin-utc.net>,
Len Brown <len.brown@...el.com>,
Linus Torvalds <torvalds@...l.org>,
Christoph Hellwig <hch@...radead.org>,
Markus Gaugusch <dsdt@...gusch.at>, linux-acpi@...r.kernel.org
Subject: Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot
For those of you new to this thread, here's the initial report:
http://marc.info/?t=120536629300001&r=1&w=2
I'm pretty sure the root cause of this bug is this commit:
ACPI: basic initramfs DSDT override support
71fc47a9adf8ee89e5c96a47222915c5485ac437
Which did this hunk:
@@ -648,6 +654,7 @@ asmlinkage void __init start_kernel(void)
check_bugs();
+ populate_rootfs(); /* For DSDT override from initramfs
*/
acpi_early_init(); /* before LAPIC and SMP init */
/* Do the rest non-__init'ed, we're now alive */
rest_init();
...
Well, the fs initcalls aren't actually done until during rest_init(),
including initializing my mnt_writer[] spinlocks. I guess I could
statically initialize them, but that's not the root of the problem, it's
just the canary in the coal mine.
I think the populate_rootfs() call is completely bogus and certainly
can't be done before the initcalls. But, I don't immediately have any
better suggestions for you. Can you delay the ACPI init until after the
fs initcalls are made?
-- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists