mjhjmtu

I'm trying to install a CSL USB 3.0 express card to my Arch Linux system.

However, when I do this, I get the following error message:

xhci_hcd 0000:05:00.0: xHCI host controller not responding, assume dead

xhci_hcd 0000:05:00.0: HC died; cleaning up

I googled and tried adding the following kernal parameters

intel_iommu=off

Some sites also mention

iommu

This unfortunately didn't help me anything.

I also tried to add:

pciehp pciehp_force=1

And tried to do

sudo modprobe pciehp pciehp_force=1

But Arch Linux complains that it doesn't find the kernel module pciehp.

I didn't find any information on how to install pciehp kernel module on Arch Linux. Some say, it is build into the kernel or something.

debug information:

kernel version: 4.16.6-1-ARCH

dmesg with debugging xhci_hcd enabled and with xhci_hcd greped

lspci -nn:

05:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller [1912:0015] (rev 02)

dmesg (old without xhci_hcd-debugging and withouth grep

Hm. Unless I'm overlooking something, it looks like the controller is initialized twice:

[ 5.195136] xhci_hcd 0000:05:00.0: xHCI Host Controller
[ 5.195145] xhci_hcd 0000:05:00.0: new USB bus registered, assigned bus number 3
[ 5.202621] xhci_hcd 0000:05:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x00000090
....
[ 5.203568] xhci_hcd 0000:05:00.0: xHCI Host Controller
[ 5.203572] xhci_hcd 0000:05:00.0: new USB bus registered, assigned bus number 4
[ 5.204014] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.

The Renesas Product Info seems to say that while there are two ports each for each USB 3.0/USB 2.0 legacy root hub, there's only one root hub, so I don't understand what's going on.

If two instances of xhci_hcd are trying to control the card at the same time, then of course this will go wrong.

Next thing I'd do is to look at the xhci_hcd source, and recompile with debugging support. This requires programming experience, so if you don't know how to do that, alternatively file a bug report on whatever kernel bugtracker handles xhci_hcd, even if the devs just tell you that I am stupid and the repeated initialization is normal.

Edit

Inspecting the debug messages, this here looks very odd:

[ 2.423207] xhci_hcd 0000:05:00.0: Finished xhci_run for USB2 roothub
[ 2.423420] xhci_hcd 0000:05:00.0: Endpoint 0x81 ep reset callback called
[ 2.423547] xhci_hcd 0000:05:00.0: set port power, actual port 0 status = 0x2a0
[ 2.423563] xhci_hcd 0000:05:00.0: set port power, actual port 1 status = 0x2a0
[ 2.423613] xhci_hcd 0000:05:00.0: xHCI Host Controller
[ 2.423616] xhci_hcd 0000:05:00.0: new USB bus registered, assigned bus number 2
[ 2.423621] xhci_hcd 0000:05:00.0: // Turn on HC, cmd = 0x5.
[ 2.426468] xhci_hcd 0000:05:00.0: Finished xhci_run for USB3 roothub
[ 2.426630] xhci_hcd 0000:05:00.0: Endpoint 0x81 ep reset callback called
[ 2.426798] xhci_hcd 0000:05:00.0: set port power, actual port 0 status = 0x2a0
[ 2.426819] xhci_hcd 0000:05:00.0: set port power, actual port 1 status = 0x2a0
[ 2.426893] xhci_hcd 0000:05:00.0: remove, state 1
[ 2.427674] xhci_hcd 0000:05:00.0: USB bus 2 deregistered
[ 2.427731] xhci_hcd 0000:05:00.0: remove, state 1

So after initializing everything, a reset gets called on both the USB 2.0 and the USB 3.0 root hub. They get removed, and then the driver tries to initialize the whole thing again (which is the second initialization I saw). Only this time it fails hard.

In the kernel source code, function xhci_endpoint_reset has comments along the lines "We might need to implement the config ep cmd in xhci 4.8.1" and "For now just print debug to follow the situation".

So this is definitely a case for the kernel developers. Make sure to amend the bug report with the debug output.

I'm having the same or a similar problem. Did open a thread here:
https://bbs.archlinux.org/viewtopic.php?pid=1784837

My testing came to the result, that it showed up with kernel 4.12.8-1-ARCH.
And in another laptop, this same card works - now with linux 4.15.15.