Re: A bug?

[Paul M. <le...@li...>]

On Sat, Oct 06, 2007 at 09:11:08PM +0100, Adrian McMenamin wrote:
> On Thu, 2007-10-04 at 19:17 +0900, Paul Mundt wrote:
> > On Sat, Sep 15, 2007 at 12:19:07AM +0100, Adrian McMenamin wrote:
> > > I have just turned on a whole host of debugging stuff in my kernel and
> > > now it won't boot because of the issue below - is this anything I need
> > > to formally file?
> > > 
> > > [    0.186328] ------------[ cut here ]------------
> > > [    0.191626] Badness at kernel/fork.c:1000
> > > [    0.196220] 
> > > [    0.197930] Pid : 0, Comm:              swapper
> > > [    0.203140] PC is at copy_process+0x13d2/0x1bc0
> > > [    0.208336] PC  : 8c017012 SP  : 8c2d9e78 SR  : 40008101 TEA :
> > > 00000000    Not tainted
> > 
> > Ho hum. So according to SR, hardirqs _are_ enabled, but the lockdep
> > accounting is confused:
> > 
> > > [    0.284087] [<8c03d860>] trace_hardirqs_off+0x0/0xa0
> > 
> > in that they're implied off here. So there's at least something slightly
> > broken with the irqflags tracing, it's also broken on SH-2 (in a
> > different path completely) whilst attempting to do lock correctness
> > proving, so it will need a bit more debugging.
> > 
> > You may just want to disable some of the lockdep related debug options to
> > get it booting in the interim. Also, if you could post your .config, it
> > would be helpful, as I've not seen this particular badness anywhere.
> 
> I cannot get seem to get this error to reappear, because other ones get
> in the way:
> 
> [    0.195810] Pid : 6, Comm:              khelper
> [    0.201013] PC is at resume_userspace+0xc/0x14

Yes, it looks like the lockdep lock proving is unhappy with some of the
irqflags trace points. I'm able to reproduce this, so I'll start doing
some more debugging on it..