Random data corruption with USB mass storage on 7.0-BETA2

[John Hay]

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:
> 
> -----
> ...
> umass0: <Sony Ericsson Mobile Communications M600i, class 2/0, rev 2.00/0.00, 
> 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 
> removed).
> 
> 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 
> bluetooth).
> 
> 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
-- 
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org