[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Mar 2008 14:46:52 -0800
From: "Tony Luck" <tony.luck@...el.com>
To: "Ard -kwaak- van Breemen" <ard@...egraafnet.nl>
Cc: "Andrew Morton" <akpm@...l.org>, "Greg KH" <greg@...ah.com>,
"Zhang, Yanmin" <yanmin.zhang@...el.com>,
"Chuck Ebbert" <76306.1226@...puserve.com>,
"Yinghai Lu" <yinghai.lu@....com>, take@...ero.it,
agalanin@...a.ru, linux-kernel@...r.kernel.org,
bugme-daemon@...zilla.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>, sfr@...b.auug.org.au
Subject: Re: [PATCH 2.6.20-rc2-git1] start_kernel: Test if irq's got enabled early, barf, and disable them again
> + printk(KERN_WARNING "start_kernel(): bug: interrupts were enabled *very* early, fixing it\n");
I built and booted the next-20080303 tag from linux-next and
found the above warning in my console log on ia64 (this is
new ... I've never seen this message before, even though
this patch was applied January 2007).
Hunting this down, I found the enabler was the lock_kernel() call
on line 536 of init/main.c ... doesn't than happen to other archs
too? We get into the first call to lock_kernel() with current->lock_depth
set to -1, so we call down(&kernel_sem) ... which does spin_lock_irq()
and then spin_unlock_irq() ... leaving interrupts enabled.
What else changed to make this suddenly kick out now? It
doesn't happen from a build from Linus' tree.
-Tony
--
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