Date: Tue, 12 May 2009 11:44:20 -0400 From: John Baldwin <jhb@freebsd.org> To: Riccardo Torrini <riccardo.torrini@esaote.com> Cc: scottl@freebsd.org, siedar@nplay.pl, freebsd-stable@freebsd.org Subject: Re: kern/130330: [mpt] [panic] Panic and reboot machine MPT ... Message-ID: <200905121144.21406.jhb@freebsd.org> In-Reply-To: <20090512152014.GN21112@tiger.fi.esaote.it> References: <20090507155012.GW21112@tiger.fi.esaote.it> <200905111407.20195.jhb@freebsd.org> <20090512152014.GN21112@tiger.fi.esaote.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 May 2009 11:20:14 am Riccardo Torrini wrote: > On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote: > > > Do you have kernel crashdumps enabled and a swap partition? > > If so, do you happen to have any files in /var/crash? > > Yes, but I'm unable to produce a crash dump :-( > Tryed even with voodoo, added and removed options to > kernel (kdb, gdb, ddb, invariants, ...). Instead of > going to db> now it panic-and-freeze with: > > cpuid = 0 > Uptime: 2m16s > panic: _mtx_lock_sleep: recursed on non-recursive mutex \ > mpt @ /usr/src/sys/cam/cam_periph.h:182 > > (above lines get repeated a lot with same uptime, then freeze) > > > Still trying other combinations... If you can get a stack trace, that would be most helpful. My guess is that the recovery thread is holding the mpt lock and calling some CAM routine which attempts to relock it via cam_periph_lock(). A stack trace would be most telling in that case. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905121144.21406.jhb>