Date: Thu, 23 Aug 2001 16:01:10 -0700 (PDT) From: Archie Cobbs <archie@packetdesign.com> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/30052: dc(4) driver queues outgoing pkts indefinitely if no link Message-ID: <200108232301.f7NN19b79162@bubba.packetdesign.com>
next in thread | raw e-mail | index | archive | help
>Number: 30052
>Category: kern
>Synopsis: dc(4) driver queues outgoing pkts indefinitely if no link
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Aug 24 12:20:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Archie Cobbs
>Release: FreeBSD 4.3-RELEASE i386
>Organization:
Packet Design
>Environment:
System: FreeBSD bubba.packetdesign.com 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Thu Apr 26 15:28:39 PDT 2001 root@bubba.packetdesign.com:/usr/obj/usr/src/sys/BUBBA i386
>Description:
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.
>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
>Fix:
Enforce a maximum age on outgoing packets.
>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?200108232301.f7NN19b79162>