Bug 138392

Summary:	[em] [altq] ALTQ queuing not working on em(4)
Product:	Base System	Reporter:	Ben Grimm <freebsd-pr>
Component:	kern	Assignee:	jfv
Status:	Closed Overcome By Events
Severity:	Affects Only Me	CC:	sbruno
Priority:	Normal	Keywords:	IntelNetworking
Version:	8.0-BETA3
Hardware:	Any
OS:	Any

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.

http://svn.freebsd.org/viewvc/base?v...evision=203834

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))
                 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).

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.