[linux] Netwerkkaart problemen, en watchdog?

[ACM]

Allereerst excuses voor de lange lap, maar ik vermoed dat zonder uitleg, het niet echt veel zin heeft dit te posten

Ik had gisteren, met mijn remote server ( ) problemen met de netwerkkaart.
Nu de server na een reboot (network restart werkte niet) weer online is, ben ik uiteraard gelijk de /var/log/messages ingedoken.

Daar stond deze message:

code:

Jun 18 00:35:28 vulcanus kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 18 00:35:28 vulcanus kernel: eth0: transmit timed out, tx_status 00 status e601.
Jun 18 00:35:28 vulcanus kernel:   diagnostics: net 0cfa media 8880 dma 0000003a.
Jun 18 00:35:28 vulcanus kernel: eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Jun 18 00:35:28 vulcanus kernel:   Flags; bus-master 1, dirty 768(0) current 768(0)
Jun 18 00:35:28 vulcanus kernel:   Transmit list 00000000 vs. dff9b200.
Jun 18 00:35:28 vulcanus kernel:   0: @dff9b200  length 8000002a status 0001002a
Jun 18 00:35:28 vulcanus kernel:   1: @dff9b240  length 8000004a status 0001004a
Jun 18 00:35:28 vulcanus kernel:   2: @dff9b280  length 80000036 status 00010036
Jun 18 00:35:28 vulcanus kernel:   3: @dff9b2c0  length 80000036 status 00010036
Jun 18 00:35:28 vulcanus kernel:   4: @dff9b300  length 80000036 status 00010036
Jun 18 00:35:28 vulcanus kernel:   5: @dff9b340  length 8000045d status 0001045d
Jun 18 00:35:28 vulcanus kernel:   6: @dff9b380  length 8000045d status 0001045d
Jun 18 00:35:28 vulcanus kernel:   7: @dff9b3c0  length 80000030 status 00010030
Jun 18 00:35:28 vulcanus kernel:   8: @dff9b400  length 80000030 status 00010030
Jun 18 00:35:28 vulcanus kernel:   9: @dff9b440  length 80000087 status 00010087
Jun 18 00:35:28 vulcanus kernel:   10: @dff9b480  length 8000008a status 0001008a
Jun 18 00:35:28 vulcanus kernel:   11: @dff9b4c0  length 8000004a status 0001004a
Jun 18 00:35:28 vulcanus kernel:   12: @dff9b500  length 8000003a status 0001003a
Jun 18 00:35:28 vulcanus kernel:   13: @dff9b540  length 8000003a status 0001003a
Jun 18 00:35:28 vulcanus kernel:   14: @dff9b580  length 8000003a status 8001003a
Jun 18 00:35:28 vulcanus kernel:   15: @dff9b5c0  length 8000003a status 8001003a

Herhaaldelijk in.
(stuk of 7.000 keer ofzo)

Wat ik eruit haal, is dat de netwerkkaart een irc-conflict weet te krijgen (terwijl het systeem al 37 dagen draaide ) en dat daardoor de kernel niet echt meer data kan sturen (heeeeeel sloom was het, met pings van 30-60seconden op systemen in het zelfde lan)

Dit is al een keer eerder voorgekomen (ander systeem, zelfde fysieke plek)
En ik zie nu die "watchdog" regel erbij staan.
Heeft iemand ervaring hiermee, oid met instellen dat ie danwel een restart van de kaart probeert, danwel gewoon een reboot uitvoert, als de watchdog weer van dit soort problemen ziet?

- Relevante hardware:
p3's + serverworks mobo
onboard intel (Ethernet Pro 100) nic (gebruikt voor intern netwerk -> eth1)
extra 3com (3c905C-TX) nic (gebruikt voor extern netwerk, de probleem kaart dus, eth0)

- Software:
RedHat 7.1 custom install
(met zelf gecompileerde, apache, proftpd etc)
En een eigen 2.4.4 kernel.
(geen watchdog ingebouwd, trouwens, dus moet bij de default redhat install, of standaard in de kernel horen)

- Vragen dus:
* Weet iemand waardoor deze meldingen (de geheugendump-achtige dingen bedoel ik niet ) komen?
De kaart draaide tenslote 37 dagen zonder problemen.
* Weet iemand hoe het is op te lossen, of waar er eventueel een oplossing is te vinden?
* Weet iemand hoe ik die watchdog zou kunnen configureren, zodat ie het systeem restart (of iig de netwerkkaart re-init oid) als het weer voorkomt?

[edit vergeten interupts te posten :)]

code:

[acm@vulcanus /proc]$ cat interrupts
         CPU0    CPU1
  0:    1375213    1371665    IO-APIC-edge  timer
  1:        1       1    IO-APIC-edge  keyboard
  2:        0       0       XT-PIC  cascade
  8:        1       0    IO-APIC-edge  rtc
 14:    34218   37054    IO-APIC-edge  ide0
 16:    2794939    2808989   IO-APIC-level  eth0
 23:    42990   43049   IO-APIC-level  eth1
 28:       14      16   IO-APIC-level  sym53c8xx
 29:    12023   12479   IO-APIC-level  sym53c8xx
NMI:        0       0
LOC:    2746581    2746635
ERR:        0

Dat is dus na de reboot, maar er zijn dus ruim voldoende irq's beschikbaar...

[Mior]

Het enigste wat ik zou kunnen bedenken (vooral omdat het spontaan gebeurt) is dat je netwerk kaart kapot is/aan het gaan is.

Verder weet ik niets van WatchDog.

[ACM]

Op maandag 18 juni 2001 08:30 schreef Phantom_ het volgende:
Het enigste wat ik zou kunnen bedenken (vooral omdat het spontaan gebeurt) is dat je netwerk kaart kapot is/aan het gaan is.

Lijkt me sterk, aangezien ie zo-goed-als-nieuw is (2 maand oud nu, oid)
En die kaart in dat andere systeem heeft het probleem sindsdien ook nooit weer gehad...

[Mior]

Al eens geprobeert om de kaart in een andere (goed werkende) bak te stoppen?

Het zou een productie fout oid kunnen zijn.

[Sjonny]

Ik zou het eerder op een SMP bug gooien ...
en ik denk niet dat het al in de kernel gefixed is... al in de kernel mailing lists gezocht?

[ACM]

Op maandag 18 juni 2001 11:33 schreef Sjonny het volgende:
Ik zou het eerder op een SMP bug gooien ...
en ik denk niet dat het al in de kernel gefixed is... al in de kernel mailing lists gezocht?

Dat zou idd kunnen
Netwerkkaart is technisch idd waarschijnlijk goed, en dat andere systeem is ook een smp-bak

Helaas heb ik nog niet kunnen zoeken (werken enzo )
Maar dat ga ik nu idd wel doen.

[ACM]

Lijkt erop dat het een APIC+3com bug is...
(en voor goede performance op je systeem heb je APIC nodig, bij smp)

't Schijnt in de ac-serie zowiezo gefixed te zijn, maar in de 2.4.5pre2 zat het nog (en kweet dus niet of het in 2.4.5 ook nog zit)

Toch maar es een ac-branche installeren dan.

[Sjonny]

Sja die Alan breng ook zowat 2 patches per dag uit eh?
veel plezier ermee!

[ACM]

Op maandag 18 juni 2001 15:00 schreef Sjonny het volgende:
Sja die Alan breng ook zowat 2 patches per dag uit eh?
veel plezier ermee!

De 2.4.5-ac15 werkt nu
Enige gekke, hij ging gelijk na bootup naar 70MB swap gebruik
(512MB ram, 270MB vrij...)
En daar schommelt ie nu nog steeds... :

code:

[acm@vulcanus acm]$ uptime
  3:26pm  up 24 min,  3 users,  load average: 0.30, 0.25, 0.14
[acm@vulcanus acm]$ free
         total   used    free     shared    buffers     cached
Mem:      512968     257956     255012     64   21348     182876
-/+ buffers/cache:  53732     459236
Swap:    524264 72020     452244

Toch maar de rest van de ac-branche in de gaten houden op eventuele swap-race-bugs ofzo (uptime is nu toch weg)