From owner-freebsd-stable@FreeBSD.ORG Fri Nov 16 07:56:24 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB80816A418 for ; Fri, 16 Nov 2007 07:56:24 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6792713C467 for ; Fri, 16 Nov 2007 07:56:24 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-30-249.net-htp.de [89.182.30.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id AF874A44529; Fri, 16 Nov 2007 08:50:15 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: "Dennis Melentyev" Date: Fri, 16 Nov 2007 08:57:17 +0100 User-Agent: KMail/1.9.7 References: <200711150952.34276.wundram@beenic.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711160857.17621.wundram@beenic.net> Cc: FreeBSD Stable Subject: Re: Random data corruption with USB mass storage on 7.0-BETA2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 07:56:24 -0000 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