You are not logged in.

Kopieren über Samba killt eth0

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Casimir

Trainee

  • "Casimir" started this thread

Posts: 127

Location: Bremen

  • Send private message

1

Tuesday, February 20th 2007, 7:47am

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

Source code

 
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

wilderigel

Im Forum Zuhause

Posts: 16,946

Location: Ansfelden

  • Send private message

2

Tuesday, February 20th 2007, 10:14am

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

Moses123

Intermediate

Posts: 280

  • Send private message

3

Tuesday, February 20th 2007, 12:53pm

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

mauerspecht

Intermediate

Posts: 515

  • Send private message

4

Tuesday, February 20th 2007, 11:37pm

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.

Casimir

Trainee

  • "Casimir" started this thread

Posts: 127

Location: Bremen

  • Send private message

5

Wednesday, February 21st 2007, 7:17am

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

Intermediate

Posts: 191

Location: Berlin

Occupation: IT-Developer

  • Send private message

6

Friday, February 23rd 2007, 2:35am

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:

Source code

 
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

Intermediate

Posts: 191

Location: Berlin

Occupation: IT-Developer

  • Send private message

7

Friday, February 23rd 2007, 3:41am

RE: Kopieren über Samba killt eth0

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

Source code

 
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

This post has been edited 1 times, last edit by "Strider" (Feb 23rd 2007, 3:43am)

Casimir

Trainee

  • "Casimir" started this thread

Posts: 127

Location: Bremen

  • Send private message

8

Friday, February 23rd 2007, 10:18am

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

Intermediate

Posts: 191

Location: Berlin

Occupation: IT-Developer

  • Send private message

9

Friday, February 23rd 2007, 5:21pm

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)

Source code

 
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:

Source code

 
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