From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 21:53:41 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 E057A106566C; Thu, 16 Apr 2009 21:53:41 +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 8F98D8FC1A; Thu, 16 Apr 2009 21:53:41 +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 n3GLrZPI016717; Thu, 16 Apr 2009 15:53:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E7A8DF.9080902@samsco.org> Date: Thu, 16 Apr 2009 15:53:35 -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> <200904161624.51920.jhb@freebsd.org> <49E7A404.5090208@samsco.org> <200904161748.08402.jhb@freebsd.org> In-Reply-To: <200904161748.08402.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.6 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 21:53:42 -0000 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. Scott