even newer info WAS: Re: new info WAS: Re: [tulip] LNE100TXversion
4.1 timeouts on tx
Erik Steffl
steffl@bigfoot.com
Wed, 06 Dec 2000 02:33:41 -0800
Donald Becker wrote:
>
> Summary: new tulip.c test version "0.92p" at
> ftp://www.scyld.com/pub/network/test/tulip.c
> that fixes a full duplex setting bug.
>
> This bug only occurs the second and subsequent time the interface is
> started, thus it wasn't caught by the usual "load module, test, unload
> module" script.
>
> On Fri, 1 Dec 2000, Erik Steffl wrote:
>
> > Subject: even newer info WAS: Re: new info WAS: Re: [tulip] LNE100TX version
> 4.1 timeouts on tx
> ...
> > I have two computers connected with crossover cable:
>
> Presumably in full duplex mode.
>
> > linux, kernel 2.2.17,
> > LNE100TX with driver tulip.c:v0.92 4/17/2000 with patch from Dan
> > Hollis,
> > the patch resets the card when tx-freeze occurs (why there
> > are these tx hung-ups in the first place?)
>
> Which patch, exactly? (I *beliThis shouldn't be needed
>
> > system two:
> > Intel PRO/100 (driver name: e100bnt5.sys)
> >
> > more info on linux side (note that it says half duplex, even though I
> > used path from Dan Hollis,the other computer thinks its full 100MB
> > duplex connection):
>
> ...and that's the problem!
>
> > TX packets:131985 errors:2152 dropped:0 overruns:0
> > carrier:2152
> > collisions:7425 txqueuelen:100
>
> Please try the latest test driver, and send a report.
>
> Note that this test driver *only* addresses the full duplex problem. It
> should have no other operational change.
I have sent one report already but since I've got no response and I
have tried another test here goes another report (in case the old one
got lost in bit bucket or new info might be useful):
I have tried the test driver, situation has not changed, I get exactly
the same behaviour.
when I forced the other side to 100
bs, half duplex mode nothing changed as well, even though now both of
them should be in same mode (100Mbs, half duplex).
the symptoms are the same - any huge transfer from LNE100TX machine to
the other one fails, transfers that go the other way work fine, no
problems at all.
over time I have got quite a few frame errors on rx:
eth0 Link encap:Ethernet HWaddr 00:20:78:12:14:CC
inet addr:192.168.1.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17650577 errors:18122 dropped:0 overruns:0
frame:18133
TX packets:10793694 errors:7225 dropped:0 overruns:0
carrier:7225
collisions:1503498 txqueuelen:100
Interrupt:9 Base address:0x5000
not sure what it means, I haven't noticed any failures on application
level (unlike tx errors).
TIA
erik