Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 May 2009 14:26:43 -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:  <200905121426.43467.jhb@freebsd.org>
In-Reply-To: <20090512161025.GO21112@tiger.fi.esaote.it>
References:  <20090507155012.GW21112@tiger.fi.esaote.it> <200905121144.21406.jhb@freebsd.org> <20090512161025.GO21112@tiger.fi.esaote.it>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 May 2009 12:10:25 pm Riccardo Torrini wrote:
> On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
> 
> > 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.
> 
> Rebooted, inserted 2nd disk (copied by hand, sorry for delay)
> 
> mpt0: External Bus Reset Detected
> mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed
> mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed (yes, two times)
> Kernel page fault with the following non-sleepable lock held:
> exclusive sleep mutex mpt r = 0 (0xc4001004) locked @ \
> 	/usr/src/sys/cam/cam_xpt.c:7153
> KBD: enter: witness_warn
> [ thread pid 19 tid 100018 ]
> Stopped at kdb_enter_why+0x3a: movl $0,kbd_why
> 
> db> bt
> Tracing pid 19 tid 100018 td 0xc3fb8880
> [...]
> --- trap 0xc, eip = 0xc0438f4e, esp = 0xc43b2b98, ebp = 0xc43b2bb0 ---
> xpt_done(c404f400,c0719000,5,5,0,...) at xpt_done+0x1b
> xpt_scan_bus(c3f39a80,c4045400,c06cfa7a,c072f824,c4011914,...) \
> 	at xpt_scan_bus+0x39f
> camisr_runqueue(c4001004,0,c06cfa7a,1bf1,0,...) \
> 	at camisr_runqueue+0x38a
> camisr(0,0,c06e99fb,4b6,c3f39a68,...) at camisr+0x10d
> ithread_loop()
> fork_exit()
> fork_trampoline()
> 
> 
> Still at db> prompt  =)

Hmm, this is a different panic. :(  You could perhaps try bzero()'ing the ccb 
before calling xpt_setup_ccb() in mpt_raid_thread() but the old code didn't 
do that either (it just used M_WAITOK w/o M_ZERO).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905121426.43467.jhb>