Date: Sun, 31 Jan 2010 14:40:33 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Nick Rogers <ncrogers@gmail.com> Cc: jfv@FreeBSD.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken Message-ID: <20100131224033.GA1107@michelle.cdnetworks.com> In-Reply-To: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 31, 2010 at 12:37:43AM -0800, Nick Rogers wrote: > I'm having problems getting PF + ALTQ to work on em(4) interfaces under > 8.0-RELEASE. Kernel was rebuilt with the additional options necessary for > ALTQ and what not. Same basic configuration works fine under 7.2-RELEASE. > Basically, the queues create successfully but running a pfctl -vsq shows a > zero packet/byte count for all queues, even the interface's root queues. > > This same problem is mentioned in PR kern/138392, and the following forum > thread... > http://forums.freebsd.org/showthread.php?t=6656 > > em(4)/e1000 driver from CURRENT does not fix the problem. Building an > 8.0-RELEASE kernel with the em(4) driver from 7.2-RELEASE fixes the problem > (i.e., replacing sys/dev/e1000 with that from 7.2). > > One of the machines im experiencing this on has the following intel > chipset... > > [user@foo ~]$ sysctl dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 > subdevice=0x040d class=0x020000 > dev.em.0.%parent: pci3 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > > Is this issue receiving any attention? I ask because one of the em(4) driver > contributors mentioned he had not heard of this problem in a recent thread > regarding a different em(4) bug, and this is a pretty serious problem for me > as I have many devices in production that need to be upgraded to 8.0, all > running Intel interfaces and relying on ALTQ. > > I appreciate any updates or information and would be happy to test any > patches and/or provide more information. Thanks. > _______________________________________________ I guess the problem comes from multi-queue support. The drbr interface is implemented with inline function so em(4)/igb(4) may have to define ALTQ to the header. I have not tested the patch(no time at this moment) but would you give it try? Thanks. --5mCyUwZo2JvN/JJP Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="em_igb_altq.patch" Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 203324) +++ sys/dev/e1000/if_igb.c (working copy) @@ -36,6 +36,7 @@ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" #include "opt_inet.h" +#include "opt_altq.h" #endif #include <sys/param.h> Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 203324) +++ sys/dev/e1000/if_em.c (working copy) @@ -35,6 +35,7 @@ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" #include "opt_inet.h" +#include "opt_altq.h" #endif #include <sys/param.h> --5mCyUwZo2JvN/JJP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100131224033.GA1107>