LAN fällt aus unter Fedora bei viel Traffic

[Krakadil]

Abend,

ich habe ein paar neue Festplatten für den NAS und bin am verschieben/ kopieren. Beim Kopieren erscheint eine Fehlemeldung, das die Verbindung weg ist und ich kann nur auf Wiederholen oder Abbrechen klicken.

Zuerst dachte ich NAS bereitet Probleme, es ist aber der LAN-Port, dieser "stirbt" einfach weg. Ein einfaches Abmelden hilft nicht, Rechner muss neu gestartet werden, dann aber läuft alles ohne Probleme. Festgestellt habe ich das als ich über den Browser den NAS aufrufen wollte aber das nicht möglich war, genau wie das Surfen im Netz, so als würde kein LAN-Kabel dran hängen. LAN an und aus > Verbindung wird hergestellt, es passierr aber nichts.

Das Problem habe ich nur, wenn ich Dateien auf den NAS kopiere. Sonst habe ich hier überhaupt keine Probleme. Das Merkwürdige ist, es gibt keine Regel dafür. Mal schmiert der Port nach 30GB ab aber auch oft nicht einmal nach einem TB. Vor allem tritt das Problem aber auf, wenn ich mehrere Kopiervorgänge am laufen habe. Von Dock auf Desktop und von Desktop auf NAS Platte 1 und 2 (gleichzeitig). Das geht aber such oft ohne Probleme durch. Wie gesagt, eine Regel kann ich hier nicht aufbauen - es passiert einfach.

2.5G LAN vom ASUS B650E-E + 2.5G Switch + Fritzbox 7690 (alles per Kabel). Beim Kopieren über SMB sind es max. 84 MB/s unter Fedora, Windows erreicht deutlich bessere Werte aber LAN ist mit 1G angebunden, somsit rund 110 MB/s. Das Problem mit der Geschwindigkeit kenne ich aber seit Ubuntu aus 2012, da SMB und das sich bis heute nicht geändert hat. Ob Fedora KDE oder GNOME (Nautilus und Dolphin) spielt keine Rolle

Ich werde es schon überleben aber es nervt halt sehr. Unter Windows habe ich es nicht getestet, da ich Windows wirklich nur boote um zu spielen.


Gruß

 

[N0Thing]

Liegt evtl. am verbauten Netzwerk-Chip auf dem Mainboard.

https://duckduckgo.com/?q=Intel+I225-V+probleme&t=fpas&ia=web

Für Windows hat Intel neue Software und Treiber veröffentlicht, für Linux gibt es vielleicht auch eine Lösung.

 

[GTrash81]

Oder es ist Gen 1 bzw. Gen 2, eine davon hat einen Designfehler, der durch Treiber nicht zu reparieren ist.

 

[JumpingCat]

Zuerst dachte ich NAS bereitet

Welches ist es denn?

2.5G Switch

Welcher ist es denn? Firmware auf dem Teil ist aktuell?

 

[Linuxfreakgraz]

Mal in den Beschreibungen der Mainboards und des Routers nachsehen was die Maximale Datenrate ist, nur weil das eine Gerät das kann heißt das nicht das die anderen das unterstützen.

 

[agon]

Evtl. mal Active-State Power Management (ASPM) auf Performance setzen (oder "deaktivieren"), siehe:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/power_management_guide/aspm

Also Kernel Parameter pcie_aspm.policy=performance hinzufügen.

Das kann nämlich auch ein Fix für den Intel I226-V sein, siehe bspw.:
https://community.intel.com/t5/Ethe...V-is-still-randomly-disconnecting/m-p/1644566

 

[Piktogramm]

Steht was im Journal, was mit dem Netzwerkchip und/oder Softwarestack zusammenhängt?
journalctl -r -p 0..3
Im Zweifelsfall auch mal die niedrigere Fehlerstufen wählen (also 0..4 oder gar 0..5).

 

[Krakadil]

pcie_aspm=off

Probiere ich mal aus.

 

[X-Worf]

Hats geklappt? Ich glaube Fedora blockiert das, weil das zu Hardwareschäden führen kann. Es wird zumindest ausdrücklich davon abgeraten.

 

[qiller]

Hab genau das gleiche Problem mit nem onboard i-219V in nem IPFire gehabt. Musste dann per ethtool diverse Offloading Funktionen deaktivieren:

ethtool -K orange0 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

'orange0' müsstest dann mit deinem NIC-Gerätenamen ersetzen.
In den Logs kamen dann solche Einträge (NIC lief in einer IPFire-FW):

ipfire kernel: e1000e 0000:00:1f.6 orange0: Detected Hardware Unit Hang:
ipfire kernel:   TDH                  <e4>
ipfire kernel:   TDT                  <15>
ipfire kernel:   next_to_use          <15>
ipfire kernel:   next_to_clean        <de>
ipfire kernel: buffer_info[next_to_clean]:
ipfire kernel:   time_stamp           <19aa905b0>
ipfire kernel:   next_to_watch        <e4>
ipfire kernel:   jiffies              <19aa92a80>
ipfire kernel:   next_to_watch.status <0>
ipfire kernel: MAC Status             <40080083>
ipfire kernel: PHY Status             <796d>
ipfire kernel: PHY 1000BASE-T Status  <3800>
ipfire kernel: PHY Extended Status    <3000>
ipfire kernel: PCI Status             <10>
ipfire kernel: e1000e 0000:00:1f.6 orange0: NETDEV WATCHDOG: CPU: 4: transmit queue 0 timed out 10822 ms
ipfire kernel: e1000e 0000:00:1f.6 orange0: Reset adapter unexpectedly

Passierte wie beim TE nur unter größerer Netzwerklast.

 

[agon]

Hats geklappt? Ich glaube Fedora blockiert das, weil das zu Hardwareschäden führen kann. Es wird zumindest ausdrücklich davon abgeraten.

Lt. https://docs.redhat.com/en/document..._parameters_changes#kernel_parameters_changes
wird jedenfalls nicht von pcie_aspm=off abgeraten. Das gleiche Ergebnis lässt sich erreichen, indem man im UEFI ASPM "deaktiviert". Das UEFI kümmert sich dann darum.

 

[Krakadil]

Hats geklappt? Ich glaube Fedora blockiert das, weil das zu Hardwareschäden führen kann. Es wird zumindest ausdrücklich davon abgeraten.

Keinen Ausfall seitdem gehabt.