Bug #979
open
Failure-prone USB mass storage (SB600? msdosfs? CAM?)
0%
Description
I'm still very behind when it comes to keeping track of development, so pardon
if this is known. I always need to do more testing, but some feedback will help
me narrow down the test cases.
Symptoms:
Using 1.12.0-RELEASE, copying from a FAT-formatted 2GB CF card in a reader with
a "Genesys" chipset hangs after the first ~82MB have been copied. A "hang" is
determined as iostat showing 0 throughput and cp not responding to ^C.
ehci.ko is not loaded, so ohci alone was involved here.
Hardware considerations:
SMP kernel (Athlon 64 x2)
SB600
The reader is part of a Mitsumi floppy combo device
(A slim conventional floppy and USB card reader crammed into one 3.5" box.)
Relevant portion of usbdevs -v:
Controller /dev/usb4:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), ATI,
rev 1.00
port 1 addr 2: full speed, power 500 mA, config 1, USB Reader(0x070e),
Genesys(0x05e3), rev 93.25
port 2 powered
...
The following from CAM was found in dmesg. I believe this was printed before
I rudely pulled the card, however I cannot be sure. (Have we considered
timestamping dmesg yet?) There was nothing else new in dmesg.
(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
Similarly, cp has produced some odd output, but since the card was pulled and
the hung cp was left sitting for 24 hours before I got around to reporting this,
I'm not sure what happened here. :}
%cd /home/floid/Photos/
%cp /mnt/dcim/101olymp/* .
cp: ./pa091308.jpg: Bad address
cp: ./pa091307.jpg: Bad address
cp: /mnt/dcim/101olymp/pa091306.jpg: Input/output error
cp: /mnt/dcim/101olymp/pa091303.jpg: Input/output error
cp: /mnt/dcim/101olymp/pa091302.jpg: Cross-device link
^C
Adding to my confusion, the Linux (Ubuntu 7.10) machine I would attempt to read
the card with has a similar hardware configuration (another SB600, another card
reader that's also Genesys Logic-based) and its own intractable problems with
USB in general! On review, I see that Linux ("2.6.22-14-generic #1 SMP" i686)
made it exactly 32MB into the card before a majority of its USB support locked
up. Unfortunately that's been happening whenever anyone breathes near that
machine, and proprietary VMWare and fglrx modules are involved, so it'll be a
while before I can fsck or chkdsk the filesystem structure on the CF card itself!
(The media should be fine, since the camera has had no complaints.)
===
Should I be suspecting the filesystem, CAM (I've noticed Peter Avalos's work on
CAM locking but haven't tried it yet), or the basic hardware support?
Updated by 
Updated by 
Updated by