Tom Collins wrote:
> I'm working with some USB drives and trying to troubleshoot a few 
> problems.  MIPS hardware, kernel 2.4.19-rc1 (for the EHCI driver).

Out of curiousity -- big-endian or little-endian MIPS?
(Or should I say, "MIPS or SPIM"? :)  Folk have used the
EHCI driver on PPC (big-endian) so I don't think there
are any issues in that area, but surprises can happen.


> I have a USB 2.0 drive that is powered off the USB bus, connected to an 
> Adaptec USB 2.0 card.  ...
> 
> Question 1 is, if the device is seen in /proc/bus/usb/devices, why 
 > didn't the SCSI driver map it to a /dev/sdx device?

Seems like some kind of usb-storage issue; what does the
/proc/scsi/scsi file tell you?


> didn't the SCSI driver map it to a /dev/sdx device?  If I remove the 
> drive and plug in a simple USB 1.1 Flash Drive (16MB), I get the following:
> 
> ...
> 
> Why do all of the ports change status?  What port number am I actually 
> plugging into?  It's not in the kernel messages, but my serial console 
> reported "hub.c: port 3 over-current change" followed by "hub.c: port 2 
> over-current change".

I'm not sure why you're seeing any over-current indications;
maybe they really do draw too much current.

As for why all those ports change status ... hub driver diagnostics
are really confusing, they're talking about two different hubs:
first the EHCI root hub, which decides the device isn't going to
work at high speed so it hands it off, then the OHCI one (to which
the device was handed by the EHCI driver).

See http://www.linux-usb.org/usb2.html to learn a bit about
how "USB 1.1 companion controllers" are used in enumeration.


> I'm led to believe that the problem is in this section:
> 
> <7>hcd/ehci-q.c: 3strikes
> <7>hcd/ehci-q.c: ep 1-out qtd token 801f8049 --> status -71
> <7>hcd.c: giveback urb 81608ee0 status -71 len 0
> <7>hcd/ehci-q.c: 3strikes
> <7>hcd/ehci-q.c: ep 0-out qtd token 00080248 --> status -71
> <7>hcd.c: giveback urb 83e2c240 status -71 len 0
> 
> What does this mean?

The first is the device reporting an error (-71 == -EPROTO on
my system) for a bulk-OUT transfer, the second does the same
for a control-out transfer.  I'm used to seeing usb-storage
issue an initial request that gets an error, and then recover.
(Can't say as I recall if that's the error though.)

But I'm not sure why you're seeing more than one, and it looks
like maybe the recovery in usb-storage isn't working for this
particular device.

- Dave




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to