:
:> Note that my other UMASS device, a compact flash reader, has always
:> worked fine with just the Quirk entry. I really need a USB expert to
:> tell me what is going on :-)
:
:The problem is that an umass bulk only umass device is allowed to stall the
:comunication pipe on an invalid command.
:I got the impression that the umass driver doesn't clear the pipe on
:errors.
:
:--
:B.Walter COSMO-Project http://www.cosmo-project.de
In my traces I did occassionally see a command wind up in a STALLED
state, but most of the time it either wound up in a BABBLE state or
in a NAK state and hit the 5 second timeout.
Since I removed the conditional (the #if 0 in the patch I posted
earlier), I have not seen either state.
These problems always occured while the CAM layer was probing the
device (e.g. doing a READ CAPACITY, telling the lower layer to not
allow user removal (as if that helps)). Once the CAM layer was
actually able to get past that state the actual READs and WRITEs
worked fine with just the Quirk entry, before my #if 0 patch. Prior
to the patch it took a lot of random pulling of the device, putting
it back in, pulling it again, putting it back in, camcontrol reset 1,
camcontrol rescan 1, that sort of thing, before I would either get
the device to work or the system would panic :-). After the patch
everything works fine (though I'm sure pulling the device without
unmounting it first will still lead to problems similar to those
describde by Frode).
p.s. the patch was against -stable. -current was crashing on me
too much while playing with the disk key, but I'm sure it applies
to -current too.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
