Date: Fri, 16 Nov 2007 08:57:17 +0100 From: "Heiko Wundram (Beenic)" <wundram@beenic.net> To: "Dennis Melentyev" <dennis.melentyev@gmail.com> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: Random data corruption with USB mass storage on 7.0-BETA2 Message-ID: <200711160857.17621.wundram@beenic.net> In-Reply-To: <b84edfa10711151134y5c83bc07gfe4c8dc3750cf444@mail.gmail.com> References: <200711150952.34276.wundram@beenic.net> <b84edfa10711151134y5c83bc07gfe4c8dc3750cf444@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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= ),=20 but I can format the stick as FAT32 (by using newfs_msdos on the device) an= d=20 still have the phone accept it, but when copying to the FAT32-formatted=20 device random data corruption still occurs, i.e. the same problem noted in = my=20 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 unmoun= t,=20 but the files being different. The file corruption that occurs is similar: random, but not completely,=20 because the differing file content comes at (somewhat) fixed offsets in the= =20 files. As I did not unplug the phone from the USB port while doing the FAT32 check= =20 run, the phone software never got a chance to actually access the memory=20 stick while doing the above (Symbian blocks all accesses to the stick when= =20 USB in file-transfer mode is active), so I should guess the corruption come= s=20 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 +=20 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=3D/dev/da0 of=3Ddisk.img bs=3D4k) 3) set that up as a memory disk, 4) mount that: lo and behold, the directory structure on the memory disk wa= s=20 just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IN= D=20 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, th= e=20 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=3Ddisk.img of=3D/dev/da0 b= s=3D4k) When I now access the memory stick from the phone (by unplugging it from US= B),=20 the files aren't corrupt. To finally test my hypothesis that this is a bug in the msdosfs-code, I=20 mounted the device directly after doing this (which had MEMSTICK.IND and=20 MEMSTICK_PRO.IND disappear again under the mount-point), copied some more=20 files over, unmounted, remounted, and the same corruption seen before=20 occurred again with the newly copied files (i.e., the phone software=20 complained about broken MP3s when unplugging the phone from USB later on).= =20 Testing the old files (which I put on the memory stick with the above=20 procedure) under the mount-point against the source showed them as being no= t=20 equal, but the phone did not complain about corrupted MP3s when trying to=20 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, m= ail=20 me, and I'll set that up somewhere as a download. =46or now, I'll personally try and see what changed between 6.2-STABLE and= =20 7.0-BETA2 in the msdosfs-code that breaks this. =2D-=20 Heiko Wundram Product & Application Development =2D------------------------------------ Office Germany - EXPO PARK HANNOVER =20 Beenic Networks GmbH Mail=C3=A4nder Stra=C3=9Fe 2 30539 Hannover =20 =46on +49 511 / 590 935 - 15 =46ax +49 511 / 590 935 - 29 Mobil +49 172 / 437 3 734 Mail wundram@beenic.net Beenic Networks GmbH =2D------------------------------------ Sitz der Gesellschaft: Hannover Gesch=C3=A4ftsf=C3=BChrer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711160857.17621.wundram>