Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Feb 2010 00:46:06 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        Stephane LAPIE <stephane.lapie@darkbsd.org>
Cc:        freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer <julian@elischer.org>, freebsd-hardware@freebsd.org
Subject:   Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE
Message-ID:  <4B6B4E2E.2010902@icyb.net.ua>
In-Reply-To: <4B695CA3.50008@darkbsd.org>
References:  <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua>	<4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> <4B695CA3.50008@darkbsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B6B4E2E.2010902>