4.15.17-3 - xHCI host controller not responding

loomes

Renowned Member
May 22, 2018
113
27
68
44
Ist gestern bei mir passiert:
Code:
[Jul 5 22:48] xhci_hcd 0000:39:00.0: xHCI host controller not responding, assume dead
[  +0,000622] xhci_hcd 0000:39:00.0: HC died; cleaning up

Scheint wohl ein Kernel Bug zu sein soweit ich in Erfahrung bringen konnte?! Ein Patch scheint es auch zu geben: https://marc.info/?l=linux-usb&m=152544392822763&w=2

Ich hab jedenfalls nicht schlecht geschaut gestern. Ich musste einen reboot machen, jetzt läuft erstmal alles wieder. Mal sehen wie lange.
 
Hmm war das jetzt ein einmaliger Vorfall bei mir und das ist sonst niemanden passiert?
Im Moment läuft er wieder seid 4 Tagen ohne Probleme. Davor ist es nach 6 Tagen passiert.
Ich plane demnächst mehrere Datenträger per USB3 anzuschließen die im Moment noch per NFS eingebunden werden.
Es wäre sehr unschön wenn ich dann alle paar Tage rebooten müsste wenn der USB Controller abschmiert.
 
Und nun ist es wieder passiert, nach 14 Tagen laufzeit ist der Typ-C USB Port tot und somit der dort angeschlossene Netzwerk Adapter.
Kann ich den Port irgendwie wiederbeleben ohne einen reboot?

Code:
[Jul21 23:56] xhci_hcd 0000:39:00.0: xHCI host controller not responding, assume dead
[  +0,000742] xhci_hcd 0000:39:00.0: HC died; cleaning up
[  +0,000786] usb 4-1: USB disconnect, device number 2
[  +0,033623] vmbr1: port 1(enx00e04c68180d) entered disabled state
[  +0,000132] device enx00e04c68180d left promiscuous mode
[  +0,000001] vmbr1: port 1(enx00e04c68180d) entered disabled state

Code:
pveversion
pve-manager/5.2-5/eb24855a (running kernel: 4.15.17-3-pve)
root@proxmox:~# pveversion  -v
proxmox-ve: 5.2-2 (running kernel: 4.15.17-3-pve)
pve-manager: 5.2-5 (running version: 5.2-5/eb24855a)
pve-kernel-4.15: 5.2-4
pve-kernel-4.15.18-1-pve: 4.15.18-15
pve-kernel-4.15.17-3-pve: 4.15.17-14
corosync: 2.4.2-pve5
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-35
libpve-guest-common-perl: 2.0-17
libpve-http-server-perl: 2.0-9
libpve-storage-perl: 5.0-24
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.0-3
lxcfs: 3.0.0-1
novnc-pve: 1.0.0-1
proxmox-widget-toolkit: 1.0-19
pve-cluster: 5.0-28
pve-container: 2.0-24
pve-docs: 5.2-4
pve-firewall: 3.0-13
pve-firmware: 2.0-5
pve-ha-manager: 2.0-5
pve-i18n: 1.0-6
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.2-1
pve-xtermjs: 1.0-5
qemu-server: 5.0-29
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.9-pve1~bpo9
 
Hi, ich habe genau das gleiche Problem, allerdings mit einem externen 4 HDD Bay von Fantec, sobald ich da längere Zeit Daten drüberschiebe verabschiedet sich der USB-C genau mit der gleichen Meldung... Hast du diesbezüglich was erreichen können?
 
Also ich habe usb Autosuspend bei mir abgeschaltet: echo 'on' | tee /sys/bus/usb/devices/usb*/power/control
Und zusätzlich für meine USB Lan Adapter (beide Realtek Chip) direkt die Treiber von Realtek eingebunden, die sind um einiges neuer als die im Kernel selbst. Seitdem ist der Fehler nicht mehr aufgetreten *aufHolzKlopf*, ich hoffe das bleibt so.

Also das mit dem autosuspend könntest du probieren.
 
Habs mal getestet, macht leider keinen Unterschied.

Ich denke es geht Richtung Kernel; Ich teste später mal noch zwei andere USB-C Kabel...
 
So, nun neue Erkenntnis. Ich habe mal testweise UASP deaktiviert wie in dem Thread h ttps://forum.proxmox.com/threads/usb3-uas-probleme-uas_eh_abort_handler.43386/ und hier h ttps://unix.stackexchange.com/questions/239782/connection-problem-with-usb3-external-storage-on-linux-uas-driver-problem beschrieben.

Bisher läuft es mal noch, an den Stellen wo es bisher abgebrochen ist, ist er nun "drübergekommen"
 
Diese Sache kam mir heute wieder in den Sinn als ich den unbenutzten TB LAN Adapter in den Händen hatte.
Hab also mal wieder recherchiert und der Patch scheint es endlich in den Ubuntu Kernel geschafft zu haben im Jahre 2019:
https://git.launchpad.net/~ubuntu-k.../?id=006f19b211003235c55e9f9939a307df5ddbdb12
Das wäre dann der Release: "Ubuntu-4.15.0-46.49" gewesen.
Proxmox aktueller Kernel: "4.15.18-35" bassiert auf "Ubuntu-4.15.0-47.50"

Somit dürfte der Fix also im Kernel sein. Dann werde ich es wohl mal wagen und den Adapter die Tage mal wieder anschließen und in Betrieb nehmen.
 
Tja zu früh gefreut, nach drei Tagen ist es passiert:

Code:
Apr 28 21:21:04 proxmox kernel: xhci_hcd 0000:39:00.0: xHCI host controller not responding, assume dead
Apr 28 21:21:04 proxmox kernel: xhci_hcd 0000:39:00.0: HC died; cleaning up
Apr 28 21:21:04 proxmox kernel: usb 4-1: USB disconnect, device number 2
Apr 28 21:21:04 proxmox kernel: DMAR: DRHD: handling fault status reg 3
Apr 28 21:21:04 proxmox kernel: DMAR: [DMA Write] Request device [39:00.0] fault addr ff31c000 [fault reason 05] PTE Write access is not set
Apr 28 21:21:04 proxmox kernel: bond0: Releasing backup interface enx00e04c68180d
Apr 28 21:21:04 proxmox kernel: DMAR: DRHD: handling fault status reg 3
Apr 28 21:21:04 proxmox kernel: DMAR: [DMA Write] Request device [39:00.0] fault addr ff318000 [fault reason 05] PTE Write access is not set
Apr 28 21:21:04 proxmox kernel: device enx00e04c68180d left promiscuous mode
Apr 28 21:21:04 proxmox kernel: DMAR: DRHD: handling fault status reg 3
Apr 28 21:21:04 proxmox kernel: DMAR: [DMA Write] Request device [39:00.0] fault addr ff1d0000 [fault reason 05] PTE Write access is not set
Apr 28 21:21:04 proxmox kernel: DMAR: DRHD: handling fault status reg 3
Apr 28 21:21:04 proxmox kernel: DMAR: [DMA Write] Request device [39:00.0] fault addr ff61c000 [fault reason 05] PTE Write access is not set
Apr 28 21:21:04 proxmox kernel: DMAR: DRHD: handling fault status reg 3
Apr 28 21:21:04 proxmox kernel: DMAR: [DMA Write] Request device [39:00.0] fault addr ff53c000 [fault reason 05] PTE Write access is not set

Es passiert nur mit dem LAN Adapter mit r8152 Driver. Hab auch schon verschiedene probiert.
Die Festplatten die per USB3 angeschlossen sind laufen Wochenlang ohne Probleme.
Habe weiter gegoogelt, aber keine Lösung gefunden. IOMMU abschalten (iommu=soft) war noch ein Tip irgendwo und pci=nomsi.
Hab beides also mal gesetzt. Jetzt heisst es wieder warten...
 
@loomes - I have exactly the same issue as you had - have you solved it somehow?

Did the IOMMU parameters help? My USB network card is dropping every other day and it makes Proxmox unusable :(
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!