Bug 30052
| Summary: | [dc] [patch] dc driver queues outgoing pkts indefinitely if no link | ||
|---|---|---|---|
| Product: | Base System | Reporter: | archie.cobbs <archie.cobbs> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | gonzo |
| Priority: | Normal | ||
| Version: | 4.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Archie Cobbs writes: > >Number: 30052 > >Category: kern > >Synopsis: dc(4) driver queues outgoing pkts indefinitely if no link .... > Seems like there should be some maximum age for these queued up > packets, after which time they would expire instead of being sent > out on the wire, on the order of half a second or so perhaps. Or may be 25.5 sec? - max TTL is 255 -- @BABOLO http://links.ru/ Below is a patch which fixes this problem in a brute force way. (note: patch is cut&pasted) -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- pci/if_dc.c.orig Thu Aug 23 16:05:36 2001 +++ pci/if_dc.c Thu Aug 23 16:06:03 2001 @@ -2797,8 +2797,10 @@ sc = ifp->if_softc; +#if 0 if (!sc->dc_link && ifp->if_snd.ifq_len < 10) return; +#endif if (ifp->if_flags & IFF_OACTIVE) return; Responsible Changed From-To: freebsd-bugs->mbr I'll look at this. Responsible Changed From-To: mbr->archie Hi, this is a ooooooold PR of yours, and I'm sorry I had never the right hardware to test it. If you like you can close it. Responsible Changed From-To: archie->freebsd-bugs@FreeBSD.org I'm no longer actively working on the FreeBSD kernel, and no longer have this hardware to test anyway either. It's fine with me to close out this bug but I figured I'd let someone else make that decision. Responsible Changed From-To: freebsd-bugs@FreeBSD.org->freebsd-bugs Canonicalize assignment. For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped The code in question has been changed and patch no longer applies. Closing as OBE. Feel free to reopen if issues is reproducible on recent FreeBSD versions. |
We've noticed an odd problem with the dc driver. It seems to hold outgoing packets in the send queue indefinitely if the link state is down. By "indefinitely" we've measured 15 seconds of latency between the time the driver received the the packet and the time it was transmitted (as visible in both tcpdump and on the wire), immediately after plugging in a 10baseT cable and getting a link up light. We didn't bother to measure any longer because 15 seconds is already an eternity. I noticed this comment in the code: /* * When the init routine completes, we expect to be able to send * packets right away, and in fact the network code will send a * gratuitous ARP the moment the init routine marks the interface * as running. However, even though the MAC may have been initialized, * there may be a delay of a few seconds before the PHY completes * autonegotiation and the link is brought up. Any transmissions * made during that delay will be lost. Dealing with this is tricky: * we can't just pause in the init routine while waiting for the * PHY to come ready since that would bring the whole system to * a screeching halt for several seconds. * * What we do here is prevent the TX start routine from sending * any packets until a link has been established. After the * interface has been initialized, the tick routine will poll * the state of the PHY until the IFM_ACTIVE flag is set. Until * that time, packets will stay in the send queue, and once the * link comes up, they will be flushed out to the wire. */ Seems like there should be some maximum age for these queued up packets, after which time they would expire instead of being sent out on the wire, on the order of half a second or so perhaps. This is with a four port DLINK card. Fix: Enforce a maximum age on outgoing packets. How-To-Repeat: - ifconfig dc0 normally and verify you can ping, etc. - start tcpdump on dc0 - unplug network cable from 10baseT port - cause a few packets to be transmitted (arp, ping, etc) - wait 15 seconds or more - plug cable back in - watch packets be transmitted out the interface