eth0: transmit timed out

[Merc]

Hallo allerseits.

Ich habe mal wieder ein kleineres Problem mit einer meiner Netzwerkkarten.
Die betreffende Karte ist eine 3com 3c905 (Typ Boomerang), derzeit als eth0 arbeitend.

Seit einiger Zeit (diese Woche) tritt das Phänomen (zumindest für mich) auf, das die Übertragungsgeschwindigkeiten bei Netzverbindungen (ein- sowohl als auch ausgehend) vom Maximum bis zum Minimum (sprich Null) sinken, was etwa in einer Minute vonstatten geht.

Soll heißen, eben noch geht alles bei voller Geschwindigkeit, dann sinkt eben diese über oben genannten Zeitraum ab bis auf Null.

EIn kleiner Auszug aus "dmesg":

Code: Alles auswählen

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status 6800.
  diagnostics: net 0cc0 media 8802 dma 002000a1 fifo 0000
  Flags; bus-master 1, dirty 2352473(9) current 2352489(9)
  Transmit list 01b63ac0 vs. c1b637a0.
  0: @c1b63200  length 800005ea status 000005ea
  1: @c1b632a0  length 800005ea status 000005ea
  2: @c1b63340  length 80000047 status 00000047
  3: @c1b633e0  length 80000036 status 00000036
  4: @c1b63480  length 800005ea status 000005ea
  5: @c1b63520  length 800005ea status 000005ea
  6: @c1b635c0  length 80000036 status 00000036
  7: @c1b63660  length 800005ea status 800005ea
  8: @c1b63700  length 8000017a status 8000017a
  9: @c1b637a0  length 80000036 status 00000036
  10: @c1b63840  length 800005ea status 000005ea
  11: @c1b638e0  length 800005ea status 000005ea
  12: @c1b63980  length 80000036 status 00000036
  13: @c1b63a20  length 800005ea status 000005ea
  14: @c1b63ac0  length 800005ea status 000005ea
  15: @c1b63b60  length 80000036 status 00000036
eth0: Resetting the Tx ring pointer.

EIn wenig google'n hat auch einiges an Treffern gebracht, allerdings weiß ich nicht so recht, woran es wirklich liegt.

Hat einer von euch irgend eine Idee, woran es liegen könnte ?


MfG
Merc

ps: als OS läuft immer noch Debian mit 2.6.18.5er Kernel, weiterhin gibts noch zwei andere NIC's im System (ebenfalls 3com)

[knecht]

was sagt den ifconfig eth0, Steht da was bei errors oder dropped ?
Vielleicht ist einfach die Karte kaputt.

mach einfach mal ein

Code: Alles auswählen

watch ifconfig eth0

und schau ob die Pakete verworfen werden oder was eben passiert

[Merc]

Hallo.

Hier der Auszug aus "ifconfig eth0":

Code: Alles auswählen

eth0      Link encap:Ethernet  HWaddr 00:60:97:31:5A:7D
          inet addr:xxx.xxx.xxx.xxx  Bcast: xxx.xxx.xxx.xxx  Mask:255.255.254.0
          inet6 addr: :xxx:xxxx:xxxx:xxxxxx/xx Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9285709 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7941152 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2334123453 (2.1 GiB)  TX bytes:2642657394 (2.4 GiB)
          Interrupt:12 Base address:0xdc00

Die Kiste ist jetzt knapp 4 Tage am Laufen, in der Zeit ist der angegebene Fehler einmal aufgetaucht, was wohl auch die "1" bei den TX-Errors erklärt (oder auch nicht).

Besteht die Möglichkeit, der derartige Fehler durch "extensives" NATing auftreten können oder ist diese Erklärung eher abwegig ?


MfG
Merc

[gms]

Könnte ein Duplex-Konflikt ( Autonegotiation Problem ) sein. Überprüfe einmal ob die Duplex Einstellung der Karte gleich ist, wie die vom Partner ( mii-diag )

Gruß
gms

[knecht]

Soweit ich das beurteilen kann hat NAT damit nix zu tun. Aber um sicher zu sein müßte man die Adressdaten der einzelnen Pakete mit einem Paketsniffer mal ansehen (ethereal)

Da er keine Pakete verwirft, sehr wohl aber welche Empfängt und Sendet scheint die Karte in Ordnung zu sein. Wenn die Verbindung zusammenbricht, was sagt da mii-tool über die physikalische Verbindung ?

Ist aber schon ein komisches Problem

[Merc]

@gms:

Ein "mii-diag eth0" zeigt folgendes:

Code: Alles auswählen

mii-diag eth0
Basic registers of MII PHY #24:  3100 782d 2000 5c00 01e1 0461 0001 0000.
 Basic mode control register 0x3100: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
 Your link partner is generating 10baseT link beat  (no autonegotiation).
   End of basic transceiver information.

"mii-tool eth0" bringt

Code: Alles auswählen

eth0: no autonegotiation, 10baseT-FD, link ok

@knecht

Sollte das Problem wieder auftauchen und ich sitze grad am Rechner, werde ich mit "mii-tool" mal nachsehen.

So gesehen ist das Problem nicht gravierend, laut den verschiedenen bei Google gefundenen Problemberichten zu speziell diesem Thema heißt es, das die NIC (oder das, was alles alles damit zu un hat) sich selbst resettet und damit alles wieder normal laufen sollte.
Allerdings ist mein ISP da etwas strenger, ein falsches Paket (was dann wohl meist auch noch ne falsche MAC mit rausgibt) und mein Port ist erstmal bis zur nächsten vollen Stunde zu.


MfG
Merc

[knecht]

Ich kann mir irgendwie nicht vorstellen warum die Netzwerkkarte sich resetten sollte . . . wenn das vorkommt ist doch schon irgendwas schiefgelaufen. Ich kann mir auch nicht vorstellen das deine NIC mal schnell ne andere source MAC Adresse anstatt ihrer eigenen in die Pakete schreibt.

Aber das erklärt deine Fehlermeldungen in dmesg

Code: Alles auswählen

The driver thinks that the Tx ring is full, yet it has six spare slots. 
It remains in limbo until a Tx timeout.   I fixed this IRQ race in
3c59x.c in 2.2 and 2.4, but I confess it never occurred to me to send
some patches to David Hinds, who maintains the PCMCIA clients, of which
this driver is one.

I will do that thing, especially as it now appears that David's package
will be the recommended way of getting PCMCIA support in 2.4.

In the meanwhile, you could try recompiling the driver with
tx_interrupt_mitigation set to zero (if it's not).  This doesn't fix the
problem, but it lessens its probability.

(http://lkml.org/lkml/2000/7/19/81)
Laut dem Thread macht der Treiber hierbei Fehler, auch wenn die von 2.2 und 2.4er Versionen sprechen scheint es das gleiche Problem wie deines zu sein.

Einfach mal ne andere Kernel Version probieren ??

[Merc]

knecht:

Ich kann mir irgendwie nicht vorstellen warum die Netzwerkkarte sich resetten sollte . . . wenn das vorkommt ist doch schon irgendwas schiefgelaufen. Ich kann mir auch nicht vorstellen das deine NIC mal schnell ne andere source MAC Adresse anstatt ihrer eigenen in die Pakete schreibt.

Wenn man eine z.B. eine 3com 3c905b-combo mit Boot-ROM hat, das einem erlaubt, andere MAC's außer die herstellergegebene einzutragen, kann es vorkommen, das fälschlicherweise die Orginal-MAC "auftaucht".
Aber das ist mir bisher nur einmal passiert (was auch der Grund war, warum ich die Combo-Karte gegen die 3c905 getauscht habe).
BTW: Bei meinem Problem mit dem NAT von letztens sind ja auch Pakete mit falscher MAC durchgegangen.

Bezüglich http://lkml.org/lkml/2000/7/19/81 : Das war das, was ich auch gelesen hatte, ich habe mich lediglich mit dem Wort "resetten" bzw. der ganzen Umschreibung ziemlich schlecht ausgedrückt.

Der Versuch, einen anderen Kernel zu benutzen, bliebe mir noch.
Ich frag' mich bloß, ob man das Problem mit der NIC im 2.6er Kernel nicht mittlerweile behoben hat und wenn ja, es bedeuten würde, das die Karte eventuell einen, wie es ja schon angesprochen wurde, Defekt aufweist.

MfG
Merc

[swuing]

oder war es der rechner auf der gegenseite der die bandbreite runtergedrosselt hat? (bzw. dein router)

[Merc]

swuing:

oder war es der rechner auf der gegenseite der die bandbreite runtergedrosselt hat? (bzw. dein router)

Nein, glaub ich nicht. Nachdem die volle Stunde rum war und mein Port wieder auf war, ging's ja weiter wie vorher.
Ich denke das ganze hängt an diesem "Tx ring is full"-Problem.

Zusätzlich zum im ersten Posting erwähnten dmsg-Auszug tritt jetzt noch folgendes auf:

Code: Alles auswählen

pci_set_power_state(): 0000:00:0d.0: state=3, current state=5
pci_set_power_state(): 0000:00:0d.0: state=3, current state=5
pci_set_power_state(): 0000:00:0d.0: state=3, current state=5
pci_set_power_state(): 0000:00:0d.0: state=3, current state=5

Hier noch der passende Auszug aus "lspci":

Code: Alles auswählen

0000:00:0d.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

Das wäre die Netzwerkkarte, welche Probleme macht.

Ein wenig aus Google:

pci_set_power_state(): 0000:01:09.0:
> state=3, current state=5
> [5002828.321000] pci_set_power_state(): 0000:01:09.0:
> state=3, current state=5
>
> >From lspci:
>
> 01:09.0 Ethernet controller: 3Com Corporation 3c590
> 10BaseT [Vortex]
> Flags: bus master, medium devsel, latency 248,
> IRQ 5
> I/O ports at ec60
> Expansion ROM at 30060000 [disabled]
>
> I first started seeing these after upgrading my debian
> box, not the kernel. Anyone else see these before?

Watch for some userspace code playing with /sys/.../power/state.

Ahja...


MfG
Merc