From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 22:08:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B43961065672; Thu, 16 Apr 2009 22:08:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 484128FC14; Thu, 16 Apr 2009 22:08:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3GM835A016814; Thu, 16 Apr 2009 16:08:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E7AC43.8050901@samsco.org> Date: Thu, 16 Apr 2009 16:08:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <49BD117B.2080706@163.com> <200904161748.08402.jhb@freebsd.org> <49E7A8DF.9080902@samsco.org> <200904161804.42399.jhb@freebsd.org> In-Reply-To: <200904161804.42399.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:08:15 -0000 John Baldwin wrote: > On Thursday 16 April 2009 5:53:35 pm Scott Long wrote: >> John Baldwin wrote: >>> On Thursday 16 April 2009 5:32:52 pm Scott Long wrote: >>>> John Baldwin wrote: >>>>> Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? > This >>>>> lines up with your analysis in that it fixes a problem in the bounce >>> buffer >>>>> code that was introduced with the new USB stack (and only triggers when >>> the >>>>> USB code has to use a bounce buffer). >>>>> >>>> As a data point, most normal I/O is not going to trigger this bug, even >>>> if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can >>>> as well. Since memory is allocated from the top of the system, I think >>>> that the damage gets done early during boot, and then propagates out >>>> over time as the system becomes busier. >>> Hmm, are you sure regular I/O won't trigger it as well? All it takes is > for >>> any USB transfer that starts off within a page to get a page into a > non-zero >>> offset and later have a request >= PAGE_SIZE bounce. Since the VM is > going >>> to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would >>> break if it uses the bad bounce page I think. >>> >> Sorry, I knew what I meant but didn't say it that well. Once it gets >> triggered, it poisons that bounce page from thereon out, and any I/O >> will be affected. But the only I/O that will typically trigger it is >> GEOM scanning and O_DIRECT. > > Ah, ok. Actually, couldn't any USB request trigger it (so long as the source > buffer isn't page aligned?) E.g. if you malloc()'d a 16-byte buffer and used > it to receive some descriptor for the keyboard driver and malloc() used a > backing page > 4GB, wouldn't that bounce and end up breaking a bounce page? > It could, and if that's happening, then some proactive measures should be taken by the usb code to generate buffers that won't bounce. It would suck to have to go through the bounce code for every single keystroke or mouse movement. I haven't looked at the new usb code, though, and I thought that the old code did a contigmalloc of some sort to avoid this. Scott