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.
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: em_igb_altq.patch Type: text/x-diff Size: 699 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100131/cdaeebb5/em_igb_altq.bin
> 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? > > I tried the patch and it did not work.
On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:> > 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? > > > > I tried the patch and it did not work.You rebuilt kernel, right? Rebuilding kernel module has no effect.
On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:> On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > 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? > > > > > > I tried the patch and it did not work. > > You rebuilt kernel, right? Rebuilding kernel module has no effect. >Yes I rebuilt the kernel itself and replaced the one on my test system.
So apparently this thing needs no special knowledge in the driver, yet something in the new code breaks it, can someone explain tersely how the altq app actually "pokes" or "hooks up" to the driver? I am not clear about that and I suspect if I was this would all be clearer. Jack On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:> On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > 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? > > > > > > I tried the patch and it did not work. > > You rebuilt kernel, right? Rebuilding kernel module has no effect. >
On Tue, Feb 02, 2010 at 09:47:17AM -0800, Nick Rogers wrote:> On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote: > > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > > 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? > > > > > > > > I tried the patch and it did not work. > > > > You rebuilt kernel, right? Rebuilding kernel module has no effect. > > > Yes I rebuilt the kernel itself and replaced the one on my test system.Hmm, I have to find time to experiment this. Thank you for testing!