[DragonFlyBSD - Bug #979] (Feedback) Failure-prone USB mass storage (SB600? msdosfs? CAM?)
bugtracker-admin at leaf.dragonflybsd.org
bugtracker-admin at leaf.dragonflybsd.org
Thu Jan 15 08:38:47 PST 2015
Issue #979 has been updated by tuxillo.
Description updated
Category set to Driver
Status changed from New to Feedback
Assignee deleted (0)
Target version set to Unverifiable
Moving to unverifiable.
Feel free to update it if you can test it again.
Cheers,
Antonio Huete
----------------------------------------
Bug #979: Failure-prone USB mass storage (SB600? msdosfs? CAM?)
http://bugs.dragonflybsd.org/issues/979#change-12471
* Author: floid
* Status: Feedback
* Priority: Normal
* Assignee:
* Category: Driver
* Target version: Unverifiable
----------------------------------------
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?
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
More information about the Bugs
mailing list