From nobody@FreeBSD.org  Mon Aug 31 12:36:28 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7CABC1065670
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 31 Aug 2009 12:36:28 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 6C6538FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 31 Aug 2009 12:36:28 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VCaRMk075392
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 31 Aug 2009 12:36:27 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n7VCaRXV075391;
	Mon, 31 Aug 2009 12:36:27 GMT
	(envelope-from nobody)
Message-Id: <200908311236.n7VCaRXV075391@www.freebsd.org>
Date: Mon, 31 Aug 2009 12:36:27 GMT
From: Ben Grimm <freebsd-pr@bengrimm.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ALTQ queuing not working on em(4)
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         138392
>Category:       kern
>Synopsis:       [em] [altq] ALTQ queuing not working on em(4)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jfv
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 31 12:40:02 UTC 2009
>Closed-Date:    
>Last-Modified:  Mon Nov 12 19:30:00 UTC 2012
>Originator:     Ben Grimm
>Release:        8.0-BETA3 (csup Aug 30 2009)
>Organization:
None
>Environment:
FreeBSD box 8.0-BETA3 FreeBSD 8.0-BETA3 #0: Sun Aug 30 19:08:45 CEST 2009     .@.:/usr/obj/usr/src/sys/HAIL  i386

>Description:
PF's ALTQ queueing mechanism does not seem to work on 'em' right now. Queues are visible (pfctl  -sq, pftop, pfstat), but next to no traffic gets passed to them, despite queue definitions on every pass in/out rule in pf.conf. Even the root queue is silent.

See http://forums.freebsd.org/showthread.php?t=6656 for problem description. 

On the same machine, queueing works fine on a different interface ('re0'). On a different server, the exact same ALTQ ruleset works on an 'fxp0' NIC as well.

Could this be a regression due to a recent patch?
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->jfv 
Responsible-Changed-By: remko 
Responsible-Changed-When: Mon Aug 31 13:10:49 UTC 2009 
Responsible-Changed-Why:  
Reassign to Jack to analyse the em(4) part of the code. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=138392 

From: Simon Lok <scl@rgnets.com>
To: bug-followup@FreeBSD.org, freebsd-pr@bengrimm.net
Cc:  
Subject: Re: kern/138392: [em] [altq] ALTQ queuing not working on em(4)
Date: Sun, 31 Jan 2010 12:52:52 -0500

 --0016e68ed77ba13154047e7989ff
 Content-Type: text/plain; charset=ISO-8859-1
 
 We have been able to successfully replicate this problem on FreeBSD 8
 RELEASE p2.  We have also create a custom kernel using the FreeBSD 8 sources
 but replacing sys/dev/e1000 with the files in CVS.  Using what is in head
 (as of 29-JAN-2010) results in the same behavior where altq is not
 functional.  Replacing the e1000 files with the version in CVS that is
 tagged as for FreeBSD 7.2 results in a kernel that does not exhibit the
 behavior.  Please let us know if you need any assistance with replicating
 this bug or testing a patch for it.  This problem is causing us significant
 problems and we would like to avoid deploying a Frankenstein FreeBSD 8 with
 FreeBSD 7.2 e1000 drivers if possible.  Thanks in advance.
 
 --0016e68ed77ba13154047e7989ff
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 We have been able to successfully replicate this problem on FreeBSD 8 RELEA=
 SE p2.=A0 We have also create a custom kernel using the FreeBSD 8 sources b=
 ut replacing sys/dev/e1000 with the files in CVS.=A0 Using what is in head =
 (as of 29-JAN-2010) results in the same behavior where altq is not function=
 al.=A0 Replacing the e1000 files with the version in CVS that is tagged as =
 for FreeBSD 7.2 results in a kernel that does not exhibit the behavior.=A0 =
 Please let us know if you need any assistance with replicating this bug or =
 testing a patch for it.=A0 This problem is causing us significant problems =
 and we would like to avoid deploying a Frankenstein FreeBSD 8 with FreeBSD =
 7.2 e1000 drivers if possible.=A0 Thanks in advance.<br>
 
 --0016e68ed77ba13154047e7989ff--

From: Ben Grimm <freebsd-pr@bengrimm.net>
To: bug-followup@FreeBSD.org, freebsd-pr@bengrimm.net
Cc:  
Subject: Re: kern/138392: [em] [altq] ALTQ queuing not working on em(4)
Date: Mon, 01 Feb 2010 02:09:08 +0100

 Would it be possible to testdrive a patch at the FreeBSD Forums 
 (http://forums.freebsd.org/showthread.php?t=6656)? Several people have already 
 reported the exact same problem. More eyeballs, more results, I guess.

From: Simon Lok <scl@rgnets.com>
To: bug-followup@FreeBSD.org,
 freebsd-pr@bengrimm.net
Cc:  
Subject: Re: kern/138392: [em] [altq] ALTQ queuing not working on em(4)
Date: Sat, 13 Feb 2010 23:21:12 -0500

 --Apple-Mail-1-51263649
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii
 
 It appears that a fix has been applied to the FreeBSD tree.
 
 http://svn.freebsd.org/viewvc/base?v...evision=3D203834
 
 What is the best way for us to get this into our FreeBSD 8 =
 installations?  Replacing sys/dev/e1000 in a FreeBSD 8 source tree with =
 the contents of CVS head?=
 
 --Apple-Mail-1-51263649
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 	charset=us-ascii
 
 <html><head></head><body style=3D"word-wrap: break-word; =
 -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span =
 class=3D"Apple-style-span" style=3D"font-family: verdana, geneva, =
 lucida, 'lucida grande', arial, helvetica, sans-serif; font-size: 13px; =
 -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: =
 1px; ">It appears that a fix has been applied to the FreeBSD =
 tree.<br><br><a =
 href=3D"http://svn.freebsd.org/viewvc/base?view=3Drevision&amp;revision=3D=
 203834" target=3D"_blank" style=3D"color: rgb(153, 0, 0); =
 ">http://svn.freebsd.org/viewvc/base?v...evision=3D203834</a><br></span><d=
 iv><font class=3D"Apple-style-span" face=3D"verdana, geneva, lucida, =
 'lucida grande', arial, helvetica, sans-serif" size=3D"3"><span =
 class=3D"Apple-style-span" style=3D"font-size: 13px; =
 -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: =
 1px;"><br></span></font></div><div><font class=3D"Apple-style-span" =
 face=3D"verdana, geneva, lucida, 'lucida grande', arial, helvetica, =
 sans-serif" size=3D"3"><span class=3D"Apple-style-span" =
 style=3D"font-size: 13px; -webkit-border-horizontal-spacing: 1px; =
 -webkit-border-vertical-spacing: 1px;">What is the best way for us to =
 get this into our FreeBSD 8 installations? &nbsp;Replacing sys/dev/e1000 =
 in a FreeBSD 8 source tree with the contents of CVS =
 head?</span></font></div></body></html>=
 
 --Apple-Mail-1-51263649--

From: Karim <fodillemlinkarim@gmail.com>
To: bug-followup@FreeBSD.org, freebsd-pr@bengrimm.net
Cc:  
Subject: Re: kern/138392: [em] [altq] ALTQ queuing not working on em(4)
Date: Mon, 12 Nov 2012 14:22:30 -0500

 This issue is mainly caused by the ALTQ token bucket regulator timeout 
 function to be unable to call if_start since this critical function was 
 replaced by if_transmit():
 
 tbr_timeout() :
 
 ...
 
          for (ifp = TAILQ_FIRST(&V_ifnet); ifp;
              ifp = TAILQ_NEXT(ifp, if_list)) {
              /* read from if_snd unlocked */
              if (!TBR_IS_ENABLED(&ifp->if_snd))
                  continue;
              active++;
              if (!IFQ_IS_EMPTY(&ifp->if_snd) &&
                  ifp->if_start != NULL)
                  (*ifp->if_start)(ifp);
          }
 
 ...
 
 One solution is to restore if_start in the em driver (and all drivers 
 that have set if_start to NULL).
>Unformatted:
