Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Dienstag, 20. Februar 2007, 07:47

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

Quellcode

1
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

2

Dienstag, 20. Februar 2007, 10:14

Steht was in /var/log/syslog, oder in nem Samba Log?
2003 - 2011 - R.I.P.

3

Dienstag, 20. Februar 2007, 12:53

RE: Kopieren über Samba killt eth0

Hallo,

bei großen Datenmengen kann sich auch mal die Karte komplett abschalten, hatte ich mal mit einer Realtek...

Gruß,

Moses123

4

Dienstag, 20. Februar 2007, 23:37

RE: Kopieren über Samba killt eth0

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.

5

Mittwoch, 21. Februar 2007, 07:17

RE: Kopieren über Samba killt eth0

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

Strider

Fortgeschrittener

Beiträge: 191

Wohnort: Berlin

Beruf: IT-Developer

  • Nachricht senden

6

Freitag, 23. Februar 2007, 02:35

RE: Kopieren über Samba killt eth0

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:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <23>
  TDT                  <51>
  next_to_use          <51>
  next_to_clean        <23>
buffer_info[next_to_clean]
  time_stamp           <44f7>
  next_to_watch        <27>
  jiffies              <461f>
  next_to_watch.status <0>
e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <23>
  TDT                  <51>
  next_to_use          <51>
  next_to_clean        <23>
buffer_info[next_to_clean]
  time_stamp           <44f7>
  next_to_watch        <27>
  jiffies              <4813>
  next_to_watch.status <0>
e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <23>
  TDT                  <51>
  next_to_use          <51>
  next_to_clean        <23>
buffer_info[next_to_clean]
  time_stamp           <44f7>
  next_to_watch        <27>
  jiffies              <4a07>
  next_to_watch.status <0>
e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <23>
  TDT                  <51>
  next_to_use          <51>
  next_to_clean        <23>
buffer_info[next_to_clean]
  time_stamp           <44f7>
  next_to_watch        <27>
  jiffies              <4bfb>
  next_to_watch.status <0>
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <23>
  TDT                  <51>
  next_to_use          <51>
  next_to_clean        <23>
buffer_info[next_to_clean]
  time_stamp           <44f7>
  next_to_watch        <27>
  jiffies              <4df0>
  next_to_watch.status <0>
e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

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…302&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

Strider

Fortgeschrittener

Beiträge: 191

Wohnort: Berlin

Beruf: IT-Developer

  • Nachricht senden

7

Freitag, 23. Februar 2007, 03:41

RE: Kopieren über Samba killt eth0

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

Quellcode

1
2
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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Strider« (23. Februar 2007, 03:43)


8

Freitag, 23. Februar 2007, 10:18

RE: Kopieren über Samba killt eth0

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

Strider

Fortgeschrittener

Beiträge: 191

Wohnort: Berlin

Beruf: IT-Developer

  • Nachricht senden

9

Freitag, 23. Februar 2007, 17:21

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)

Quellcode

1
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:

Quellcode

1
2
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

Immortal Romance Spielautomat