Treiberproblem e1000e [war: NIC-Hardwarefehler erkennen]

[reox]

Code: Alles auswählen

Jan 18 07:17:51 host0 kernel: [    0.595558] igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) d0:50:99:64:d3:35
Jan 18 07:17:51 host0 kernel: [    0.595611] igb 0000:02:00.0: eth0: PBA No: 001300-000
Jan 18 07:17:51 host0 kernel: [    0.595612] igb 0000:02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Jan 18 07:17:51 host0 kernel: [    0.646996] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid
Jan 18 07:17:51 host0 kernel: [    0.682050] e1000e: probe of 0000:00:19.0 failed with error -5

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP mode DEFAULT group default qlen 1000
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff

Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?

Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259

[BenutzerGa4gooPh]

Ist dir entgangen, dass ich auf dem Server nicht Virtualbox sondern KVM/Qemu einsetze, deshalb sind die verlinkten Anleitungen wenig hilfreich.
Ein Hauptgrund für die gewählte Netzwerkkonfiguration ist, dass es darüber unmöglich ist den Host aus dem WAN zu erreichen. Mit VirtualBox wäre das so nicht realisierbar, es benutzt nämlich immer die (konfigurierte) NIC des Hosts.
Entgegen deiner Ansicht wird eine Bridge durchaus auch im Wirtsystem eingerichtet z.B.: http://mywiki.bluelupo.net/mediawiki_1_ ... t_anpassen

KVM/Qemu kenne ich nicht, deshalb meine "Parallelen" zu VBox. Die Nichtkonfiguration der WAN-NIC des Hostsystems (auch kein DHCP-Client *) und die (ausschließliche) Konfiguration der gebridgten WAN-NIC des Gastsystems (Firewall-Distributuion) ist wohl eine gute Idee für Sicherheit, wenn man iptables auf dem Host vermeiden will. Sollte doch mit VBox auch klappen, werde ich mal testen. Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???

Die ganze Diskussion ist aber hinfällig solange auch in einem Live-System wie Knoppix nur die zweite NIC (Treiber igb) startet und die erste NIC wg. eines Treiber-Fehlers (e1000e: probe of 0000:00:19.0 failed with error -5) nicht startet (s. auch meinen vorherigen Post).
Gruß max

Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Edit: *)

[reox]

Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.

Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Nicht wenn du Gigabit WAN hast *scnr*

[BenutzerGa4gooPh]

Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Nicht wenn du Gigabit WAN hast *scnr*

Funktionieren die nicht gut/angemessen? Also Adapter USB3.0->GBE.

[unitra]

Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Nicht wenn du Gigabit WAN hast *scnr*

Funktionieren die nicht gut/angemessen? Also Adapter USB3.0->GBE.

Als "Workaround" kann man diese Adapter zeitweise einsetzten, oder um Fehlerquellen auszuschliessen. Aber für professionellen Betrieb sind sie ungeeignet.
Von diesen "Adaptern" kann man nur abraten, die USB-to-Ethernet Adapter bieten nie Wirespeed/Linerate D.h. mit Gigabit unter Umständen z.B. maximal 60 MB/s Übertragungsrate (Linerate wäre 125MB/s bei Gigabit) . Die Treiber sind oft schlecht geschrieben, weil es z.B kein TCP offloading gibt, alles wird von der CPU berechnet, schlimstenfalls jedes IP Packet, jede TCP Session, jeder Ethernet Rahmen.

[BenutzerGa4gooPh]

Nur zur Info: https://www.computerbase.de/forum/showt ... ?t=1474645
Notlösung, zu bevorzugen sind die natürlich nicht, besser aktive NICs: https://wiki.ipfire.org/hardware/passivenics

[reox]

Also es stimmt schon, mein APU Board hat auch noch die alten passiven Realtek Chips. Man merkt das bei 100% WAN auslastung (50MBit) die CPU schon so auf 10% geht. Liegt aber auch daran, dass da noch suricata rennt... Wo ich das Teil bekommen hab, hab ich ein paar Benchmarks gemacht und bei 100% Gigabit über 2 Ports waren das so ca 50% CPU auslastung auf einem Core.
Aber der Benchmark ist auch nicht ganz so gut geeignet, da er nicht auf maximale Paketanzahl pro Sekunde abziehlt sondern auf maximalen Durchsatz. maximale Anzahl der Pakete ist aber eigentlich wichtiger.

[max123kl]

Hallo und vielen Dank für die bisherige Beteiligung am Thread.

Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?

Sehr aufmerksam!
Aber das hat seine Richtigkeit. Defaultmäßig wird/wurde der i217LM-Chip als eth0 und der i210-Chip als eth1 erkannt. Per udev-Regel habe ich die Schnittstellen in der Server-Installation vertauscht.

Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259

Genau diese Links und ein paar parallele Threads hatte ich gelesen. Weshalb ich denke, dass mein Problem treiberbasiert ist.
Mir ist aber unbehaglich bei dem Geanken einen Treiber zu patchen.
a) habe ich so etwas noch hie gemacht und b) bin ich unsicher ob die Lösung Upgrade-fest ist. Im UP hatte ich ja schon geschrieben, dass das OS Debian8 ist, da steht irgendwann der Wechsel zu stretch an.

Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.

Das ist ein weiterer Grund weshalb ich noch am Überlegen bin.

Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???

Siehe hier: https://www.linux-kvm.org/page/Networking#Public_Bridge
oder hier: https://wiki.qemu.org/Documentation/Networking
oder hier: https://wiki.ubuntu.com/KvmWithBridge
im Wesentlichen habe ich mich hieran orientiert: https://www.linuxmuster.net/wiki/anwend ... -netzwerk

Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Zu deinem Vorschlag sind ja schon ein paar Kommentare gekommen, die dir zeigen sollten, dass er nur als Notlösung in Betracht käme.
Der betreffende Rechner ist ein (Eigenbau-) Server, deshalb habe ich bei der Auswahl des MB's darauf geachtet habe, dass Server-Chips für die NICs verbaut sind. Ursprünglich hätte ich auch einen zusätzlichen Dual-Port NIC-Kontroller einsetzen können, auf den ich jetzt notgedrungen zurückgreifen muss.
Da ich aber weder Broadcom- noch Realtek-Chips im Server einsetzen will, bleibt eigentlich nur Intel übrig und damit auch das Treiberproblem bestehen.
Gut lt. Intel unterstützt 'bootutil' die Karten im Gegensatz zu den OnBoard-Kontrollern, aber ein Restrisiko bleibt.

Gruß max
Edit: weiterer Link hinzugefügt

[max123kl]

Hallo und vielen Dank für die bisherige Beteiligung am Thread.

Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?

Sehr aufmerksam!
Aber das hat seine Richtigkeit. Defaultmäßig wird/wurde der i217LM-Chip als eth0 und der i210-Chip als eth1 erkannt. Per udev-Regel habe ich die Schnittstellen in der Server-Installation vertauscht.

Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259

Genau diese Links und ein paar parallele Threads hatte ich gelesen. Weshalb ich denke, dass mein Problem treiberbasiert ist.
Mir ist aber unbehaglich bei dem Geanken einen Treiber zu patchen.
a) habe ich so etwas noch hie gemacht und b) bin ich unsicher ob die Lösung Upgrade-fest ist. Im UP hatte ich ja schon geschrieben, dass das OS Debian8 ist, da steht irgendwann der Wechsel zu stretch an.

Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.

Das ist ein weiterer Grund weshalb ich noch am Überlegen bin.

Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???

Siehe hier: https://www.linux-kvm.org/page/Networking#Public_Bridge
oder hier: https://wiki.qemu.org/Documentation/Networking
oder hier: https://wiki.ubuntu.com/KvmWithBridge
im Wesentlichen habe ich mich hieran orientiert: https://www.linuxmuster.net/wiki/anwend ... -netzwerk

Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Zu deinem Vorschlag sind ja schon ein paar Kommentare gekommen, die dir zeigen sollten, dass er nur als Notlösung in Betracht käme.
Der betreffende Rechner ist ein (Eigenbau-) Server, deshalb habe ich bei der Auswahl des MB's darauf geachtet habe, dass Server-Chips für die NICs verbaut sind. Ursprünglich hätte ich auch einen zusätzlichen Dual-Port NIC-Kontroller einsetzen können, auf den ich jetzt notgedrungen zurückgreifen muss.
Da ich aber weder Broadcom- noch Realtek-Chips im Server einsetzen will, bleibt eigentlich nur Intel übrig und damit auch das Treiberproblem bestehen.
Gut, lt. Intel unterstützt 'bootutil' die Karten im Gegensatz zu den OnBoard-Kontrollern, aber ein Restrisiko bleibt.

Gruß max
Edit: weiterer Link hinzugefügt