RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write

From: Terry Kennedy <TERRY_at_tmk.com>
Date: Fri, 14 May 2010 14:02:47 -0400 (EDT)
> 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
Received on Fri May 14 2010 - 16:37:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC