Kopieren über Samba killt eth0

  • Moin,


    nachdem ich eigentlich schon dachte, dass meine neue Netzwerkkarte das Problem gelöst hat, passiert immer noch folgendes:


    Wenn ich über ein Samba-Share von XP aus größere Datenmengen auf den vdr kopiere, vorzugsweise ein paar GB vdr- oder avi-Dateien, bricht die Netzwerkverbindung immer mal wieder zusammen und der Kopiervorgang bricht ab.


    Dann ist eth0 immer so tot, dass vom vdr aus nichts mehr geht - kein ping, gar nix. Ein Restart mit


    Code
    ifdown eth0; ifup eth0


    an der Konsole des vdr lässt alles wie vorher weiterlaufen, sogar offene ssh-Sessions machen weiter als wär' nix passiert. Ist natürlich ärgerlich, weil man nicht weiß, welche Dateien nun erfolgreich kopiert wurden und welche nicht.


    Kennt das jemand und weiß Abhilfe? Evtl. neuen Kernel mit neueren Netzwerkmodulen bauen? Andere Einstellungen im Netzwerkinterfache oder bei Samba?


    Ratlose Grüße,
    Carsten


    Asrock 4CoreDualSATA2 R2.0, VIA KT800, Celeron 2800, 512 MB, 250 GB PATA System,
    4 x 250 GB SATA RAID 5 (No Spare) /video, c't-vdr 4.5 + e-tobi, dist-upgrade auf etch, Intel PRO/1000MT, Kernel 2.6.26-bpo
    2 x Hauppauge Nova-T 2, 2 x Hauppauge MediaMVP E1 unter VOMP

  • Wenn der Link weg ist sollte eine Meldung im Output von dmesg zu finden sein.


    Statistiken zum Interface gibt es bei ifconfig, bei unterstützen Karten auch mit ethtool -S ethX.


    der VIA Chipsatz könnte auch das Problem sein, allerdings sind in halbwegs aktuellen Kernel Workarrounds implementiert. Stichwort quirks.

  • Erstmal danke für die Tipps, werde heute mal schauen, ob ich das gezielt reproduzieren kann und dann die Protokolle durchsehen.


    Grüße,
    Carsten


    Asrock 4CoreDualSATA2 R2.0, VIA KT800, Celeron 2800, 512 MB, 250 GB PATA System,
    4 x 250 GB SATA RAID 5 (No Spare) /video, c't-vdr 4.5 + e-tobi, dist-upgrade auf etch, Intel PRO/1000MT, Kernel 2.6.26-bpo
    2 x Hauppauge Nova-T 2, 2 x Hauppauge MediaMVP E1 unter VOMP

  • Und bist Du schon weitergekommen?


    Ich vermute mal Du nutzt die Intel PRO/1000MT und nicht ein eventuelles VIA onboard LAN?


    Ich habe nämlich auch die Intel und eben selbiges Problem festgestellt.
    Habe den 2.6.20.1er kernel am laufen da passiert allerdings was anderes.
    Mier ist beim Kopieren meiner VDR backups übers Netz aufgefallen, dass ich alle Nase lang meine SSH Verbindung verliere und auch die externe Festplatte auf die ich kopierte immer wieder stehen geblieben ist.


    Tja dmesg zeigts:


    Da existiert also wirklich ein Problem.
    Habe dann mal den Kernel 2.6.15-ct-1 (den Du ja auch nutzt) gebootet und siehe da, nix dmesg sondern wie von Dir beschrieben das interface komplett weg, nur noch direkt am Rechner mit ifconfig wieder zum Leben zu erwecken.


    Nun bin ich selber am forschen, das Problem scheint aber am Treiber selbst zu liegen, siehe auch:
    http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449

    VDR1: AMD Sempron 2200+, KT600-A, 2TB HDD, TT DVB-T 1.2, 2x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.21.4 (ct4), VDR 1.4.7-2 (Tobi/TomG), touchTFT, atmo, Wakü

    VDR2: Intel Celeron Core 440, P5VD2-X, 2.5TB HDD, TT DVB-S 1.5, 3x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.25.10 (ct6.1), VDR 1.6.0-6 (Tobi/TomG), touchTFT

  • Also ich habe eine Verbesserung erzielt (bisher keinerlei Hänger - kernel 2.6.20.1) durch Setzen von:

    Code
    ethtool -s ethX autoneg off duplex full
    ethtool -K ethX tso off


    Infos dazu habe ich von hier und hier


    Vermutlich hilft das deaktvieren von tso. Bin mir aber nicht sicher, da ich erst seit dem ich beides gemacht hatte Ruhe habe. Kann aber auch ein Zufall sein. Werde jetzt noch mal eine Weile gigabytes durchs Netz schaufen.

    VDR1: AMD Sempron 2200+, KT600-A, 2TB HDD, TT DVB-T 1.2, 2x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.21.4 (ct4), VDR 1.4.7-2 (Tobi/TomG), touchTFT, atmo, Wakü

    VDR2: Intel Celeron Core 440, P5VD2-X, 2.5TB HDD, TT DVB-S 1.5, 3x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.25.10 (ct6.1), VDR 1.6.0-6 (Tobi/TomG), touchTFT

    Einmal editiert, zuletzt von Strider ()

  • Hallo,


    danke für die Tipps bzgl. der Einstellungen der Intel-Karte. Bin in den letzten Tagen nicht so recht zum ausprobieren gekommen, das werde ich mal am Wochenende nachholen. Habe mich in den letzten Tagen mit einem merkwürdigen Transkodier-Phänomen rumgeschlagen, deshalb keine Zeit für anderes.


    Deine Vermutung bzgl. der Ethernet-Karte ist richtig, eth0 ist die Intel-Karte. Die hatte ich eingebaut, als das gleiche Phänomen (aber noch öfter) mit der Onboard-Realtek-Karte auftrat. Die liegt z.Z. brach.


    Danke schonmal für die Infos.


    Grüße,
    Carsten


    Asrock 4CoreDualSATA2 R2.0, VIA KT800, Celeron 2800, 512 MB, 250 GB PATA System,
    4 x 250 GB SATA RAID 5 (No Spare) /video, c't-vdr 4.5 + e-tobi, dist-upgrade auf etch, Intel PRO/1000MT, Kernel 2.6.26-bpo
    2 x Hauppauge Nova-T 2, 2 x Hauppauge MediaMVP E1 unter VOMP

  • Also ich habe nun bestimmt die letzten 10 Stunden mit dem Problem verbracht, immerhin mit Teilerfolg.


    Wie es aussieht liegt es am Treiber, nur bevor ich jetzt mir die Funktionsweise eines für mich neuen Contentversionierungssystems (GIT) aneigene und bis in die Tiefen von Linus Torvalds und der kernel Entwickler vordringe, warte ich ersteinmal das nächste Release des Intel Treibers ab.


    Es gibt die Version 7.3.20 vom Treiber (mitte Dezember), welcher aber zu kernel 2.6.20 inkompatiebel ist, 2.6.19 Version soll noch funktionieren.
    Es gibt zwar auch den k2 patchlevel (wie u.a. auch für 7.3.15-k2 im 2.6.20.1er kernel einer existiert), nur habe ich dazu erstmal keinen patch gefunden, der liegt irgendwo in GIT.
    Da habe ich jetzt aber kein Bock mehr drauf, da die Möglichkeit besteht, dass mein Problem immer noch bestehen wird. Es gibt nämlich viele Gründe. Es hängt oft mit anderen Komponenten zusammen die sich im PCI bus irgendwie stören. Bei einigen half ein Eeprom patch, bei anderen dafür diverse Optionen für den Treiber, wiederum woanders das Aktivieren von delayed PCI transaction oder das Tauschen das Mainboards bzw Umstecken der PCI Karten etc pp.


    Bevor ich jetzt aber alle gesammelten hardware Infos in den bugtracker schiebe, will ich ersteinmal den neuen Treiber testen. Evtl. backe ich mir mal einen 19er kernel zum Teseten.


    Was ich Dir empfehlen kann ist auch bei Gelegenheit auf den 2.6.20er kernel umzusteigen (wilderigel hat ja ein schönes howto dafür geschrieben klick)


    Wenn Du NFS nutzt, dann nimm aber gleich die 2.6.20.1, da die 20 ein bug im Zusammenhang mit NFS enthält.
    In diesem Fall das howto genauso anwenden nur entprechend anstatt 2.6.20 überall 2.6.20.1 verwenden und im Makefile: EXTRAVERSION = .1-dvb


    Vorteil gegenüber 2.6.15 ist ein greifender watchdog, so dass Dein ethernet interface bei "Detected Tx Unit Hang" immer neu gestartet wird:
    "e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex"


    Was ich sonst noch rausgefunden habe (bei mir zumindest) ist, dass wenn unter dmesg TDH nicht gleich TDT ist, dann das Problem sehr häufig auftritt.
    Kopiere ich große Files, dann hängt mein interface spätestens alle 30 Sekunden. Samba stört das nicht, das macht dann nach 10 Sekunden weiter, aber die Performance geht klar in den Keller und parallel auf SSH Vernindungen rumtoben ist dann auch nicht, weil laufend Abbrüche.


    Deaktivieren von TSO hat bei mir zwar keine 100% Lösung gebracht, aber eine wesentliche Verbesserung (hangs höchstens mal alle 5 Minuten anstatt alle 30 Sekunden)


    Code
    ethtool -K ethX tso off


    Das zuvor genannte "ethtool -s ethX autoneg off duplex full" kannst Du vergessen, das hilft nicht. Das einzige was dadurch passiert, ist dass das interface neu initialisiert und das wohl nötig ist, damit das TSO = off auch was bringt (bzw ist dann TDH erst gleich TDT).


    Sowieso müsste die Reihenfolge dann sein:

    Code
    ethtool -K ethX tso off
    ethtool -s ethX autoneg off duplex full


    Ein "ifconfig -ethX down; ifconfig ethX up" wird es sicher genauso tun.


    Oder halt den watchdog zuschlagen lassen.


    Von daher, und da ich eh selten mal grosse Daten schiebe, kann ich damit erstmal gut leben wenn ich alle Jubeljahre mal GBs an Daten schieben muss bricht mir nix ab wenn ich mal TSO deaktivieren muss. Wen es dennoch nervt -> /etc/init.d/ + /etc/rc2.d/ sein Dein Freund.

    VDR1: AMD Sempron 2200+, KT600-A, 2TB HDD, TT DVB-T 1.2, 2x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.21.4 (ct4), VDR 1.4.7-2 (Tobi/TomG), touchTFT, atmo, Wakü

    VDR2: Intel Celeron Core 440, P5VD2-X, 2.5TB HDD, TT DVB-S 1.5, 3x Avermedia AverTV DVB-T 771, Debian Linux etch 2.6.25.10 (ct6.1), VDR 1.6.0-6 (Tobi/TomG), touchTFT

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!