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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
