Interesting, yet stupid test case

[Sean Bruno]

Was able to get mfi to detonate (via CAM) today on stable/9 

At the loader prompt, physically remove some amount of drives (in my
case drives 0-5, as 6-11 are my zroot).  Boot up into single user via
boot -s

System will attempt to process all the events in the controller on boot
up and die violently.  :-)


(noperiph:mfi0:0:1:-1): rescan already queued
panic: mutex MFI I/O lock not owned at ../../../cam/cam_xpt.c:4684
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame
0xffffff9fee9c7690
kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff9fee9c7750
panic() at panic+0x1d8/frame 0xffffff9fee9c7850
_mtx_assert() at _mtx_assert+0xdc/frame 0xffffff9fee9c7860
xpt_release_device() at xpt_release_device+0x28/frame 0xffffff9fee9c7880
xpt_release_path() at xpt_release_path+0x1a/frame 0xffffff9fee9c78a0
xpt_free_path() at xpt_free_path+0x11/frame 0xffffff9fee9c78c0
xpt_rescan() at xpt_rescan+0xf9/frame 0xffffff9fee9c78f0
mfip_cam_rescan() at mfip_cam_rescan+0x17e/frame 0xffffff9fee9c7930
mfi_handle_evt() at mfi_handle_evt+0x2bc/frame 0xffffff9fee9c79a0
taskqueue_run_locked() at taskqueue_run_locked+0x93/frame
0xffffff9fee9c7a00
taskqueue_run() at taskqueue_run+0x3d/frame 0xffffff9fee9c7a20
intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame
0xffffff9fee9c7a50
ithread_loop() at ithread_loop+0xac/frame 0xffffff9fee9c7aa0
fork_exit() at fork_exit+0x135/frame 0xffffff9fee9c7af0
fork_trampoline() at fork_trampoline+0xe/frame 0xffffff9fee9c7af0
--- trap 0, rip = 0, rsp = 0xffffff9fee9c7bb0, rbp = 0 ---
Uptime: 5s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20130819/37e73ccb/attachment.sig>