[abgebrochen] Einzelnes USB-3.0-Gerät auf USB 2.0 umstellen?

[hikaru]

Hallo,

ich habe hier einen USB-3.0-Hub für den 3,5"-Schacht, dessen USB-3.0-Controller Probleme macht (der Hub samt angeschlossener Geräte "verschwindet" nach wenigen GB Übertragung).
Via USB 2.0 (mittels eingeschleifter USB-2.0-Verlängerung) funktioniert er aber tadellos und im Rahmen der Möglichkeiten auch schnell.

Nun würde ich mir das USB-2.0-Kabel gern sparen und den Hub rein softwareseitig als USB 2.0 betreiben. Ich möchte also gezielt den einen Port auf dem Mainboard an dem der Hub hängt (nicht beide), oder den Hub selbst auf USB 2.0 umstellen. xhci insgesamt möchte ich aber nicht blacklisten.
Geht das irgendwie?

[rhHeini]

Bei meinem ASUS X570 Prime kann ich jeden einzelnen USB-Port im Bios konfigurieren.

Edith: Sorry, falsche Fährte. Geht doch nicht so wie ich gedacht habe (hab das USB SIngle Port Control nie benutzt): bietet nur Enable/Disable. War also nix.

[hikaru]

Das könnte auch eine Lösung sein.

Mit "jeden einzelnen" meint du, du kannst die beiden Ports des internen USB-3.0-Headers getrennt einstellen? Falls ja, sag mir bitte wo das geht, damit ich mal schauen kann, ob mein BIOS das auch hergibt!
Bei mir geht's um ein Asus Prime B450-A, auf das ich aber auf absehbare Zeit keinen Zugriff habe. Ich habe momentan nur den ausgebauten USB-Hub an einem Testrechner zu hängen.

Die Umstellung wirtklich nur eines einzelnen Ports/Geräts hätte ich gern, weil im selben 3,5"-Modul noch eine zweite Platine mit Cardreadern verbaut ist, die über USB 3.0 keine Probleme macht. Cardreader und USB-Hub hängen jeweils an einem der beiden USB-Ports des internen Mainboardheaders.

[TRex]

Habs weder ausprobiert noch recherchiert, aber könnte man nicht ne udev-rule dafür anlegen?

[hikaru]

Wäre auch meine Vermutung. Aber udev ist nicht gerade mein Steckenpferd. Mir fallen offenbar nicht mal sinnvolle Suchbegriffe ein.

[Livingston]

Mit den Suchbegriffen "usb force ehci" stolpert man in verschiedenen Foren über ein Script, dessen Kern so aussieht:

Code: Alles auswählen

# setpci -H1 -d <vendor>:<device> d0.l=0

wobei <vendor>:<device> den üblichen Ausgaben von lspci/lsusb entsprechen. Frag mich nicht nach dem kryptischen Parameter am Ende. Die Betonung scheint auf =0 zu liegen. Nix genaues weiß ich nicht.
Ich komme jetzt nicht dazu, was zu testen, deshalb hier nur ein paar Suchergebnisse:

https://linuxmusicians.com/viewtopic.ph ... 010#p79849
https://www.systutorials.com/how-to-for ... -in-linux/

Sieht also so aus, als müsstest Du das fragliche Gerät mit lspci (oder wahrscheinlich einfacher: lsusb) identifizieren und dann per setpci in die Hardwarekonfiguration reingrätschen.
Vielleicht hilft Dir das weiter.

[hikaru]

Mit den Suchbegriffen "usb force ehci" stolpert man in verschiedenen Foren über ein Script, dessen Kern so aussieht:

Code: Alles auswählen

# setpci -H1 -d <vendor>:<device> d0.l=0

Ja, das hatte ich auch gefunden. Aber soweit ich es verstanden habe, funktioniert setpci nur bei Geräten, die per PCI(e) angebunden sind. Mein USB-Einbau-Hub hängt ja aber bereits am USB-Controller des Mainboards. Ich könnte also den per PCIe angebundenen Mainboard-Controller insgesamt auf USB 2.0 umstellen, aber nicht den daran angeschlossenen Hub allein.

Ich habe das gerade mal mit einer externen HDD versucht:

Code: Alles auswählen

# lsusb | grep 0bc2:ab28
Bus 004 Device 025: ID 0bc2:ab28 Seagate RSS LLC Seagate Backup Plus Portable 5TB SRD00F1
# setpci -H1 -d 0bc2:ab28 d0.l=0
setpci: Warning: No devices selected for operation group 1.

Die HDD wird nach wie vor als USB 3.0 erkannt.

[smutbert]

Hier [1] ist in einer Antwort auch die Rede davon einzelne Ports des Onboardcontrollers auf USB 2-Modi zu begrenzen, im Beispiel

Code: Alles auswählen

setpci -H1 -d 8086:1e31 d8.l=0

um alle Ports auf USB 2 zu schalten. Ziel wäre natürlich nur den Port zu begrenzen an dem der Hub hängt.

Die restlichen Beispiele um einzelne Ports auf USB 2 zu schalten kann ich mit dem in der Antwort verlinkten PDF [2] nicht ganz nachvollziehen bzw. halte ich sie in der Antwort zumindest für unvollständig beschrieben.
Jedenfalls gibt es im PDF auf Seite 714 diese Tabelle

[...]
When set to 1, this bit enables the SuperSpeed terminations and allows the xHC to
view the SuperSpeed connections on the USB port.
When set to 0, the port’s SuperSpeed capability is not visible to the xHC.

Bit 3 = USB 3.0 Port 4
Bit 2 = USB 3.0 Port 3
Bit 1 = USB 3.0 Port 2
Bit 0 = USB 3.0 Port 1

[1] https://superuser.com/questions/812022/ ... as-usb-2-0
[2] https://www.intel.com/content/dam/www/p ... asheet.pdf

[Livingston]

Entsprechend dem PDF, Abschnitte 17.1.33 und 17.1.35, müsste man also jeweils das eine richtige Bit auf 0 bzw. 1 setzen, um nur den einen gesuchten Port zu manipulieren.
Also sollte bspw.

Code: Alles auswählen

setpci -H1 -d vendor:device d0.l=2 # 0010
setpci -H1 -d vendor:device d8.l=13 # 1101

Port 1 auf 2.0-Betrieb umstellen.
Ich probier's gleich mal aus, wenn ich Zeit habe.

[smutbert]

Ehrlich, ich bin mir gerade nicht sicher inwieweit ich meinen Überlegungen trauen soll – ich habe schon ein paar Minuten damit zugebracht herauszufinden ob hinter dx. ein großes i oder ein kleines L folgt... aber ich hätte es anders verstanden:
Das jeweilige Bit muss auf 0 gesetzt werden um die USB 3-Modi zu deaktivieren. Also wäre ich für d8.l nicht auf 13 sondern 14 gekommen (0 für ersten Port und 2+4+8 für die restlichen drei).

Außerdem braucht es das Setzen von d0.l=2 nach meinem Verständnis überhaupt nur, wenn man xhci gar nicht verwenden will – das scheint mir bei hikaru aber über das Ziel hinausgeschossen, wenn schon ein simples USB 2-Kabel genügt, dass alles problemlos läuft. Diesen Teil würde ich also weglassen, wenn er sich nicht als dringend notwendig erweist.

[Livingston]

Ich kann auch nur raten. Port 1 (von 0-3) habe ich nur als Beispiel rausgepickt. Das entspräche dann dem 2. Bit von rechts. Welcher Port der richtige ist, bekommt man wohl durch Ausprobieren raus (hoffe ich zumindest).
Einen ausgiebigen Test kann ich leider erst morgen machen.

[smutbert]

das mit 13 oder 14 nehme ich zurück. Ich habe nicht übernasert, dass du bei 0 zu zählen begonnen hast.

[Livingston]

Zwischenergebnis: Einen USB-Stick habe ich schon mal soweit gebracht, dass er langsamer spricht (runter von USB 3.0 auf 2.0). Muss noch rauskriegen, wie ich ihn zuverlässig identifizieren kann, um das Ganze zu scripten. Am Ende sollte da eine udev-rule draus baubar sein. Ich halte euch auf dem Laufenden.

OT:

... dass du bei 0 zu zählen begonnen hast.

Du weißt doch, es gibt nur 10 verschiedene Typen von Menschen: Die, die das Binärsystem verstehen, und all die anderen.

Ich habe nicht übernasert...

Sagt man das so in Graz? Gefällt mir auch als Ruhrpottler.

[hikaru]

Zwischenergebnis: Einen USB-Stick habe ich schon mal soweit gebracht, dass er langsamer spricht (runter von USB 3.0 auf 2.0).

Kannst du bitte schon mal das Zwischenergebnis präsentieren? Genau das hatte ich mit der externen HDD bisher noch nicht hinbekommen.
Mein Hub hängt ja später immer am selben (internen) USB-Port. Ihn "zuverlässig" zu identifizieren wäre für mich also vielleicht gar nicht wichtig, so lange ich zuverlässig immer den selben Port downgrade.

[Livingston]

Nächstes Zwischenergebnis: Ein USB-Stick ist geschrottet
Die gestern festgestellte Verlangsamung könnte mit dem Rumfummeln an den Registern gelegen haben. Ich habe lediglich die Register D0 und D8 eines USB3.0-Hub der Reihe nach (bitweise) bearbeitet.
Mal sehen: Ich hab noch einen Sack Billig-Sticks, aber ich werde vorher nochmal die Specs sorgfältig lesen.

WARNUNG
Ich habe auf Grundlage der oben verlinkten Intel-Spezifikation (C216) herumexperimentiert. Inzwischen weiß ich, dass ich damit völlig danebenlag, da bei mir ein anderer Chipsatz verbaut ist, nämlich der C230. Hier gibt es eine völlig andere Registerbelegung. Was auch immer gestern scheinbar funktioniert hat, war auf alle Fälle für meine Hardware reichlich ungesund.

[smutbert]

Sagt man das so in Graz? Gefällt mir auch als Ruhrpottler.

Ja, nicht nur in Graz. Wäre vielleicht eine Idee für einen grml-Releasenamen? ☺

WARNUNG
Ich habe auf Grundlage der oben verlinkten Intel-Spezifikation (C216) herumexperimentiert. Inzwischen weiß ich, dass ich damit völlig danebenlag, da bei mir ein anderer Chipsatz verbaut ist, nämlich der C230. [...]

Das tut mir leid. Ich hätte auch daran denken müssen, dass es unterschiedliche Chipsätze gib und beteilige mich gerne am entstandenen Schaden.
Kannst du schon abschätzen ob der über den Stick hinausgeht?

[Livingston]

Alles gut, smutbert, ist ja fast nix passiert. Es ist nur ein billiger USB-Stick umgekommen. Außerdem habe ich mich selten dämlich angestellt: Gescriptet alle Bitmuster durchgenudelt, Treiber vorher nicht abgemeldet und außerdem die Specs nicht gelesen. Da hat mein Spieltrieb mein Hirn überflügelt.
Ich ärgere mich über mich selbst, weil ich es eigentlich besser wissen sollte.
Ich habe das Ganze jetzt als Privat-Forschungsprojekt mit niedriger Priorität auf der Agenda. Also erst mal viel lesen, in den Kernel-/Treibercode reinschauen. Vielleicht gibt's ja eine machbare Lösung für hikarus Problem. Mir macht diese Art von Forschung jedenfalls Spaß und ich versuche mich da weiter dran. Wenn's was Neues gibt, melde ich mich natürlich hier bei euch zuerst.

[hikaru]

Bevor hier noch weitere Hardware geschrottet wird, breche ich mein Anliegen lieber ab. Das USB-2.0-Kabel bleibt dran.
Damit will ich nicht euren Spieltrieb bremsen, aber zumindest will ich nicht für etwaige Kollateralschäden verantwortlich sein.