Laden des Modules für ein spezifisches Device verhindern

Nachdem ich festgestellt habe, dass meine Realtek-basierende Netzwerkkarte (r8169-Treiber) im Betrieb in der VM PCIe-Fehler (AER: Multiple Corrected error received) auf dem Host-System verursacht hat, habe ich eine Intel-basierende Netzwerkkarte (e1000e-Treiber) eingebaut. Fehler war sofort weg. Nun habe ich nur ein Problem: um die Netzwerkkarte per PCI-Passthrough in die VM zu holen, muss man im Host-System die Karte deaktivieren. Das ging bei der Realtek einfach, da die eine Karte einen speziellen Treiber nutzte und ich den per blacklist am Laden hindern konnte. Nun hat aber meine Onboard-Netzwerkkarte den gleichen Treiber wie die zusätzlich gesteckte und somit kann ich kein globales blacklisting machen, sondern ich muss den Treiber für das spezifische Device entladen.

Geht im Betrieb einfach per echo -n 0000:03:00.0 >/sys/bus/pci/drivers/e1000e/unbind, wobei 03:00.0 die PCI Adresse der Steckkarte ist. Gibt es eine Möglichkeit, ähnlich wie beim Blacklisting, schon beim Starten von Linux zu verhindern, dass der Treiber für das Device geladen wird? Freund Google hat eine Idee aufgebracht, ein Skript in der Initramfs zu plazieren. Habe ich noch nicht probiert, da ich das Risiko sehe bei Änderung der Adressen oder was auch immer mich aus dem System auszuschliessen (Server im Rackschrank, ok - könnte mich lokal anmelden). Mir wäre also etwas in der Art

blacklist e1000e 0000:03:00.0

recht.

Hat hier einer der Linux-Gurus eine Idee? Oder vielleicht auch Erfahrung mit einem Initramfs-Skript um den Treiber da schon von der Karte zu lösen? Wäre super...

MrJoe

Das Vorgehen funktioniert - bekomme aber mittlerweile nun auf der DD-Karte und auf der Netzwerkkarte PCI Fehler (AER wie bei der Realtek), die vorher nicht da waren (als ich e1000e für die Netzwerkkarte von Hand entladen habe). Mal schauen, ob ich das noch löse.

Kleines Update:

• keine Fehler auf der DD-Karte, nur die Intel-Netzwerkkarte wirft einen Fehler pcieport 0000:00:1c.7: AER: Corrected error received: 0000:03:00.0
• habe kurz wieder alles rückgängig gemacht, neu gebootet und mit dem unbind-Befehl von oben gearbeitet --> System läuft seit >30min stabil. Lasse es mal heute vollends laufen und teste am Wochenende nochmals die vfio_pci.ids.

Kurz nochmals zu der Methode mit vfio_pci.ids. Prinzipiell verhindere ich damit, dass für die Netzwerksteckkarte der e1000e Treiber geladen wird. Leider habe ich in der Konstellation das Problem, dass die DD Cine sporadisch (50:50) bei einem Reboot nicht mehr erkannt wird (taucht bei lspci nicht auf, auch kein Eintrag in dmesg bzgl. Fehler). Das Problem habe ich nicht, ohne den vfio_pci.ids Eintrag im Grub bzw. des geänderten initramfs.

Aufgrund des Fehlers habe ich einen Dauertest gemacht ohne vfio_pci.ids. Karten wird bei jedem Boot korrekt erkannt und mit meinem Vorgehen wie im ersten Post beschrieben, kann ich die PCIe-Karten auch in die VMs durchreichen. In dieser Konfiguration gab es in 12h Dauerlauf keinen einzigen "Corrected AER-Fehler".

Nun stellte ich wieder um auf mit vfio_pci.ids Einträge im Grub, usw. und habe dann wieder das Problemm mit dem zuverlässigen Erkennen der Karte. Nach ca. 5 Minuten erhalte ich wieder Fehler der Art pcieport 0000:00:1c.7: AER: Corrected error received: 0000:03:00.0. Das kann doch aber eigentlich nichts damit zu tun haben, ob virtio-pci schon von Beginn an oder erst im laufenden System an die Karte gebunden wird. Ausser die macht mit dem e1000e-Treiber noch irgendeinen Reset, der jetzt fehlt.

Zitat von SHF

Wenn meine Aufzeichnungen korrekt sind, hat ein iface enpXs0 inet manual in der /etc/network/interfaces gereicht. (3x Intel I210, davon 2 in VMs durchgereicht.)

Das ist eine Möglichkeit die Konfiguration der Karte (DHCP, usw.) zu verhindern und die Karte läuft quasi "ohne Funktion" mit. Die vfio_pci.ids-Methode wäre die schönere, weil gleich der richtige Treiber (virtio-pci) für die durchzureichende Devices geladen wird. Aber für mich momentan nicht brauchbar bzw. ich will die Fehler im Syslog nicht ignorieren.

Zitat von SHF

Bei mir steht aber Kernel driver in use: vfio-pci bei den durchgereichten Karten und

Kernel driver in use: igb bei den nicht durchgereichten.

Ich würde daher sagen, da läuft kein anderer Treiber auf dem Host "ohne Funktion" mit.

Auch gehe ich davon aus, dass das Durchreichen korrekt geklappt hat. Und es läuft seit Jahren stabil 24/7.

Frage interessenhalber: das ist der Fall, wenn du den Host neu startest und die VM noch nicht läuft oder nachdem die VM gestartet wurde. Letzteres würde ich verstehen (bei managed Passthroughs sowieso), ersteres nur wenn auch der Kernelparameter vfio_pci.ids angegeben wäre. Aber bei mir läuft auch kein Proxmox.

Meine bisherigen Tests hier unter Debian 12 sind leider eindeutig: mit dem Kernelparameter bekomme ich bei laufender VM auf dem Host PCIe-Fehler bei der Intel Netzwerkkarte, keine Fehler bekomme ich, wenn ich für den e1000e-Treiber nach dem Starten "unbind" der Netzwerkkarte aufrufe. Keine Ahnung woran das liegen könnte, finde mich aber mittlerweile damit ab. Hardwaredefekte schliesse ich aus, da es momentan schon in Summe >24h fehlerfrei geht. Netzteilprobleme eigentlich auch, da noch genügend Reserven da sein sollten. Wie schon geschrieben keine begleitende Protokolleinträge vorhanden, die auf eine Ursache deuten könnten.