On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
veg...@tuxpowered.netwrote:
Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
Is this FreeBSD 9.x or HEAD?
I found the problem and developed the patch on 9.1.
Can you please test this more 'beautiful' patch.
Its similar to
Also do not forget to rebuild pfctl so that statistics are shown correctly.
On Sat, Mar 9, 2013 at 1:14 PM, Ermal Luçi e...@freebsd.org wrote:
On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
veg...@tuxpowered.net wrote:
Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
Dnia sobota, 9 marca 2013 o 13:14:16 Ermal Luçi napisał(a):
On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
veg...@tuxpowered.netwrote:
Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
Is this FreeBSD 9.x or HEAD?
I found the problem and developed the patch on 9.1.
On Sat, Mar 9, 2013 at 2:37 PM, Kajetan Staszkiewicz
veg...@tuxpowered.netwrote:
Dnia sobota, 9 marca 2013 o 13:14:16 Ermal Luçi napisał(a):
On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
veg...@tuxpowered.netwrote:
Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
Dnia sobota, 9 marca 2013 o 16:11:56 napisałeś:
Though the src node removal option through pfctl -K does a lot of job
to cleanup things
Still need to undertand why it takes so much time for you to loop
through 500K states.
That is because the loop will not be called just once.
Garrett Wollman wrote:
On Fri, 8 Mar 2013 19:47:13 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
The cached replies are copies of the mbuf list done via m_copym().
As such, the clusters in these replies won't be free'd (ref cnt -
0)
until the cache is trimmed (nfsrv_trimcache()
Garrett Wollman wrote:
On Fri, 8 Mar 2013 19:47:13 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
If reducing the size to 4K doesn't fix the problem, you might want
to
consider shrinking the tunable vfs.nfsd.tcphighwater and suffering
the increased CPU overhead (and some
On Sat, 9 Mar 2013 11:50:30 -0500 (EST), Rick Macklem rmack...@uoguelph.ca
said:
I suspect this indicates that it isn't mutex contention, since the
threads would block waiting for the mutex for that case, I think?
No, because our mutexes are adaptive, so each thread spins for a while
before
On Sat, 9 Mar 2013 11:27:32 -0500 (EST), Rick Macklem rmack...@uoguelph.ca
said:
around the highwater mark basically indicates this is working. If it wasn't
throwing away replies where the receipt has been ack'd at the TCP
level, the cache would grow very large, since they would only be
In article 20795.29370.194678.963...@hergotha.csail.mit.edu, I wrote:
On Sat, 9 Mar 2013 11:50:30 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
I've thought about this. My concern is that the separate thread might
not keep up with the trimming demand. If that occurred, the cache would
On Mar 7, 2013, at 9:42 PM, John-Mark Gurney j...@funkthat.com wrote:
Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 +0100:
Adding interface address is handled via atomically deleting old prefix and
adding interface one.
This brings up a long standing sore point of our
On 09.03.2013 23:17, Nikolay Denev wrote:
On Mar 7, 2013, at 9:42 PM, John-Mark Gurneyj...@funkthat.com wrote:
Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 +0100:
Adding interface address is handled via atomically deleting old prefix and
adding interface one.
This
Old Synopsis: user-mode netgraph node hangs when replying to control message
New Synopsis: [libnetgraph] [patch] user-mode netgraph node hangs when replying
to control message
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Mar
Garett Wollman wrote:
In article 20795.29370.194678.963...@hergotha.csail.mit.edu, I
wrote:
On Sat, 9 Mar 2013 11:50:30 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
I've thought about this. My concern is that the separate thread
might
not keep up with the trimming demand. If that
Garrett Wollman wrote:
On Sat, 9 Mar 2013 11:27:32 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
around the highwater mark basically indicates this is working. If it
wasn't
throwing away replies where the receipt has been ack'd at the TCP
level, the cache would grow very large,
Garrett Wollman wrote:
On Sat, 9 Mar 2013 11:50:30 -0500 (EST), Rick Macklem
rmack...@uoguelph.ca said:
I suspect this indicates that it isn't mutex contention, since the
threads would block waiting for the mutex for that case, I think?
No, because our mutexes are adaptive, so each
Old Synopsis: panic: IPsec + enc(4); device name clash with CAM
New Synopsis: [ipsec] [enc] [patch] panic: IPsec + enc(4); device name clash
with CAM
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Mar 10 04:52:34 UTC 2013
Old Synopsis: process of 'ifconfig gif0 create hangs' when if_gif_load exists
in /etc/loader.conf and 'device gif' exists in kernel config.
New Synopsis: [gif] process of 'ifconfig gif0 create hangs' when if_gif_load
exists in /etc/loader.conf and 'device gif' exists in kernel config.
On Fri, 8 Mar 2013 12:13:28 -0800, Jack Vogel jfvo...@gmail.com said:
Yes, in the past the code was in this form, it should work fine Garrett,
just make sure
the 4K pool is large enough.
[Andre Oppermann's patch:]
if (adapter-max_frame_size = 2048)
adapter- rx_mbuf_sz = MCLBYTES;
-
19 matches
Mail list logo
