kern/130330: [mpt] [panic] Panic and reboot machine MPT ...

[Riccardo Torrini]

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  =)


-- 
Riccardo.