DragonFlyBSD

:Relevant portion of usbdevs -v:
:Controller /dev/usb4:
:addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), ATI(0x00=
:00),
:rev 1.00
:...
:
:Should I be suspecting the filesystem, CAM (I've noticed Peter Avalos's wor=
:k on
:CAM locking but haven't tried it yet), or the basic hardware support?

Well, if Linux is also blowing up on it then it is either going to be
    the USB chipset on the motherboard, or the device plugged into or
    otherwise connected to the USB.

If other USB mass-storage devices work (for example, if you plug in
    a usb storage key and that works ok), then it is likely the device
    plugged into the usb slot and not the usb chipset that is to blame.

If no mass storage devices work then it is likely an issue with the
    usb chipset or driver.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Thanks for the attention -- in the past few minutes I decided to make sure
Ubuntu had an issue open, and found some information that may be promising or
headache-inducing.

"Slow" should really be removed from the subject here since I typed it before I
remembered I was running OHCI only. Of course, 0 bytes/sec when it fails does
feel slow!

Matt said,

Well, if Linux is also blowing up on it then it is either going to be
the USB chipset on the motherboard, or the device plugged into or
otherwise connected to the USB.

Naturally, but Linux support has been so flaky that I had no reason to believe
the DragonFly and Linux bugs were related.. until now, see below.

If other USB mass-storage devices work (for example, if you plug in
a usb storage key and that works ok), then it is likely the device
plugged into the usb slot and not the usb chipset that is to blame.

I think I've noticed this before with other devices but that might've been well
before 1.12. I'm doing the right thing and testing with a USB stick now. (So
far it's being well-behaved with one large file; I'm still using OHCI only for
determinism. I'll try generating the equivalent of a photo card's dcim
directory. I'll also pull out an external card reader that I forgot about and
see how that fares.)

If no mass storage devices work then it is likely an issue with the
usb chipset or driver.

Apparently it took a while for SB600 ownership to reach critical mass.
Checking Ubuntu found their issue, opened this month:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/198619
...which is bursting with useful links to LKML and Kernel.org discussion and
instrumentation, including:
http://bugzilla.kernel.org/show_bug.cgi?id=8692
http://lkml.org/lkml/2008/2/19/546
(It's easiest to refer to the Launchpad entry, which provides some chronology.
It'll take a while to check that all the patches referenced made it back into
the kernel.org bugzilla.)

Apparently there are quirks or surprises with IAA behavior/IAAD register
handling ("Interrupt on Asynchronous Advance Doorbell") on the SB600, possibly
on the SB700. It also seems there are some similar (but presumably different)
IAA/IAAD quirks with other vendors' USB host controllers.

I'm still working to understand exactly what they found and whether it even
applies outside EHCI. In the meantime, I'll do the tests mentioned above. I do
have some other CF media to try, and some NEC-based USB controllers I should
probably drop into these boxes to see if I can copy and preserve the cards' data
in the meantime, now that there's reason to suspect the controller.

Short update:

The USB stick (PNY Attache 2GB) seems to be working fine with 1.12. Perhaps I
wasn't stressing it much because the files were immediately copied from the HD
and back and a large portion may've been retained in cache.

Using a second card reader ("Zio Corporation," detected with a generic string
per below):

Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), ATI,
rev 1.00
port 1 addr 2: low speed, power 100 mA, config 1, PS2/USB Browser Combo
Mouse(0x0011), Cypress Sem(0x05fe), rev 0.00
port 2 addr 3: full speed, power 500 mA, config 1, USB2.0 Card Reader(0x0001),
Storage Device(0x0dda), rev 1.6f

... the 2GB CF card (which may or may not have a corrupt FS at this point)
presented with a severely truncated directory listing. I believe it was trying
fsck_msdos that produced the following in dmesg:

contigmalloc_map: failed in index < 0 case!
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
contigmalloc_map: failed in index < 0 case!
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
contigmalloc_map: failed in index < 0 case!
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
contigmalloc_map: failed in index < 0 case!
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
contigmalloc_map: failed in index < 0 case!
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, STALLED
umass1: BBB bulk-out clear stall failed, STALLED
(da2:umass-sim1:1:0:0): Synchronize cache failed, status 0x4, scsi status 0x0
umass1: BBB reset failed, STALLED
umass1: BBB bulk-in clear stall failed, IOERROR
umass1: BBB bulk-out clear stall failed, TIMEOUT

With the Zio reader, ls of a known-good 1GB CF was fine, while fsck_msdos failed
with that exact same output in dmesg.

Attempting to copy the roughly 1GB of large JPEGs from that card has proceeded
for perhaps a minute, hung for approximately 1 minute, and now to my surprise is
proceeding again. That pattern now seems to be repeating, so I'm logging iostat
with timestamps to try to get some sense of it.

Can you please try with latest ISO snapshot? There was some work done on the USB
stack and many commits to CAM.