Synopsis: [ip6] [ndp] panic when changing routes
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Sep 17 07:28:55 UTC 2012
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=171697
___
The following reply was made to PR kern/171697; it has been noted by GNATS.
From: "Eugene M. Zheganin"
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/171697: [ip6] [ndp] panic when changing routes
Date: Mon, 17 Sep 2012 14:03:02 +0600
Actually it's repeatable.
There's a bug in net/bird
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
Hi
Thanks for your replies.
Mike Tancsa mike at sentex.net wrote:
We approach it a little differently and collect all the data via
netflow, or in this case argus.
Netflow is fine. We used ng_netflow with ng_vlan on a previous
installation with FreeBSD-6.x and it worked fine.
Then we had to d
I know that there have been a lot of discussions about fixing how
packets are handed off to ifnets due to the current methods being
extremely race-prone. Has there been any consensus on how the problem
is going to be solved?
In my particular case, I've seen an if_bridge interface whose if_snd
que
On Monday, September 17, 2012 11:49:59 am Ryan Stone wrote:
> I know that there have been a lot of discussions about fixing how
> packets are handed off to ifnets due to the current methods being
> extremely race-prone. Has there been any consensus on how the problem
> is going to be solved?
>
>
On 17 September 2012 10:16, John Baldwin wrote:
> I think for if_bridge the fix is that it no longer uses if_start. :)
:)
> For real hardware you will get some sort of TX completion interrupt that will
> restart the transmit queue. Virtual software-only interfaces such as vlan(4)
> and if_brid
On Monday, September 17, 2012 1:45:12 pm Adrian Chadd wrote:
> On 17 September 2012 10:16, John Baldwin wrote:
>
> > I think for if_bridge the fix is that it no longer uses if_start. :)
>
> :)
>
> > For real hardware you will get some sort of TX completion interrupt that
> > will
> > restart t
So, you mean having them create their own buf ring I assume? Would be easy
enough to hack some code and try it if someone is so inclined?
Jack
On Mon, Sep 17, 2012 at 12:03 PM, John Baldwin wrote:
> On Monday, September 17, 2012 1:45:12 pm Adrian Chadd wrote:
> > On 17 September 2012 10:16, J
On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote:
> So, you mean having them create their own buf ring I assume? Would be easy
> enough to hack some code and try it if someone is so inclined?
No, that would be backwards (back to giving them a queue). Adrian's
suggestion is to provide a m
On Mon, Sep 17, 2012 at 1:22 PM, John Baldwin wrote:
> On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote:
> > So, you mean having them create their own buf ring I assume? Would be
> easy
> > enough to hack some code and try it if someone is so inclined?
>
> No, that would be backwards (ba
There's a lot less cache in these boards. Going through the stack
trace all the way and back for each packet is actually quite
expensive.
Then there's the overhead of having if_start() be called multiple
times, concurrently, from multiple senders. It's fine for a wifi AP
setup where the if_start()
12 matches
Mail list logo
