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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
