Date: Sat, 13 Sep 2003 00:23:25 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Andrew Thompson <andy@fud.org.nz> Cc: Nate Lawson <nate@root.org> Subject: Re: USB da(4) quirks deprecated Message-ID: <20030913072325.GT39788@funkthat.com> In-Reply-To: <3F629E00.7010708@fud.org.nz> References: <20030806213504.S74720@root.org> <03Aug8.140932nzst.119071@homer.fire.org.nz> <20030807200629.G77081@root.org> <1060346467.33258.3.camel@localhost> <20030808084040.C78146@root.org> <1060413953.33258.18.camel@localhost> <20030822094621.T4440@root.org> <3F629E00.7010708@fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
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?
(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.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030913072325.GT39788>