Tim Clewlow wrote: > Michal Varga wrote: > > Rainer Alves wrote: > > > I'm having the exact same problem. > > > Ever since I've switched from RELENG_6 to RELENG_7 I'm still able to > > > mount my SonyEricsson W810 phone, but whatever is copied there gets > > > corrupted. > > > I first noticed this yesterday when copying a new batch os MP3s to its 4 > > > GB memory stick. > > > > "Me too" - I see this with USB2.0 support/controller enabled, tested on > > two nforce5 and amd690 boards. Random (but pretty heavy) corruptions > > with data transferred to and from digital camera and mp3 player (both > > acting as common "usb flash disks"). Disabling USB2.0 seems to fix it > > AND also no board without USB2.0 controller exhibits this here (I just > > did a few quick tests, and nothing so far). Possibly some EHCI-specific > > bug? I remember there was an msdosfs corruption problem reported a few months ago. It could be worked around by disabling read/write clustering when mounting the file systems (see the options in the mount(8) manpage). I don't think this issue is related, but it might still be worth a try. > I noticed that the large msdos filesystem option caused kernel build > to fail on 7.0 as it is now considered an invalid option. > > options MSDOSFS_LARGE # MSDOS Filesystem That's expected. That kernel option doesn't exist anymore because it was converted to a mount option (for example, "mount -o large /dev/foo /media/bar"). It's certainly not related to the corruption problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java"Received on Tue Nov 13 2007 - 16:37:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:22 UTC