On Wed, 19 Jul 2000, Pekka Savola wrote:
> Cc: linux-net@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
This should be on the Tulip mailing list. Please follow-up there.
> Subject: Re: D-Link DFE-570TX: driver issues w/ tulip and de4x5
>
> > > Both de4x5 (either from 2.2.16-3 or the one from 2.2.17pre12) and tulip
> > > fail to work properly in forced full duplex, 100Mb environment.
> > ...
> > > With tulip, you get no warnings but it just won't work. I tried both
> > > options=5,5,5,5 and options=14,14,14,14 arguments.
> >
> > Hmmm, read the boot message. '5' only works only when using the SYM
> > transceiver, not a MII transceiver.
>
> It doesn't work with your 0.92 driver and options=14,14,14,14 out of the
> box. With fiddling w/ mii-diag, it begins to work, but TCP performance
> (measured with ttcp) is poor.
Ahhh, that's the answer.
> The switch is configured to Autonegotiation disable, 100Mb FDX.
Note: This will all "just work" with autonegotiation enabled.
I strongly recommend that autonegotiation always be enabled. If the switch
is doesn't have autonegotiation, or it's broken (Cisco), forgo full duplex
to avoid many future configuration problems.
> However, mii-diag appears to show that the NIC is still autonegotiating:
> ----
> Basic registers of MII PHY #1: 3100 7849 2000 5c10 0100 0081 0016 2001.
> Basic mode control register 0x3100: Auto-negotiation enabled.
> Basic mode status register 0x7849 ... 7849.
> Link status: not established.
> Your link partner is generating 100baseTx link beat (no autonegotiation).
Leaving autonegotiation set was intentional, but flawed. It was an effort to
get the transceiver to attempt autonegotiation -- and inform the link
partner of the full duplex setting, before switching to forced-100Mbps.
If you force just force 100Mbps, the link is broken for long enough to clear
the autonegotiation state.
> After 'mii-diag -F 100baseTx-FD eth1' it appears to work:
...
> But shouldn't the driver do this job for you?
The correction is around line 863.
Note that it fixes two problems. The code must *clear* the bits first!
/* Enable autonegotiation: some boards default to off. */
mdio_write(dev, phy, 0, mii_reg0 |
(tp->full_duplex ? 0x1100 : 0x1000) |
(media_cap[tp->default_port]&MediaIs100 ? 0x2000:0));
___
/* Configure the xcvr: some boards default to autonegotiation off. */
mdio_write(dev, phy, 0, (mii_reg0 & ~0x3100) |
(tp->full_duplex ? 0x0100 : 0x0000) |
((media_cap[tp->default_port] & MediaIs100)
? 0x2000 : 0x1000));
> I also noticed that P166 can't really handle 100mbit (w/ ttcp). When
> the card was on the receiving side, it could only handle 55 Mbit/s until
> CPU hit 100%. As a sender, it could go as far as 71Mbit/s. UDP wasn't so
> CPU-intensive (94Mbit/s with CPU to spare).
You should check your configuration.
A P100 should be able to drive 2-3 100Mbps channels with 'ttcp'.
(Although that was last tested with 2.0.*.)
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
Annapolis MD 21403
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST