One more .....
Willem Jan Withagen
wjw at withagen.nl
Fri Jul 16 10:38:41 PDT 2004
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
More information about the freebsd-current
mailing list