spin lock sched lock held by 0xffffff007b712250 for > 5 seconds

[Willem Jan Withagen]

From: "John Baldwin" <jhb at FreeBSD.org>
> On Friday 16 July 2004 12:21 pm, Robert Watson wrote:
> > On Fri, 16 Jul 2004, Willem Jan Withagen wrote:
> > > After todays kernelbuild the system seem to be a lot better...
> > > It can take quite some buildworld abuse, but still:
> > >
> > > spin lock sched lock held by 0xffffff007b712250 for > 5 seconds
> > > panic: spin lock held too long
> > > cpuid = 1;
> > > KDB: enter: panic
> > >
> > > But I'm not shure what I could/should do now, since the KDB
> > > introduction.  Normally I'd expect to see:  db>
> >
> > We have trouble entering the debugger when in a critical section/and or
> > have sched_lock held -- I think this is because we try to halt the other
> > CPUs and that gets nastily stuck in some form.  We need to fix this.
> >
> > This could well be a symptom of some of the other hangs we've been seeing,
> > and I've seen similar things on my test box with preemption enabled.
>
> You can hack sys/i386/include/smptests.h (or smptest.h, whichever it is) and
> comment out CPUSTOP_ONDDBREAK as a hack.  I did that recently for some
> debugging.

This is i386 only .....
I'm running in 84bit mode.

But in all this is a nice suggestion, to see if the same thing will cause so
many crashes when running in native 32bit-i386 mode.

If it does the same there, would that mean a hardware problem??
Or is i386 much more stable?

--WjW