Date: Sun, 07 Feb 2010 11:44:49 +0900 From: Stephane LAPIE <stephane.lapie@darkbsd.org> To: Andriy Gapon <avg@icyb.net.ua> 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: <4B6E2921.60403@darkbsd.org> In-Reply-To: <4B6B4E2E.2010902@icyb.net.ua> References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> <4B695CA3.50008@darkbsd.org> <4B6B4E2E.2010902@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktuKSQACgkQ24Ql8u6TF2Mi0wCeMGhdcjKdsyf7TBUyBF1L2n/4 WH8Anjbf3lVlT2hX7D8dABVqck5WAdPv =DwuS -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B6E2921.60403>