Bug 138392 - [em] [altq] ALTQ queuing not working on em(4)
Summary: [em] [altq] ALTQ queuing not working on em(4)
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-BETA3
Hardware: Any Any
: Normal Affects Only Me
Assignee: jfv
Keywords: IntelNetworking
Depends on:
Reported: 2009-08-31 13:40 UTC by Ben Grimm
Modified: 2015-08-04 16:45 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ben Grimm 2009-08-31 13:40:02 UTC
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?
Comment 1 Remko Lodder freebsd_committer 2009-08-31 14:10:49 UTC
Responsible Changed
From-To: freebsd-i386->jfv

Reassign to Jack to analyse the em(4) part of the code.
Comment 2 scl 2010-01-31 17:52:52 UTC
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.
Comment 3 Ben Grimm 2010-02-01 01:09:08 UTC
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.
Comment 4 scl 2010-02-14 04:21:12 UTC
It appears that a fix has been applied to the FreeBSD tree.


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?=
Comment 5 fodillemlinkarim 2012-11-12 19:22:30 UTC
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))
             if (!IFQ_IS_EMPTY(&ifp->if_snd) &&
                 ifp->if_start != NULL)


One solution is to restore if_start in the em driver (and all drivers 
that have set if_start to NULL).
Comment 6 Sean Bruno freebsd_committer 2015-08-04 16:45:18 UTC
It appears that this code has been rewritten a bit over the years, making the commit referenced at svn r203834 not applicable.

For now, closing this issue related to ALTQ as it was fixed in years gone by, but I suspect that it may have returned.