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