[Mint 21.3] Spezifischen Treiber für spezifisches USB-Device laden

Hallo liebes Forum,

vorab: ich habe absichtlich den inxi -Fzxi Output nicht mitkopiert, da sich meine Frage nicht auf einen spezfischen Rechner bezieht, sondern recht generell gehalten ist. Falls trotzdem Infos benötigt werden, bitte gerne nachfragen

Könnte mir bitte jemand erklären, wie ich unter Mint 21.3 Cinnammon festlegen kann, welcher Treiber für ein bestimmtes Device geladen wird?

Hintergrund meiner Frage (ohne zu sehr ins Detail gehen zu wollen um Euch nicht zu erschlagen): ich habe eine ASUS USB-Netzwerkkarte, die problemlos bis einschl. Kernel 6.5.0-26 funktioniert und bei allen neueren Kernel-Versionen nicht mehr.

Im Rahmen meiner Recherchen habe ich via inxi -n festgestellt, dass Mint für die Karte bis einschl. 6.5.0-26 als Treiber cdc_ncm lädt und bei allen neueren Kernel-Versionen r8152. Und das wäre natürlich erstmal eine naheliegende und plausible Erklärung, warum es ab genau dieser Kernel-Version nicht mehr klappt.

Nun würde ich gerne testen, ob die USB-Netzwerkkarte auf einem aktuellen 6.5.0-44 funktionieren würde, wenn als Treiber cdc_ncm verwendet wird.
Nur habe ich leider absolut keine Ahnung, wie ich das anstelle.
Vorhanden ist er anscheinend nach wie vor:
modinfo cdc_ncm
filename: /lib/modules/6.5.0-44-generic/kernel/drivers/net/usb/cdc_ncm.ko

Herzlichen Dank schon mal vorab für Eure Unterstützung

Viele Grüße
Ben

Hallo Ihr beiden,

danke für Eure Rückmeldung, anbei die gewünschten Ausgaben.
In beiden Fällen wurde frisch gebootet und die USB NIC nach dem Anmelden verbunden

Gutfall (Boot von 6.5.0-26-generic)

[  477.184977] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[  477.217201] usb 4-1: New USB device found, idVendor=0b05, idProduct=1976, bcdDevice=31.05
[  477.217217] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  477.217224] usb 4-1: Product: USB 10/100/1G/2.5G LAN
[  477.217230] usb 4-1: Manufacturer: Realtek
[  477.217235] usb 4-1: SerialNumber: 5013000001
[  477.242299] usbcore: registered new interface driver cdc_ether
[  477.271424] cdc_ncm 4-1:2.0: MAC-Address: 10:7c:61:2b:89:73
[  477.271427] cdc_ncm 4-1:2.0: setting rx_max = 16384
[  477.272461] cdc_ncm 4-1:2.0: setting tx_max = 16384
[  477.273370] cdc_ncm 4-1:2.0 eth0: register 'cdc_ncm' at usb-0000:03:00.0-1, CDC NCM (NO ZLP), 10:7c:61:2b:89:73
[  477.273420] usbcore: registered new interface driver cdc_ncm
[  477.275885] usbcore: registered new interface driver cdc_wdm
[  477.277251] usbcore: registered new interface driver cdc_mbim
[  477.282806] cdc_ncm 4-1:2.0 enx107c612b8973: renamed from eth0

Device-4: ASUSTek USB 10/100/1G/2.5G LAN type: USB driver: cdc_ncm
  IF: enx107c612b8973 state: up speed: 2500 Mbps duplex: half
    mac: 10:7c:61:2b:89:73

Schlechtfall (alles neuer als 6.5.0-26, im konkreten Fall mit 6.5.0-44-generic durchgeführt)

[   64.212610] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[   64.243217] usb 4-1: New USB device found, idVendor=0b05, idProduct=1976, bcdDevice=31.05
[   64.243221] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[   64.243223] usb 4-1: Product: USB 10/100/1G/2.5G LAN
[   64.243224] usb 4-1: Manufacturer: Realtek
[   64.243225] usb 4-1: SerialNumber: 5013000001
[   64.258952] usbcore: registered new device driver r8152-cfgselector
[   64.396920] r8152-cfgselector 4-1: reset SuperSpeed USB device number 2 using xhci_hcd
[   64.614301] r8152 4-1:1.0: ram code speedup mode fail
[   64.614306] r8152 4-1:1.0: load rtl8156b-2 v2 04/27/23 successfully
[   64.749069] r8152 4-1:1.0 (unnamed net_device) (uninitialized): netif_napi_add_weight() called with weight 256
[   64.749357] r8152 4-1:1.0 eth0: v1.12.13
[   64.749382] usbcore: registered new interface driver r8152
[   64.756261] usbcore: registered new interface driver cdc_ether
[   64.757788] usbcore: registered new interface driver cdc_ncm
[   64.759803] usbcore: registered new interface driver cdc_wdm
[   64.761013] usbcore: registered new interface driver cdc_mbim
[   64.791200] r8152 4-1:1.0 enx107c612b8973: renamed from eth0
[   67.172638] r8152 4-1:1.0 enx107c612b8973: carrier on

Device-4: ASUSTek USB 10/100/1G/2.5G LAN type: USB driver: r8152
  IF: enx107c612b8973 state: up speed: 2500 Mbps duplex: full
    mac: 10:7c:61:2b:89:73

Wie Ihr seht ist in beiden Fällen der Port up... Unterschied ist einmal der Treiber und einmal Duplex. Ich habe im Schlechtfall (also mit dem r8152 Treiber) auch mal manuell mit ethtool die Karte auf half gesetzt... ändert nichts am Problem.

Nachdem wir jetzt ja doch recht ins Detail abgetaucht sind: das genaue Problem ist übrigens, dass die Karte mit r8152 zwar hochkommt, ich aber nicht mal die 192.168.178.1 anpingen kann, geschweige denn ins Internet komme. Und damit es noch komplizierter wird: das Problem tritt ausschließlich auf, wenn der Port mit 2,5GBit konfiguriert ist. Lasse ich den Port auf 1GBit/s, ist auch der r8152-Treiber happy. Wie Ihr Euch aber vielleicht denken könnt war der Grund für den Kauf der USB-NIC, dass ich 2,5GBit nutzen möchte
Aktuell habe ich also die Wahl einen alten Kernel mit 2,5GBit zu nutzen oder einen aktuellen Kernel mit 1 GBit. Ziel wäre - wenig überraschend: aktueller Kernel und 2,5GBit

Gruß
Ben

Hi Josefine,

nochmal danke für Deine Hilfe... und ich hoffe Du liest in meinen nächsten Zeilen nichts raus, was Du als "Undankbarkeit" auffasst, denn so wäre es nicht gemeint. Was durchaus mitklingen könnte ist ein gewisser Frust (der sich aber in keiner Form auf Dich oder ein anderes Forenmitglied bezieht), denn ich hab schon ziemlich viel Zeit in das Thema investiert

Jetzt sind wir wieder bei meinem Ursprungsposting angekommen, als ich schrieb "ohne zu sehr ins Detail gehen zu wollen um Euch nicht zu erschlagen" So langsam landen wir doch im Detail.

Die Seite kenne ich... den Treiber auch. Leider ist es ja eben kein fertiger Treiber, den man runterlädt, sondern Sources und ein Makefile zum Selberbauen. Make fliegt mit zigtausend Compilerfehlern raus... und der frischeste ist der Treiber ja auch nicht grad, wie man anhand des "Kernel v4.10 and later" sieht. Die README ignoriert den Part des Installierens komplett und spricht nur von "You may have to run the following command after installing the driver"... meine Vermutung wäre "make" und anschließend "make install" gewesen, aber wie gesagt, fliegt mit ziemlich vielen Errors raus. Den Command aus dem ReadMe habe ich auch getestet (allerdings mit dem vom Kernel mitgebrachten r8152 Treiber)

sudo ethtool -s eth0 autoneg on advertise 0x80000000002f             
netlink error: no device matches name (offset 24)
netlink error: No such device

Wenn wir schon auf den Weg in das tiefe Hasenloch sind Den ASUS-Support hatte ich frühzeitig kontaktiert... ob ich es mit dem Treiber probieren soll. Deren Aussage war zusammengefasst "den Treiber von unserer Seite brauchst für aktuelle Linux-Versionen nicht, wird out of the box unterstützt".
Was ja auch stimmt - aber eben leider ab Kernel 6.0.5-27 und neuer nicht mehr. Zumindest nicht mit 2,5GBit. Dazu hat der ASUS-Support bisher auch noch keine schlaue Idee

Achja, und um noch ein bissl weiter runterzusteigen: ich habe das Ganze mal auf einem Rechner getestet, der Windows 10 im Dualboot hat. Unter Windows 10: 2,5GBit kein Problem, funktioniert genauso wie unter Linux pre-6.0.5.-27. Boote ich ein einziges mal einen Linux Kernel neuer als 6.0.5-26, tritt das beschriebene Phänomen nach einem Reboot auch unter Windows 10 auf. Oder wenn ich danach einen Kernel 6.0.5-26 boote: geht auch nicht mehr. Solange bis ich den Rechner wirklich komplett runterfahre. Nach einem Coldboot ist wieder alles OK (so lange bis ich wieder 6.0.5-27 oder neuer boote). Sprich: was auch immer der r8152 mit der Karte "kaputtmacht" (in Ermangelung eines besseren Wortes ): es überlebt sogar einen Warmstart und macht es für andere Betriebssysteme "kaputt".

Das mal so als "kleiner Exkurs" in meine Freizeitbeschäftigung der letzten 2-3 Wochen

Deshalb wollte ich jetzt einfach mal einen Schritt zurückmachen wollen und nochmal zur ursprünglichen Frage zurückkommen (die mich auch ganz unabhängig von dem konkreten Problem interessiert): anhand welches Kriteriums entscheidet Mint, welcher Treiber für welches Device geladen wird? Ich würde mir erhoffen, dass der bisher funktionierende cdc_ncm auch weiterhin klappt - denn wie schon in meinem Ausgangspost geschrieben: ihn gibts ja nach wie vor. Zumindest würde ich das gerne mal verifizieren (oder eben... ausschließen). Aber da scheiterts eben daran, dass ich nicht mal weiß wie ich Mint beibringe "nimm diesen Treiber". Bei Windows wüsste ich's (amüsantes am Rande... der ASUS-Supporter meinte auch zwischendurch mal "if it is possible reinstall the drivers from the device manager equivalent and restart". Genau... dieses device manager equivalent würde mich interessieren ;-))

Aus einem Linux-Buch (Kofler) glaube ich verstanden zu haben, dass es dafür eigentlich eine /etc/modprobe.conf gibt, in der z.B. per "alias eth0 8139too" gesteuert wird, dass das Modul 8139too geladen wird. Von daher war meine naive Vorstellung, dass es in der /etc/modprobe.conf auch irgendwo etwas geben muss à la "alias enx107c612b8973 cdc_ncm" bzw "alias enx107c612b8973 r8152" bei neueren Kerneln. Oder hab ich hier einen Denkfehler bzgl. Treiber / Modul?

Es scheitert aber schon daran, dass ich unter Mint die modprobe.conf gar nicht erst finde Es gibt /etc/modprobe.d - aber auch darin keine modprobe.conf oder etwas in der Richtung

Viele Grüße
Ben
PS: ich seh schon, mein "nicht zu sehr ins Detail gehen" ging super auf

Quote from Gerbil

Was spricht für dich eigentlich dagegen, mit dem etwas älteren Kernel zu leben? Ich bin hier immer noch auf 5.15 irgendwas und bleibe wohl auch erst mal dabei. Mit irgendeinem sechser Kernel ist ab und zu die Kiste eingefroren und ich sehe keinen Nachteil (für mich) den älteren Kernel weiter zu benutzen.

Mhh... eigentlich nur, dass diese "Minor Releases" innerhalb der 6.5.0er Reihe (analog der 5.15er Reihe) doch Security-Updates mitbringen die man mitnehmen sollte, oder habe ich das missverstanden?
Ich hab übrigens auch mit 5.15 getestet... da ist das Verhalten das gleiche... der aktuelle 5.15er zeigt das Problemverhalten, mit einem alten 5.15er gehts. Hier bin ich allerdings nicht so weit gegangen wie bei der 6.5.0er, sprich gesucht ab wann genau in der 5.15er Linie der Treiber gewechselt wurde.
Auch die Beta von Mint 22 mit 6.8 und (vermutlich wenig überraschend, nachdem Mint 22 drauf basiert :-)) Ubuntu 24.04 zeigen das Problem.

Quote from Gerbil

Man kann entweder eine modprobe.conf erzeugen oder besser, so wird es inzwischen mit den einzelnen Modulen gemacht, unter modprobe.conf.d eine Datei mit entsprechendem Inhalt eintragen.

Hmm, aber es existiert ja in dem Verzeichnis aktuell keine Datei, die sagt "nimm r8152" für das Device und trotzdem machts der Kernel. OK, wenn ich Dich richtig verstehe meinst Du, ich sollte mal probieren eine "usb-nic.conf" (der Name scheint ja egal zu sein, Hauptsache .conf und in dem Verzeichnis?) in dem Verzeichnis anzulegen? Und dann alias enx107c612b8973 cdc_ncm rein?

Quote from josefine

Du wirst hier wahrscheinlich eth0 durch enx107c612b8973 ersetzen müssen - versuch macht kluch

Da hast Du völlig Recht, das ist mir gestern direkt nach dem Abschicken meines Posts auch noch aufgefallen
Hab ich gestern auch noch probiert, in der Tat kam dann auch nicht der Fehler "no such device" sondern gar keine Rückmeldung... funktioniert hats aber leider trotzdem nicht Kann natürlich durchaus sein, dass dieser Aufruf den ASUS-eigenen Treiber voraussetzen würde und mit dem mitgelieferten nicht implementiert ist...

Quote from josefine

Dem kann ich mich nur anschließen - eventuell kommt ja mit einem neueren Kernel auch wieder Besserung ........

Das war auch meine Hoffnung, weshalb ich mal die Beta von Mint 22 probiert hatte, die ja den 6.8er mitbringt... der zeigt das Verhalten leider auch noch. Aber die Hoffnung stirbt natürlich bekanntlich zuletzt

Quote from josefine

Wie sollte ich denn Wissen, dass du schon ganz viel versucht hast. Meine Glaskugel ist leider beim Service ...
Ich wollte einfach nur helfen .......

OK - habe dann hier auch nichts mehr zu sagen ....

Hmm, das klingt jetzt irgenwie verletzt? Wenn ja tut mir das sehr leid.
Ich hatte doch extra geschrieben "nochmal danke für Deine Hilfe... und ich hoffe Du liest in meinen nächsten Zeilen nichts raus, was Du als "Undankbarkeit" auffasst, denn so wäre es nicht gemeint"
Natürlich konntest Du das nicht wissen (und vermutlich liegt Deine Glaskugel beim gleichen Servicebetrieb wie meine ). Das war doch nur der Versuch einer Erklärung warum ich mein Ursprungsposting relativ knapp an Details gehalten und gleich konkret gefragt hatte, wie ich steuere welchen Treiber Mint für ein Device nimmt.

Wenn Du Dich trotzdem ausklinken möchtest ist das natürlich OK... vielen Dank nochmal für Deine Mühe

Soderle, ich hab eine gute und eine halbschlechte Nachricht

Die gute Nachricht: ich habe eine Lösung (oder lasst es uns mal mehr einen Workaround nennen) für das eigentlich zugrundeliegende Problem "die NIC funktioniert mit 2,5GBit auf aktuellem 6.5er Kernel nicht mehr" gefunden.

Meine Vermutung, dass es tatsächlich der Wechsel von cdc_ncm auf r8152 war, trifft zu. Ich bin die Tage schon mal auf die blacklist.conf gestoßen und dachte mir "wäre mal interessant zu sehen was passiert wenn ich den r8152 auf die Blacklist setze... lädt er dann gar keinen Treiber mehr oder vielleicht wieder den alten Funktionierenden?".
Also hatte ich die Tage schon mal testweise die zwei Zeilen "blacklist r8152-cfgselector" und "blacklist r8152" in der blacklist.conf angefügt, was aber nichts geändert hatte. Den Ausschlag gegeben hat nun eine Anmerkung, die ich in der Doku zu Kernelmodulen bei ubuntuusers.de gefunden habe: "Manchmal kann es erforderlich sein, das initramfs mit dem Befehl update-initramfs -u zu aktualisieren, wenn die Module trotz Blacklisting nach einem Neustart wieder geladen werden."
Genau das war der Fall... nachdem ich das gemacht habe, kann ich den aktuellen 6.5.0-44-generic booten, es wird automatisch wieder cdc_ncm geladen und 2,5GBit funktioniert tadellos.

Warum ich es eher als Workaround denn als Lösung bezeichnen würde: es wäre vermessen davon auszugehen, dass sich die Kernel-Entwickler nicht irgendwas dabei gedacht hätten, den Treiber zu wechseln. Von daher gut möglich, dass mir das irgendwann wieder auf die Füße fallen könnte (keine Ahnung, vielleicht soll cdc_ncm wirklich künftig rausfliegen o.ä.). Aber zumindest für den Moment habe ich nun einen aktuell gepatchten 6.5er Kernel in Kombination mit der funktionierenden NIC. Zwischenzeitlich hat das Mint-Team ja auch 6.8 für Mint 21.3 freigegeben, wenn ich zu viel Zeit hab probiere ich mal noch aus ob mein Workaround damit auch noch funktioniert oder ob er mir spätestens beim Update auf Mint 22 (was ja 6.8 mitbringt) schon wieder um die Ohren fliegt [EDIT 23.07.24 12:01: grade mit Kernel 6.8.0-38-generic unter Mint 21.3 Cinnamon getestet: funktioniert nach wie vor, wird immer noch cdc_ncm geladen]

Die halbschlechte () Nachricht: so 100%ig verstanden wie ich steuern kann, welchen Treiber Mint für welches Device lädt hab ich nach wie vor nicht. OK, ich hab jetzt gelernt, wie ich via blacklist verhindern kann, dass ein bestimmter Treiber überhaupt geladen wird und habe Glück, dass dadurch automatisch wieder der alte Funktionierende geladen wird. Aber mein Versuch einer "/etc/modprobe.d/asus-usb-nic.conf" mit dem Inhalt "alias enx107c612b8973 cdc_ncm" hatte nichts gebracht (die hab ich vor meinem erneuten, erfolgreichen Anlauf mit der blacklist.conf auch wieder gelöscht), es wurde trotzdem r8152 geladen. Also entweder war meine Herangehensweise hier einfach komplett falsch... oder es ist ähnlich wie bei der blacklist.conf, dass ich danach noch irgendwas ausführen muss. update-initramfs -u hatte aber in dem Fall nix gebracht Also falls da noch jemand einen Tipp hat, gerne her damit.

Ansonsten nochmal vielen Dank an Euch drei!