[Linux] Oplossing voor Transmit timeout?

[Super Snackman]

Heya all,

ik heb al meerde linux machines geinstalleerd, of gewoon mee gewerkt de laatste tijd. Ze hadden verschillende netwerkkaarten. Uiteenlopend van Realtek8139 tot Intel Ethernet Express Pro. De Distro was verschillend, en de Kernels zijn verschillend.
Echter hebben al deze Linux machines 1 ding gemeen:
Op het moment dat er veel data op de netwerkkaart binnenkomt gaat hij keihard onderuit. Eigenlijk altijd met een foutmelding als deze:
kernel: eth1: Transmit timeout, status 0d 0000 media 08

Nu heb ik wat op internet gestruind, en nu blijk ik niet de enige te zijn. (Integendeel). Ook op de wat duurdere 3com kaarten zie ik mensen met dit probleem.

Ik heb nu thuis een Linux_router staan, met de 2.4.21 (laatste stabiele) kernel, naar wens geconfigureerd. De gebruikte NIC is een el-cheapo RTL8139 (maar dat zou toch geen problemen mogen veroorzaken). En de nieuwe netwerk-drivers van scyld. Toch krijg ik nog steeds dit probleem op het moment dat er erg veel data via de nic binnenkomt.

Kennen jullie dit probleem ook? Hebben jullie dingen die jullie aan kunnen raden? Ik heb bijvoorbeeld al alle overbodige onzin uitgezet (Paralel, Serieel, USB, Audio). Is er een Netwerkkaart die wel ECHT lekker draait onder linux. Ook als er met 100mbit data binnenkomt...

[ Voor 4% gewijzigd door Super Snackman op 13-07-2003 23:50 ]

[stunn0r]

die netwerk kaarten die jij gebruikt werken bij mij prima onder linux ik heb hier een switched netwerkje liggen met 5 computers erin en zelfs als ik met alle 4 de clients mn fileserver flink stress krijg ik geen timeout errors, je zou wel is wat meer info kunnen geven over je netwerk.. gebruik je een hub of een switch of een cross cable? heb je je kaarten op full duplex staan en ga zo maar door

ik kan me trouwens goed voorstellen dat die timeouts worden veroorzaakt door packet collisions.. zeker als het alleen gebeurd als je netwerk druk is

[ Voor 17% gewijzigd door stunn0r op 14-07-2003 00:03 ]

[Super Snackman]

Cyrix-300
64mb geheugen / 750 mb swap
Redhat Linux 7.3
Linux linux-masjien 2.4.21 #1 SMP Sat Jul 12 23:50:21 CEST 2003 i686 unknown
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) ETH0
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10) ETH1
Ik gebruik de rtl8139-module die ik van scyld heb gedownload.

Netwerk:
Deze linux-computer als router, daarachter een hub, daarachter 4 computers. Alles 10mbit.
Internet gedeeld via iptables / masquearade. ETH0 (RTL8029) is op het kabel modem aangesloten. ETH1 (RTL8139) op het interne netwerk.
Maximaal van internet downloaden (180k/sec) is geen enkel probleem.
Zodra er 2 computers in het netwerk data naar elkaar versturen is de kans groot dat de linux-server deze timeout geeft, en dat je via het down en up brengen van eth1 alles weer laat werken. Dat is het nadeel van een hub, die dus deze week vervangen wordt door een switch. De linux-bak zal nog veel sneller deze time-out geven als er veel data naar hemzelf wordt toegepompt. En dat is nog maar 10mbit. Ik ben benieuwd wat het gaat worden bij 100mbit.

Op mijn vorige router p75, 16mb, linux 2.2, zelfde NICS, had ik dit probleem zo goed als niet. Maar zoals ik al zei, ik heb ditzelfde probleem ook op anderer distro's en kernels meegemaakt.

[stunn0r]

heb je de de gewone driver uit de kernel al eens geprobeerd?

[Super Snackman]

Ik heb 8139too geprobeerd, en daar crashed linux helemaal mee. Scherm wordt ineens zwart, en alleen computer aan/uit zorgt dat linux weer gaat draaien.

[Verwijderd]

Ik denk dat het probleem aan de hub ligt. Als 2 clients data met elkaar gaan transmitten zullen ze snel de volle 10 Mbit gebruiken die beschikbaar is. Tot gevolg dat er in het netwerk flinke problemen ontstaan.
Tip: Koop vandaag nog een switch. 30 euro's voor een 5 ports

[ Voor 3% gewijzigd door Verwijderd op 14-07-2003 10:02 ]

[Super Snackman]

Zoals ik al zei heb ik al een switch gekocht. 30 euro, 8 poorts, 10/100mbit.
Alleen blijft het probleem dan bestaan als ik daadwerkelijk files up/download naar de linuxserver.

[Verwijderd]

Super Snackman schreef op 14 July 2003 @ 10:20:
Zoals ik al zei heb ik al een switch gekocht. 30 euro, 8 poorts, 10/100mbit.
Alleen blijft het probleem dan bestaan als ik daadwerkelijk files up/download naar de linuxserver.

Correctie: Je zou deze week een switch gaan kopen:

... Dat is het nadeel van een hub, die dus deze week vervangen wordt door een switch. ...

Misschien dat de server gewoon te traag is om al die data aan te kunnen?
Staat DMA wel aan? Anders gebruikt de server te veel processor kracht en kan de boel niet meer aan. (wat dus het geval is). 300 MHz is veel te weinig als je zonder DMA werkt. Ik had al problemen met mijn 1000 MHz.

//edit
Het gaat hier toch om het wegschrijven van toegezonden data naar de HDD en geen forwarding ofziets?

[ Voor 8% gewijzigd door Verwijderd op 14-07-2003 11:27 ]

[JeroenT]

Ik heb dit nog nooit meegemaakt op mijn Debian + kernel 2.4.20 installatie.
Wat ik wel merk is dat sinds ik over gestapt ben op BSD de hele netwerk performance van het ding vooruit is gegaan.

[Super Snackman]

DE linux-bak crashed al bij het pompen van data tussen 2 clients. (Immers bij een hub krijgt hij dat ook voor z'n kiezen). Dus DMA kan het niet zijn.

Maar zou een andere distro met dezelfde Kernel, en dezelfde drivers, niet ook hetzelfde probleem geven?

[smoking2000]

Ik denk dat het een hardware probleem is, je geeft al aan dat de normale 8192too driver je systeem laat crashen, dat heb ik nog nooit mee gemaakt, en ik wat 8192too nic in linux machines gezien. Heb je misschien last van IRQ probleempje, die ben ik al veel te vaak tegen gekomen.
suc6

[Super Snackman]

Hoe vraag ik in linux het IRQ-gebruik van de apparten op?
Om IRQ's vrij te maken heb ik al de serieele poort, usb poort, paralelle poort en onboard audio uitgezet.
Ik heb 2 verschillende rtl8139 netwerkkaarten gebruikt, maar beiden het zelfde probleem. Overigens heb ik exact dit probleem in een compleet andere machine/distro/kernel/netwerkkaart gehad.

IRQ-gebruik tijdens Linux:
IRQ 0 / timer
IRQ 10 / eth0
IRQ 12 / eth1
IRQ 14 / ide0

UIt /proc/interrupts:
CPU0
0: 5930868 XT-PIC timer
1: 687 XT-PIC keyboard
2: 0 XT-PIC cascade
10: 2114036 XT-PIC eth0
12: 1904066 XT-PIC eth1
14: 42709 XT-PIC ide0
15: 18 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0

[ Voor 45% gewijzigd door Super Snackman op 14-07-2003 11:51 ]

[stunn0r]

cat /proc/pci | less geeft je een vrolijk lijstje meende ik

[Super Snackman]

Naja zoals ej al ziet heb ik mijn IRQ's en dergelijke op kunnen vragen. Ik zal dit weekend als ik thuis ben eens even prutsen met een andere netwerkkaart.
Zijn er ook fabrikanten die ZELF linux-drivers voor hun nic uitbrengen, en die ook updaten. Net zoals die realtek is ook min-of-meer door een 'amateur' geschreven.

[stunn0r]

mjah maar met die drivers is niks mis hoor
ik zou dus zelf zoals smoking eerder al zei is bij de hardware gaan zoeken

[ Voor 48% gewijzigd door stunn0r op 15-07-2003 19:58 ]

[Super Snackman]

Ik heb de haperende NIC al vervangen door een andere. En onder win32 (sorry) geen enkel probleem. En dat zou dan ook betekenen dat al die tientallen mensen met hetzelfde probleem het allemaal aan de hardware ligt? En dat het ''toeval'' is dat ik het bij meerde nics/kernels etc. heb meegemaakt...

[ Voor 51% gewijzigd door Super Snackman op 16-07-2003 09:02 ]

[Verwijderd]

Super Snackman schreef op 14 July 2003 @ 11:32:
DE linux-bak crashed al bij het pompen van data tussen 2 clients. (Immers bij een hub krijgt hij dat ook voor z'n kiezen). Dus DMA kan het niet zijn.

Hardware op de kaart moet die data al afvangen!
Je NIC ziet zijn eigen MAC adres niet langskomen , en ook geen broadcast, dus de NIC mag in dat geval niets doen richting CPU.

Ik ga ervan uit dat je kaart niet in promiscious (=sniffer) mode staat.
oa tcpdump gebruikt dat

[Zwerver]

Dat denk ik wel ja, want ik heb mijn hele huisnetwerk opgebouwd met 8139too kaartjes en nooit problemen gehad, en wij gooien met tien personen toch echt behoorlijk veel data over die fileserver en vv. Nou draai ik wel 2.4.20 op die fileserver, en dan de gentoo variant daarvan. Wat ik me wel voor kan stellen is dat je die nic elke keer in het zelfde pci slot hebt gehad? Waardoor elke kaart hetzelfde probleem lijkt te geven.... Dat een kaart onder windows geen problemen oplevert, hoe heb je dat getest? Want ik weet geen manier om transmit timeouts te zien onder windows...

edit:
De linux bak crashed zeg jij? Of crashed alleen het dataverkeer (<-- oftewel je netwerkkaart)... als die bak namelijk _echt_ crashed dan heb je 99,9% kans dat het een hw probleem is. Linux bakken crashen namelijk niet zomaar

[ Voor 19% gewijzigd door Zwerver op 16-07-2003 09:15 . Reden: chrash test dummy! ]

[Super Snackman]

Omdat de machine onder windows niet crashed mischien bij zwaar netwerk verkeer, en onder linux wel. Een transmit timeout vind ik niet zo erg, maar dat dan Linux helemaal vastknalt, of alleen eth1 dat vind ik veel erger.
Ik heb inmiddels kernel 2.5.75 gecompiled. Zal die dit weekend eens proberen.


Bij het gebruik van rtl8139 crashed alleen de netwerkkaart. Bij het gebruik van 8139too de hele bak. Kernel 2.4.21
Onder kernel 2.4.18-3 die bij de distro zat ging zelf het beeldscherm uit. Zou dat PCI-slot dan gaar kunnen zijn ofzow?

[ Voor 29% gewijzigd door Super Snackman op 16-07-2003 09:17 ]

[Zwerver]

probeer het zou ik zeggen? Zelfde kaartje in ander slotje etc? Ik had overigens wel verwacht (en met mij nog anderen?!) dat je dit al getest had? Er staat iets over dit soort vragen in de FAQ btw, dus je kan verwachten dat het *nu het op een helpdeskdraad begint te lijken* op slot gaat! Ik had overigens

edit:
Je pakt nu wel een development kernel!!!! Hou er rekening mee dat nu een aantal andere dingen ook wel eens niet mee kan gaan werken!

[ Voor 20% gewijzigd door Zwerver op 16-07-2003 09:29 . Reden: kernel lul verhaal ]

[Super Snackman]

Ja ik weet het, is ook meer om te testen. Voorlopig staat kernel 2.4.21 te draaien. Hij crashed ook helemaal niet. Alleen bij zwaar netwerkverkeer. Ik had al wel andere NIC geprobeerd, maar aangezien alles onder windows knalgoed werkt verwachtte ik niet dat het PCI-slot stuk zou zijn. (Kan ik me nog steeds niet voorstellen, want als je google zoekt op dit probleem zou dat ridicuul zijn)

[Zwerver]

tjah, twordt hier al wel vaker gezegt: iets wat onder windows werkt hoeft niet onder linux te werken. Er zijn hier iig genoeg mensen die deze kaart wel aan het werk hebben met de standaard driver, en je kan die andere driver wel gaan gebruiken, maar de standaard driver zou het moeten doen!

[Super Snackman]

Maar helaas is mijn probleem niet opgelost met 'bij andere mensen wel' en 'zou moeten werken'.
In mijn andere linux-machine met de nieuwe 2.2-kernel had ik ook helemaal geen problemen. Ik ben er dus zelf vrijwel zeker van dat het OF aan de kernel OF aan de drivers ligt. En ik hoopte dat ik hier iemand zou treffen met hetzelfde probleem die een oplossing aan zou dragen.

[Zwerver]

dan is het toch duidelijk geen driver probleem in de zin van het woord? Dan ligt het toch eerder aan de combinatie van onderdelen van je systeem? Hier @ GoT zul je denk ik weinig mensen vinden die dat probleem hebben. Conclusie: ga een trouble shooten met een andere kaart, danwel ander pc slot. Desnoods een ander systeem. Treed het probleem dan niet op --> zelfde kaart anders systeem. Treed het dan nog niet op... etc etc. En je zegt dat je het probleem op google tegenkomt, welk systeem hebben die mensen? Misschien zelfde mobo etc?
Als het gros van de mensen geen problemen heeft en een klein deel wel, wat heeft dat kleine deel dan anders dan de rest?

[Super Snackman]

Het kan niet de NIC zijn. Zoals ik al aangaf draaide de NIC perfect in een andere linux-machine, en ook onder Windows. Ondanks dat heb ik de NIC vervangen en het zelfde probleem blijft.
En voor de 3e keer dit topic: ik heb het bij compleet verschillende machines/kernels/distro's/nics ook meegemaakt. En zelf in de GOT-search zijn een aantal mensen met dit probleem.

Het is dus niet een specifiek probleem van mijn moederbord of netwerkkaart, maar veel algemener.

Cyrix 300, Kernel 2.4.21, RTL8139 --> ETH0 Transmit Timeout
Intel Pentium II 400, Kernel 2.2.?, Intel EEPRO 100 --> ETH0 Transmit Timeout
Pentium I 75, Kernel 2.2.?, RTL8029 --> ETH0 Transmit Timeout

Ze staan in compleet andere omgevingen. Het probleem van de Intel Pentium II heb ik opgelost door ipv de EEPRO100-driver de EE (geloof ik)-driver te gebruiken. Het probleem van de P75 heb ik opgelost door de nieuwste kernel met de nieuwste drivers te gebruiken.
Alleen krijg ik het helaas op de Cyrix 300 niet voor elkaar.

[Zwerver]

heb je hem nou al in een ander pci slot gedaan?

[ Voor 47% gewijzigd door Zwerver op 16-07-2003 11:29 ]

[Super Snackman]

Ik heb vrijdagnacht weer fysieke toegang tot de linux-bak, dus dat zal ik een kaartendans doen.

[Super Snackman]

Helaas heeft dat niet geholpen. 2.5 kernel crashed de ganze computer. Als er gene oplossing is voor je probleem moet je er maar omheen werken. Elke 5 minuten de volgende cronjob:
ifconfig eth1 down
ifconfig eth1 up


Merk je werkelijk helemaal NIETS van. Downloads die bezig zijn lopen lekker door, en ook de putty client wordt niet disconnect

[deadinspace]

Super Snackman schreef op 20 July 2003 @ 22:24:
2.5 kernel crashed de ganze computer.

Wat heet crashen? Geen beeld toevallig?

Als er gene oplossing is voor je probleem moet je er maar omheen werken.

Ja, maar je wil eigenlijk een oplossing

[Super Snackman]

De 2.5 kernel zal ik wel verkeerd geconfigd hebben.
Decompressing kernel................. --> dan reset de computer zich vanzelf

[deadinspace]

Super Snackman schreef op 21 July 2003 @ 06:00:
De 2.5 kernel zal ik wel verkeerd geconfigd hebben.
Decompressing kernel................. --> dan reset de computer zich vanzelf

edit: ik kan niet lezen...

Ik zou zeggen: kijk eens wat rond in Kernel 2.5.x en pre 2.6.0 draadje.... , er waren meen ik wel meer mensen met zo'n probleem.

[ Voor 51% gewijzigd door deadinspace op 21-07-2003 10:01 ]