On Thu, Jul 28, 2005 at 05:44:59PM -0400, Alan Stern wrote: > On Wed, 27 Jul 2005, Keith Hellman wrote: > > > Thanks for getting back to me so quickly. Here is the snippit of the > > /var/log/debug immediately after the rsync error. > > > > Jul 26 13:24:52 localhost kernel: usb-storage: -- transfer complete > > Jul 26 13:24:52 localhost kernel: usb-storage: Bulk status result = 0 > > Jul 26 13:24:52 localhost kernel: usb-storage: Bulk Status S 0x53425355 T > > 0x6e85 R 0 Stat 0x0 > > Jul 26 13:24:52 localhost kernel: usb-storage: scsi cmd done, result=0x0 > > Jul 26 13:24:52 localhost kernel: usb-storage: *** thread sleeping. > > Jul 26 13:24:53 localhost khellman: FIRST SYNC ERROR DISPLAYED ON CONSOLE > > Jul 26 13:42:05 localhost kernel: usb-storage: queuecommand called > > Jul 26 13:42:05 localhost kernel: usb-storage: *** thread awakened. > > Jul 26 13:42:05 localhost kernel: usb-storage: Command READ_10 (10 bytes) > > Jul 26 13:42:05 localhost kernel: usb-storage: 28 00 00 00 4a 57 00 00 01 > > 00 > > Jul 26 13:42:05 localhost kernel: usb-storage: Bulk Command S 0x43425355 T > > 0x6e86 L 512 F 128 Trg 0 LUN 0 CL 10 > > > > As you can see, there aren't anymore debug messages for almost 15 > > minutes. I inserted the 'FIRST SYNC ERROR...' message by just hovering > > over the enter key of a logger invokation while my sync process ran in > > another window, so there is definetly a delay between the filesystem > > switching to read-only and my logger message showing up. Apparently, > > that delay is enough for all of the usb i/o to complete. > > Interestingly, in your original log the last write operation occurred 33 > seconds before your sync error message, with lots of reads in between. I > guess that's typical for rsync operations, though. > > > More disheartening is that the usb logs don't show any abnormal > > conditions. > > Yes. Whatever went wrong, it doesn't seem to be connected with the USB > stack. > <snip>
It would seem that the solution was to simply reformat the partition with mkfs.vfat -F 32 after this everything appears to be working without a glitch. There is mention in the man pages of the kernel vfat driver not supporting more than 2 FAT tables (or some such thing) and this may have been what was causing the hiccup and forcing the mount to read-only. I'm letting you know because I may not be the only person who trips over this problem, and with the links on the net about usb-storage and the iRiver, you may well be contacted about this again by someone else. Now you've got something to forward to them. Thanks again for your help & usb-storage! -- Keith Hellman #include <disclaimer.h> [EMAIL PROTECTED] from disclaimer import standard public key @ www.mcprogramming.com The purpose of computing is insight, not numbers. -- Richard W. Hamming, 1962
signature.asc
Description: Digital signature
