Crash dump problem - sleeping thread owns a non-sleepable lock
during crash dump write
Terry Kennedy
TERRY at tmk.com
Fri May 14 18:37:44 UTC 2010
> Oops, youre right that other CPUs are running.
>
> The stop_cpus() call is only made if kdb is entered. doadump() is called
> out of boot() which comes later. At Isilon weve been running with a patch
> that does stop_cpus() pretty close to the front of panic(9).
This is interesting, and changing the behavior will probably allow the
crash dump for the original problem (repeatable crash in the bce driver)
to be analyzed.
At the moment, I'm more interested in dealing with the original problem
of the crash in bce. Right now, I'm running this vendor's product under
Linux compatibility mode. The vendor is hard at work building a native
FreeBSD version of their product. One of two things is going to happen
here: 1) the crash doesn't happen in native mode due to different code
paths being taken, and I lose the ability to reproduce the crash when the
box goes into production, or 2) the crash continues to happen and the ven-
dor gets the impression FreeBSD is unstable and not worth supporting. I'd
like to avoid that.
So, any ideas on how to troubleshoot the panic in bce?
Thanks,
Terry Kennedy http://www.tmk.com
terry at tmk.com New York, NY USA
More information about the freebsd-current
mailing list