Date: Sun, 26 Oct 2014 10:54:28 +0100 From: Guido Falsi <madpilot@FreeBSD.org> To: FreeBSD FS <freebsd-fs@FreeBSD.org> Cc: Glen Barber <gjb@FreeBSD.org>, freebsd-stable@FreeBSD.org Subject: Re: panic: detach with active requests on 10.1-RC3 Message-ID: <544CC4D4.7040203@FreeBSD.org> In-Reply-To: <544BC990.4030700@madpilot.net> References: <544A538F.6060202@FreeBSD.org> <544BBB85.2020909@madpilot.net> <544BC990.4030700@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/25/14 18:02, Guido Falsi wrote: > On 10/25/14 17:02, Guido Falsi wrote: >> On 10/24/14 15:26, Guido Falsi wrote: >>> Hi, >>> >>> I'm making some experiments with 10.1-RC3 on alix boards as hardware >>> using NanoBSD. >>> >>> By mounting and umounting UFS filesystems I have seen umount constantly >>> hanging hard in a deadlock. I have tested on two boards with two >>> distinct compactflash disks with same results. This was not happening >>> with 10.0-RELEASE. >>> >>> I have build a 10.1-RC3 kernel with full debugging and caused the >>> problem to happen, I got this: >>> >>> root@qtest:~ [0]# umount /cfg >>> panic: detach with active requests >>> KDB: stack backtrace: [...] > I must admit I am out of ideas. > I bisected commits and finally found out this happens starting with r268815, which MFCed r268205. It is related to trim support, in fact disabling trim on the filesystm "fixes" it. I filed bug #194606 on bugzilla [1] to further track this issue, if anyone is interested. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194606 -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?544CC4D4.7040203>