
Hi, There was some brief discussion recently about trouble with a specific USB3 controller under Linux. I wondered if anyone can provide anecdotal evidence for controllers which work *well* under Linux? Day in, day out, without hiccups. Also, ideally ones which are supported well in the Ubuntu 12.04 LTS or Debian Wheezy kernels, rather than bleeding edge. (So that's 3.2.0 or earlier) Cheers, Toby

On 11/04/12 11:05, Toby Corkindale wrote:
Hi, There was some brief discussion recently about trouble with a specific USB3 controller under Linux.
I wondered if anyone can provide anecdotal evidence for controllers which work *well* under Linux? Day in, day out, without hiccups. Also, ideally ones which are supported well in the Ubuntu 12.04 LTS or Debian Wheezy kernels, rather than bleeding edge. (So that's 3.2.0 or earlier)
To kick things off, I did some (quick, not at all comprehensive) research via google. I found an article comparing a whole load of USB 3 chipsets, and then I very quickly chucked each chipset at google to see if there were any obvious "it works" or "help it doesn't work" reports for linux in the first page of results. (It probably isn't an exhaustive list, but I figured it was covering the main ones.) Summary: * There are some pre-1.0-standard (0.96) controllers, and some actually-1.0-standard controllers. * The only 1.0-compatible controller with what looks like active support and reports of it working is the Etron EJ168A chipset. Details per chipset: AMD A75: Unknown if it's 1.0 compatible or not. Performed worst in tests. No comments about Linux support. ASMedia ASM1042: pre-1.0 spec. As of Squeeze/Oneiric, reports on internet of it being flakey back then, but actually suspect it's all sorted by the time of the wheezy/precise kernel. Etron EJ168A: Meets 1.0 spec. Performed fastest in tests. Reports on internet have it totally broken around Squeeze's kernel, working but with bugs around Oneiric's kernel, and probably good by wheezy/precise. Fresco Logic FL1009: Meets 1.0 spec. Reports of it being broken in Natty, no reports either way later. NEC/Renesas µD720200: The oldest (and thus most common) chipset. Doesn't meet 1.0 spec. Has a slightly odd implementation according to this review. Reports of it not working properly on Oneiric. Renesas µD720201: Updated version of above chipset. Now 1.0 compatible. Was second-fastest in tests. Nothing about it working (or not) on Linux. VLI VL800 and VL801: Doesn't meet 1.0 spec. Came second-slowest in tests after the AMD A75. Nothing on the internet about linux support.

Toby, Thanks for taking the time to research and post this!
NEC/Renesas µD720200: The oldest (and thus most common) chipset. Doesn't meet 1.0 spec. Has a slightly odd implementation according to this review. Reports of it not working properly on Oneiric.
This is the one I've had problems with. Avoid. One that I couldn't see on your list (unless it was under a different name) was: USB controller: VIA Technologies, Inc. Device 3432 (rev 02) 02:00.0 0c03: 1106:3432 (rev 02) Which has been working flawlessly for me under a variety of 3.2 kernels. James

On 11/04/12 11:54, James Harper wrote:
Toby,
Thanks for taking the time to research and post this!
NEC/Renesas µD720200: The oldest (and thus most common) chipset. Doesn't meet 1.0 spec. Has a slightly odd implementation according to this review. Reports of it not working properly on Oneiric.
This is the one I've had problems with. Avoid.
One that I couldn't see on your list (unless it was under a different name) was:
USB controller: VIA Technologies, Inc. Device 3432 (rev 02) 02:00.0 0c03: 1106:3432 (rev 02)
Which has been working flawlessly for me under a variety of 3.2 kernels.
That's good to know -- I don't suppose you can find out what the chipset is actually called? It might be in your kernel messages somewhere. "Device 3432" in lspci just means the id isn't in the PCI ids table, but the xhci driver must have known more about it.

One that I couldn't see on your list (unless it was under a different name) was:
USB controller: VIA Technologies, Inc. Device 3432 (rev 02) 02:00.0 0c03: 1106:3432 (rev 02)
Which has been working flawlessly for me under a variety of 3.2 kernels.
That's good to know -- I don't suppose you can find out what the chipset is actually called? It might be in your kernel messages somewhere.
The kernel messages for loading the xhci_hcd module have long since been rotated out, so I can't easily verify.
"Device 3432" in lspci just means the id isn't in the PCI ids table, but the xhci driver must have known more about it.
Actually the xhci driver just loads anything with the right PCI class: /* PCI driver selection metadata; PCI hotplugging uses this */ 297 static const struct pci_device_id pci_ids[] = { { 298 /* handle any USB 3.0 xHCI controller */ 299 PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0), 300 .driver_data = (unsigned long) &xhci_pci_hc_driver, 301 }, 302 { /* end: all zeroes */ } 303 }; Any device specific quirk is handled by exception: 54 static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) 55 { 56 struct pci_dev *pdev = to_pci_dev(dev); 57 58 /* Look for vendor-specific quirks */ 59 if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC && 60 pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK) { 61 if (pdev->revision == 0x0) { 62 xhci->quirks |= XHCI_RESET_EP_QUIRK; 63 xhci_dbg(xhci, "QUIRK: Fresco Logic xHC needs configure" 64 " endpoint cmd after reset endpoint\n"); 65 } 66 /* Fresco Logic confirms: all revisions of this chip do not 67 * support MSI, even though some of them claim to in their PCI 68 * capabilities. 69 */ 70 xhci->quirks |= XHCI_BROKEN_MSI; 71 xhci_dbg(xhci, "QUIRK: Fresco Logic revision %u " 72 "has broken MSI implementation\n", 73 pdev->revision); 74 } 75 76 if (pdev->vendor == PCI_VENDOR_ID_NEC) 77 xhci->quirks |= XHCI_NEC_HOST; 78 79 if (pdev->vendor == PCI_VENDOR_ID_AMD && xhci->hci_version == 0x96) 80 xhci->quirks |= XHCI_AMD_0x96_HOST; 81 82 /* AMD PLL quirk */ 83 if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info()) 84 xhci->quirks |= XHCI_AMD_PLL_FIX; 85 if (pdev->vendor == PCI_VENDOR_ID_INTEL && 86 pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) { 87 xhci->quirks |= XHCI_SPURIOUS_SUCCESS; 88 xhci->quirks |= XHCI_EP_LIMIT_QUIRK; 89 xhci->limit_active_eps = 64; 90 xhci->quirks |= XHCI_SW_BW_CHECKING; 91 } 92 if (pdev->vendor == PCI_VENDOR_ID_ETRON && 93 pdev->device == PCI_DEVICE_ID_ASROCK_P67) { 94 xhci->quirks |= XHCI_RESET_ON_RESUME; 95 xhci_dbg(xhci, "QUIRK: Resetting on resume\n"); 96 } 97 } (code copied from http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=blob;f=drivers/us...) James

On 11/04/12 11:54, James Harper wrote:
One that I couldn't see on your list (unless it was under a different name) was: USB controller: VIA Technologies, Inc. Device 3432 (rev 02) 02:00.0 0c03: 1106:3432 (rev 02)
Which has been working flawlessly for me under a variety of 3.2 kernels.
Actually, I think VLI is the same as VIA Technologies -- VLI stands for "VIA Labs Inc".

Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
Summary: * There are some pre-1.0-standard (0.96) controllers, and some actually-1.0-standard controllers. * The only 1.0-compatible controller with what looks like active support and reports of it working is the Etron EJ168A chipset.
Interesting... Intel were sponsoring the USB 3 implementation in the kernel (presented a few years ago at LCA). Thus I would expect Intel USB controllers to have working support.

On 11/04/12 12:08, Jason White wrote:
Toby Corkindale<toby.corkindale@strategicdata.com.au> wrote:
Summary: * There are some pre-1.0-standard (0.96) controllers, and some actually-1.0-standard controllers. * The only 1.0-compatible controller with what looks like active support and reports of it working is the Etron EJ168A chipset.
Interesting...
Intel were sponsoring the USB 3 implementation in the kernel (presented a few years ago at LCA). Thus I would expect Intel USB controllers to have working support.
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.

Interesting...
Intel were sponsoring the USB 3 implementation in the kernel (presented a few years ago at LCA). Thus I would expect Intel USB controllers to have working support.
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.
The author of the xhci driver (Intel employee) hasn't committed anything since October 2011... I don't know if that means she's no longer working on it or if her code is perfect and no longer requires any changes ;) James

Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.
Thanks for the update. I almost always learn something new from discussions on this list.

On 04/11/2012 02:12 AM, Toby Corkindale wrote:
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.
I could be wrong here, but aren't USB 3.0 and Thunderbolt apples and oranges? From what I understand, Thunderbolt is all about proxying connections from multiple technologies (including USB) from a hub, whereas USB is all about the actual connection to a device.

On 18/04/12 20:52, Jeremy Visser wrote:
On 04/11/2012 02:12 AM, Toby Corkindale wrote:
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.
I could be wrong here, but aren't USB 3.0 and Thunderbolt apples and oranges?
From what I understand, Thunderbolt is all about proxying connections from multiple technologies (including USB) from a hub, whereas USB is all about the actual connection to a device.
Not according to the wikipedia page. But, it's wikipedia. Maybe it's wrong?

On Thu, Apr 19, 2012 at 10:08 AM, Toby Corkindale < toby.corkindale@strategicdata.com.au> wrote:
On 18/04/12 20:52, Jeremy Visser wrote:
On 04/11/2012 02:12 AM, Toby Corkindale wrote:
I guess you didn't hear -- Intel ditched USB3 and created Thunderbolt instead. There are no Intel USB3 chipsets around currently.
I could be wrong here, but aren't USB 3.0 and Thunderbolt apples and oranges?
From what I understand, Thunderbolt is all about proxying connections from multiple technologies (including USB) from a hub, whereas USB is all about the actual connection to a device.
Not according to the wikipedia page. But, it's wikipedia. Maybe it's wrong?
Wikipedia may be wrong but I doubt Intel are wrong http://www.intel.com/content/www/us/en/io/thunderbolt/thunderbolt-technology... -- Mark "Hiddensoul" Clohesy Mob Phone: (+61) 406 417 877 Email: hiddensoul@twistedsouls.com G-Talk: mark.clohesy@gmail.com - www.shed.twistedsouls.com - GNU/Linux.. Linux Counter #457297 "I would love to change the world, but they won't give me the source code" "Linux is user friendly...its just selective about who its friends are" "Never underestimate the bandwidth of a V8 station wagon full of tapes hurtling down the highway" "The difference between e-mail and regular mail is that computers handle e-mail, and computers never decide to come to work one day and shoot all the other computers"
participants (6)
-
Hiddensoul (Mark Clohesy)
-
James Harper
-
Jason White
-
Jeremy Visser
-
Toby Corkindale
-
Trent W. Buck