--- Alan Stern <[EMAIL PROTECTED]> wrote:
> A better guess would be that there are
> two UHCI controllers, each with one port attached to a connector and one
> port attached to nothing, and the first controller is broken.
N Lin:
> > So maybe I need to somehow (a) supress the creation of the "bogus" UHCI controller
> > entry, and/or (b) explicitly tell EHCI to pass USB1 traffic onto the real
> > controller
> > and not the bogus one? Any easy way to do either of these?
--- Alan Stern <[EMAIL PROTECTED]>:
> (a) won't help, because it doesn't matter whether or not you have a
> "bogus" entry if the hardware doesn't work. (b) is impossible; the
> mapping from EHCI ports to companion UHCI controllers/ports is determined
> by the wiring on the card and can't be changed in software.
The PCMCIA USB2 card came, as might be expected, with proprietary closed-source drivers
for a certain commercial operating system that I don't have installed. I suspect that
either (1) the card works but only with the closed-source drivers doing some black-box
magic with the card, or (2) the card is simply broken as you suggest (i.e. 2 UHCI
controllers, one broken and one working, with the EHCI being hard-wired to use the
broken
controller).
Anyway, my main objective - to use my USB2 hard drive at USB2 speeds - has been met
with
EHCI handling the USB2 hi-speed transfers, so I am mostly happy, but still interested
in
principle about utilizing hardware to its best capabilities under Linux. So, to engage
in
some theoretical speculation, is it possible (i.e. have there been similar cases in
the past)
that the card has 2 UHCI controllers, one broken for whatever reason, with EHCI being
"soft-wired" by default to use the broken one, but with some black-box hidden secret
code
(probably in the proprietary driver) that will cause the EHCI controller to re-route
USB1
requests to the other, working UHCI controller? Is such a thing (rerouting of the
EHCI's UHCI
companion controller by the driver software) heard-of?
I can also wait for (or try myself to add) your suggested patch to increase debugging
output in EHCI to indicate specifically which UHCI controller EHCI is handing off to,
to
see if, as believed, EHCI is indeed handing off to the non-working UHCI controller on
the
card instead of the working one. This would at least confirm that the failure theory
is
correct.
> You left out option (c): exchange the PCMCIA card because it isn't
> working!
As I mentioned, my main use of accessing my USB2 hard drive is satisfied. I'm now
mostly
interested in getting the hardware to work to its maximum capabilities as a matter of
principle (if the proprietary driver can get the card to work, then a Linux driver must
also be able to!). The only open question is if the proprietary driver can indeed get
the
card to work to its full capabilities or if a hardware failure is at fault, a question
which
I unfortunately cannot definitively answer as I don't have access to the alternative
operating system needed by the proprietary driver.
Thanks a lot again for all your help. It's been quite instructive. Also, will your
previous patch for better handling of the timeout error (to prevent UHCI from locking
up when it encounters the broken controller) will be in the next version of the
driver?
Thanks,
N Lin
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
