weird usb problem

Maksim Yevmenkin maksim.yevmenkin at gmail.com
Tue Aug 9 17:26:20 GMT 2005


Guys,

> > > > it seems that usb does even detect that device is plugged
> > > > or something broken in discovery.
> > >
> > > See my PR on this issue. This should have been fixed a long time ago, but
> > > I have not commit rights :-(
> > >
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/79656
> >
> > well, i looked at the PR but i do not see any patches :( all it says
> >
> > <quote>
> >
> > >Fix:
> >
> > ehci_pcd_enable() must call ehci_pcd() to catch up missed interrupts
> >
> > ohci_rhsc_enable() must call ohci_rhsc() to catch up missed interrupts
> >
> > </qoute>
> >
> > could you please submit the patch? i can test and commit it for you.
> >
> > > If you want, try out the following and see if the problem dissappears:
> > >
> > > Download the three files below into a new directory and type
> > > "make install"  (to uninstall type "make deinstall")
> > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile
> > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2
> > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2
> >
> > that seems like a lot of changes. i tried it and one of the patches
> > failed completely. are all these changes required to fix the problem?
> 
> No, don't worry about the patches failing. As long as it compiles it should be
> OK.
> 
> 
> You find "ehci_pcd_enable()" in "/sys/dev/usb2/_ehci.c" (my driver) and in
> "/sys/dev/usb/ehci.c" (old driver).
> 
> 
> You find "ohci_rhsc_enable()" in "/sys/dev/usb2/_ohci.c" (my driver) and in
> "/sys/dev/usb/ohci.c" (old driver).
> 
> 
> I'm not sure how this patch would look for the "old USB driver", but basically
> you need to finish the root interrupt transfer, that again will wakeup the
> explore thread. Also you need to clear the PCD/RHSC status bits, to make sure
> that the PCD/RHSC interrupt does not stop.
> 
> From a quick glimpse, you need to add something like
> 
> "ehci_pcd(sc, sc->sc_intrxfer);" after "ehci_pcd_able(sc, 1);".
> 
> In the middle you have to add something like this:
> 
>         /* acknowledge any PCD interrupt */
>         EOWRITE4(sc, EHCI_USBSTS, EHCI_STS_PCD);
> 
> Just look at the code in my USB driver, and if it fixes the problem, just
> backport it.

well, i tried a naive thing like this

beetle% diff -u10 ehci.c.orig ehci.c
--- ehci.c.orig Sat May 28 21:42:27 2005
+++ ehci.c      Tue Aug  9 09:53:13 2005
@@ -632,20 +632,21 @@
                sc->sc_eintrs &= ~EHCI_STS_PCD;
        EOWRITE4(sc, EHCI_USBINTR, sc->sc_eintrs);
 }
 
 void
 ehci_pcd_enable(void *v_sc)
 {
        ehci_softc_t *sc = v_sc;
 
        ehci_pcd_able(sc, 1);
+       ehci_pcd(sc, sc->sc_intrxfer);
 }
 
 void
  ehci_pcd(ehci_softc_t *sc, usbd_xfer_handle xfer)
 {
        usbd_pipe_handle pipe;
        u_char *p;
        int i, m;
 
        if (xfer == NULL) {
==

which does what you have suggested, i.e. acknowledge any PCD interrupt
(because ehci_pcd_able() is called with on == "1") and than call
ehci_pcd() to complete interrupt transfer, but unfortunately it did
not work :(

so what i do not get is why usb 1.0 devices work just fine in _any_
usb slot. is usb 2.0 discovery process different from usb 1.0
discovery process? or there is something else i'm missing?

again the usb 2.0 device is _not_ recognized unless its plugged into
usb slot connected directly to the ehci root hub.

now i'm case, i have a 

usb4: <EHCI (generic) USB 2.0 controller> on ehci0

and

uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered

port 2 on uhub4 (root ehci hub) is connected to the

uhub5: vendor 0x413c product 0x0058, class 9/0, rev 2.00/0.00, addr 2
uhub5: multiple transaction translators
uhub5: 4 ports with 4 removable, self powered

few usb slots are directly connected to the uhub4 (root ehci hub)
ports 5 to 7.  the usb 2.0 device is working when plugged into these
slots.

other usb slots are connected to the uhub5 ports 2 to 4 and the usb
2.0 device is _not_ working when plugged into these slots.

usb 1.0 devices work in every usb slot. 

so, it seems that the usb 2.0 device is not working when there is a
hub in between. for whatever reason it does not affect usb 1.0
devices.

i recall similar(?) problem with "broken" usb 1.0 devices that were
related to timing or something like that. i think the solution was to
reset port several times. the symptoms were different also. i think
one would failed (IOERROR) transfer when device is plugged.

finally a few stupid questions:

- what does "multiple transaction translators" mean? (on uhub5)

- in my scenario: what happens when usb 1.0 hub (uhub5) is plugged
into usb 2.0 root hub (uhub4) and will usb 2.0 devices work when
plugged into the usb 1.0 hub (uhub5) ?

thanks,
max


More information about the freebsd-usb mailing list