Re: Random data corruption with USB mass storage on 7.0-BETA2
Hello Heiko, Yes, you really have different issue. From now on, I have no more ideas. Hope you'll find the root of the problem. 2007/11/16, Heiko Wundram (Beenic) <[EMAIL PROTECTED]>: > Am Donnerstag, 15. November 2007 20:34:57 schrieb Dennis Melentyev: > > You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show > > this info. > > It's a FAT16 when formatted by the phone software (I checked that initially), > but I can format the stick as FAT32 (by using newfs_msdos on the device) and > still have the phone accept it, but when copying to the FAT32-formatted > device random data corruption still occurs, i.e. the same problem noted in my > last mail: > > 1) format device as FAT32 with newfs_msdos, > 2) mount, > 3) copy files, > 4) unmount, (and don't plug the USB out) > 5) mount, > 6) checking files shows the metadata as being the same as before the unmount, > but the files being different. > > The file corruption that occurs is similar: random, but not completely, > because the differing file content comes at (somewhat) fixed offsets in the > files. > > As I did not unplug the phone from the USB port while doing the FAT32 check > run, the phone software never got a chance to actually access the memory > stick while doing the above (Symbian blocks all accesses to the stick when > USB in file-transfer mode is active), so I should guess the corruption comes > purely from the host system. > > > Had the same problem with SE 64Mb card in K750i. It turned out that SE > > creates FAT12 on a 32+Mb disk, which is not supposed to be an option. > > The K750i is not comparable, as the W600i is UIQ-based (i.e. Symbian + > extras), whereas the K750i is not. > > > PS. To just make it work - just re-format it and restore folders > > structure. But please, create a filesystem dump first, to let > > developers decide is it a fault of SE phone or MSDOSFS code. > > After you talked about filesystem dumps, you got me an idea: > > 1) format the memory stick with the phone software > 2) make a dump with dd (dd if=/dev/da0 of=disk.img bs=4k) > 3) set that up as a memory disk, > 4) mount that: lo and behold, the directory structure on the memory disk was > just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IND > and MEMSTICK_PRO.IND were there in the root of the mount-point) > 5) copy my files over to the mount point, > 6) unmount the memory disk, > 7) mount the memory disk, check files against the source, lo and behold, the > files were equal (i.e., not corrupted during copy), > 8) unmount the memory disk, > 9) remove the memory disk, > 10) copy the disk image back to the phone (dd if=disk.img of=/dev/da0 bs=4k) > > When I now access the memory stick from the phone (by unplugging it from USB), > the files aren't corrupt. > > To finally test my hypothesis that this is a bug in the msdosfs-code, I > mounted the device directly after doing this (which had MEMSTICK.IND and > MEMSTICK_PRO.IND disappear again under the mount-point), copied some more > files over, unmounted, remounted, and the same corruption seen before > occurred again with the newly copied files (i.e., the phone software > complained about broken MP3s when unplugging the phone from USB later on). > Testing the old files (which I put on the memory stick with the above > procedure) under the mount-point against the source showed them as being not > equal, but the phone did not complain about corrupted MP3s when trying to > play them, so basically on the "real" medium the data was still intact. > > If anybody wants to test with a dump of the filesystem or just more info, mail > me, and I'll set that up somewhere as a download. > > For now, I'll personally try and see what changed between 6.2-STABLE and > 7.0-BETA2 in the msdosfs-code that breaks this. > > -- > Heiko Wundram > Product & Application Development > - > Office Germany - EXPO PARK HANNOVER > > Beenic Networks GmbH > Mailänder Straße 2 > 30539 Hannover > > Fon+49 511 / 590 935 - 15 > Fax+49 511 / 590 935 - 29 > Mobil +49 172 / 437 3 734 > Mail [EMAIL PROTECTED] > > > Beenic Networks GmbH > - > Sitz der Gesellschaft: Hannover > Geschäftsführer: Jorge Delgado > Registernummer: HRB 61869 > Registergericht: Amtsgericht Hannover > -- Dennis Melentyev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random data corruption with USB mass storage on 7.0-BETA2
Am Donnerstag, 15. November 2007 20:34:57 schrieb Dennis Melentyev: > You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show > this info. It's a FAT16 when formatted by the phone software (I checked that initially), but I can format the stick as FAT32 (by using newfs_msdos on the device) and still have the phone accept it, but when copying to the FAT32-formatted device random data corruption still occurs, i.e. the same problem noted in my last mail: 1) format device as FAT32 with newfs_msdos, 2) mount, 3) copy files, 4) unmount, (and don't plug the USB out) 5) mount, 6) checking files shows the metadata as being the same as before the unmount, but the files being different. The file corruption that occurs is similar: random, but not completely, because the differing file content comes at (somewhat) fixed offsets in the files. As I did not unplug the phone from the USB port while doing the FAT32 check run, the phone software never got a chance to actually access the memory stick while doing the above (Symbian blocks all accesses to the stick when USB in file-transfer mode is active), so I should guess the corruption comes purely from the host system. > Had the same problem with SE 64Mb card in K750i. It turned out that SE > creates FAT12 on a 32+Mb disk, which is not supposed to be an option. The K750i is not comparable, as the W600i is UIQ-based (i.e. Symbian + extras), whereas the K750i is not. > PS. To just make it work - just re-format it and restore folders > structure. But please, create a filesystem dump first, to let > developers decide is it a fault of SE phone or MSDOSFS code. After you talked about filesystem dumps, you got me an idea: 1) format the memory stick with the phone software 2) make a dump with dd (dd if=/dev/da0 of=disk.img bs=4k) 3) set that up as a memory disk, 4) mount that: lo and behold, the directory structure on the memory disk was just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IND and MEMSTICK_PRO.IND were there in the root of the mount-point) 5) copy my files over to the mount point, 6) unmount the memory disk, 7) mount the memory disk, check files against the source, lo and behold, the files were equal (i.e., not corrupted during copy), 8) unmount the memory disk, 9) remove the memory disk, 10) copy the disk image back to the phone (dd if=disk.img of=/dev/da0 bs=4k) When I now access the memory stick from the phone (by unplugging it from USB), the files aren't corrupt. To finally test my hypothesis that this is a bug in the msdosfs-code, I mounted the device directly after doing this (which had MEMSTICK.IND and MEMSTICK_PRO.IND disappear again under the mount-point), copied some more files over, unmounted, remounted, and the same corruption seen before occurred again with the newly copied files (i.e., the phone software complained about broken MP3s when unplugging the phone from USB later on). Testing the old files (which I put on the memory stick with the above procedure) under the mount-point against the source showed them as being not equal, but the phone did not complain about corrupted MP3s when trying to play them, so basically on the "real" medium the data was still intact. If anybody wants to test with a dump of the filesystem or just more info, mail me, and I'll set that up somewhere as a download. For now, I'll personally try and see what changed between 6.2-STABLE and 7.0-BETA2 in the msdosfs-code that breaks this. -- Heiko Wundram Product & Application Development - Office Germany - EXPO PARK HANNOVER Beenic Networks GmbH Mailänder Straße 2 30539 Hannover Fon+49 511 / 590 935 - 15 Fax+49 511 / 590 935 - 29 Mobil +49 172 / 437 3 734 Mail [EMAIL PROTECTED] Beenic Networks GmbH - Sitz der Gesellschaft: Hannover Geschäftsführer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random data corruption with USB mass storage on 7.0-BETA2
You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show this info. Had the same problem with SE 64Mb card in K750i. It turned out that SE creates FAT12 on a 32+Mb disk, which is not supposed to be an option. Some time ago this was discussed, but I was unable to provide a dump from such card (have no such card anymore). PS. To just make it work - just re-format it and restore folders structure. But please, create a filesystem dump first, to let developers decide is it a fault of SE phone or MSDOSFS code. PPS. http://docs.FreeBSD.org/cgi/mid.cgi?b84edfa10707011305g4cffb298q70c3507f75121799 2007/11/15, Heiko Wundram (Beenic) <[EMAIL PROTECTED]>: > 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: 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 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Dennis Melentyev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random data corruption with USB mass storage on 7.0-BETA2
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: 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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Random data corruption with USB mass storage on 7.0-BETA2
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: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
