From owner-freebsd-hackers  Thu Nov 23 14: 0:38 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id 5332E37B4C5; Thu, 23 Nov 2000 14:00:36 -0800 (PST)
Subject: Re: Ethernet de driver problem on 3.5 stable
In-Reply-To: <200011231920.OAA70638@manor.msen.com> from "Michael R. Wayne" at "Nov 23, 2000 02:20:52 pm"
To: wayne@staff.msen.com (Michael R. Wayne)
Date: Thu, 23 Nov 2000 14:00:36 -0800 (PST)
Cc: freebsd-hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20001123220036.5332E37B4C5@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 
> I have run into an issue with the de driver and Dlink quad cards under
> 3.5 stable.
> 
> Despite the messages from the driver, claiming to be in full duplex,
[...]
> Is there a known problem with the Dlinks or is this a possible
> issue in the driver?
[...]
> Probing for devices on PCI bus 2:
> de0: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 11 on pci2.4.0
[...]

It's a driver bug, although it's partly Intel's fault for screwing up
the 21143 design. To enable full duplex mode, you're supposed to set
the full duplex bit in in CSR6. In the 21140A, that's all this bit does;
it's not affected by anything else. But in the 21143 design, this bit
performs two functions, depending on the setting of the autoneg enable
bit in CSR14. If the autoneg enable bit is off, then the full duplex
bit works as expected. But if the autoneg enable bit is turned on,
the full duplex bit controls whether or not the 21143 will advertise
10Mbps/full-duplex during an NWAY exchange.

Unfortunately, after a software reset, the autoneg enable bit in CSR14
is turned on by default, and the de driver never bothers to clear it.

The stupid thing is that there are plenty of unused bits in other
registers that Intel could have used rather than overloading the full
duplex bit in CSR6 to perform two functions.

Anyway. The dc driver in FreeBSD 4.0 and later should get this right.
If you want to try and fix it in the de driver, you need to add a line
somewhere that says:

	TULIP_CSR_WRITE(sc, csr_14, 0);

It should probably at the end of tulip_init(), or possibly near the
end of tulip_reset(), the point being to do it immediately after
invoking a software reset in order to clear the autoneg enable flag.

Either that, or upgrade to FreeBSD 4.2.

-Bill


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message