Opened 12 years ago

Closed 8 years ago

Last modified 6 years ago

#8954 closed enhancement (fixed)

USB3 support

Reported by: dsjonny Owned by: korli
Priority: high Milestone: Unscheduled
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: usb3 Cc: akshay1994.leo@…
Blocked By: Blocking: #10750, #11169, #11256, #11648
Platform: All

Description

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

Attachments (14)

xhci.txt (24.1 KB ) - added by dsjonny 10 years ago.
syslog (85.6 KB ) - added by jessicah 10 years ago.
syslog.old (512.0 KB ) - added by jessicah 10 years ago.
syslog-no-xhci-patches.log (130.7 KB ) - added by jessicah 10 years ago.
0001-XHCI-Fixes.patch (25.2 KB ) - added by akshay1994 10 years ago.
Updates Updates!!
syslog.txt (11.4 KB ) - added by jessicah 10 years ago.
syslog.old.txt (512.0 KB ) - added by jessicah 10 years ago.
listusb.txt (5.0 KB ) - added by jessicah 10 years ago.
0001-XHCI-More-Fixes.patch (6.1 KB ) - added by akshay1994 10 years ago.
syslog-intel-lp.txt (189.9 KB ) - added by korli 10 years ago.
syslog intel lp boot on ehci
0001-XHCI.patch (13.0 KB ) - added by akshay1994 10 years ago.
Lenovo-syslog-failed (56.9 KB ) - added by dsjonny 10 years ago.
Lenovo-syslog-success (159.7 KB ) - added by dsjonny 10 years ago.
syslog.2.old (512.0 KB ) - added by kallisti5 8 years ago.
SkyLake-xhci-1.1-wl-log

Change History (97)

comment:1 by anevilyak, 12 years ago

Owner: changed from mmlr to korli
Status: newassigned
Type: bugenhancement
Version: R1/alpha4R1/Development

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.

comment:2 by dsjonny, 10 years ago

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.

comment:3 by korli, 10 years ago

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).

comment:4 by umccullough, 10 years ago

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.

comment:5 by korli, 10 years ago

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)

comment:6 by dsjonny, 10 years ago

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

Last edited 10 years ago by dsjonny (previous) (diff)

by dsjonny, 10 years ago

Attachment: xhci.txt added

comment:7 by umccullough, 10 years ago

Keywords: usb3 added
Summary: USB 3 supportUSB3 support

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

comment:8 by jessicah, 10 years ago

Milestone: R1R1/alpha5
Priority: normalhigh

comment:9 by jessicah, 10 years ago

Blocking: 7665, 10750 added

comment:10 by waddlesplash, 10 years ago

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 :)

comment:11 by pulkomandy, 10 years ago

Milestone: R1/alpha5Unscheduled

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.

comment:12 by korli, 10 years ago

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

comment:13 by akshay1994, 10 years ago

patch: 01
Last edited 10 years ago by akshay1994 (previous) (diff)

comment:14 by akshay1994, 10 years ago

Cc: akshay1994.leo@… added

comment:15 by akshay1994, 10 years ago

patch: 10

comment:16 by akshay1994, 10 years ago

patch: 01

comment:17 by jessicah, 10 years ago

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);

comment:18 by korli, 10 years ago

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

comment:19 by akshay1994, 10 years ago

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.

comment:20 by akshay1994, 10 years ago

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.

comment:21 by akshay1994, 10 years ago

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.

comment:22 by akshay1994, 10 years ago

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.

by jessicah, 10 years ago

Attachment: syslog added

by jessicah, 10 years ago

Attachment: syslog.old added

comment:23 by jessicah, 10 years ago

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

comment:24 by akshay1994, 10 years ago

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

by jessicah, 10 years ago

Attachment: syslog-no-xhci-patches.log added

comment:25 by korli, 10 years ago

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?

in reply to:  25 ; comment:26 by akshay1994, 10 years ago

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!

comment:27 by akshay1994, 10 years ago

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

comment:28 by akshay1994, 10 years ago

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.

in reply to:  28 ; comment:29 by korli, 10 years ago

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.

in reply to:  29 comment:30 by akshay1994, 10 years ago

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.

in reply to:  26 comment:31 by korli, 10 years ago

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!

by akshay1994, 10 years ago

Attachment: 0001-XHCI-Fixes.patch added

Updates Updates!!

comment:32 by akshay1994, 10 years ago

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)

comment:33 by jessicah, 10 years ago

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.

Last edited 10 years ago by jessicah (previous) (diff)

comment:34 by akshay1994, 10 years ago

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!!

by jessicah, 10 years ago

Attachment: syslog.txt added

by jessicah, 10 years ago

Attachment: syslog.old.txt added

by jessicah, 10 years ago

Attachment: listusb.txt added

comment:35 by jessicah, 10 years ago

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.

comment:36 by akshay1994, 10 years ago

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!!)

comment:37 by akshay1994, 10 years ago

Fix

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

by akshay1994, 10 years ago

Attachment: 0001-XHCI-More-Fixes.patch added

comment:38 by korli, 10 years ago

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.

comment:39 by jessicah, 10 years ago

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?

in reply to:  38 comment:40 by akshay1994, 10 years ago

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!

in reply to:  39 comment:41 by akshay1994, 10 years ago

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

by korli, 10 years ago

Attachment: syslog-intel-lp.txt added

syslog intel lp boot on ehci

comment:42 by korli, 10 years ago

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.

in reply to:  42 ; comment:43 by akshay1994, 10 years ago

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!

comment:44 by akshay1994, 10 years ago

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

in reply to:  43 ; comment:45 by korli, 10 years ago

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?

in reply to:  39 comment:46 by akshay1994, 10 years ago

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 :)

in reply to:  45 ; comment:47 by akshay1994, 10 years ago

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.

comment:48 by korli, 10 years ago

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?

in reply to:  47 ; comment:49 by korli, 10 years ago

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?

in reply to:  49 ; comment:50 by akshay1994, 10 years ago

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!

in reply to:  48 comment:51 by akshay1994, 10 years ago

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.

in reply to:  50 comment:52 by akshay1994, 10 years ago

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.

comment:53 by akshay1994, 10 years ago

@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?

in reply to:  53 comment:54 by korli, 10 years ago

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.

comment:55 by jessicah, 10 years ago

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.

in reply to:  55 ; comment:56 by akshay1994, 10 years ago

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.

in reply to:  56 comment:57 by jessicah, 10 years ago

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.

by akshay1994, 10 years ago

Attachment: 0001-XHCI.patch added

comment:58 by akshay1994, 10 years ago

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.

comment:59 by korli, 10 years ago

Thanks for the patch.

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

in reply to:  59 comment:60 by akshay1994, 10 years ago

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.

comment:61 by pulkomandy, 10 years ago

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.

comment:62 by diver, 10 years ago

Blocking: 11169 added

comment:63 by dsjonny, 10 years ago

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.

by dsjonny, 10 years ago

Attachment: Lenovo-syslog-failed added

by dsjonny, 10 years ago

Attachment: Lenovo-syslog-success added

comment:64 by dsjonny, 10 years ago

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).

in reply to:  64 comment:65 by akshay1994, 10 years ago

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).

comment:66 by anevilyak, 10 years ago

Blocking: 11256 added

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

comment:67 by phoudoin, 9 years ago

Blocking: 11648 added

comment:68 by waddlesplash, 9 years ago

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".

comment:69 by waddlesplash, 9 years ago

Component: Drivers/USBDrivers/USB/XHCI

comment:70 by waddlesplash, 9 years ago

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

comment:71 by waddlesplash, 8 years ago

Applied the last patch in hrev49948.

comment:72 by waddlesplash, 8 years ago

patch: 10

comment:73 by pulkomandy, 8 years ago

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

by kallisti5, 8 years ago

Attachment: syslog.2.old added

SkyLake-xhci-1.1-wl-log

comment:74 by kallisti5, 8 years ago

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)

in reply to:  73 comment:75 by korli, 8 years ago

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.

in reply to:  63 comment:76 by korli, 8 years ago

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.

comment:77 by kallisti5, 8 years ago

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
Last edited 8 years ago by kallisti5 (previous) (diff)

comment:78 by waddlesplash, 8 years ago

"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?

comment:79 by edglex, 8 years ago

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])

Version 1, edited 8 years ago by edglex (previous) (next) (diff)

comment:80 by kallisti5, 8 years ago

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.

in reply to:  80 comment:81 by edglex, 8 years ago

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...

comment:82 by waddlesplash, 8 years ago

Resolution: fixed
Status: assignedclosed

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.

comment:83 by waddlesplash, 6 years ago

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.