[Lookbehind]

Hallo zusammen,

ich hab einen kleinen Server auf einem Core i5-4590T laufen, der öfter mal kleine Aussetzer hat, die scheinbar durch Probleme mit dem Netzwerk entstehen.

Auszug aus dmesg:

Spoiler:(zum lesen bitte Text markieren)

[Sa Jan 20 10:58:05 2024] e1000e 0000:00:19.0 eno1: Detected Hardware Unit Hang:
                            TDH                  <14>
                            TDT                  <77>
                            next_to_use          <77>
                            next_to_clean        <11>
                          buffer_info[next_to_clean]:
                            time_stamp           <11031e3c6>
                            next_to_watch        <14>
                            jiffies              <11031e660>
                            next_to_watch.status <0>
                          MAC Status             <80083>
                          PHY Status             <796d>
                          PHY 1000BASE-T Status  <3c00>
                          PHY Extended Status    <3000>
                          PCI Status             <10>
[Sa Jan 20 10:58:07 2024] e1000e 0000:00:19.0 eno1: Detected Hardware Unit Hang:
                            TDH                  <14>
                            TDT                  <77>
                            next_to_use          <77>
                            next_to_clean        <11>
                          buffer_info[next_to_clean]:
                            time_stamp           <11031e3c6>
                            next_to_watch        <14>
                            jiffies              <11031e858>
                            next_to_watch.status <0>
                          MAC Status             <80083>
                          PHY Status             <796d>
                          PHY 1000BASE-T Status  <3c00>
                          PHY Extended Status    <3000>
                          PCI Status             <10>
[Sa Jan 20 10:58:09 2024] e1000e 0000:00:19.0 eno1: Detected Hardware Unit Hang:
                            TDH                  <14>
                            TDT                  <77>
                            next_to_use          <77>
                            next_to_clean        <11>
                          buffer_info[next_to_clean]:
                            time_stamp           <11031e3c6>
                            next_to_watch        <14>
                            jiffies              <11031ea48>
                            next_to_watch.status <0>
                          MAC Status             <80083>
                          PHY Status             <796d>
                          PHY 1000BASE-T Status  <3c00>
                          PHY Extended Status    <3000>
                          PCI Status             <10>
[Sa Jan 20 10:58:11 2024] e1000e 0000:00:19.0 eno1: Reset adapter unexpectedly
[Sa Jan 20 10:58:11 2024] brvlan28: port 1(eno1.28) entered disabled state
[Sa Jan 20 10:58:11 2024] brvlan42: port 1(eno1.42) entered disabled state
[Sa Jan 20 10:58:11 2024] brvlan66: port 1(eno1.66) entered disabled state
[Sa Jan 20 10:58:14 2024] e1000e 0000:00:19.0 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[Sa Jan 20 10:58:14 2024] brvlan28: port 1(eno1.28) entered blocking state
[Sa Jan 20 10:58:14 2024] brvlan28: port 1(eno1.28) entered forwarding state
[Sa Jan 20 10:58:14 2024] brvlan42: port 1(eno1.42) entered blocking state
[Sa Jan 20 10:58:14 2024] brvlan42: port 1(eno1.42) entered forwarding state
[Sa Jan 20 10:58:14 2024] brvlan66: port 1(eno1.66) entered blocking state
[Sa Jan 20 10:58:14 2024] brvlan66: port 1(eno1.66) entered forwarding state

Ich frage mich halt, woher das kommt. Natürlich kann es sein, dass die Netzwerkkarte einen Weg hat. (Onboard-NIC)
Aber, da die Kiste aktuell nicht wirklich was zu tun hat und sich eher in der Gegend herum langweilt, frage ich mich, ob da nicht evtl auch ein Zusammenhang mit den Power-Saving-Optionen (C-States) bestehen könnte.

Ist das eine völlig abwegige Idee? Besteht da ein wahrscheinlicher Zusammenhang? Hat da jemand Erfahrungen oder kann näheres dazu sagen?

Leider steht die Kiste gerade nicht direkt neben mir und hat leider keinen BMC, so dass ich mal eben schnell ins BIOS nach den konfigurierten C-States schauen könnte. Aber ich wollte hier wenigstens schon mal fragen, ob das überhaupt eine Richtung ist, die es wert ist, weiter untersucht zu werden.

TIA

Look

Edith meint: Falls es hilft, die Netzwerkkarte ist eine Intel Corporation Ethernet Connection I217-LM (rev 04)

[foobar]

Im Prinzip ist es denkbar. Die C-States betreffen die CPU und dort läuft ja der Treiber für die NIC. Es kann aber auch am Power Management der PCIe-Verbindung, über welche der Chip vermutlich angebunden ist, liegen. Die ist unabhängig von der CPU und kann auch manchmal Probleme machen. Also im Zweifel auch mal danach gucken (meist unter dem Begriff ASPM zu finden, aber die Board-Hersteller können es nennen, wie sie wollen). Auch mit den entsprechenden Kernel-Parametern kann man mal testweise spielen (z.B. »pcie_aspm=off« oder »pcie_aspm=force pcie_aspm.policy=performance«).

[Lookbehind]

Ich war vor Ort, hab die Kiste durchgebootet und dabei einmal in die BIOS-Einstellungen geschaut. ASPM oder anderweitige Energiespar-Funktionen hab ich nicht gefunden. Aber C-States waren bis einschließlich C7 erlaubt. Ich habs jetzt mal auf C1, C1E und C3 reduziert. Mal sehen ob das Besserung bringt.

Ich habe außerdem Hinweise gefunden, dass es evtl ein Problem mit Hardware-Offloading-Features in dem Ethernet-Chip sein könnten. Zwar beziehen sich die Berichte, die ich gefunden habe, auf den I218 und I219, aber sie tauchen ebenfalls oft im Zusammenhang mit VLAN oder LXC-Containern auf. Beides Dinge, die bei mir eine Rolle spielen.
Man kann das Hardware-Offloading mit ethtool wohl recht feingranular ein und aus schalten. Wenn sich durch die C-States nichts geändert hat, versuche ich das mal.

Jetzt müsste ich nur noch wissen, wie ich das gezielt triggern kann.

[Lookbehind]

So, nach einigem hin und her probieren, bin ich recht zuversichtlich, das Problem behoben zu haben. Auch wenn ich mir da noch nicht 100% sicher bin, da ich es nicht direkt und gezielt auslösen kann. Aber bisher hatte es sich innerhalb von wenigen Stunden manifestiert. Aktuell läuft es seit knapp 3 Stunden stabil.

Das Problem waren nicht, wie zunächst vermutet, die C-States der CPU, sondern tatsächlich das Hardware-Offloading der Netzwerkkarte. Diese kann etliche Aufgaben aus dem Netzwerk-Stack direkt in Hardware erledigen, statt sie dem Betriebssystem zu übergeben. Was natürlich Compute-Ressourcen sparen kann.

Allerdings kommt das hardwareseitige Checksumming wohl nicht so gut mit der Kombination aus VLAN, Bridges und LXC-Containern zurecht. Die Lösung ist, das Hardware-Offloading dafür ab zu schalten.

ethtool -K eno1 tx off rx off

Spoiler:(zum lesen bitte Text markieren)

Aus man ethtool

...
       -K --features --offload
              Changes  the  offload  parameters and other features of the specified network device.
              The following feature names are built-in and others may be defined by the kernel.

           rx on|off
                  Specifies whether RX checksumming should be enabled.

           tx on|off
                  Specifies whether TX checksumming should be enabled.

...

Das muss leider jedes mal gemacht werden, wenn die Netzwerkkarte sich neu initialisiert (Reboot, Kabel raus und wieder rein, link down/up, ...). Daher macht es Sinn, das in ein Post-Up Script für das Netzwerk-Interface zu gießen.