Date: Thu, 6 Apr 2000 08:24:11 -0700 (PDT) From: matt@thebiz.net To: freebsd-gnats-submit@FreeBSD.org Subject: kern/17829: The dc driver is seriously broken Message-ID: <200004061524.IAA48633@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 17829
>Category: kern
>Synopsis: The dc driver is seriously broken
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Apr 6 08:30:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Matthew Zahorik
>Release: 4.0-RELEASE
>Organization:
BiznessOnline.com
>Environment:
[web1]:11:06am:~% uname -a
FreeBSD web1.thebiz.net 4.0-RELEASE FreeBSD 4.0-RELEASE #8: Tue Apr 4 13:36:42 EDT 2000 root@web1.thebiz.net:/usr/src/sys/compile/DISKLESS-DS10 alpha
>Description:
The dc driver is broken in many different ways:
1. It doesn't autonegotate properly. On a Cisco 2948 switch, set to
defaults, it will autoneg 10BaseT/half duplex. All other machines
(and the de driver) autoneg 100BaseTX/half or full duplex. If the
switch is hard coded to 100Mb/full or half, the card will never
negotiate.
2. When hard-coding the interface to a specific speed/duplex, packets
flow too early. You run the risk that BOOTP clients time out,
or DHCP requests go unanswered.
3. Link lights don't work, so you have no way of visually telling
that the card has link. (which is important if you have stacks
of headless machines)
The Alpha platform has a hack to address #1. It looks in the BIOS settings (SRM) and if the code is hard-coded to a specific speed/duplex, the driver will force the card to that speed/duplex.
#2 makes it real difficult to bootp reliably, since the kernel misses it's first ARP and BOOTPc packets go unanswered.
#3 is awful annoying.
Once the card is hard-coded 100/full, and the machine actually boots diskless (assuming it doesn't timeout), it runs perfectly clean in full duplex mode. (minus the link lights)
>How-To-Repeat:
Just use a 2114x type card in a machine, let it go to full auto, watch the results. Also, try building a diskless client and make sure the driver initialization routine comes back only after the card is really ready. If this is correct, the diskless client should boot without timeouts. Also, do this all through a switch where the card has to
do full autonegotiation with a smarter partner (rather than a hub)
>Fix:
Recompile the kernel to use de rather than dc. de has a known problem where it can't do full-duplex, but at least it autonegotiates 100Mb/half.
I'd also suggest GENERIC kernels don't go out with dc enabled - it can really fubar an installation if things don't autonegotiate properly.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004061524.IAA48633>