Bug 17829
| Summary: | The dc driver is seriously broken | ||
|---|---|---|---|
| Product: | Base System | Reporter: | matt <matt> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
On Thu, 06 Apr 2000 08:24:11 MST, matt@thebiz.net wrote: > >Number: 17829 > >Category: kern > >Synopsis: The dc driver is seriously broken Hi Bill, What do you think about the originator's suggestion to disable dc(4) in GENERIC? Ciao, Sheldon. State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE? I don't know about #2, but #1 and #3 are no longer true on 4.4. Perhaps the originator would care to confirm though ? Ceri kern/32118 is similar to this. On a 21143 with 4.4-RELEASE autonegotiation does not work correctly with 10baseT/UTP media (it now does work for 100baseTX). And the lights don't work either. State Changed From-To: feedback->closed Feedback timeout. |
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) 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. 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)