kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
jhb at freebsd.org
Tue May 12 18:26:51 UTC 2009
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 @ \
> 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
> 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).
More information about the freebsd-stable