From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 23:58:00 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A839F4F; Sun, 22 Sep 2013 23:58:00 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E27D20B4; Sun, 22 Sep 2013 23:58:00 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 29D7B28435; Sun, 22 Sep 2013 16:52:45 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id 09F3828434; Sun, 22 Sep 2013 16:52:45 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id 6E2871679862; Sun, 22 Sep 2013 16:52:33 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21055.33473.385334.574140@gargle.gargle.HOWL> Date: Sun, 22 Sep 2013 16:52:33 -0700 To: Andriy Gapon Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: <520202E5.30300@FreeBSD.org> References: <20967.760.95825.310085@gargle.gargle.HOWL> <51E80B30.1090004@FreeBSD.org> <20968.10645.880772.30501@gargle.gargle.HOWL> <520202E5.30300@FreeBSD.org> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@FreeBSD.org, hartzell@alerce.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 23:58:00 -0000 Andriy Gapon writes: > on 18/07/2013 20:44 George Hartzell said the following: > > Andriy Gapon writes: > > > on 17/07/2013 23:47 George Hartzell said the following: > > > > How should I move forward with this? > > > > > > Could you please try to reproduce this problem using a kernel built with > > > INVARIANTS options? > > > > I added INVARIANT_SUPPORT and INVARIANTS options to the GENERIC > > kernel, rebuilt it, installed it and running through my "test case" > > generated a lot of invalid flac files. I"m not sure what the options > > are/were supposed to do though, it looks like they generally lead to > > KASSERTS, which lead to abort()'s. Nothing in /var/log/messages or on > > the console. > > George, > > do you have anything new on this issue? > > Could you please try the following patch? > http://people.freebsd.org/~avg/zfs-putpages.diff > > I expect it to not really fix the issue, but it may help to narrow it down. > Please keep INVARIANTS. > Thank you. > -- > Andriy Gapon Hi Andriy, This weekend I built up a system using the 10.0 beta 2 dvd, then updated /usr/src from head. I grabbed a fresh copy of your patch this afternoon. I applied your patch with no problems. I was unable to build a new kernel though, you have one reference to m->busy, where m is a vm_page_t (if I remember correctly). I dug around a bit and decided that you meant m->busy_lock, which let me build a usable kernel. It looks like INVARIANTS and INVARIANT_SUPPORT are included in the GENERIC conf file. I ran through my test routine with the original system and was able to reproduce the problem. After building and installing a kernel with your patch I was still able to trigger the problem. If anything it was worse (sample size = 1, I know...). I did not see any interesting output in /var/log/messages or to the console or anywhere else obvious. I'm not sure what to do next. It's likely that my m->busy to m->busy_lock change was not The Right Thing to Do and might have invalidated what the patch was trying to do. In any case, I now have a system running HEAD and should be able to test things more easily. Thanks for the help, g.