[tulip] DLINK DFE-570TX forcing 100TX-FD under linux 2.4.x

Ingar Řyahals ingar@kvalito.no
Wed Mar 27 03:11:02 2002


Hi,

> Yes, see
>    http://www.scyld.com/network/tulip.html
> for the options.
> 
> Note that forcing the speed and duplex will (must) disable
> autonegotiation.  Autonegotiation takes place on the 10baseT link beat
> signal, so forcing 100baseTx makes it impossible for 
> autonegotiation to
> take place.
> 
I am aware of that, this is excactly what I want. (Yes, I know what I'm doing).

> Forcing full duplex is a bad idea.  But if you must, use 
> options to the
> driver so that the card isn't permanently set to a non-standard mode.
> 
I loaded the driver with 'options=14' according to the description and it worked perfectly.
As I searched the list I found that some people got carrier problems with tx-packets loading the driver with 'options=0x3 duplex=1'.
So did I, but this problem disappeared with 'options=14'.

> Hmmm, the link partner is correctly autonegotiating.  Usually 
> when I see
> "Cisco", the immediate response is "don't set forced full duplex, use
> autonegotation or half duplex".
> With autonegotiation enabled, if you force this end to full 
> duplex, you
> will screw up the link.  What specific problem are you experiencing?
> 
Sure, the initial negotiation works fine. The problem occurs when the traffic lohigh.ad gets extremely  I frequently got transmit time out on all interfaces in such periods, and for some reason link speed changed.
(The box is acting as a border router to the internet running zebra/bgp routing system with 3x100 mbit full duplex links).
I ran 3com earlier, but wanted to test the hardware throttling and bridge code with tulip to gain performance.
For the record, seems to me that enabling 'forwarding between high speed interfaces' while compiling kernel is a bad idea if the box is acting a a router. :-)

Thanks for your time and help!
--
Sincerely,
Ingar Oyahals
Kvalito IT AS
ingar@kvalito.no