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
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.
--
Heiko Wundram
Product & Application Development
More information about the freebsd-stable
mailing list