Random data corruption with USB mass storage on 7.0-BETA2

Heiko Wundram (Beenic) wundram at beenic.net
Thu Nov 15 00:51:43 PST 2007

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 

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.

Heiko Wundram
Product & Application Development

More information about the freebsd-stable mailing list