This is a discussion on Re: Random data corruption with USB mass storage on 7.0-BETA2 - FreeBSD ; On Thu, Nov 15, 2007 at 09:52:34AM +0100, Heiko Wundram (Beenic) wrote: > Hey all! > > While trying to upload some music to my mobile phone, I stumbled across the > following odd behaviour when uploading files to an ...
On Thu, Nov 15, 2007 at 09:52:34AM +0100, Heiko Wundram (Beenic) wrote:
> Hey all!
> While trying to upload some music to my mobile phone, I stumbled across the
> following odd behaviour when uploading files to an SD-card (inserted into my
> Sony Ericsson M600i) which is connected via USB as a mass-storage device:
> addr 2> on uhub0
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: < M600i 1.0> Removable Direct Access SCSI-0 device
> da0: 1.000MB/s transfers
> da0: 59MB (121821 512 byte sectors: 64H 32S/T 59C)
> The card is formatted as FAT (by the phone software), and I can mount it with
> a plain "mount -t msdosfs /dev/da0 /mnt" without any kind of problems, except
> that directories that should be there, at least as displayed by the File
> Manager on the phone, aren't present under the mount point. There is no
> output to dmesg on the mounting (besides the GEOM label for the stick being
> When copying files to the device, the phone displays that a transfer is taking
> place, and after finishing the transfer, comparing files on the mountpoint to
> the source files shows them as being equal. When I then unmount the device
> (which also runs cleanly, without any further output to dmesg except the
> reappearance of the GEOM label) and remount it, the copied files appear under
> the mount-point, but comparing the files on the mount-point against the
> source files shows them as being different. The sizes and modification dates
> are equal, though, and most of a file is correct, but non-deterministically
> every 16k or similar a stream of random bytes appears.
> When I do the same transfer from a 6.2-STABLE (last csupped some two months
> ago), the directories the phone reports appear under the mount-point, and the
> same transfer works properly (i.e., uploading the file, unmounting,
> remounting and comparing show the files as being the same, and playing the
> file on the phone works, and doesn't contain corruption artefacts).
> The 6.2-STABLE shows similar information on the device in dmesg (esp. the
> H/S/C info).
> 6.2-STABLE is a plain GENERIC kernel, with atapicam loaded (and some other
> device drivers for sound and Bluetooth), 7.0-BETA2 is a slightly adapted
> GENERIC (with SCHED_4BSD replaced with SCHED_ULE and SMP support removed)
> also with atapicam loaded (and some other device drivers for sound and
> I'll try to do some digging into the changes made to msdosfs between
> 6.2-STABLE and 7.0-BETA2 some time later on, but if anybody else is seeing
> this behaviour too or wants me to produce more debugging info on this (esp.
> some msdosfs debugging infos), feel free to send me a mail, and I'll try to
> get this done some time during the day.
I'm not sure that it is msdosfs' fault. Last night I also corrupted my
FAT based USB memory stick. But I used mtools and did not mount it. That
was on 8-current though. I have not looked into it because there are
other higher priority stuff also not working. :-/
John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"