On Sun, 7 Sep 2003, John-Mark Gurney wrote: > > Hmmm. I just thought of something. Now is the data corrupt still correupt > on another system? What I mean is did the data get written properly, but > just isn't being read back from the media correctly. Unless you are > coping a file larger than memory size, the cmp just pulls it from memory, > not from the media. The umount/mount forces a flush of the cache, and so > attempts to read from the media. I'm also suffering (probably) the same problem. In my case, the drive is a Sony memory stick slot on a PCG-U1 laptop; connection to the system is via OHCI. For my usage, it's definitely a _read_ phenomenon - I'm creating images on the memory stick in my P800 phone/camera and trying to read them via an msdosfs mount on the laptop. Retrieving them via Windows demonstrates that the images are good; reading them under FreeBSD shows them corrupt at a _file_ offset of 4096 decimal. I tried copying the whole filesystem with 'dd', then using 'mdconfig' to mount the resulting image, eg.: dd if=/dev/da0s1 of=stickfile4 bs=32k mdconfig -a stickfile4 mount -t msdos /dev/md0 /mnt With a blocksize to 'dd' of 512, 8k it worked fine (no corruption); with a block size of 100k the files were corrupt (but in different places compared to mounting the memorystick directly). Using a block size of 32k, it copied for a minute or so and then the machine hung totally (repeatable across two attempts). In terms of dates, I'm now running with -current of 4th september; this problem was also present in a kernel built on August 22nd. It was working OK with whatever kernel I was running on 23rd May (based on timestamps on some files I wrote on the PC). In fact, up until around that time this setup didn't work at all: the internal OCHI port that connects to the memory stick slot always reported 'device problem' and wouldn't find the device (the second OHCI controller that is brought out to conventional sockets worked OK). One system update that I did suddenly made everything work, then a month or two later this problem arrived.Received on Sun Sep 07 2003 - 13:01:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC