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

[Stephen Rothwell]

Hi Tony,

On Mon, 3 Mar 2008 14:46:52 -0800 "Tony Luck" <tony.luck@xxxxxxxxx> wrote:
>
> >  +               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.

This is Willy's generic semaphore code that is included in linux-next.
It is being discussed in another thread "linux-next: Tree for Feb 29:
WARNING: at kernel/lockdep.c:2024 trace_hardirqs_on" on the
linux-next@xxxxxxxxxxxxxxx mailing list (archived at
http://marc.info/?l=linux-next&m=120440556729954&w=2).

-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx
http://www.canb.auug.org.au/~sfr/

Attachment: pgp00000.pgp
Description: PGP signature