Problems with USB devices connecting to UHCI instead of EHCI

[Hans Petter Selasky]

On Sunday 11 March 2007 21:19, Kevin Oberman wrote:
> > From: Hans Petter Selasky <hselasky at c2i.net>
> > Date: Sun, 11 Mar 2007 19:25:14 +0100
> >
> > On Sunday 11 March 2007 02:04, Kevin Oberman wrote:
> > > If I load umass after plugging in a disk or flash fob, it will be
> > > connected as a UHCI device. If I load umass and then connect the
> > > device, it is properly connected as EHCI. When connected as a UHCI
> > > device, it is too slow to be useful.
> > >
> > > Looks like a race condition as the EHCI is the last USB device probed.
> > > I suspect that the disk is already connected to a UHCI device before an
> > > EHCI device is found.
> > >
> > > uhci0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> port
> > > 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED]
> > > uhci0: [ITHREAD]
> > > usb0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> on uhci0
> > > usb0: USB revision 1.0
> > > uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> > > uhub0: 2 ports with 2 removable, self powered
> > > uhci1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> port
> > > 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED]
> > > uhci1: [ITHREAD]
> > > usb1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> on uhci1
> > > usb1: USB revision 1.0
> > > uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> > > uhub1: 2 ports with 2 removable, self powered
> > > uhci2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> port
> > > 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED]
> > > uhci2: [ITHREAD]
> > > usb2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> on uhci2
> > > usb2: USB revision 1.0
> > > uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
> > > uhub2: 2 ports with 2 removable, self powered
> > > uhci3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> port
> > > 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED]
> > > uhci3: [ITHREAD]
> > > usb3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> on uhci3
> > > usb3: USB revision 1.0
> > > uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
> > > uhub3: 2 ports with 2 removable, self powered
> > > ehci0: <Intel 82801FB (ICH6) USB 2.0 controller> mem
> > > 0xb0000000-0xb00003ff irq 11 at device 29.7 on pci0 ehci0:
> > > [GIANT-LOCKED]
> > > ehci0: [ITHREAD]
> > > usb4: EHCI version 1.0
> > > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> > > usb4: <Intel 82801FB (ICH6) USB 2.0 controller> on ehci0
> > > usb4: USB revision 2.0
> > > uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
> > > uhub4: 8 ports with 8 removable, self powered
> > >
> > > Any idea if this is fixable? Not a huge problem, but an annoying
> > > one. Will the new USB system (hopefully coming soon) deal with this?
> >
> > It might have something to do with the probe order. Did you try the new
> > USB stack. I recommend you install it on 6-stable, because on 7-current
> > it needs some small patches to compile, due to some changes in the kernel
> > API lately.
>
> Yes, I suspect the probe order is significant, but the only system I use
> USB devices on is my laptop and I really don't want to roll it back to
> stable.
>
> I can continue to work around it until you have a set of current patches
> for me to try. I'm really anxious to try out the new stack as I am
> hoping it will make USB behave better in terma of power management on my
> laptop. That's why i don't build USB into my kernel, but just load it
> when I need it.
>
> I don't normally read usb@, so I may drop you a note in a couple of
> weeks to see if the stack has been updated for current.
>

If you install the SVN version of my USB stack, and you are running the latest 
7-CURRENT, then you need to patch the following by hand:

Insert a NULL argument, to all bus_setup_intr() functions you find 
under /sys/dev/usb/, like shown below ?

        error = bus_setup_intr(dev, sc->sc_irq_res, INTR_TYPE_TTY,
-                              si_intr, sc, &ih);
+                              NULL, si_intr, sc, &ih);


That's it. Then it should compile.

--HPS