From owner-freebsd-fs@FreeBSD.ORG Sun Oct 26 15:27:57 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C06A299 for ; Sun, 26 Oct 2014 15:27:57 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id D4A722E3 for ; Sun, 26 Oct 2014 15:27:56 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6C2AD20E7088C; Sun, 26 Oct 2014 15:27:54 +0000 (UTC) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 6072020E70886 for ; Sun, 26 Oct 2014 15:27:54 +0000 (UTC) Message-ID: <544D137A.7010006@multiplay.co.uk> Date: Sun, 26 Oct 2014 15:30:02 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: panic: detach with active requests on 10.1-RC3 References: <544A538F.6060202@FreeBSD.org> <544BBB85.2020909@madpilot.net> <544BC990.4030700@madpilot.net> <544CC4D4.7040203@FreeBSD.org> In-Reply-To: <544CC4D4.7040203@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------080209070109080503070307" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 15:27:57 -0000 This is a multi-part message in MIME format. --------------080209070109080503070307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 26/10/2014 09:54, Guido Falsi wrote: > 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 Nice work Guido, can you try the attached patch and see if that fixes it please? Regards Steve --------------080209070109080503070307 Content-Type: text/plain; charset=windows-1252; name="cf_erase.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cf_erase.patch" Index: sys/cam/ata/ata_da.c =================================================================== --- sys/cam/ata/ata_da.c (revision 273157) +++ sys/cam/ata/ata_da.c (working copy) @@ -1470,6 +1470,8 @@ ada_cfaerase(struct ada_softc *softc, struct bio * uint64_t lba = bp->bio_pblkno; uint16_t count = bp->bio_bcount / softc->params.secsize; + bioq_remove(&softc->trim_queue, bp); + cam_fill_ataio(ataio, ada_retry_count, adadone, --------------080209070109080503070307--