On Mon, Jan 21, 2013 at 03:24:03PM -0800, David Moore wrote:
> On Mon, Jan 21, 2013 at 11:35 AM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx wrote:
> > It's possible that the device is just buggy, and it expects the Windows
> > enumeration scheme. Windows will send an 8-byte request for the device
> > descriptor, set the device address, and then ask for the whole device
> > descriptor. We call this the 'new' enumerating scheme. Some devices
> > barf when Linux first sets the device address, then asks for the device
> > descriptor (the 'old' enumeration scheme).
> >
> > Currently, devices under xHCI will always see the old enumeration
> > scheme. We'd have to add new API in order to facilitate the new
> > enumeration scheme.
> >
> > You can test that hypothesis by loading the EHCI module and forcing it
> > to use the old enumeration scheme:
> >
> > sudo modprobe ehci old_scheme_first=1 use_both_schemes=0
> >
> > If you device doesn't enumerate under EHCI with those module parameters
> > set, then it probably doesn't tolerate the old enumeration scheme.
> >
>
> Yes, you are spot-on. I tried with those module options and then ehci can't
> enumerate either (btw, the module with the options was "usbcore", not
> "ehci"):
>
> [ 208.368058] hub 1-1:1.0: state 7 ports 6 chg 0000 evt 0008
> [ 208.368372] hub 1-1:1.0: port 3, status 0101, change 0001, 12 Mb/s
> [ 208.471954] hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms
> status 0x101
> [ 208.482927] hub 1-1:1.0: port 3 not reset yet, waiting 10ms
> [ 208.544751] usb 1-1.3: new high-speed USB device number 12 using ehci_hcd
> [ 213.542183] usb 1-1.3: khubd timed out on ep0in len=0/8
> [ 213.542192] usb 1-1.3: device descriptor read/8, error -110
Ok, good to know.
> So I guess my next question is: What are you plans, if any, to add the
> "new" enumeration scheme to xHCI? Is this a huge amount of work?
Not a huge amount of work, but it does require an API change to the USB
host controller driver functions, so the patch itself is not likely to
get backported to stable kernels. And I have no idea how the current
batch of USB 3.0 devices will react to an enumeration sequence change.
I've only heard of one other device that has this issue (a very old
mouse) in the 3+ years the xHCI driver has been out. I told the
reporters they probably should get another mouse, and put the todo item
aside. However, if buggy devices like your webcam are integrated into
systems, we really should support this behavior. It's just not very
high priority on my todo list.
> Either way, your information has been very helpful. This gives me some
> concrete information I can provide to the camera vendor. Hopefully this is
> something they can adjust in firmware and is not baked into the Freescale
> MX257 microcontroller that is being used.
Ok, let me know if you can't work it out with the camera vendor. Do you
know if they're already shipping devices with this bug?
> > > Another thing I'd like to do is operate these ports as EHCI ports instead
> > > of XHCI in order to solve my problem. I understand that ports can be
> > > switchable, but I've had to jump through some hoops to get them into EHCI
> > > mode. More on that later -- let's talk about the USB 3.0 issues first.
> >
> > I don't want to facilitate people switching ports between EHCI and xHCI.
> > I don't like the Intel xHCI/EHCI port switchover mechanism, and I
> > frankly don't trust the BIOS to correct switchover the ports on the fly
> > after boot. I would rather attempt to solve issues with USB devices
> > under xHCI than sweep the issues under the rug by using EHCI.
> >
>
> Fair enough. For the record, let me tell you what I did to get EHCI working
> on the USB 3.0 ports:
>
> First, I had to disable CONFIG_USB_XHCI_HCD completely to prevent the
> EHCI->xHCI switch from happening after boot. However, that wasn't enough --
> it just gave me dead ports. I also had to apply this patch:
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index eb5563a..9dc3240 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -780,6 +780,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> "defaulting to EHCI.\n");
> dev_warn(&xhci_pdev->dev,
> "USB 3.0 devices will work at USB 2.0 speeds.\n");
> + usb_disable_xhci_ports(xhci_pdev);
> return;
> }
>
> @@ -832,6 +833,7 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
> {
> pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
> pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
> + dev_dbg(&xhci_pdev->dev, "Disabling XHCI ports forcefully\n");
> }
> EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
>
> Probably because my bios leaves the ports in xHCI mode after boot, I needed
> the patch to get them back into EHCI mode. BTW, I'm using a Dell Optiplex
> 7010.
>
> Once I did all that, the ports work fine as EHCI.
Ok, that's a much easier fix than the one I had in mind. Would you care
to create a patch (without the debug in usb_disable_xhci_ports), and
submit it to me?
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
