Thanks for helping me debug this! On Mon, Jun 30, 2003 at 03:02:32PM -0400, Alan Stern wrote: > > http://bostoncoop.net/adam/temp/kernel-log-2.5 > I looked at this. It doesn't show any problems at all. Did you see > anything go wrong at the time this log was written?
I was experiencing some of the problems when that log was written, but I think I left out some important things by grepping only for usb. When I mount or unmount the device, I see this in syslog (and on the console): Jun 28 00:32:30 joehill kernel: SCSI error: host 1 id 0 lun 0 return code = 8000002 Jun 28 00:32:30 joehill kernel: ^ISense class 7, sense error 0, extended sense 0 As long as I don't read or write to the device, I can mount and unmount (in 2.5.73) repeatedly with no problems other than this error message. > How about sending the debugging output for when you try to unmount the > drive? I'm having some trouble figuring out what constitutes an abnormal message amongst the verbose debugging messages in syslog. I just tried copying a bunch of data to the device. After 50M or so, it slowed to a crawl. Initially, I thought it was crashed but eventually it started moving again, very slowly (probably around 10K-100K / sec). The log from this operation is here: http://bostoncoop.net/adam/temp/log_while_copying Here is the log from the point where I tried unsuccessfully to unmount the device: http://bostoncoop.net/adam/temp/unmount_log Interestingly, while the unmount process was stuck, I ran df, and got: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 18313076 17338432 44388 100% / /dev/sda1 18313076 17338432 44388 100% /mnt/neuros /dev/sda1, the USB drive, is now returning to same size as the hard drive (in reality, it's a 128M drive, which is the capacity it returned before I started the unmount). After several minutes where the unmount process was stuck, I finally removed the module, which caused lots of Buffer I/O errors, a filesystem panic, etc.. There is a call trace log as well. Here is the log from the point of removing the module until the time it was finally done: http://bostoncoop.net/adam/temp/remove_module_log > Don't worry about data corruption for now; it might just be a side-effect > from this problem. Or it might be something else entirely unrelated; I've > heard of at least one device where it turned out the manufacturer > acknowledged the firmware had bugs that would cause data corruption. Okay, corruption doesn't really hurt anyway--it's just holding mp3 files stored elsewhere. Incidentally, if are able to isolate this to a firmware bug, my expectation is that Neuros would be open to suggestions. > > Also, frequently the drive appears to be full when it's not. Although > > it's a 128M memory card, it usually maxes out around 60-70M. > What do you mean, appeared to be full? What did 'df' show? df showed 0M free... I can't replicate it now, so I don't remember what it thought the capacity was at the time. I suspect this is related to filesystem corruption on the drive rather than anything else... Space is occupied by files that were copied to the device but don't actually show up. > Again, debugging output and the kernel log from the segfault would be > useful. Hopefully the logs above will provide more insight into the situation. Is there debugging output I should send other than what usb-storage is putting in syslog? --Adam Kessel
pgp00000.pgp
Description: PGP signature
