From archie@packetdesign.com  Fri Aug 24 12:15:23 2001
Return-Path: <archie@packetdesign.com>
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by hub.freebsd.org (Postfix) with ESMTP id 2045437B407
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 24 Aug 2001 12:15:23 -0700 (PDT)
	(envelope-from archie@packetdesign.com)
Received: from bubba.packetdesign.com (bubba.packetdesign.com [192.168.0.223])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f7NN1A254251
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 23 Aug 2001 16:01:10 -0700 (PDT)
	(envelope-from archie@packetdesign.com)
Received: (from archie@localhost)
	by bubba.packetdesign.com (8.11.3/8.11.1) id f7NN19b79162;
	Thu, 23 Aug 2001 16:01:10 -0700 (PDT)
	(envelope-from archie)
Message-Id: <200108232301.f7NN19b79162@bubba.packetdesign.com>
Date: Thu, 23 Aug 2001 16:01:10 -0700 (PDT)
From: archie.cobbs@gmail.com
Reply-To: archie@packetdesign.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: dc(4) driver queues outgoing pkts indefinitely if no link
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         30052
>Category:       kern
>Synopsis:       [dc] [patch] dc 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:  Mon Jan 11 17:58:00 UTC 2010
>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:

From: .@babolo.ru
To: archie@packetdesign.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/30052: dc(4) driver queues outgoing pkts indefinitely if no link
Date: Sat, 25 Aug 2001 01:20:42 +0400 (MSD)

 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/

From: Archie Cobbs <archie@packetdesign.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/30052: dc(4) driver queues outgoing pkts indefinitely if no 
 link
Date: Wed, 12 Dec 2001 14:14:53 -0800

 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 
Responsible-Changed-By: mbr 
Responsible-Changed-When: Sat Feb 8 00:08:42 PST 2003 
Responsible-Changed-Why:  
I'll look at this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30052 
Responsible-Changed-From-To: mbr->archie 
Responsible-Changed-By: mbr 
Responsible-Changed-When: Sat Jan 2 23:13:44 UTC 2010 
Responsible-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30052 
Responsible-Changed-From-To: archie->freebsd-bugs@FreeBSD.org 
Responsible-Changed-By: archie 
Responsible-Changed-When: Mon Jan 11 15:35:04 UTC 2010 
Responsible-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30052 
Responsible-Changed-From-To: freebsd-bugs@FreeBSD.org->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jan 11 17:57:47 UTC 2010 
Responsible-Changed-Why:  
Canonicalize assignment. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30052 
>Unformatted:
