FWIW I have been experiencing a similar issue on a number of systems
using the em(4) driver under 9.1-RELEASE. This is after upgrading from
a snapshot of 8.3-STABLE. My systems use PF+ALTQ as well. The symptoms
are: interface stops passing traffic until the system is rebooted. I
have not yet been a
On Fri, Mar 1, 2013 at 8:04 AM, Nick Rogers wrote:
> FWIW I have been experiencing a similar issue on a number of systems
> using the em(4) driver under 9.1-RELEASE. This is after upgrading from
> a snapshot of 8.3-STABLE. My systems use PF+ALTQ as well. The symptoms
> are: int
On Sun, Mar 3, 2013 at 2:14 AM, Sepherosa Ziehau wrote:
> On Sat, Mar 2, 2013 at 12:18 AM, Nick Rogers wrote:
>> On Fri, Mar 1, 2013 at 8:04 AM, Nick Rogers wrote:
>>> FWIW I have been experiencing a similar issue on a number of systems
>>> using the em(4) driver
On Mon, Mar 4, 2013 at 10:22 AM, Jack Vogel wrote:
>
>>
>> Thanks. So on FreeBSD 9.1-RELEASE it is advisable to set
>> hw.em.enable_msix=0 for 82574L? Are there other em(x) NICs where this
>> is advisable?
>>
>
> As I explained in a previous email, this is not advisable unless you are
> experienci
Hello,
I am attempting to create awareness of a serious issue affecting users
of FreeBSD 9.x and PF. There appears to be a bug that allows the
kernel's routing table to be corrupted by traffic routing through the
system. Under heavy traffic load, the default route can seemingly
randomly change to
I'm not sure. I have not explicitly enabled/disabled it. I am using
the GENERIC kernel from 9.1 plus PF+ALTQ.
# sysctl net.inet.flowtable.enable
sysctl: unknown oid 'net.inet.flowtable.enable'
# sysctl -a | grep flow
kern.sigqueue.overflow: 0
net.inet.tcp.reass.overflows: 0
net.inet6.ip6.auto_flow
On Wed, Mar 6, 2013 at 12:25 AM, Andre Oppermann wrote:
> On 05.03.2013 18:39, Nick Rogers wrote:
>>
>> Hello,
>>
>> I am attempting to create awareness of a serious issue affecting users
>> of FreeBSD 9.x and PF. There appears to be a bug that allows the
>>
On Thu, Mar 7, 2013 at 12:51 PM, Li, Qing wrote:
> Hi,
>
>>
>> I can confirm I get these messages as well:
>>
>> Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
>> 86.58.122.125
>> Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
>> 86.58.122.125
>>
>> IP 86.
I've been using igb(4) in conjunction with ALTQ under 7.x/8.x for
years on hundreds of servers. I recently began upgrading my production
servers to 9.1-RELEASE, with the GENERIC kernel including ALTQ
support. I recently discovered the hard way that igb(4) no longer
supports ALTQ.
The issue is the
On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote:
> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff wrote:
>
>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
>> J> UH, maybe asking the owner of the driver would help :)
>> J>
>> J> ... and no, I've never been aware of doing anything
th an igb
driver that works again with ALTQ, ASAP, would be much appreciated.
>
> Jack
>
>
>
> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers wrote:
>>
>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel wrote:
>> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff
age-
>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
>> On Behalf Of Barney Cordoba
>> Sent: Friday, March 29, 2013 5:51 AM
>> To: Jack Vogel; Nick Rogers
>> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)
>> Subject: Re:
th other matters, one thing I could do short
>> term is
>> change the defines in igb the way I did in the em driver so you could
>> still
>> define
>> the older if_start entry. Right now those are based on OS version and so
>> you will
>> automatically get if_tra
ith em(4) interfaces and similar pf configurations on the same kernel that
work fine.
> Regards,
>
> Karim.
>
> On 01/04/2013 8:22 PM, Nick Rogers wrote:
>
> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
> wrote:
>
> Hi Jack,
>
> I think this would hel
the older if_start non-multiqueue capable interface.
+# This might be desireable for testing, or to enable the use of
+# ALTQ.
+CFLAGS += -DIGB_LEGACY_TX
>
> Regards,
>
> Karim.
>
>
> On 02/04/2013 9:58 AM, Nick Rogers wrote:
>>
>> On Tuesday, April 2, 2013, K
ush;
> -#else
> +#endif
>
> ifp->if_start = igb_start;
> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
> IFQ_SET_READY(&ifp->if_snd);
> -#endif
>
>
On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers wrote:
> On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
> wrote:
>> Hi Nick,
>>
>> Unfortunately I do not have a FBSD 9 box around where I can compile and test
>> this so bear with me as this is pretty much straight o
ke effect when building the driver
into the kernel (i.e., not as a module). Can anyone comment on a
correct way to set this macro without modifying the driver code?
>
> Best regards,
>
> Karim.
>
>
> On 02/04/2013 1:17 PM, Nick Rogers wrote:
>>
>> On Tue, Apr 2, 2013 at 9
On Tue, Apr 2, 2013 at 3:39 PM, Adrian Chadd wrote:
> Yes:
>
> * you need to add it to conf/options - see if there's an opt_igb.h to
> add it to, otherwise you'll need to add one;
> * Make sure the driver code includes opt_igb.h;
> * Then make sure you make kernel modules using either make buildke
On Wed, Apr 24, 2013 at 11:50 AM, Randall Stewart wrote:
> All
>
> Ok I fixed it ;-)
>
> Its in SVN r249848.
>
> I will see about getting it to 9 stable, 8 stable and maybe even
> 8.4 if RE will let me ;-)
>
Great work. Thanks so much. I was afraid this would linger forever!
> R
> On Apr 23, 201
,
-Nick Rogers
uname -v
FreeBSD 9.2-STABLE #16 r264331M: Thu Apr 10 21:23:18 EDT 2014
root@fbsd_91_amd64_builder.rgnets.com:/usr/obj/usr/src/sys/RGNETS
Here is the kernel conf...
..
include GENERIC
ident RGNETS
t to clarify/clean
> this up but i am not sure the staus of that so far.
>
>
> On Fri, May 2, 2014 at 10:49 PM, Nick Rogers wrote:
>>
>> Hello,
>>
>> I am hoping someone can help me debug a kernel panic I have been
>> experiencing
>> on one o
On Fri, May 2, 2014 at 1:49 PM, Nick Rogers wrote:
> Hello,
>
> I am hoping someone can help me debug a kernel panic I have been experiencing
> on one of my production systems. The system is a PF+ALTQ firewall/gateway with
> about 1k simultaneous devices behind it at any given t
On Mon, May 12, 2014 at 5:16 PM, Jack Vogel wrote:
> Nick,
>
> I'm very busy with some critical internal deadlines, I will look at this
> when I can
> come up for air, but please be patient.
Thank you.
>
> Jack
>
>
>
> On Mon, May 12, 2014 at 4:56 PM, N
On Fri, May 2, 2014 at 1:49 PM, Nick Rogers wrote:
> Hello,
>
> I am hoping someone can help me debug a kernel panic I have been experiencing
> on one of my production systems. The system is a PF+ALTQ firewall/gateway with
> about 1k simultaneous devices behind it at any given t
I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having
a network interface (em(4)) configured with 4000 aliases. The "arp -na"
command takes what I consider to be an extremely long time to finish (up to
30s on an otherwise unloaded system). I am able to replicate this in a tes
FYI there is a bugfix/patch for this issue being discussed in
freebsd-hackers:
http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg157097.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubs
Hello,
I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
Initially, loading a PF rulset with ALTQ enabled fails on an ix interface,
reporting "ix0: driver does not support altq". This is similar to the
behavior over the last few years when dealing with the igb driver. However,
sd.org/bugzilla/show_bug.cgi?id=193053
>
> Thank!
>
>
> -a
>
>
> On 26 August 2014 13:42, Nick Rogers wrote:
> > Hello,
> >
> > I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
> > Initially, loading a PF rulset with ALTQ enabl
On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers wrote:
>
>
>
> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd wrote:
>
>> Hi,
>>
>> I'm not surprised the legacy tx path has bitrotted there.
>>
>> Please file a bug with this - https://bugs.freebsd
Any chance we can get some kind of resolution to this for 10.1?
On Mon, Sep 22, 2014 at 4:40 PM, wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053
>
> --- Comment #8 from ncrog...@gmail.com ---
> (In reply to ncrogers from comment #7)
> > (In reply to Eric Joyner from comment #6)
On Wed, Sep 17, 2014 at 8:17 AM, Nick Rogers wrote:
>
>
> On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers wrote:
>
>>
>>
>>
>> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd wrote:
>>
>>> Hi,
>>>
>>> I'm not surprised t
On Wed, Apr 15, 2015 at 5:26 AM, Gleb Smirnoff wrote:
> On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote:
> L> > With the new ifnet KPI, that is now being developed in
> projects/ifnet,
> L> > the ALTQ will need some tweaking. It is discontinued by initial author
> L> > for a decade
Hello,
I am wondering if there is a simple way to determine which iflib queue
kernel threads belong to which network interface's rxq or txq.
For example if in ps/top there is a busy thread such as "if_io_tqg_0" is it
possible to get a mapping between thread name and interface rx / tx queue
names
Hello,
In 12.0-RELEASE, STABLE, and 13-CURRENT, gb(4) interfaces report an
incorrect media status after they are disconnected (ethernet cable
unplugged). Ifconfig reports active + autoselect/1000baseT when it should
report inactive.
I filed a bug for this a few weeks ago and have not had any luc
On Wed, Jan 20, 2016 at 2:01 PM, Matthew Grooms wrote:
> All,
>
> I have a curious problem with a lightly loaded pair of pf firewall running
> on FreeBSD 10.2-RELEASE. I'm noticing TCP entries are disappearing from
> the state table for no good reason that I can see. The entry limit is set
> to
On Thu, Jan 21, 2016 at 11:44 AM, Matthew Grooms wrote:
> On 1/21/2016 11:04 AM, Nick Rogers wrote:
>
>> On Wed, Jan 20, 2016 at 2:01 PM, Matthew Grooms
>> wrote:
>>
>> All,
>>>
>>> I have a curious problem with a lightly loaded pair of pf firewa
On Sat, Apr 8, 2017 at 3:55 AM, Eugene M. Zheganin wrote:
> Hi,
>
> regarding all this stir around ALTQ and igb(4), and mentioning that igb(4)
> doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) and
> ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally from
> FreeBSD
On Tue, Jan 14, 2020 at 10:09 AM Hans Petter Selasky
wrote:
> On 2020-01-14 16:07, Slawa Olhovchenkov wrote:
> >> this is a known issue in iflib.
> > Unresolved?
>
> See mail I sent off-list.
>
I would be interested to know if this is resolved or not as well.
>
> --HPS
> __
39 matches
Mail list logo
