e1000e - eth1: Detected Hardware Unit Hang
Hallo! Habe auf einem wichtigen Server Opensuse 12.3 laufen und habe den Kernel inzwischen schon auf 3.12.6 (vanilla; von kernel.org) hochgerüstet. Seit kurzem hat der Server gewollt viel Ethernet-Verkehr. Seither fallen immer kurze Hänger bei den Netzwerkverbindungen auf. Zufällig habe ich dann im "dmesg" folgende Meldungen gesehen: [2527105.320470] monitor[28495]: segfault at 205 ip b7649253 sp bfadd670 error 4 in libglib-2.0.so.0.3400.3[b75bf000+fc000] [2527178.928728] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: [2527178.928728] TDH <bb> [2527178.928728] TDT <f9> [2527178.928728] next_to_use <f9> [2527178.928728] next_to_clean <bb> [2527178.928728] buffer_info[next_to_clean]: [2527178.928728] time_stamp <25a74437> [2527178.928728] next_to_watch <bc> [2527178.928728] jiffies <25a74735> [2527178.928728] next_to_watch.status <0> [2527178.928728] MAC Status <2080787> [2527178.928728] PHY Status <792d> [2527178.928728] PHY 1000BASE-T Status <3800> [2527178.928728] PHY Extended Status <3000> [2527178.928728] PCI Status <10> [2527182.204932] monitor[31297]: segfault at 205 ip b7703253 sp bfddb440 error 4 in libglib-2.0.so.0.3400.3[b7679000+fc000] [2527182.928676] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: [2527182.928676] TDH <bb> [2527182.928676] TDT <f9> [2527182.928676] next_to_use <f9> [2527182.928676] next_to_clean <bb> [2527182.928676] buffer_info[next_to_clean]: [2527182.928676] time_stamp <25a74437> [2527182.928676] next_to_watch <bc> [2527182.928676] jiffies <25a74b1d> [2527182.928676] next_to_watch.status <0> [2527182.928676] MAC Status <2080787> [2527182.928676] PHY Status <792d> [2527182.928676] PHY 1000BASE-T Status <3800> [2527182.928676] PHY Extended Status <3000> [2527182.928676] PCI Status <10> [2527182.972596] e1000e 0000:04:00.1 eth1: Reset adapter unexpectedly [2527186.183396] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [2527199.561477] check_nt[1536]: segfault at 0 ip b7588acc sp bfe0b330 error 4 in libc-2.17.so[b7556000+174000] [2527200.571616] check_nt[1542]: segfault at 0 ip b75ecacc sp bff0d210 error 4 in libc-2.17.so[b75ba000+174000] Jedes Mal, wenn dieser Fehler auftritt, ist die Netzwerkverbindung für ein paar Sekunden weg. Abhängig von der Reaktionsgeschwindigkeit des Switches können das schon mal 3 bis 6 Sekunden sein. Hab nach dem Fehler schon fleißig gegoogelt, hab aber keine Lösung finden können. z.B. https://bugzilla.redhat.com/show_bug.cgi?id=785806 Mancherorts wird empfohlen, FlowControl auszuschalten, was bei mir schon immer so war, ohne Erfolg. Den Tipp mit dem Byte im EEPROM ändern hab ich nicht angewendet, da bei mir der Ausgangs-Inhalt ein anderer war. # ethtool eth1 Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes # ethtool -i eth1 driver: e1000e version: 2.3.2-k firmware-version: 1.0-0 bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no Einen Hardware-Defekt schließe ich aus, da der Fehler meistens auf eth1 auftritt und gelegentlich auch auf eth0. Auch der Switch wurde schon probehalber getauscht. Bin ich der einzige, der diesen Netzwerktreiber bei hoher Netzwerklast einsetzt und damit Probleme hat? (der anderer Server läuft mit Kernel 2.6.32.8 mit mindestens der selben Netzwerklast, da gibt es diese Probleme nicht) Hab keine Idee, wie ich das wirksam lösen könnte. Könnt ihr mir da bitte helfen? Liebe Grüße Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 2. Februar 2014, 12:21:41 schrieb Günther Zisham:
(...). Seit kurzem hat der Server gewollt viel Ethernet-Verkehr. Seither fallen immer kurze Hänger bei den Netzwerkverbindungen auf.
Was ist das für ein Ethernet-Adapter genau? (lspci)
(...). Den Tipp mit dem Byte im EEPROM ändern hab ich nicht angewendet, da bei mir der Ausgangs-Inhalt ein anderer war.
Falls wir das gleiche meinen, dafür gibt es ein Bash-Script, was auch überprüft, ob du überhaupt so einen betroffenen Adapter hast: fixeep-82573- dspd.sh
(...). # ethtool -i eth1 driver: e1000e version: 2.3.2-k (...).
Kannst du mal die aktuelle Version des e1000e-Treibers ausprobieren? Ich würde ihn an deiner Stelle wohl selbst kompilieren, wegen des Vanilla- Kernels. Fertig gibt es den sonst hier: http://software.opensuse.org/package/intel-e1000e Aus dem Changelog: | - Version 2.5.4 | (...). | * Fix - Hardware Unit Hang | (...). Gruß Jan -- Some men are alive simply because it is against the law to kill them. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo! Am 2014-02-02 14:35, schrieb Jan Ritzerfeld:
Am Sonntag, 2. Februar 2014, 12:21:41 schrieb Günther Zisham:
(...). Seit kurzem hat der Server gewollt viel Ethernet-Verkehr. Seither fallen immer kurze Hänger bei den Netzwerkverbindungen auf.
Was ist das für ein Ethernet-Adapter genau? (lspci)
Gut, das ist ein Argument, ich habe keinen 82573-Chip drauf: 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) Detailliert (lspci -vvv): 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Intel S5000PSLSATA Server Board Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 66 Region 0: Memory at b8820000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at b8400000 (32-bit, non-prefetchable) [size=4M] Region 2: I/O ports at 2020 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 4162 Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM unknown, Latency L0 <128ns, L1 <64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 10, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-xx-xx-xx Kernel driver in use: e1000e 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Intel S5000PSLSATA Server Board Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 67 Region 0: Memory at b8800000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at b8000000 (32-bit, non-prefetchable) [size=4M] Region 2: I/O ports at 2000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 4142 Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM unknown, Latency L0 <128ns, L1 <64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 10, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140 v1] Device Serial Number 00-15-17-ff-ff-xx-xx-xx Kernel driver in use: e1000e
(...). Den Tipp mit dem Byte im EEPROM ändern hab ich nicht angewendet, da bei mir der Ausgangs-Inhalt ein anderer war.
Falls wir das gleiche meinen, dafür gibt es ein Bash-Script, was auch überprüft, ob du überhaupt so einen betroffenen Adapter hast: fixeep-82573- dspd.sh
Folgendes Skript habe ich probiert: http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh No appropriate hardware found for this fixup Gut so :-)
(...). # ethtool -i eth1 driver: e1000e version: 2.3.2-k (...).
Kannst du mal die aktuelle Version des e1000e-Treibers ausprobieren? Ich würde ihn an deiner Stelle wohl selbst kompilieren, wegen des Vanilla- Kernels. Fertig gibt es den sonst hier: http://software.opensuse.org/package/intel-e1000e Aus dem Changelog: | - Version 2.5.4 | (...). | * Fix - Hardware Unit Hang | (...).
Ja, das werde ich als nächstes testen. Muss aber erst mal meine Testumgebung dafür anpassen.
Gruß Jan
Vielen Dank!! Hab ein gutes Gefühl mit dem neuen Treiber, könnte funktionieren. Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2014-02-02 23:08, schrieb Günther Zisham:
Vielen Dank!! Hab ein gutes Gefühl mit dem neuen Treiber, könnte funktionieren.
Hallo! Hab den neuen Treiber einspielen können: # ethtool -i eth1 driver: e1000e version: 2.5.4-NAPI firmware-version: 1.0-0 bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no Leider tritt der Fehler unter Netzwerk-Last noch immer auf: Feb 4 23:36:19 s1 kernel: [2985571.964754] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:36:19 s1 kernel: [2985571.964754] TDH <2f> Feb 4 23:36:19 s1 kernel: [2985571.964754] TDT <5a> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_use <5a> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_clean <2d> Feb 4 23:36:19 s1 kernel: [2985571.964754] buffer_info[next_to_clean]: Feb 4 23:36:19 s1 kernel: [2985571.964754] time_stamp <2c7be49d> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_watch <2f> Feb 4 23:36:19 s1 kernel: [2985571.964754] jiffies <2c7be8a8> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_watch.status <0> Feb 4 23:36:19 s1 kernel: [2985571.964754] MAC Status <2080787> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY Status <792d> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY 1000BASE-T Status <3800> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY Extended Status <3000> Feb 4 23:36:19 s1 kernel: [2985571.964754] PCI Status <10> Feb 4 23:36:23 s1 kernel: [2985575.964694] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:36:23 s1 kernel: [2985575.964694] TDH <2f> Feb 4 23:36:23 s1 kernel: [2985575.964694] TDT <5a> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_use <5a> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_clean <2d> Feb 4 23:36:23 s1 kernel: [2985575.964694] buffer_info[next_to_clean]: Feb 4 23:36:23 s1 kernel: [2985575.964694] time_stamp <2c7be49d> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_watch <2f> Feb 4 23:36:23 s1 kernel: [2985575.964694] jiffies <2c7bec90> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_watch.status <0> Feb 4 23:36:23 s1 kernel: [2985575.964694] MAC Status <2080787> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY Status <792d> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY 1000BASE-T Status <3800> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY Extended Status <3000> Feb 4 23:36:23 s1 kernel: [2985575.964694] PCI Status <10> Feb 4 23:36:27 s1 kernel: [2985580.171413] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Feb 4 23:58:25 s1 kernel: [2986898.000712] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:58:25 s1 kernel: [2986898.000712] TDH <fe> Feb 4 23:58:25 s1 kernel: [2986898.000712] TDT <12> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_use <12> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_clean <fa> Feb 4 23:58:25 s1 kernel: [2986898.000712] buffer_info[next_to_clean]: Feb 4 23:58:25 s1 kernel: [2986898.000712] time_stamp <2c80f23b> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_watch <fe> Feb 4 23:58:25 s1 kernel: [2986898.000712] jiffies <2c80f79d> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_watch.status <0> Feb 4 23:58:25 s1 kernel: [2986898.000712] MAC Status <2080787> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY Status <792d> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY 1000BASE-T Status <7800> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY Extended Status <3000> Feb 4 23:58:25 s1 kernel: [2986898.000712] PCI Status <10> Feb 4 23:58:27 s1 kernel: [2986900.012061] e1000e 0000:04:00.1 eth1: Reset adapter unexpectedly Feb 4 23:58:30 s1 kernel: [2986902.783430] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Desto mehr Netzwerklast, desto mehr Fehler dieser Art. Noch andere Ideen? Gruß Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 05.02.2014 00:12, schrieb Günther Zisham:
Am 2014-02-02 23:08, schrieb Günther Zisham:
Vielen Dank!! Hab ein gutes Gefühl mit dem neuen Treiber, könnte funktionieren.
Hallo!
Hab den neuen Treiber einspielen können:
# ethtool -i eth1 driver: e1000e version: 2.5.4-NAPI firmware-version: 1.0-0 bus-info: 0000:04:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no
Leider tritt der Fehler unter Netzwerk-Last noch immer auf:
Feb 4 23:36:19 s1 kernel: [2985571.964754] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:36:19 s1 kernel: [2985571.964754] TDH <2f> Feb 4 23:36:19 s1 kernel: [2985571.964754] TDT <5a> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_use <5a> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_clean <2d> Feb 4 23:36:19 s1 kernel: [2985571.964754] buffer_info[next_to_clean]: Feb 4 23:36:19 s1 kernel: [2985571.964754] time_stamp <2c7be49d> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_watch <2f> Feb 4 23:36:19 s1 kernel: [2985571.964754] jiffies <2c7be8a8> Feb 4 23:36:19 s1 kernel: [2985571.964754] next_to_watch.status <0> Feb 4 23:36:19 s1 kernel: [2985571.964754] MAC Status <2080787> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY Status <792d> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY 1000BASE-T Status <3800> Feb 4 23:36:19 s1 kernel: [2985571.964754] PHY Extended Status <3000> Feb 4 23:36:19 s1 kernel: [2985571.964754] PCI Status <10>
Feb 4 23:36:23 s1 kernel: [2985575.964694] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:36:23 s1 kernel: [2985575.964694] TDH <2f> Feb 4 23:36:23 s1 kernel: [2985575.964694] TDT <5a> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_use <5a> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_clean <2d> Feb 4 23:36:23 s1 kernel: [2985575.964694] buffer_info[next_to_clean]: Feb 4 23:36:23 s1 kernel: [2985575.964694] time_stamp <2c7be49d> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_watch <2f> Feb 4 23:36:23 s1 kernel: [2985575.964694] jiffies <2c7bec90> Feb 4 23:36:23 s1 kernel: [2985575.964694] next_to_watch.status <0> Feb 4 23:36:23 s1 kernel: [2985575.964694] MAC Status <2080787> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY Status <792d> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY 1000BASE-T Status <3800> Feb 4 23:36:23 s1 kernel: [2985575.964694] PHY Extended Status <3000> Feb 4 23:36:23 s1 kernel: [2985575.964694] PCI Status <10> Feb 4 23:36:27 s1 kernel: [2985580.171413] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Feb 4 23:58:25 s1 kernel: [2986898.000712] e1000e 0000:04:00.1 eth1: Detected Hardware Unit Hang: Feb 4 23:58:25 s1 kernel: [2986898.000712] TDH <fe> Feb 4 23:58:25 s1 kernel: [2986898.000712] TDT <12> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_use <12> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_clean <fa> Feb 4 23:58:25 s1 kernel: [2986898.000712] buffer_info[next_to_clean]: Feb 4 23:58:25 s1 kernel: [2986898.000712] time_stamp <2c80f23b> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_watch <fe> Feb 4 23:58:25 s1 kernel: [2986898.000712] jiffies <2c80f79d> Feb 4 23:58:25 s1 kernel: [2986898.000712] next_to_watch.status <0> Feb 4 23:58:25 s1 kernel: [2986898.000712] MAC Status <2080787> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY Status <792d> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY 1000BASE-T Status <7800> Feb 4 23:58:25 s1 kernel: [2986898.000712] PHY Extended Status <3000> Feb 4 23:58:25 s1 kernel: [2986898.000712] PCI Status <10> Feb 4 23:58:27 s1 kernel: [2986900.012061] e1000e 0000:04:00.1 eth1: Reset adapter unexpectedly Feb 4 23:58:30 s1 kernel: [2986902.783430] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Desto mehr Netzwerklast, desto mehr Fehler dieser Art.
Noch andere Ideen?
Hallo Günther, meine Recherchen haben ergeben, dass dieses Problem schon seit ungefähr 6 Jahren besteht. Hm, das spricht jetzt nicht gerade von Qualität. :-/ Als ich noch ein bisschen weiter recherchiert habe, ist mir eine Sache aufgefallen, die evtl. das Problem lösen könnte. <http://marc.info/?l=e1000-devel&m=123692876128935> Es scheint wohl ein BIOS-Problem bzgl. DMA 64-bit zu der Netzwerkkomponente zu geben. Entweder hilft hier ein BIOS-Update oder man muss die Netzwerkkomponente über den Treiber zwangsweise mit DMA 32-bit kommunizieren lassen. Im Anhang habe ich ein Patch, der die besagte Stelle auskommentiert, falls du es lokal bauen willst. Zusätzlich habe ich mir das e1000e-Paket vom Weberhofer geschnappt und darin den Patch eingepflegt, welches du sofort installieren und ausprobieren kannst. Ich habe zusätzlich noch das Update-Repo in meinem Home-Repo reingehängt, um auch die aktuellen Kernel der jeweiligen openSUSE-Version bereitzustellen. <http://download.opensuse.org/repositories/home:/Freespacer:/branches:/home:/weberho:/kernel-modules/> Lass mal hören, wie es funktioniert. -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: <http://www.sebastian-siebert.de> Wichtiger Hinweis zur openSUSE Mailing Liste: <http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette>
Am 05.02.2014 01:55, schrieb Sebastian Siebert:
Am 05.02.2014 00:12, schrieb Günther Zisham:
Noch andere Ideen? [...] Es scheint wohl ein BIOS-Problem bzgl. DMA 64-bit zu der Netzwerkkomponente zu geben. Entweder hilft hier ein BIOS-Update oder man muss die Netzwerkkomponente über den Treiber zwangsweise mit DMA 32-bit kommunizieren lassen.
Hier muss ich nochmal meine Aussage revidieren. Man sollte ein Problem nicht wirklich in der Nacht lösen, aber es erschien mir zu dem Zeitpunkt noch logisch. Daher vergiss bitte die 32-bit Sache. :-) Also nochmal, der Patch-Schreiber hatte auf ein DAC Problem bei aktivierter DMA unter einem 64-bit System ausfindig gemacht und diesen DAC-Feature deaktiviert. Es scheint aber nach wie vor ein Mainboard-Problem in Verbindung mit dem BIOS zu sein. Anscheinend konnte er das Problem so beheben.
Im Anhang habe ich ein Patch, der die besagte Stelle auskommentiert, falls du es lokal bauen willst.
Im alten Patch habe ich versehentlich zuviel auskommentiert. Im Anhang ist ein korrigierter Patch.
Zusätzlich habe ich mir das e1000e-Paket vom Weberhofer geschnappt und darin den Patch eingepflegt, welches du sofort installieren und ausprobieren kannst. Ich habe zusätzlich noch das Update-Repo in meinem Home-Repo reingehängt, um auch die aktuellen Kernel der jeweiligen openSUSE-Version bereitzustellen.
In meinem Home-Repo wird gerade das Paket nochmal neu gebaut. -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: <http://www.sebastian-siebert.de> Wichtiger Hinweis zur openSUSE Mailing Liste: <http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette>
Hallo Sebastian! Vielen Dank schon mal für die Mühe und die vielen Infos! :-) Am 2014-02-05 21:10, schrieb Sebastian Siebert:
Am 05.02.2014 01:55, schrieb Sebastian Siebert:
Am 05.02.2014 00:12, schrieb Günther Zisham:
Noch andere Ideen? [...] Es scheint wohl ein BIOS-Problem bzgl. DMA 64-bit zu der Netzwerkkomponente zu geben. Entweder hilft hier ein BIOS-Update oder man muss die Netzwerkkomponente über den Treiber zwangsweise mit DMA 32-bit kommunizieren lassen.
Hier muss ich nochmal meine Aussage revidieren. Man sollte ein Problem nicht wirklich in der Nacht lösen, aber es erschien mir zu dem Zeitpunkt noch logisch. Daher vergiss bitte die 32-bit Sache. :-)
Also nochmal, der Patch-Schreiber hatte auf ein DAC Problem bei aktivierter DMA unter einem 64-bit System ausfindig gemacht und diesen DAC-Feature deaktiviert. Es scheint aber nach wie vor ein Mainboard-Problem in Verbindung mit dem BIOS zu sein. Anscheinend konnte er das Problem so beheben.
Werde auf jeden Fall mal diesen Weg versuchen. Ein neueres Bios habe ich soeben gefunden.
Im Anhang habe ich ein Patch, der die besagte Stelle auskommentiert, falls du es lokal bauen willst.
Im alten Patch habe ich versehentlich zuviel auskommentiert. Im Anhang ist ein korrigierter Patch.
Vielen Dank, den Patch werde ich nach dem Bios-Upgrade-Versuch ausprobieren.
Zusätzlich habe ich mir das e1000e-Paket vom Weberhofer geschnappt und darin den Patch eingepflegt, welches du sofort installieren und ausprobieren kannst. Ich habe zusätzlich noch das Update-Repo in meinem Home-Repo reingehängt, um auch die aktuellen Kernel der jeweiligen openSUSE-Version bereitzustellen.
In meinem Home-Repo wird gerade das Paket nochmal neu gebaut.
Danke! Werde doch selbst kompilieren müssen, weil die Versionen im Repository auf den Suse-Kernel 3.7.10 abzielen und ich den Vanilla-Kernel 3.12.6 im Einsatz habe. Oder? Vielen Dank! Gruß, Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo! Am 2014-02-05 21:26, schrieb Günther Zisham:
Also nochmal, der Patch-Schreiber hatte auf ein DAC Problem bei aktivierter DMA unter einem 64-bit System ausfindig gemacht und diesen DAC-Feature deaktiviert. Es scheint aber nach wie vor ein Mainboard-Problem in Verbindung mit dem BIOS zu sein. Anscheinend konnte er das Problem so beheben.
Werde auf jeden Fall mal diesen Weg versuchen. Ein neueres Bios habe ich soeben gefunden.
Das Bios-Upgrade hat funktioniert und der Fehler scheint weg zu sein!! (vorher war es ein Bios von Maxdata von 2006; hab das "neue" Bios von 2009 installiert): http://ftp.maxdata.de/MAXDATA_PLATINUM_Server/Archive/Firmware_and_Bios/Sing... Vielen Dank! Gruß, Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 12.02.2014 22:14, schrieb Günther Zisham:
Hallo!
Am 2014-02-05 21:26, schrieb Günther Zisham:
Also nochmal, der Patch-Schreiber hatte auf ein DAC Problem bei aktivierter DMA unter einem 64-bit System ausfindig gemacht und diesen DAC-Feature deaktiviert. Es scheint aber nach wie vor ein Mainboard-Problem in Verbindung mit dem BIOS zu sein. Anscheinend konnte er das Problem so beheben.
Werde auf jeden Fall mal diesen Weg versuchen. Ein neueres Bios habe ich soeben gefunden.
Das Bios-Upgrade hat funktioniert und der Fehler scheint weg zu sein!! (vorher war es ein Bios von Maxdata von 2006; hab das "neue" Bios von 2009 installiert): http://ftp.maxdata.de/MAXDATA_PLATINUM_Server/Archive/Firmware_and_Bios/Sing...
Vielen Dank!
Gern geschehen. Danke auch für dein Feedback. Ich erlaube mir mal diesen Thread als gelöst zu markieren. ;-) -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: <http://www.sebastian-siebert.de> Wichtiger Hinweis zur openSUSE Mailing Liste: <http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette> -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Günther Zisham -
Jan Ritzerfeld -
Sebastian Siebert