# LAN-Verbindung bricht unter Last zusammen>reset erf.[solved]

## Randy Andy

Hallo Leute es geht mal wieder um den leidigen Toshiba Satellite Laptop für meine Perle.

Habe das hier beschriebene Problem, mit dem zusammen brechendem WLAN immer noch:

https://forums.gentoo.org/viewtopic-t-902840-highlight-.html Daher surft meine Perle stets per LAN-Kabel.

Alle kernel-updates seither haben keine Verbesserung gebracht. 

Doch entgegen meiner dort aufgestellten Behauptung, habe ich heute festgestellt dass auch das LAN unter hoher Last zusammenbricht.

Vielleicht gibt es ja einen Zusammenhang der sich mir nicht erschließt und bei dem ihr mir mit neuen Ideen helfen könnt...

Ein Backup einer 20GB Partition mittels ssh/rsync genügt, damit sich die Verbindung und damit auch die Netzwerkkarte aufhängt.

Im Verlauf der Übertragung nimmt die Geschwindigkeit plötzlich drastisch ab bis es schließlich zu einem Verbindungsabbruch kommt, dann erhalte ich meist diese Fehlermeldung:

```

Write failed: Broken pipe

rsync: connection unexpectedly closed (706959024 bytes received so far) [receiver]

rsync error: error in rsync protocol data stream (code 12) at io.c(605) [receiver=3.0.9]

rsync: connection unexpectedly closed (300 bytes received so far) [generator]

rsync error: unexplained error (code 255) at io.c(605) [generator=3.0.9]
```

Anschließend antwortet die NIC auf keinen ping, und ein reset/reboot ist erforderlich um sie wieder ansprechen zu können.

Am Kabel bzw. der Qualität der Verbindung liegt's nicht, denn andere Laptops am gleichen Kabel laufen prima durch unter gleichen Bedingungen.

Ich hab's auch schon mit der SystemRescueCD versucht, passiert damit genauso.

Hab auch schon mit verschiedenen kerneln und mit unterschiedlichen Konfigurationen experimentiert, bisher ohne Erfolg:

 [*]   Realtek devices                                                                                         │

                           < >     RealTek RTL-8139 C+ PCI Fast Ethernet Adapter support (EXPERIMENTAL)                                  

                          <*>     RealTek RTL-8129/8130/8139 PCI Fast Ethernet Adapter support                                          

                           [*]       Use PIO instead of MMIO                                                                             

                           [*]       Support for uncommon RTL-8139 rev. K (automatic channel equalization)                              

                           [*]       Support for older RTL-8129/8130 boards                                                              

                           [*]       Use older RX-reset method  

Habe alle denkbaren Kombinationen der oben gesetzten * der kernel module  durchprobiert. 

Mit der oberen hier nicht gewählten Variante lässt sich die NIC garnicht ansprechen, obwohl laus lspci diese eine RTL-8139 C+ sein soll.

```
09:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

        Subsystem: Toshiba America Info Systems Device ff31

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 64 (8000ns min, 16000ns max)

        Interrupt: pin A routed to IRQ 21

        Region 0: I/O ports at a000 [size=256]

        Region 1: Memory at c0210000 (32-bit, non-prefetchable) [size=256]

        Capabilities: [50] Power Management version 2

                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)

                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

        Kernel driver in use: 8139too

Und das noch zustätzlich wegen des WLAN-Problems:

09:04.0 Ethernet controller: Atheros Communications Inc. AR2413/AR2414 Wireless Network Adapter [AR5005G(S) 802.11bg] (rev 01)

        Subsystem: Askey Computer Corp. Device 7094

        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes

        Interrupt: pin A routed to IRQ 22

        Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=64K]

        Capabilities: [44] Power Management version 2

                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-

        Kernel driver in use: ath5k

```

Gibt's da sonst noch Netzwerk-Protokoll mäßig Einstellungen die derlei Wechselwirkung ausüben können?

Hab so'n Mist bisher noch mit keiner Hardware gehabt, zur Sicherheit hier noch die gesamte kernel.config:

http://paste.pocoo.org/show/584160/

Hab die stille Hoffnung, dass wenn erstmal dieses Problem gelöst ist, es vielleicht mit dem WLAN  auch klappen könnte.

Gruß und Dank, Andy.

----------

## yuhu

Hallo,

das was du beschreibst klingt so ähnlich was meine Intel Netzwerkkarte auch hat.

```
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

   Subsystem: Intel Corporation Gigabit CT Desktop Adapter

   Kernel driver in use: e1000e

```

Und zwar stellt diese nach einer undefinierten Zeit den Dienst ein.

Im Netz bin ich dann nach längerer Suche auf Probleme dieses Chipsatzes im Zusammenhang mit ASPM gekommen.

Mit Hilfe des Artikels ASPM - Linux Wireless habe ich dann gezielt für dieses Device das ASPM deaktiviert.

Sieht dann so aus. (local.d)

```
setpci -s 00:1c.0 0x50.B=0x40
```

Seitdem läuft wieder alles ohne Probleme.Last edited by yuhu on Sun Apr 22, 2012 5:06 pm; edited 2 times in total

----------

## Randy Andy

Yuhu,

danke für deine Antwort und die damit neu gewonnenen Kenntnisse.

Leider hat besagter Laptop kein ASPM da er kein PCI-Express hat. 

Im Kernel dagegen war ASPM Support aktiviert, abschalten dort hat aber auch nichts verbessert.

Habe darauf hin angefangen mit allerlei Kernel-Einstellungen bezüglich QOS, und Flow Control zu experimentieren und scheine nun eine Einstellung gefunden zu haben, die zumindest einen stabilen rsync Abgleich per LAN ermöglicht.

Habe im ersten Schwung aber so viele Settings geändert, dass ich nicht konkret sagen kann welcher denn letztlich davon ausschlaggebend war.

Mit dem WLAN bin ich deshalb aber keinen Schritt weiter.

Aber hier in diesem Thread ging's ja auch nur um's LAN, weshalb ich ihn wohl in Bälde als gelöst markieren werde.

Gruß, Andy.

----------

