4.15.17-3 - xHCI host controller not responding

Discussion in 'Proxmox VE (Deutsch)' started by loomes, Jul 6, 2018.

  1. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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.
     
  2. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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.
     
  3. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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
     
  4. mostschaedel

    mostschaedel New Member

    Joined:
    Aug 27, 2018
    Messages:
    3
    Likes Received:
    0
    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?
     
  5. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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.
     
  6. mostschaedel

    mostschaedel New Member

    Joined:
    Aug 27, 2018
    Messages:
    3
    Likes Received:
    0
    Habs mal getestet, macht leider keinen Unterschied.

    Ich denke es geht Richtung Kernel; Ich teste später mal noch zwei andere USB-C Kabel...
     
  7. mostschaedel

    mostschaedel New Member

    Joined:
    Aug 27, 2018
    Messages:
    3
    Likes Received:
    0
    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"
     
  8. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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.
     
  9. loomes

    loomes Member

    Joined:
    May 22, 2018
    Messages:
    52
    Likes Received:
    9
    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...
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice