One more .....

From: "Willem Jan Withagen" <wjw_at_withagen.nl>
To: "Robert Watson" <rwatson_at_freebsd.org>
Cc: <freebsd-current_at_freebsd.org>
Sent: Friday, July 16, 2004 6:33 PM
Subject: Re: spin lock sched lock held by 0xffffff007b712250 for > 5 seconds


> From: "Robert Watson" <rwatson_at_freebsd.org>
> > 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.
> 
> To be honest, it is a lot better than at the beginning of the week.
> Anything I can do to help debug either of them??
> Suggestions where/what to look for?

panic: process 82471(sh):2 holds Giant but isn't blocked on a lock

cpuid = 1;
KDB: enter: panic

Is there any purpose in reporting these crashes this way???

--WjW