Date: Fri, 14 May 2010 14:02:47 -0400 (EDT) From: Terry Kennedy <TERRY@tmk.com> To: Matthew Fleming <matthew.fleming@isilon.com> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write Message-ID: <01NN3XTJDNMS006UN1@tmk.com> In-Reply-To: "Your message dated Fri, 14 May 2010 08:42:44 -0700" <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@tmk.com New York, NY USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01NN3XTJDNMS006UN1>