Hi,
I'm on 9.0-RELEASE-p3 and have had a number of instances where my igb0 network
connectivity locked up under heavy load.
I've had another em1 device which I used for side-band access which does not
have as much load as my primary igb0 device.
I've read previous cases of this but can't seem
On 11.03.2013 08:52, Ihsan Junaidi Ibrahim wrote:
Hi,
I'm on 9.0-RELEASE-p3 and have had a number of instances where my igb0 network
connectivity locked up under heavy load.
This problem is also known on CURRENT and we are under active investigation
on how to solve it properly.
I've had ano
On Mar 11, 2013, at 4:18 PM, Andre Oppermann wrote:
> On 11.03.2013 08:52, Ihsan Junaidi Ibrahim wrote:
>> Hi,
>>
>> I'm on 9.0-RELEASE-p3 and have had a number of instances where my igb0
>> network connectivity locked up under heavy load.
>
> This problem is also known on CURRENT and we are
On 11.03.2013 00:46, Rick Macklem wrote:
Andre Oppermann wrote:
On 10.03.2013 03:22, Rick Macklem wrote:
Garett Wollman wrote:
Also, it occurs to me that this strategy is subject to livelock. To
put backpressure on the clients, it is far better to get them to
stop
sending (by advertising a sma
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
Synopsis: [net] [if_bridge] [patch] use-after-free in if_bridge
State-Changed-From-To: open->patched
State-Changed-By: glebius
State-Changed-When: Mon Mar 11 12:00:29 UTC 2013
State-Changed-Why:
Committed, thanks.
Responsible-Changed-From-To: freebsd-net->glebius
Responsible-Changed-By: glebius
The following reply was made to PR kern/176667; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/176667: commit references a PR
Date: Mon, 11 Mar 2013 12:22:52 + (UTC)
Author: glebius
Date: Mon Mar 11 12:22:44 2013
Synopsis: [libnetgraph] [patch] user-mode netgraph node hangs when replying to
control message
State-Changed-From-To: open->patched
State-Changed-By: glebius
State-Changed-When: Mon Mar 11 12:59:12 UTC 2013
State-Changed-Why:
Committed. Thanks for submission!
Responsible-Changed-From-To: freeb
There are some things I find flawed in your patch:
1.
+#if 0
if (killed > 0)
pf_purge_expired_src_nodes(1);
+#endif
This means that after using `pfctl -K` the src nodes are still around until
purged and any new states created will still use them and bump
On Mon, Mar 11, 2013 at 4:05 PM, Kajetan Staszkiewicz wrote:
> There are some things I find flawed in your patch:
>
> 1.
>
> +#if 0
> if (killed > 0)
> pf_purge_expired_src_nodes(1);
> +#endif
>
> This means that after using `pfctl -K` the src nodes are sti
In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
>Garrett's problem is receive side specific and NFS can't do much about it.
>Unless, of course, NFS is holding on to received mbufs for a longer time.
Well, I have two problems: one is running out of mbufs (caused, we
think, by
How large are you configuring your rings Garrett? Maybe if you tried
reducing them?
Jack
On Mon, Mar 11, 2013 at 9:05 AM, Garrett Wollman <
woll...@hergotha.csail.mit.edu> wrote:
> In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
>
> >Garrett's problem is receive side specif
Dnia poniedziałek, 11 marca 2013 o 16:27:33 Ermal Luçi napisał(a):
> On Mon, Mar 11, 2013 at 4:05 PM, Kajetan Staszkiewicz
>
> > wrote:
> >
> > There are some things I find flawed in your patch:
> >
> > 1.
> >
> > +#if 0
> >
> > if (killed > 0)
> >
> >
In article
,
jfvo...@gmail.com writes:
>How large are you configuring your rings Garrett? Maybe if you tried
>reducing them?
I'm not configuring them at all. (Well, hmmm, I did limit the number
of queues to 6 (per interface, it appears, so that's 12 in all).)
There's a limit to how much experim
Then you are using the default ring size, which is 2K descriptors, you
might try reducing to 1K
and see how that works.
Jack
On Mon, Mar 11, 2013 at 10:09 AM, Garrett Wollman <
woll...@hergotha.csail.mit.edu> wrote:
> In article
> ,
> jfvo...@gmail.com writes:
>
> >How large are you configuring
On 11.03.2013 17:05, Garrett Wollman wrote:
In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
Garrett's problem is receive side specific and NFS can't do much about it.
Unless, of course, NFS is holding on to received mbufs for a longer time.
Well, I have two problems: one
In article <513e3d75.7010...@freebsd.org>, an...@freebsd.org writes:
>On 11.03.2013 17:05, Garrett Wollman wrote:
>> Well, I have two problems: one is running out of mbufs (caused, we
>> think, by ixgbe requiring 9k clusters when it doesn't actually need
>> them), and one is livelock. Allowing pot
Andre Oppermann wrote:
> On 11.03.2013 17:05, Garrett Wollman wrote:
> > In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
> >
> >> Garrett's problem is receive side specific and NFS can't do much
> >> about it.
> >> Unless, of course, NFS is holding on to received mbufs for a lo
Garrett Wollman wrote:
> In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
>
> >Garrett's problem is receive side specific and NFS can't do much
> >about it.
> >Unless, of course, NFS is holding on to received mbufs for a longer
> >time.
The NFS server only holds onto receive mb
<
said:
> To be honest, I'd consider seeing a lot of non-empty receive queues
> for TCP connections to the NFS server to be an indication that it is
> near/at its load limit. (Sure, if you do netstat a lot, you will occasionally
> see a non-empty queue here or there, but I would not expect to see
20 matches
Mail list logo
