Bug #979
Updated by tuxillo over 9 years ago
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(0x0000), 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?