[zfs][hardware] Reproducible kernel panic in 8.0-STABLE

[Andriy Gapon]

on 03/02/2010 13:23 Stephane LAPIE said the following:
> 
> I just rebuilt a kernel with debugger options, and obtained the
> following output upon pulling out one disk :
> 
> Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock
> sched_switch() at sched_switch+0xf8
> mi_switch() at mi_switch+0x16f
> sleepq_timedwait() at sleepq_timedwait+0x42
> _cv_timedwait() at _cv_timedwait+0x129
> _sema_timedwait() at _sema_timedwait+0x55
> ata_queue_request() at ata_queue_request+0x526
> ata_controlcmd() at ata_controlcmd+0xa1
> ata_setmode() at ata_setmode+0xdc
> ad_init() at ad_init+0x27
> ad_reinit() at ad_reinit+0x48
> ata_reinit() at ata_reinit+0x268
> ata_conn_event() at ata_conn_event+0x49
> taskqueue_run() at taskqueue_run+0x93
> taskqueue_thread_loop() at taskqueue_thread_loop+0x46
> fork_exit() at fork_exit+0x118
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff80000aad30, rbp = 0 ---
> panic: sleeping thread
> cpuid = 2
> KDB: enter: panic
> [thread pid 12 tid 100008 ]
> Stopped at      kdb_enter+0x3d: movq    $0,0x4943d0(%rip)

Not sure if I can derive anything useful from here.
Someone with more expertise is needed.
One thing I noticed is that ata_conn_event and ata_reinit and some other
functions up the stack acquire state_mtx recursively, but the mutex is not
initialized with MTX_RECURSE.

Perhaps, indeed you would have a better luck with AHCI controller _and_ ahci(4)
driver.  It seems to handle dynamic coming and going of disks much better than
ata(4).

-- 
Andriy Gapon