freebsd stable - Feb 2010 - [zfs][hardware] Reproducible kernel panic in 8.0-STABLE

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

Andriy Gapon wrote:
> 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).
I just moved half of the "flaky" drives on an AHCI controller.

This seems to work much better, starting with disk detection issues 
being solved, and hotplug working exactly like SCSI does. It does 
require using camcontrol to recognize the disks again, but that much is 
not exactly a problem.

Although I'm probably dreaming : Did anyone heard about AHCI controllers 
beside the on-board ones ?

Thanks to everyone for their advice.
-- 
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100207/c15cfa51/signature.pgp