Re: [PATCH 2.6.20-rc2-git1] start_kernel: Test if irq's got enabled early, barf, and disable them again

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Ard -kwaak- van Breemen <ard@...>
Cc: Andrew Morton <akpm@...>, Greg KH <greg@...>, Zhang, Yanmin <yanmin.zhang@...>, Chuck Ebbert <76306.1226@...>, Yinghai Lu <yinghai.lu@...>, <take@...>, <agalanin@...>, <linux-kernel@...>, <bugme-daemon@...>, Eric W. Biederman <ebiederm@...>, <sfr@...>
Date: Monday, March 3, 2008 - 6:46 pm

>  +               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
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 2.6.20-rc2-git1] start_kernel: Test if irq's got ..., Tony Luck, (Mon Mar 3, 6:46 pm)