[issue979] Failure-prone USB mass storage (SB600? msdosfs? CAM?)

[Joe "Floid" Kanowitz]

Joe "Floid" Kanowitz <jkanowitz at snet.net> added the comment:

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.

----------
title: Slow, failure-prone USB mass storage (SB600? msdosfs? CAM?) -> Failure-prone USB mass storage (SB600? msdosfs? CAM?)

_____________________________________________________
DragonFly issue tracker <bugs at lists.dragonflybsd.org>
<https://bugs.dragonflybsd.org/issue979>
_____________________________________________________