[gelöst] USB issue - device descriptor read/8, error -110

[debiankoe]

Guten Abend,

Lösung:
Firmware des USB3.0 Controlles flashen !


VIA -> Via VL-805/806 Firmware Version 013704
Renesas -> Renesas/Nec uPD720201/720202 USB 3.0 Firmware Version 2.0.2.6

Download:
VIA -> https://www.station-drivers.com/index.p ... 95&lang=en
Renesas -> https://www.station-drivers.com/index.p ... 48&lang=en

WICHTIG:
Die Hersteller der Chips veröffentlichen die Firmware nicht weil die Hersteller der Controller-Karten die Firmware zum Teil modifizieren.
Man geht immmer das Risiko ein dass der Controller danach nicht mehr funktioniert!

---------------------------------------------------------------------------------------------------------------------------------------------------------

System:
Debian 10.2 64x nonfree
Tyan S7012 Manual : https://www.tyan.com/manuals/S7012_UG_v1.1_06212012.pdf
2x L5640
72GB DDR3 FB Hynix (18x4GB, voll belegt)
Radeon RX480
Adaptec 71605 Raidcontroller (16x2TB)
USB3.0 Controller : https://i-tec.cz/de/produkt/pce22u3-3/
Corsair HX1200

Es geht um folgenden Fehler:

USB issue - device descriptor read/8, error -110

Im folgendem Forum habe ich mehr Informationen zu diesem Problem gefunden.
Leider haben diese Lösungen bei mir nicht funktioniert.
https://bbs.archlinux.org/viewtopic.php?id=198460

Folgende Aussage ist im Forum sehr interessant:

It does look like your system uses a mix of usb2 & usb3 ports .
Bus 001 and 002 appear to be usb2 and managed by ehci_pci .
Bus 003 & 004 appear to be usb3 ports, managed by xhci-hcd .

Eigentlich bedeutet der 101 error das der USB-Port nicht genügend Strom bekommt.
Dies ist nicht möglich ausser auf dem Mainboard liegt ein Defekt vor.
Das ganze System ist ohne USB3.0 Controller 2 Tage mit Prime95 getestet worden. (Ram & CPU)
Dazu habe ich das System ca 2 Wochen (nicht volllast) täglich gebraucht (Windows 10 Pro).
Das Problem tritt auch mit Windows auf. Linux liefert mir aber detailiertere Logs.
In diesem Zeitraum hatte ich nicht einmal irgend ein Problem.

Im Forum wurden mehr Logs verlangt, da ich dieses Problem gelöst haben möchte hier bitte:

Error: https://i.ibb.co/wz2J4Jn/error.jpg

dmesg : https://pastebin.com/syHwEBgW
lspci -k : https://pastebin.com/xMmFtGmD
lsusb -t : https://pastebin.com/aYpbLkKg
lsusb -v : https://pastebin.com/W5Li4hab

lsusb -v INFO : https://i.ibb.co/rbqcJvc/lsusbV.jpg

Ich hoffe hier kann jemand die Logs interpretieren und mir bei der Lösung behilflich sein.
Falls ich im BIOS eine spezifische Funktion deaktivieren soll bitte oben zuerst im Manual verifizieren das diese existiert.
Gerade im PCIe bereich ist das BIOS extrem limitiert.

Gruss Koe

PS: Aktuellstes BIOS und BMC Version ist vorhanden.

Edit Update:
- Molex-Anschluss ist angeschlossen. Die Spannung habe ich mit einem Multimeter geprüft!
- Diese logs wurden gemacht ohne das ein USB-Laufwerk angeschlossen ist!
- Der PCIe Controller wurde bereits auf mehreren PCIe-Slots getestet.
- Verschiedene USB3.0 PCIe Controller wurden verwendet: VLI / Renesas
- Mainboard ausgetauscht, Problem besteht weiterhin
- diverse versuche mit blacklisting : uhci_hcd, ehci_pci, ehci_hcd, xhci_hcd (aktuell)

BIOS Settings Aktuell:
- Crystal Beach/DMA - Enabled
- Quick Boot - Disabled
- onboard VGA - Disabled
- onboard Raid Controller - Disabled

[hikaru]

Ist das ein USB-Port direkt auf dem Mainbard oder hängt der an irgendeiner Art Hub oder einer sonstigen Verlängerung (z.B. auch in's Gehäuse integriertes Front-Panel)?
Was für ein USB-Gerät versuchst du da zu betreiben?

[debiankoe]

Ist das ein USB-Port direkt auf dem Mainbard oder hängt der an irgendeiner Art Hub oder einer sonstigen Verlängerung (z.B. auch in's Gehäuse integriertes Front-Panel)?
Was für ein USB-Gerät versuchst du da zu betreiben?

Es geht darum einen ganz normalen PCI-E USB3.0 Controller der in jedem anderen PC ohne weiteres funktioniert zu betrieben.
Das Mainboard hat standardmässig nur USB2.0 Ports.
USB3.0 Controller : https://i-tec.cz/de/produkt/pce22u3-3/

[hikaru]

Hast du dem PCIe-Adapter eine Stromversorgung über den Molex-Anschluss gegeben?
Was du da für ein USB-Gerät anschließt ist geheim?

[debiankoe]

Hast du dem PCIe-Adapter eine Stromversorgung über den Molex-Anschluss gegeben?
Was du da für ein USB-Gerät anschließt ist geheim?

1. Ja der Molex-Anschluss ist angeschlossen. Die Spannung habe ich mit einem Multimeter geprüft!
2. Nein, es ist nicht geheim schlussendlich möchte ich eine SSD/USB-Stick anschliessen.
Diese logs wurden gemacht ohne das ein USB-Laufwerk angeschlossen ist!
Dazu habe ich mehrere solcher USB3.0 Controller. Auch mit verschiedenen Chips : VLI / Renesas
Also wenn du mir als nächstes sagst das der Controller ist defekt müssten bei mir nun 5 Stück defekt sein.
Das hätte ich vielleicht noch erwähnen sollen.

[hikaru]

Diese logs wurden gemacht ohne das ein USB-Laufwerk angeschlossen ist!

Das scheint mir eine wichtige Info zu sein. Mein Verdacht war, du hättest eine externe HDD "bus-powered" angeschlossen. Da wäre zumindest damit zu rechnen gewesen, dass nicht genug Strom zur Verfügung steht. Ohne jegliche angeschlossene Geräte sollte das Problem aber eigentlich nicht auftreten.

Dazu habe ich mehrere solcher USB3.0 Controller. Auch mit verschiedenen Chips : VLI / Renesas
Also wenn du mir als nächstes sagst das der Controller ist defekt müssten bei mir nun 5 Stück defekt sein.

Das halte ich für eher unwahrscheinlich. Ich habe selbst zwei USB3-Expresscards* mit Renesas-Controller, und die funktionieren beide problemlos. Allerdings schafft es nur eine der Expresscards, eine 2,5"-HDD bus-powered zu versorgen.

Wenn ich mir das Schaltbild deines Mainboards anschaue, dann sehe ich, dass du insgesamt fünf PCIe-Slots hast (1, 3, 4, 5, 6). Nummer 2 ist vermutlich intern irgendwo verschaltet.
PCIe1 hängt am ICH10-R-Teil der Southbridge, während #3-6 direkt am Tylersburg-Teil hängen. Davon scheint sich offenbar #3 die Lanes mit dem optionalen SAS-Controller zu teilen.
Je nachdem wo du die Karte jetzt reingesteckt hast, würde ich sie mal in einen anderen Port stecken: #4, 5 und 6 sollten sich identisch verhalten. #1 könnte sich anders verhalten. #3 wäre meine letzte Wahl, da ich den SAS-Controller als zusätzliche Variable eliminieren wollen würde.


*) signaltechnisch im Grunde identisch zu deinem Adapter, nur die mechanische Bauform ist anders

[debiankoe]

Je nachdem wo du die Karte jetzt reingesteckt hast, würde ich sie mal in einen anderen Port stecken: #4, 5 und 6 sollten sich identisch verhalten. #1 könnte sich anders verhalten. #3 wäre meine letzte Wahl, da ich den SAS-Controller als zusätzliche Variable eliminieren wollen würde.

Dies habe ich als erstes versucht. Habe auf den anderen PCIe Slots genau die gleichen Symptome.
Ich vermute das der onboard-USB Controller und der PCIe USB Controller sich nicht leiden können.
Das er ja einen Controller nicht leiden kann könnte ich verstehen. Aber das gleich kein USB3.0 Controller geht is für mich das grösste mysterium seit langem.

Ich suche einfach ein Workaround. Bzw schon mal zu wissen wo genau der Fehler liegt wäre sehr hilfreich.

[king-crash]

Das bedeutet ohne Erweiterungskarten besteht auch kein Problem?
Tritt das Problem auch auf wenn du xhci_hcd geblacklisted hast?

[debiankoe]

Das bedeutet ohne Erweiterungskarten besteht auch kein Problem?

Genau. Ohne den PCIe USB3.0 Controller besteht kein Problem. Mit Grafikkarte + Raidcontroller funktioniert alles einwandfrei.
Hatte vorher Windows 10 64x Pro drauf und hab da 2 Tage lang Prime95 (Ram + CPU) laufen lassen.
Das ist "rock-solid" gelaufen.

Sobald ich den PCIe USB3.0 Controller eingesetzt habe hatte auch Windows 10 Probleme.
Manchmal wurde das USB-Laufwerk erkannt, meistens jedoch nicht.
Von 30GB konnte ich 3GB übertragen, danach ist die Übertragungsrate auf 0Mbit/s gesunken.
Meist ist das komplette System eingefrohren.

Tritt das Problem auch auf wenn du xhci_hcd geblacklisted hast?

Wie kann ich "xhci_hcd" blacklisten ?

[OrangeJuice]

Hier hat jemand auch ein Problem "-110" und USB gehabt, der hat aber ehci_pci auf die blacklist gesetzt(Link).

Du kannst es testweise direkt beim Startvorgang "e" drücken und dann eingeben oder

Code: Alles auswählen

nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=xhci_hcd"
update-grub

[debiankoe]

Vielen Dank,
Werde dies aber erst gegen Abend testen können.

[king-crash]

Das kann auch in eine beliebige Datei in /etc/modprobe.d/
Mit "blacklist xhci_hcd".

ehci_hcd -> USB 2
xhci_hcd -> USB 3
Ohne ehci bin ich nicht sicher ob die onboard USBs noch gehen.

Edit:
ohci_hcd oder uhci_hcd -> USB1
Vermutlich wird das dann verwendet, wenn ehci auf der Blacklist steht.

[debiankoe]

Also,

Folgendes habe ich nun für "ehci_pci","ehci_hcd","xhci_hcd" gemacht:

Code: Alles auswählen

vi /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset modprobe.blacklist=ehci_pci"
update-grub
reboot

Kontrolle:

Code: Alles auswählen

cat /proc/cmdline
lspci | grep USB

Keine Änderung des Zustandes, auch wenn ich xhci_hcd auf die blacklist setzte wird mein Controller weiterhin erkannt und der Fehler besteht weiterhin.
Was macht das blacklist genau ?
Es sollte den Treiber deaktivieren korrekt ?
Dann ist es sehr kurios das weiterhin xhci_hcd verwendet wird wenn dieser geblacklisted ist....

Ich hoffe, ich habe keine Schreibfehler gemacht, bitte kontrollieren.

Gruss Koe

EDIT: Habe es gerade noch mit "modprobe.blacklist=uhci_hcd" versucht(siehe logs).... Nun funktioniert aber gar kein USB-Port mehr.

[OrangeJuice]

Du kannst probieren ob es mit folgendem klappt. Ich meine, ich musste das bei einem AMD Treiber mal so machen. Nur mit "modprobe" hat es, meine ich, nicht geklappt. Genau erklären kann ich dir es nicht, vielleicht kann das jemand anderes.

Code: Alles auswählen

modprobe.blacklist=xhci_hcd blacklist=xhci_hcd

[debiankoe]

Um ein Modul (Treiber) zu blacklisten muss man wie folgt vorgehen
lsmod - zeigt die aktuell geladenen Module an.
modinfo - damit kann man herausfinden ob Module von anderen abhängig sind. Dies ist insofern wichtig weil man Module nur deaktiviert werden können wenn die abhängigkeiten auch deaktiviert werden.

Code: Alles auswählen

lsmod
modinfo -F depends (modulName)

Blacklisten

Code: Alles auswählen

touch /etc/modprobe.d/(modulName).conf
echo "blacklist (modulName)" > /etc/modprobe.d/(modulName).conf
depmod -ae
update-initramfs -u
reboot

Die folgende Zeile kann alternativ verwendet werden. Hier wird das Modul fehlerhaft ausgeführt und dadurch deaktiviert.
Der Vorteil bei diesem Beispiel ist das man sich nicht um abhängikeiten kümmern muss weil diese auch gerade deaktiviert werden.

Code: Alles auswählen

echo "install (modulName) /bin/true" > /etc/modprobe.d/(modulName).conf

Achtung: Per GRUB lassen sich keine Module deaktivieren
https://wiki.debian.org/KernelModuleBlacklisting
https://linuxconfig.org/how-to-blacklis ... bian-linux

Nun wieder zu meinem Problem.
Leider hat alles nichts gebracht. Ich habe alles deaktivert was ich konnte.
Sogar mehrere Module miteinander.
"uhci_hcd" , "ehci_pci" , "ehci_hcd" , "xhci_hcd" , "xhci_pci" diese habe ich alle getestet.

Naja ich denke am Wochenende werde ich mein zweites Tyan S7012 Mainboard in betrieb nehmen und schauen ob ich dort genau das selbe Problem habe. Somit könnte ich zumindest einen HW Defekt ausschliessen. Ich kann mir langsam nicht mehr vorstellen das es sich nicht um einen HW Defekt handelt. Somit müssten die Windows und Linux treiber den gleichen Bug haben.

Danke für die Hilfe, falls jemand noch eine Idee hat.
Ich bin für alles offen.

[king-crash]

in deinem Kernel log sind noch noch mehr Ungewöhnlichkeiten

[ 9.121628] ioatdma 0000:00:16.0: channel error register unreachable
[ 9.121630] ioatdma 0000:00:16.0: channel enumeration error
[ 9.121634] ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
[ 9.121684] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)
[ 9.121707] ioatdma 0000:00:16.1: PCI->APIC IRQ transform: INT B -> IRQ 44

Als du xhci_hcd geblacklisted hattest, was war da die Fehlermeldung?

[debiankoe]

Also DMA ist klar. Dieser ist standardmässig im BIOS deaktiviert wenn ich "optimal defaults" lade.
Daher wird dies in der syslog korrekt dargestellt.
Da ich ja bekanntlich ein kleines Problem habe, habe ich im BIOS nur folgende Optionen geändert:
- onboard VGA Deaktiviert
- Fast Boot Aktiviert
- SATA auf AHCI gesetzt

EDIT:
Habe nun DMA mal aktiviert. Soll ich dies Aktiviert lassen?
Hat keine einfluss auf mein Problem.

Wenn ich nur "xhci_hcd" blackliste dann läuft der Controller immer noch mit den selben Fehlern.

[king-crash]

Dann sollte aber kein "xhci_hcd 0000:07:00.0: Abort failed to stop command ring: -110" mehr stehen oder?
Das Selbe mit ehci_hcd?

Stell mal Fastboot im BIOS aus. Da hatten Andere schon Probleme damit.

[debiankoe]

Dann sollte aber kein "xhci_hcd 0000:07:00.0: Abort failed to stop command ring: -110" mehr stehen oder?
Das Selbe mit ehci_hcd?

Stell mal Fastboot im BIOS aus. Da hatten Andere schon Probleme damit.

- Habe jetzt "xhci_hcd" geblacklisted. Und ja "stop command ring" kommt nicht mehr.
- Quick Boot ist auch ausgeschaltet.
- Bei blacklist "ehci_hcd" :
Feb 7 22:52:01 debianTest kernel: [ 34.244661] xhci_hcd 0000:07:00.0: Abort f ailed to stop command ring: -110

Habe nun das komplette Mainboard gewechselt. Das Problem besteht weiterhin.
Es muss ein Treiber oder BIOS Problem sein... unglaublich!

PS: gibt es ein weg den "Ram-Check" beim booten zu skippen? Darum habe ich normalerweise "Quick Boot" eingeschaltet.
Bei 72GB dauert die Prüfung ca 10 Minuten....

[king-crash]

Und was für Fehler kommen dann noch, wenn xhci_hcd weg ist?

[debiankoe]

Also wenn "xhci_hcd" geblacklisted ist kommt der fehler mit dem "command ring" nicht mehr im syslog.

Sobald ich ein USB-Laufwerk anschliesse kommen folgende fehler:

Code: Alles auswählen

Feb  8 14:22:07 debianTest systemd[1031]: Reached target Sockets.
Feb  8 14:22:07 debianTest systemd[1031]: Reached target Basic System.
Feb  8 14:22:07 debianTest systemd[1031]: Reached target Default.
Feb  8 14:22:07 debianTest systemd[1031]: Startup finished in 49ms.
Feb  8 14:22:07 debianTest systemd[1]: Started User Manager for UID 1000.
Feb  8 14:22:07 debianTest systemd[1]: Started Session 2 of user koe.
Feb  8 14:22:48 debianTest kernel: [  164.309906] usb 4-4: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Feb  8 14:22:53 debianTest kernel: [  169.573818] usb 4-4: device descriptor read/8, error -110
Feb  8 14:22:53 debianTest kernel: [  169.681502] usb 4-4: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Feb  8 14:22:58 debianTest kernel: [  174.950017] usb 4-4: device descriptor read/8, error -110
Feb  8 14:22:59 debianTest kernel: [  175.281673] usb 4-4: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Feb  8 14:23:04 debianTest kernel: [  180.325858] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:04 debianTest kernel: [  180.433249] usb 4-4: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Feb  8 14:23:09 debianTest kernel: [  185.701827] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:09 debianTest kernel: [  185.837195] usb usb4-port4: attempt power cycle
Feb  8 14:23:10 debianTest kernel: [  186.765481] usb 4-4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
Feb  8 14:23:15 debianTest kernel: [  191.845676] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:15 debianTest kernel: [  191.953071] usb 4-4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
Feb  8 14:23:21 debianTest kernel: [  197.221691] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:21 debianTest kernel: [  197.553323] usb 4-4: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Feb  8 14:23:26 debianTest kernel: [  202.597531] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:26 debianTest kernel: [  202.704970] usb 4-4: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Feb  8 14:23:31 debianTest kernel: [  207.973470] usb 4-4: device descriptor read/8, error -110
Feb  8 14:23:32 debianTest kernel: [  208.108895] usb usb4-port4: unable to enumerate USB device

[king-crash]

... 2 using xhci_hcd

Ist das auch sicher nicht geladen?
Such mal mit "lsmod | grep xhci" danach.

[debiankoe]

Ist das auch sicher nicht geladen?
Such mal mit "lsmod | grep xhci" danach.

Also ich habe 2 möglichkeiten zu blacklisten:
1) blacklist xhci_hcd
2) install xhci_hcd /bin/true

Wenn ich Version (1) benutze ist "xhci_hcd" noch aktiv unter lsmod.
Die oben genannte Fehler sind somit aufgetaucht als "xhci_hcd" noch aktiv war.

Da du mich das nochmals gefragt hast weis ich nun das ich mit Version (2) blacklisten muss.
Bei Version (2) ist "xhci_hcd" nicht mehr aktiv unter lsmod.
Nur habe ich mir gedacht das dies nichts bringt weil dann der USB3.0 Controller gar keinen wank macht.
Wenn ich ein USB-Laufwerk anschliesse kommen gar keine Meldungen mehr vom USB3.0 Controller.
Die exter angeschlossene SSD wird mit Strom versorgt, LED leuchtet.
Weder Fehlermeldungen noch sonstige Meldungen werden in den Logs angezeigt.
Der USB3.0 Controller ist wie unsichtbar/deaktiviert.

Nur als Info: "xhci_pci" ist abhänig von "xhci_hcd". Wenn "xhci_pci" nicht geladen ist sehe ich den Controller zwar unter "lspci" aber wie gesagt er ist unsichtbar/deaktiviert.

Bei folgenden logs ist "xhci_hcd" deaktiviert! :

lsmod -> https://pastebin.com/rM4KYi2A
lspci -> https://pastebin.com/tYdBuHn7
syslog -> https://pastebin.com/vVywip0w
dmesg -> https://pastebin.com/sgBJeJat
lsusb -> https://pastebin.com/50XrpFmu

PS: Meine Tastatur & Maus ist über einen KVM-Switch angeschlossen an einem onboard USB2.0 Anschluss. Der KVM-Switch wird hier kein Problem sein oder ?

[habakug]

Hallo,

möglicherweise ist es dies:

All VIA USB 3.0 controllers can go DIAF [*] too for breaking when the kernel parameter iommu=1 is active. It was never fixed and will never be fixed.

Also probeweise mit "iommu=off" oder "iommu=soft" booten. Siehe auch hier [2].

Gruss, habakug

[1] https://forum.level1techs.com/t/xhci-po ... t/131622/5
[2] https://www.linuxmintusers.de/index.php?topic=58166.0

[*] die in a fire

[debiankoe]

Also probeweise mit "iommu=off" oder "iommu=soft" booten. Siehe auch hier [2].

IOMMU ist anscheinend ein AMD Ding.
Ist bei meinem system gar nicht aktiviert.
Habe es aber es trotzdem aber mal deaktiviert. Hat aber nix gebracht.

Danke Trozdem!