USB3 support

[dsjonny]

USB 3.0 support for NEC controller. I have no USB 3 device, but I use it for USB 2.0 disk drives. Haiku can detect the controller, but cannot use it.

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 1033: NEC Corporation
  device 0194: uPD720200 USB 3.0 Host Controller

[anevilyak]

XHCI support isn't implemented at this point for any controller. The output of listdev is just what's seen on the PCI bus, it has nothing to do with driver support.

[dsjonny]

Just an add-note: I have no idea what big work is to create new driver, but on many new PC has only USB 3.0. Like GIGABYTE Brix PC or SONY VAIO Pro laptop. I want to buy these, but I'm affraid Haiku cannot boot on these without USB 3.0 driver. On my current PC there are only some USB 2.0 ports what can use, and the most of they are already in use (keyboard, mouse, pendrive (Haiku boot)). If I want to plug more USB disk, than I have only one port available, because the USB 3.0 ports cannot use.

Is it possible to add this as an GSoC idea? I hope Haiku will support USB 3.0 in the near future.

[korli]

One can eventually build Haiku with experimental USB XHCI (no isochronous). In ​http://cgit.haiku-os.org/haiku/tree/build/jam/packages/Haiku, where one sees <usb>ehci one can add <usb>xhci (two places to be exact).

[umccullough]

Is this almost ready to be added to the default image? Seems a lot of people complain about Haiku not booting from USB only to discover they're trying to boot from a USB3 port.

[korli]

Here is the current status:

• Fresco Logic FL1009 USB 3.0 Host Controller: OK
• Intel Corporation Lynx Point USB xHCI Host Controller: KO (locks up, failure during handover from BIOS).
• Nec Corporation uPD720200 USB 3.0 Host Controller: KO (status to be updated)

[dsjonny]

I tried to make the xhci, but failed. I have attached a jam output (xhci.txt). Using hrev47196 nightly anyboot.

[umccullough]

apparently some people don't realize this ticket exists, so I'm changing the summary to be easier to search for.

[waddlesplash]

Jerome, any update?

Can I make this a R1a5 blocker? The ML consensus was divided, although I think it's pretty much mission-critical now... (although, Jerome, if you're working on GCC 4.8.3, finish that first :)

[pulkomandy]

I think this is out of scope of R1 (a binary compatible replacement for BeOS R5) and shouldn't delay alpha5 further. A note in our release note should be enough.

The priority should, however, stay high, given the current hardware is phasing out usb2.

[korli]

xhci build fixed in hrev47285. I'd suggest to let people test and report their current status.

[akshay1994]

• Fix -> ​http://lkml.iu.edu/hypermail/linux/kernel/1204.2/02460.html
• fCapabilityLength was never getting set.
• Correction in Bios Ownership code. (Line 200)
• PrepareKernelAccess called, to avoid page-fault condition.
• Changed values of constants, according to latest revision -> ​http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf

[jessicah]

Small style fix needed here (missing spaces):

fCapabilityLength=HCI_CAPLENGTH(hciCapLength);

Also, even though the trace statement is commented out, you should always use the B_PRI macros for numerical arguments:

TRACE("port %d status=0x%08lx\n", index, portStatus);

And you forgot to remove the format argument when updating to B_PRI in:

TRACE("eecp register: 0x%04" B_PRIx32 "\n", eecp);

[korli]

Thanks for the patch, I'll go through it in the next few days (will probably adjust the commit message).

[akshay1994]

Thanks. Also, going through the code further, I did some changes in _InsertEndpointForPipe. The SetDequeuePointer was failing with a context error, as a result of which, the queued requests for the endpoint were never getting executed. Also, I added HUB code, to detect devices on non root hubs. Didn't get time to make a patch. Will do it after a little more testing, soon.

[akshay1994]

Added ->

-Hub Support -Fixes to _InsertEndpointToPipe # -Prevent PageFault in FinishThread

# SetTRDequePointer Command was being called before ConfigureEndpoint Command. Endpoints in disabled state do not respond to SetTRDequePointer, and thus the command was failing with a Context Error. As a result, even on Ringing the doorbell, it didn't know where to take the next TR from. Note that this didn't affect the default Control Endpoint 0, as it never exists in Disabled state, but Stopped or Running.

[akshay1994]

Also note that the changes shown by git diff, on xhci.cpp line 202 seem confusing. For clarity, I moved the BIOS ownership code, from below the loop to inside it.

[akshay1994]

I'm sorry! There is no problem with _InsertEndpointToPipe. EvaluateContext() sets the right TRDequePointer. Though this does reports context errors, as StopEndpoint, ResetEndpoint, SetTRDequePointer Commands are called, with the endpoint in disabled state. This can be repaired. I will look into it. Also SetTRDequePointer doesn't handle Deque Cycle State flag.

[jessicah]

Attached syslogs from testing current patch for xhci (others disabled in my image). No working mouse & keyboard; however, booted to desktop without a problem.

[akshay1994]

It seems from the syslog that the controller starts okay.

The HC as jessicah mentioned -> Output from lspci -v -nn on Ubuntu Server gives me the following output:

00:14:0 USB controller [0c03]: Intel Corporation Lynx Point-LP USB xHCI HC [8086:9c31] (rev 04) (prog-if 30 [XHCI])

Subsystem: Intel Corporation Device [8086:2054] Flags: bus master, medium devsel, latency 0, IRQ 58 Memory at f7c20000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd

Probably, this is the same as the one mentioned in comment:5

[korli]

I checked without and with the patch on the Intel Lynx Point. Both cases work (no lock on init), but the ports are still routed to the EHCI controller. I'll try to enable routing It doesn't work on the Nec controller but doesn't crash either.

I wonder why hub support is needed. Hubs are discovered by explore thread in USB manager, and HubDevice are allocated there. Could you explain a bit?

[akshay1994]

Replying to korli:

I checked without and with the patch on the Intel Lynx Point. Both cases work (no lock on init), but the ports are still routed to the EHCI controller. I'll try to enable routing

Yes. But earlier it was checking the wrong extended capability register. For jessicah's case, the USB Legacy Support capability register was located at 0x8460, but it was looking at 0x8480 and wrongly believing that the controller is BIOS owned.

It doesn't work on the Nec controller but doesn't crash either.

I wonder why hub support is needed. Hubs are discovered by explore thread in USB manager, and HubDevice are allocated there. Could you explain a bit?

The explore thread calls GetBusManager()->AllocateDevice(), which in turn checks whether the newly connected device is a hub or a function. AllocateDevice() was made virtual in ​https://github.com/haiku/haiku/commit/319a3798bc05579e8be813c2524bc89864bae489, and we (re)implement it for XHCI. As a result, Hubs were getting allocated as devices. Also, we need to initialise the slot context accordingly for hubs.

P.S. -> Yes, routing needs to be enabled for both, Panther Point and Lynx Point. I can look into this, if you are busy!

[akshay1994]

Updates in patch ->

• Avoid Device-Slot and Memory leaks if device initialisation fails (look out for added "device->state = XHCI_STATE_DISABLED;" and "delete_area"s )
• Allocate area was allocating for just one TRB, while we needed (XHCI_MAX_ENDPOINTS-1)*(XHCI_MAX_TRANSFERS) (line 1068)
• Proper initialisation of slot context for HUBs
• Added Event handling for failed/stalled/etc. transfers
• Correction to SLOT_2_IRQ_TARGET

[akshay1994]

Hey Jerome! It seems like we need to switch over the ports, even before PCI enumerates them. Quoting from lkml (for Panther Point) ->

• The ports should be switched over to xHCI before PCI probes for any device start. This avoids active devices under EHCI being disconnected during the port switchover, which could cause loss of data on USB storage devices, or failed boot when the root file system is on a USB mass storage device and is enumerated under EHCI first.

[korli]

Replying to akshay1994:

Hey Jerome! It seems like we need to switch over the ports, even before PCI enumerates them. Quoting from lkml (for Panther Point) ->

I know but FreeBSD doesn't do that for some reason. In our case, I would suggest to move xhci before other buses ​here; this way ports can't be used by EHCI.

Once our USB stack use the device manager, yes, this could be a problem as the bus would be loaded on demand.

[akshay1994]

Replying to korli:

Replying to akshay1994:

Hey Jerome! It seems like we need to switch over the ports, even before PCI enumerates them. Quoting from lkml (for Panther Point) ->

I know but FreeBSD doesn't do that for some reason. In our case, I would suggest to move xhci before other buses ​here; this way ports can't be used by EHCI.

Did that already :)

Once our USB stack use the device manager, yes, this could be a problem as the bus would be loaded on demand.

[korli]

Replying to akshay1994:

Yes. But earlier it was checking the wrong extended capability register. For jessicah's case, the USB Legacy Support capability register was located at 0x8460, but it was looking at 0x8480 and wrongly believing that the controller is BIOS owned.

Agreed.

The explore thread calls GetBusManager()->AllocateDevice(), which in turn checks whether the newly connected device is a hub or a function. AllocateDevice() was made virtual in ​https://github.com/haiku/haiku/commit/319a3798bc05579e8be813c2524bc89864bae489, and we (re)implement it for XHCI. As a result, Hubs were getting allocated as devices. Also, we need to initialise the slot context accordingly for hubs.

Completely forgotten that point! Thanks!

[akshay1994]

Updates Updates!!

[akshay1994]

Updates ->

• Enabled port routing for Intel Panther and Lynx Point (7/8 Chipset) xHC

Confirmed boot on a USB 3.0 port, using a USB 2.0 Flash Drive (Sandisk 0781:5567), on an Intel 7 Chipset Panther Point xHC (8086:1e31)

[jessicah]

My touchpad doesn't work with these changes, but the keyboard does. The keyboard drops a significant number of keystrokes however.

Also, with listusb -v, it fails to retrieve the product & manufacturer strings and configuration for the touchpad, with significant delay for these lines.

time listusb -v: 0m7.125s 0m0.001s 0m0.684s

Also, the touchpad at /dev/bus/usb/0/0 should have Vendor ID of 0x24ae and Product ID of 0x1002.

[akshay1994]

Jessicah! Try with this. Log tells that the default endpoint becomes halted for your touchpad. Also, please enable TRACE in usb_raw.

Fixes

• XHCI can only tell the speed of the port, if the device is connected to a root hub port. For non-root hub ports, we need to believe the value sent by the Hub explore thread (which currently does not send the correct value, as we have it designed for only USB2.0 Hubs and not USB3.0 hubs)
• Fix max endpoint packet size for default control endpoint on full speed devices

P.S. - with this, I start on a new patch, to avoid cluttering the old one with too many changes!!

[jessicah]

Uploaded new versions of syslog & listusb. The touchpad does indeed now work!

However, I still seem to be experiencing weird packet loss with both the keyboard and mouse. Lost keystrokes, really, really slow mouse movements.

[akshay1994]

Jessicah, this will solve the issue!

Fix->

• Setting IRQ rate above 4000 irqs/second can cause IRQ lockups in Lynx Point xHC (current setting was 25000 irqs/second)

Now I need to see why is the usb stack unable to find any xHC on a mac book pro! With the keyboard not working, I should probably try a high frame rate camera to capture the logs :P

(Or if anyone can install haiku on a partition on mac. Call for help!!)

[akshay1994]

Fix

• Update slot input context for LS/FS devices connecting to non root HS hub

[korli]

I pushed the first patch, but had to edit a lot to:

• compile on gcc4
• fix code style

It works OK on Qemu with the few tests I did, but it locks up on my Intel Lynx Point. I'll try with the second patch.

[jessicah]

I'm still having the weird packet loss with keyboard & mouse after pulling in the 2 commits Jerome pushed. Do you need more log output again?

[akshay1994]

Replying to korli:

I pushed the first patch, but had to edit a lot to:

• compile on gcc4
• fix code style

I'll try to keep that in mind, the next time :)

It works OK on Qemu with the few tests I did, but it locks up on my Intel Lynx Point. I'll try with the second patch.

Log output for the Lynx Point will be a saviour!

[akshay1994]

Replying to jessicah:

I'm still having the weird packet loss with keyboard & mouse after pulling in the 2 commits Jerome pushed. Do you need more log output again?

Does it include ​https://github.com/haiku/haiku/commit/192f01c669102651bdc81273811079e90e0a29e5 ? If it does, then the problem must lie someplace else! Yes, log will help! (Send it at your preference, though. I can eat any amount of log you send me)

Btw, I was looking into booting on a MacBook, and I think this might be of some help! ​http://fxr.watson.org/fxr/source/i386/i386/machdep.c?v=FREEBSD10#L265

[korli]

syslog intel lp boot on ehci

[korli]

jessica, xhci logs a lot atm, it might be related to your packet loss.

I booted an anyboot image on the ehci controller, that's weird. It's like we fail to set the default configuration on the root hub. I'll try again with traces.

[akshay1994]

Replying to korli:

jessica, xhci logs a lot atm, it might be related to your packet loss.

I booted an anyboot image on the ehci controller, that's weird. It's like we fail to set the default configuration on the root hub. I'll try again with traces.

That's weird. You have the same controller as Jessica. (Though Jessica is testing with EHCI disabled) Looking at the log, the controller starts up, then generates some events (which I guess includes the first Noop test, and then enumeration of a device), fails the SetAddress command, then a few more events before blacking out completely.

Yes! We tried with the log disabled. The touchpad response improved, though the keyboard gets totally off (random keypresses), and click on the touchpad also malfunctions!

I'll look at endpoint context initialisation, see if I find some errors down there!

[akshay1994]

Pardon me! *Failed to set the default configuration like you said.

[korli]

Replying to akshay1994:

That's weird. You have the same controller as Jessica. (Though Jessica is testing with EHCI disabled) Looking at the log, the controller starts up, then generates some events (which I guess includes the first Noop test, and then enumeration of a device), fails the SetAddress command, then a few more events before blacking out completely.

I tried with TRACE_USB on xhci, it works then but as expected slowly because of the log amount. It must be a timing issue, isn't it?

[akshay1994]

Replying to jessicah:

I'm still having the weird packet loss with keyboard & mouse after pulling in the 2 commits Jerome pushed. Do you need more log output again?

Try with this one! I have made some changes to endpoint context initialisation :)

[akshay1994]

Replying to korli:

Replying to akshay1994:

That's weird. You have the same controller as Jessica. (Though Jessica is testing with EHCI disabled) Looking at the log, the controller starts up, then generates some events (which I guess includes the first Noop test, and then enumeration of a device), fails the SetAddress command, then a few more events before blacking out completely.

I tried with TRACE_USB on xhci, it works then but as expected slowly because of the log amount. It must be a timing issue, isn't it?

Even I am facing a similar problem. KDL with a flash drive with the TRACE set to off, while it works perfectly fine otherwise.

[korli]

Thanks for the patch. Could you clean up the coding style a bit, and provide a bit more information on the actual fixes? Don't hesitate to write your thoughts in the commit message, or reference the spec. For instance, 1800 as a mask for the maximum packet size. Why a max transfers count of 8?

[korli]

Replying to akshay1994:

Even I am facing a similar problem. KDL with a flash drive with the TRACE set to off, while it works perfectly fine otherwise.

Does the KDL happens in a USB-related thread? Or is it a locking issue?

[akshay1994]

Replying to korli:

Replying to akshay1994:

Even I am facing a similar problem. KDL with a flash drive with the TRACE set to off, while it works perfectly fine otherwise.

Does the KDL happens in a USB-related thread? Or is it a locking issue?

Not sure. The KDL happens while mounting the bfs volume on my flash drive, specifically in get_cached_block (could not read block...). Happens with the TRACE OFF. With the TRACE ON it works perfectly fine!!

I'll try without my latest changes, once. I think it just got introduced now!

[akshay1994]

Replying to korli:

Thanks for the patch. Could you clean up the coding style a bit, and provide a bit more information on the actual fixes? Don't hesitate to write your thoughts in the commit message, or reference the spec. For instance, 1800 as a mask for the maximum packet size. Why a max transfers count of 8?

I am so sorry! Will do that :)

Also, this still needs a lot of work. Jessica tested this out, and noticed no improvement.

[akshay1994]

Replying to akshay1994:

Replying to korli:

Does the KDL happens in a USB-related thread? Or is it a locking issue?

Not sure. The KDL happens while mounting the bfs volume on my flash drive, specifically in get_cached_block (could not read block...). Happens with the TRACE OFF. With the TRACE ON it works perfectly fine!!

I'll try without my latest changes, once. I think it just got introduced now!

Confirmed, it happens without the patch also. Fails at get_cached_block.

[akshay1994]

@korli I am having some problems with non-root FULL-SPEED USB Hubs. Its mixing up devices, not processing transfers, etc.

Trying to debug the issue, I got some doubts.

​https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/busses/usb/xhci.cpp#L1300 -> Why do we give this an Address equal to ( device->address + 1 ).

​https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/bus_managers/usb/Hub.cpp#L275 -> For Full Speed Hubs, this will make the device inherit its HubAddress (and HubPort). Won't this result in wrong (only upto Full Speed Hub) route calculations by XHCI. Accompanied with the difference in actual address assigned to device can this cause a problem?

[korli]

Replying to akshay1994:

​https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/busses/usb/xhci.cpp#L1300 -> Why do we give this an Address equal to ( device->address + 1 ).

The reason was the address provided to the USB stack had to be non zero: see ​https://github.com/haiku/haiku/commit/2b31b4a88cdcc94b3db80cd453b9fd366420873c It might not be a problem any more, dunno, but the root hub gets the address one anyway, so we offset.

​https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/bus_managers/usb/Hub.cpp#L275 -> For Full Speed Hubs, this will make the device inherit its HubAddress (and HubPort). Won't this result in wrong (only upto Full Speed Hub) route calculations by XHCI. Accompanied with the difference in actual address assigned to device can this cause a problem?

Good question. We use AllocateAddress() for the root hub (which returns 1). I suppose the device address should be used minus one for calculations.

[jessicah]

I've actually noticed that Haiku seems to stall/lock up for long periods of time with heavy USB activity with the non-xhci USB controllers; so maybe the problem with XHCI on my system might be in a completely different layer of USB/kernel, related to these bizarre stalls I've been experiencing.

For instance, during such a stall/lockup, I can't even close some apps, and in a Terminal, CTRL+C would do nothing at all until the stall had finished. Some parts of the system are still responsive, but definitely a big lock somewhere.

This might also be related to tickets #11010 and #11049. However, I don't really know how to debug, as I don't have a functional keyboard in KDL.

[akshay1994]

Replying to jessicah:

Or maybe a problem with the HID driver (or even HID/USB interface). There is a thread going on in the ML, ​http://www.freelists.org/post/haiku/Touchpad-problems. Though this is for a PS2 touchpad.

[jessicah]

Replying to akshay1994:

Replying to jessicah:

Or maybe a problem with the HID driver (or even HID/USB interface). There is a thread going on in the ML, ​http://www.freelists.org/post/haiku/Touchpad-problems. Though this is for a PS2 touchpad.

Mm, unlikely. All it was doing was disk IO and CPU. Wasn't using HID devices at all during the stalls. I will try again later today/tomorrow if the merged UCHI fixes have any effect. The problem disappears when running from the internal SSD; so that alone should be sufficient to point at problems in the USB stack.

FWIW, for the longest time, on real hardware, I've always had problems with the mouse pausing for some time (see #8939). So I suspect this bug isn't at all new; just exacerbated with XHCI, or high workloads for USB 2.

[akshay1994]

Fixes

• Fix Endpoint Context Initialisation (Refer xHCI v1.1 - 6.2.3)
• Fix Interval Calculation (Refer xHCI v1.1 - 6.2.3.6 , USB 2.0 - 9.6.6 page 271)
• Fix MaxBurst, MaxPacketSize Calculation (Refer xHCI v1.1 - 6.2.3.5, USB 2.0 - 9.6.6 page 271)
• Fix MaxESITPayload Calculation (Refer xHCI v1.1 - 4.14.2)
• Remove Link TRBs as they were never being used
• Increase Number of TRBs per endpoint (to utilise the whole area allocated for Device TRBs)
• Fix usage of XHCI_MAX_ENDPOINTS (most of the checks were failing at corner cases)
• Few Coding Guideline fixes (reported by style checker script)

I still get a KDL if I connect a mass storage device with the logs disabled.

[korli]

Thanks for the patch.

• XHCI::ConfigureEndpoint() the coding style isn't right, and the "if"s should probably be exclusive.

[akshay1994]

Replying to korli:

Thanks for the patch.

• XHCI::ConfigureEndpoint() the coding style isn't right,

Can you point out the error. I'm still not too good with the coding style guidelines :(

and the "if"s should probably be exclusive.

This will increase the code length, but yes it would become easier to read and understand. I'll change it if this is the preferred way.

[pulkomandy]

Always prefer clarity over shortness. The compiler will optimize :)

Style issues I could see: dont write:

if (foo)
{

do write:

if (foo) {

(same for while, for, switch)

When the body of an if or while is single line, don't add braces.

Your computation of calcInterval from interval sounds inefficient. I think you want the log2 of interval*8 (or log2 of interval + 3), which can be computed in several more efficient ways: ​https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObvious

Since such bit operations are sometimes unclear, you may want to extract this to a separate function with an appropriate name (int_log2 maybe?)and comments on where the algorithm comes from if using the non-obvious way. We may already have some functions like this in headers/private/shared.

[dsjonny]

I have tried the latest nightly anyboot image (hrev47855 x86_gcc2) on a Lenovo T430 laptop and can boot Haiku only on the USB 2.0 port. I have tried it with an USB 2.0 and USB 3.0 pendrive. On USB 3.0 port I always got kdl during boot:

PANIC: did not find any boot partitions!
Welcome to Kernel Debugging Land...
Thread 18 "main2" running on CPU 2
stack trace for thread 18 "main2"
    kernel stack: 0x81a60000 to 0x81a64000
frame               caller     <image>:function + offset
 0 81a63998 (+  32) 8013eb96   <kernel_x86> arch_debug_stack_trace() + 0x12
 1 81a639b8 (+  16) 800a0cd7   <kernel_x86> stack_trace_trampoline__FPv() + 0x0b
 2 81a639c8 (+  12) 80130bc6   <kernel_x86> arch_debug_call_with_fault_handler() + 0x1b
 3 81a639d4 (+  48) 800a27a7   <kernel_x86> debug_call_with_fault_handler() + 0x5f
 4 81a63a04 (+  64) 800a0eeb   <kernel_x86> kernel_debugger_loop__FPCcT0Pcl() + 0x20f
 5 81a63a44 (+  48) 800a128f   <kernel_x86> kernel_debugger_internal__FPCcT0Pcl() + 0x77
 6 81a63a74 (+  48) 800a2b1a   <kernel_x86> panic() + 0x3a
 7 81a63aa4 (+1200) 800f6770   <kernel_x86> vfs_mount_boot_file_system() + 0x80
 8 81a63f54 (+  96) 80061c1d   <kernel_x86> main2__FPv() + 0xad
 9 81a63fb4 (+  48) 800810e2   <kernel_x86> common_thread_entry__FPv() + 0x3a
kdebug> 

On the USB 2.0 port I can boot Haiku any time from any USB drive.

I have attached the syslogs (the failed and the success).

The device in the laptop is:

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 8086: Intel Corporation
  device 1e31: 7 Series/C210 Series Chipset Family USB xHCI Host Controller

I hope these can help something.

[dsjonny]

I forgot something: the USB 3.0 does not working too when successfully booted from USB 2.0. If I connect any devices to the USB 3.0 port Haiku cannot use those (like USB 2.0 mouse, keyboard).

[akshay1994]

Since USB3.0 support is not yet complete, it is not enabled by default on the nightlies. You need to compile it from source to test it. :)

Replying to dsjonny:

I forgot something: the USB 3.0 does not working too when successfully booted from USB 2.0. If I connect any devices to the USB 3.0 port Haiku cannot use those (like USB 2.0 mouse, keyboard).

[anevilyak]

(In #11256) As those two tickets already address everything mentioned in this one, there's no reason for it to exist.

[waddlesplash]

Not sure why this ticket doesn't say so, but the first patch ("0001-XHCI-Fixes.patch​") was committed in hrev47481, and the second ("0001-XHCI-More-Fixes.patch") in hrev47483, so they should be marked as obsolete.

At the time of writing, the only non-committed patch is "0001-XHCI.patch".

[waddlesplash]

Following Ithamar's fixes to the USB stack in hrev49000, are the stall/hang problems mentioned above resolved?

[waddlesplash]

Applied the last patch in hrev49948.

[pulkomandy]

Hi, I tried to use the XHCI driver on my laptop, with yet another USB chipset (after adding it to the whitelist, of course).

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 104c: Texas Instruments
  device 8241: TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller

It fails to configure my USB mouse when I plug it:

KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci -1: event[1] = 34 (0x0000000001000000 0x01000000 0x00008801)
KERN: usb xhci -1: KERN: event[1] = 34 (0x0000000001000000 0x01000000 0x00008801)
KERN: usb xhci -1: KERN: port change detected
KERN: usb xhci -1: KERN: event[2] = 0 (0x0000000000000000 0x00000000 0x00000000)
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00020ae1
KERN: usb xhci roothub: request: 1
KERN: usb xhci roothub: clear feature: 16
KERN: usb xhci -1: KERN: clear port feature index 0 feature 16
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 3
KERN: usb xhci roothub: set feature: 4
KERN: usb xhci -1: KERN: set port feature index 0 feature 4
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: Last message repeated 1 time
KERN: usb xhci -1: KERN: event[2] = 34 (0x0000000001000000 0x01000000 0x00008801)
KERN: usb xhci roothub: request: 1
KERN: usb xhci -1: KERN: usb xhci roothub: clear feature: 20
KERN: usb xhci -1: Last message repeated 1 time
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 0 status=0x00000a03
KERN: usb xhci -1: AllocateDevice hubAddress 1 hubPort 1 speed 3
KERN: usb xhci -1: KERN: Enable Slot
KERN: usb xhci -1: KERN: command[1] = 9 (0x0000000000000000, 0x00000000, 0x00002400)
KERN: usb xhci -1: Ding Dong! slot:0 endpoint 0
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci -1: event[3] = 33 (0x000000000a99cd50 0x01000000 0x01008401)
KERN: usb xhci -1: KERN: event[3] = 33 (0x000000000a99cd50 0x01000000 0x01008401)
KERN: usb xhci -1: KERN: Received command event
KERN: usb xhci -1: event[4] = 0 (0x0000000000000000 0x00000000 0x00000000)
KERN: usb xhci -1: Command Complete
KERN: usb xhci -1: KERN: Storing trb 0x01000000 0x01008401
KERN: usb xhci -1: speed updated 0
KERN: usb xhci -1: KERN: slot 0x8200000 0x10000 0x0 0x0
KERN: usb xhci -1: KERN: endpoint 0x0 0x80026 0x15907001 0x8
KERN: usb xhci -1: KERN: Set Address
KERN: usb xhci -1: KERN: command[2] = b (0x0000000011dc0000, 0x00000000, 0x01002c00)
KERN: usb xhci -1: KERN: Ding Dong! slot:0 endpoint 0
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci -1: event[4] = 33 (0x000000000a99cd60 0x13000000 0x01008401)
KERN: usb xhci -1: KERN: event[4] = 33 (0x000000000a99cd60 0x13000000 0x01008401)
KERN: usb xhci -1: KERN: Received command event
KERN: usb xhci -1: usb xhci -1: KERN: event[5] = 0 (0x0000000000000000 0x00000000 0x00000000)
KERN: usb error xhci -1: KERN: unsuccessful command Context state (19)
KERN: usb xhci -1: KERN: Storing trb 0x13000000 0x01008401
KERN: usb error xhci -1: KERN: unable to set address
KERN: usb xhci roothub: request: 1
KERN: usb xhci roothub: clear feature: 1
KERN: usb xhci -1: KERN: clear port feature index 0 feature 1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 3
KERN: usb xhci roothub: set feature: 4
KERN: usb xhci -1: KERN: set port feature index 0 feature 4
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: usb xhci -1: event[5] = 34 (0x0000000001000000 0x01000000 0x00008801)
KERN: usb xhci -1: KERN: usb xhci roothub: request: 1
KERN: usb xhci roothub: clear feature: 20
KERN: usb xhci -1: KERN: usb xhci -1: port change detected
KERN: usb xhci -1: KERN: event[6] = 0 (0x0000000000000000 0x00000000 0x00000000)
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 0 status=0x00000a03
KERN: usb xhci -1: AllocateDevice hubAddress 1 hubPort 1 speed 3
KERN: usb xhci -1: KERN: Enable Slot
KERN: usb xhci -1: KERN: command[3] = 9 (0x0000000000000000, 0x00000000, 0x00002400)
KERN: usb xhci -1: KERN: Ding Dong! slot:0 endpoint 0
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci -1: event[6] = 33 (0x000000000a99cd70 0x01000000 0x02008401)
KERN: usb xhci -1: KERN: event[6] = 33 (0x000000000a99cd70 0x01000000 0x02008401)
KERN: usb xhci -1: KERN: Received command event
KERN: usb xhci -1: Last message repeated 1 time
KERN: usb xhci -1: KERN: Storing trb 0x01000000 0x02008401
KERN: usb xhci -1: speed updated 0
KERN: usb xhci -1: KERN: slot 0x8200000 0x10000 0x0 0x0
KERN: usb xhci -1: KERN: endpoint 0x0 0x80026 0x15907001 0x8
KERN: usb xhci -1: KERN: Set Address
KERN: usb xhci -1: KERN: command[4] = b (0x0000000011dc0000, 0x00000000, 0x02002c00)
KERN: usb xhci -1: KERN: Ding Dong! slot:0 endpoint 0
KERN: usb xhci -1: Event Interrupt
KERN: usb xhci -1: event[7] = 33 (0x000000000a99cd80 0x13000000 0x02008401)
KERN: usb xhci -1: KERN: event[7] = 33 (0x000000000a99cd80 0x13000000 0x02008401)
KERN: usb xhci -1: KERN: Received command event
KERN: usb xhci -1: Last message repeated 1 time
KERN: usb error xhci -1: KERN: unsuccessful command Context state (19)
KERN: usb xhci -1: KERN: Storing trb 0x13000000 0x02008401
KERN: usb error xhci -1: KERN: unable to set address
KERN: usb xhci roothub: request: 1
KERN: usb xhci roothub: clear feature: 1
KERN: usb xhci -1: KERN: clear port feature index 0 feature 1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 3 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 0 status=0x00000ae1
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: KERN: port 1 status=0x000002a0
KERN: usb xhci roothub: request: 0
KERN: usb xhci -1: port 2 status=0x000002a0
KERN: usb xhci roothub: request: 0

[kallisti5]

SkyLake-xhci-1.1-wl-log

[kallisti5]

More random logs to help. hrev50247 plus SkyLake white list and USB debug. This is an xHCI 1.1 system booting from usb (with lots of errors)

[korli]

Replying to pulkomandy:

I tried to use the XHCI driver on my laptop, with yet another USB chipset (after adding it to the whitelist, of course).

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 104c: Texas Instruments
  device 8241: TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller

Please try again (with whitelisting of course), it might work better after hrev50378.

[korli]

Replying to dsjonny:

The device in the laptop is:

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 8086: Intel Corporation
  device 1e31: 7 Series/C210 Series Chipset Family USB xHCI Host Controller

This device is as of hrev50378 whitelisted. Please check with a nightly.

[kallisti5]

My Asus ZenBook has the 1e31 USB chipset.

Chipsets seem to work with a few bugs...

On usb insertion (USB 2 or 3 device)

"unsuccessful command Parameter (17)"

A few canceled queues on plug and unplug of all USB devices.

• USB 2 device - Working 38 MB test file copied
• Reboot
• USB 3 device - Working 1 MB test file copied
• Unplug USB 3 device, disappears
• Replug same USB 3 device... doesn't show up

[waddlesplash]

"USB Tablet" pointing device now works under VirtualBox XHCI as well (it was totally busted before; mouse jumped/stalled all over the place.) Perhaps it's time to enable USB3 for all controllers by default?

[edglex]

Hi I have another here that isn't working. Do you have to enable this somehow (at build time?)? Anyway, I have a different PCI ID again so could it be added?

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])

[kallisti5]

A comment on the whitelist thing.. I know later skylake USB hosts don't function in non-XHCI mode. It might almost be time to enable this as later generations seem to work a little with XHCI vs not at all with non-XHCI.

[edglex]

Replying to kallisti5:

A comment on the whitelist thing.. I know later skylake USB hosts don't function in non-XHCI mode. It might almost be time to enable this as later generations seem to work a little with XHCI vs not at all with non-XHCI.

Yeah both my current desktop and laptop are USB 3 only (and without optical drives), so the only option to install haiku is to dd an image now. The desktop is also 2 years old already...

[waddlesplash]

The XHCI bus controller was enabled by default for all chipsets in hrev50451. If your chipset is still broken, please open a new ticket, as it's out of the scope of this issue.