Raspberry Pi4 : USB "xHCI host controller not responding"

[jmmec]

Hello,

I have a USB2 device (it holds a Sierra Wireless EM7565 for LTE internet access) connected to a Pi4. Nothing else is connected to the USB ports on the Pi4. The Pi4 has also has an ethernet cable attached & power supply. That's it.

The problem below started appearing after linux-raspberrypi4-4.19.83, where I've confirmed that it is reproducible in .86 and .88, but haven't yet confirmed if it also occurs in .84 or .85:

$this->bbcode_second_pass_code('', '[ 466.401527] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[ 466.417572] xhci_hcd 0000:01:00.0: Host halt failed, -110
[ 466.417598] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[ 466.417931] xhci_hcd 0000:01:00.0: HC died; cleaning up
[ 466.418382] usb 1-1: USB disconnect, device number 2
[ 466.418411] usb 1-1.4: USB disconnect, device number 3
[ 466.418434] usb 1-1.4.5: USB disconnect, device number 4
[ 466.419019] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[ 466.419142] qcserial 1-1.4.5:1.0: device disconnected
[ 466.419946] qmi_wwan 1-1.4.5:1.8: Error submitting int urb - -19
[ 466.425191] qcserial ttyUSB1: Qualcomm USB modem converter now disconnected from ttyUSB1
[ 466.425311] qcserial 1-1.4.5:1.2: device disconnected
[ 466.425855] qcserial ttyUSB2: Qualcomm USB modem converter now disconnected from ttyUSB2
[ 466.425946] qcserial 1-1.4.5:1.3: device disconnected
[ 466.426323] qmi_wwan 1-1.4.5:1.8 wwan0: unregister 'qmi_wwan' usb-0000:01:00.0-1.4.5, WWAN/QMI device
')

I've tried the following combinations and the problem is always reproducible after after 4.19.83:

• Plug the USB2 device into a Pi4 USB3 port
• Plug the USB2 device into a Pi4 USB2 port
• Plug the USB2 device into a powered USB2 hub which is then plugged into a Pi4 USB2 port

Any ideas? Workarounds?

I stumbled upon this patch in 5.3:

https://github.com/chewitt/linux/commit ... 978b603935

Which was referenced here, where the person was hitting the XHCI problem with a USB mouse / keyboard ("the problem also occurs without the disk ... At the moment there is just a mouse and a keyboard connected ..."):

https://forum.manjaro.org/t/kernel-xhci ... and/116108

Where this is a summary of the problem for an Amlogic device, so no idea if it might apply to Pi4:

$this->bbcode_second_pass_quote('', 'I')n certain circumstances, the XHCI SuperSpeed instance in park mode
can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
load on the single XHCI SuperSpeed instance, the controller can crash like:
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
usb 2-1.1-port1: cannot reset (err = -22)

Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
the issue. The bit is described as :
"When this bit is set to '1' all SS bus instances in park mode are disabled"

https://lore.kernel.org/linux-amlogic/2 ... e.com/T/#t

[themoseon]

$this->bbcode_second_pass_quote('', 'H')ello,

I have a USB2 device (it holds a Sierra Wireless EM7565 for LTE internet access) connected to a Pi4. Nothing else is connected to the USB ports on the Pi4. The Pi4 has also has an ethernet cable attached & power supply. That's it.

The problem below started appearing after linux-raspberrypi4-4.19.83, where I've confirmed that it is reproducible in .86 and .88, but haven't yet confirmed if it also occurs in .84 or .85:

CODE: SELECT ALL
[ 466.401527] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[ 466.417572] xhci_hcd 0000:01:00.0: Host halt failed, -110
[ 466.417598] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[ 466.417931] xhci_hcd 0000:01:00.0: HC died; cleaning up
[ 466.418382] usb 1-1: USB disconnect, device number 2
[ 466.418411] usb 1-1.4: USB disconnect, device number 3
[ 466.418434] usb 1-1.4.5: USB disconnect, device number 4
[ 466.419019] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[ 466.419142] qcserial 1-1.4.5:1.0: device disconnected
[ 466.419946] qmi_wwan 1-1.4.5:1.8: Error submitting int urb - -19
[ 466.425191] qcserial ttyUSB1: Qualcomm USB modem converter now disconnected from ttyUSB1
[ 466.425311] qcserial 1-1.4.5:1.2: device disconnected
[ 466.425855] qcserial ttyUSB2: Qualcomm USB modem converter now disconnected from ttyUSB2
[ 466.425946] qcserial 1-1.4.5:1.3: device disconnected
[ 466.426323] qmi_wwan 1-1.4.5:1.8 wwan0: unregister 'qmi_wwan' usb-0000:01:00.0-1.4.5, WWAN/QMI device


I've tried the following combinations and the problem is always reproducible after after 4.19.83:
Plug the USB2 device into a Pi4 USB3 port
Plug the USB2 device into a Pi4 USB2 port
Plug the USB2 device into a powered USB2 hub which is then plugged into a Pi4 USB2 port

Any ideas? Workarounds?

I stumbled upon this patch in 5.3:

https://github.com/chewitt/linux/commit ... 978b603935

Which was referenced here, where the person was hitting the XHCI problem with a USB mouse / keyboard ("the problem also occurs without the disk ... At the moment there is just a mouse and a keyboard connected ..."):

https://forum.manjaro.org/t/kernel-xhci ... and/116108

Where this is a summary of the problem for an my coles roster Amlogic device, so no idea if it might apply to Pi4:

In certain circumstances, the XHCI SuperSpeed instance in park mode
can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
load on the single XHCI SuperSpeed instance, the controller can crash like:
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
usb 2-1.1-port1: cannot reset (err = -22)

Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
the issue. The bit is described as :
"When this bit is set to '1' all SS bus instances in park mode are disabled"

https://lore.kernel.org/linux-amlogic/2 ... e.com/T/#t


For now I've downgraded the kernel to 4.19.83 which is stable.

Thanks!
jmmec

Posts: 8
Joined: Wed Mar 01, 2017 2:06 am
Top

[graysky]

To which physical USB is it connected? I had an issue with mine using a USB thumbdrive... the thing only works in 1/2 of the on board slots. Can't remember details. Perhaps the blue ones were bad for it (other devices worked fine).

[jmmec]

FWIW, I don't have a solution, but two things:

1. I moved the SD card to a second PI4 (and attached the USB2 device), and booted up, and it never hits the xHCI problem. It works fine, regardless if I plug the USB2 device into USB2 or USB3 ports, and regardless of the linux image (old image versus new image).

The original PI4 always hits the xHCI problem when running a newer kernel image: sometimes immediately, and sometimes within a few hours, but always always always.

2. I've been following the VL805 USB firmware updates that are discussed on the raspberry forum. They recently made a new beta version available as discussed in this thread:

https://www.raspberrypi.org/forums/view ... 9&t=260879

I upgraded the problem PI4 with the USB firmware, and it still hits the xHCI problem on newer linux images. Hmm...

Maybe the problematic PI4 has some sort of hardware fault? My other PI4 seems to work OK and never hits the problem.

[nf3rn0]

I think I have a similar problem with my FX-Audio USB DAC. I have to unplug it until after I have loaded a window manager. In my case I am using Sway.

Like jmmec said it does not happen immediately but it always pops back up at some point.

$this->bbcode_second_pass_code('', '4.19.102-1-ARCH #1 SMP PREEMPT Sun Feb 9 13:36:25 MST 2020 aarch64 GNU/Linux')


Edit:

FWIW I am using a USB thumb drive for my filesystem. I have tested an exact setup on raspbian (also loading the filesystem from a usb) and it seems to not have these issues.