On Mon, Apr 11, 2005 at 10:14:14PM -0400, Tim Howe wrote: > Brooks Davis <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 11, 2005 at 05:24:15PM -0400, Tim Howe wrote: > > > > > Reproducibly, if I begin copying data to a [...] CF card [...] it > > > works for a while, then freezes the system. > > > > It is quite likely that 5.4 fixed your problem. > > Unfortunately not. I was able, having mounted the filesystem with no > synchronization options, to copy 171MiB of data onto it and unmount. > However when I re-mounted it with the same options and tried to copy > 71MiB more, it again froze midway through.
Sounds like you should file a PR about the issue. Are you sure the file system in question is OK? There were some msdosfs corruption bugs fixed recently. > Everything else (X11, sound, printing, input) seems to be working > perfectly with 5.4, but I did notice something new and strange with > regard to umass. I still have to run "true > /dev/da0" to get the slice > to show up, but now I get the following: > > [1042] ~ # true > /dev/da0 > [1043] ~ # camcontrol rescan 0 > Re-scan of bus 0 was successful > [1044] ~ # ls -l /dev/da0* > crw-r----- 1 root operator 4, 21 Apr 11 21:45 /dev/da0 > crw-r----- 1 root operator 4, 28 Apr 11 21:45 /dev/da0s1 > crw-r----- 1 root operator 4, 29 Apr 11 21:45 /dev/da0s1s1 > [1045] ~ # mount_msdosfs /dev/da0s1 /mnt/cf > [1046] ~ # umount /mnt/cf > [1047] ~ # mount_msdosfs /dev/da0s1s1 /mnt/cf > [1048] ~ # umount /mnt/cf I'd highly recommend running the command in the other direction so you try to read rather than write. It shouldn't matter, but that makes me nervous (not that I think it has anything to do with your problem.) It would appear that your da0s1 has data at the front that looks like an MBR and GEOM is attaching to it. I'm not sure what the best solution to that problem is. Probably a reformat. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp8wZIaFCZxM.pgp
Description: PGP signature