From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 09:05:24 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E84616A4BF for ; Sat, 13 Sep 2003 09:05:24 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9E76443FAF for ; Sat, 13 Sep 2003 09:05:23 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 2205 invoked by uid 1000); 13 Sep 2003 16:05:22 -0000 Date: Sat, 13 Sep 2003 09:05:22 -0700 (PDT) From: Nate Lawson To: John-Mark Gurney In-Reply-To: <20030913072325.GT39788@funkthat.com> Message-ID: <20030913090314.T2176@root.org> References: <20030806213504.S74720@root.org> <03Aug8.140932nzst.119071@homer.fire.org.nz> <20030807200629.G77081@root.org> <1060346467.33258.3.camel@localhost> <1060413953.33258.18.camel@localhost> <20030822094621.T4440@root.org> <3F629E00.7010708@fud.org.nz> <20030913072325.GT39788@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: USB da(4) quirks deprecated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 13 Sep 2003 16:05:24 -0000 On Sat, 13 Sep 2003, John-Mark Gurney wrote: > Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200: > > I have just got around to trying this pen-drive again and have been > > trying tracking down data corruptions. If I mount the drive, write a > > file, umount/mount again the file is different. > > > > Using cmp I have found that there are consistent blocks of nulls in the > > written file where data should be. The block is always 0xfff bytes long > > and starts at 0x3000. I have tried many files and the offsets are > > always the same. All the other data in the file is correct and at the > > right location. > > > > 0x3000 -> 0x3fff > > 0x7000 -> 0x7fff > > 0xb000 -> 0xbfff > > 0xf000 -> 0xffff > > 0x13000 -> 0x13fff > > ... and so on until the end of the file ... > > > > Any suggestions? This almost certainly has nothing to do with quirks. > Is this on an ohci controller? > > I'm trying to track down mbr's problem also that appears to do the > same thing. Have you tried doing an fstat before umounting the fs? I think you mean fsync? > (There is a bug in msdosfs that doesn't sync the disk before unmount > completes.) > > This is wierd in that it's the second page of the second transfer. > The ohci can do up to 8k transfers in one TD, and then chain the TD's > together if a larger block sized is used. Maybe you can provide him a patch that limits transfers to a single page as multi-page descriptors might be broken on his controller. -Nate