Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above
with ixgbe (tons of fragmentation failed errors) was real. The issue
in 8.3-RC3 was because dummynet wasn't being loaded at all... so no
traffic could pass on it, despite dummynet_load=YES being set in
/boot/loader.conf. So
Hi Jack,
I could recreate the problem. When the problem occurs, we see
rx_nxt_check = n
rx_nxt_refresh = n + 1
(This was also reported in a mail from Karim)
This means that the *whole* receive ring has no buffers anymore. This can
occur if, for some amount of time, no clusters are available.
On 9 February 2011 12:37, rihad ri...@mail.ru wrote:
Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above with
ixgbe (tons of fragmentation failed errors) was real. The issue in 8.3-RC3
was because dummynet wasn't being loaded at all... so no traffic could pass
on it, despite
On 02/09/2011 05:47 PM, Sergey Kandaurov wrote:
On 9 February 2011 12:37, rihadri...@mail.ru wrote:
Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above with
ixgbe (tons of fragmentation failed errors) was real. The issue in 8.3-RC3
was because dummynet wasn't being loaded at
On 9 February 2011 18:15, rihad ri...@mail.ru wrote:
On 02/09/2011 05:47 PM, Sergey Kandaurov wrote:
On 9 February 2011 12:37, rihadri...@mail.ru wrote:
Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above
with
ixgbe (tons of fragmentation failed errors) was real. The
Hello.
In my routing table I see entries after Neighbor Discovery Protocol
processed:
...
2a02:6b8:0:401:51:4809:8158:1dcd 00:22:fb:3d:82:fe UHLWvlan438
...
I'd like to catch them via a routing socket when they appear.
First, try to add a static entry:
ndp -s 2a02:6b8:0:403::1:1
OK, but the question is why does the ring get totally consumed this way, the
ring has 1024 descriptors, it seems unintuitive that that whole quantity can
be
used without some being recharged. Do you see the system mbuf pool being
depleted at the same time?
Since you can reproduce it, do me a
On Tuesday 08 February 2011 10:52:53 Bernhard Schmidt wrote:
I've combined both patches (see attachment), if I get an ACK from both
of you I'll try get this into the tree ASAP.
Committed, thanks!
--
Bernhard
___
freebsd-net@freebsd.org mailing list
On Feb 9, 2011, at 6:35 PM, Jack Vogel wrote:
OK, but the question is why does the ring get totally consumed this way, the
ring has 1024 descriptors, it seems unintuitive that that whole quantity can
be
used without some being recharged. Do you see the system mbuf pool being
depleted at the
Both the em and re drivers have had a lot of work done recently. Are
you trying with 8.2RC1 ?
Tried with 8.2RC2 (via fixit shell with em): the same symptoms sadly.
Card recognized, driver loaded as a result ifconfig reports it as
available interface. Though neither static IP addressing nor
On Mon, Feb 07, 2011 at 08:27:43PM -0600, Peter Lai wrote:
On Feb 7, 2011 7:38 PM, Pyun YongHyeon pyu...@gmail.com wrote:
On Mon, Feb 07, 2011 at 06:09:16PM -0600, Peter Lai wrote:
Hello
I've got a new Dell Precision workstation here with a BCM5761 on intel
mobo for westmere xeons
Let me know attached patch makes any difference on your box.
The patch contains some other changes but that wouldn't affect your
BCM5761 controller. If you see CLKREQ enabled message after
applying the patch also let me know that too.
Can I apply this to 8.2-RC1 or should I update it to
On Wed, Feb 09, 2011 at 06:28:31PM -0600, Peter Lai wrote:
Let me know attached patch makes any difference on your box.
The patch contains some other changes but that wouldn't affect your
BCM5761 controller. If you see CLKREQ enabled message after
applying the patch also let me know that
On 02/09/2011 07:27 PM, Sergey Kandaurov wrote:
On 9 February 2011 18:15, rihadri...@mail.ru wrote:
On 02/09/2011 05:47 PM, Sergey Kandaurov wrote:
On 9 February 2011 12:37, rihadri...@mail.ruwrote:
Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above
with
ixgbe (tons
Old Synopsis: Random kernel panics on tcp_output
New Synopsis: [tcp] [panic] Random kernel panics on tcp_output
Responsible-Changed-From-To: freebsd-amd64-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Feb 10 05:41:32 UTC 2011
Responsible-Changed-Why:
reclassify and
Old Synopsis: if_msk driver causes kernel panic (fatal trap while in kernel
mode)
New Synopsis: [msk] [panic] if_msk driver causes kernel panic (fatal trap while
in kernel mode)
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu
16 matches
Mail list logo
