A simple rc.d jail patch to enable priority

Hello, I have written this tiny little patch to the jail rc.d script, which allows user to set jail nice value. It doesn't change any default behaviour. Can that make it to the trees? Patch attached. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth o

Re: connect() returns EADDRINUSE during massive host->host conn rate

w to > > duplicate the issue. > > > Have you tried to turn net.inet.ip.portrange.randomized off? Yes, it didn't change anything. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta

Re: connect() returns EADDRINUSE during massive host->host conn rate

On Wed, Nov 28, 2007 at 10:42:59AM -0800, Julian Elischer wrote: > Jan Srzednicki wrote: >> On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: >> How can I get any usable information from netstat? It shows a bunch of >> connections, of course, but since connect

Re: connect() returns EADDRINUSE during massive host->host conn rate

On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: > Jan Srzednicki wrote: >> Hello, >> I have a pair of hosts. One of them performs a massive amount of >> TCP connections to the other one, all to the same port. This setup >> mostly works fine, but fro

Re: connect() returns EADDRINUSE during massive host->host conn rate

On Tue, Nov 27, 2007 at 02:53:20PM +0100, Jan Srzednicki wrote: > Hello, > > setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, > setting O_NONBLOCK on the descriptor. No bind(2) is performed. The > connection is initiated from inside a jail (not sure if

connect() returns EADDRINUSE during massive host->host conn rate

Google said all BSD had a bad habit of throwing out EADDRINUSE from time to time. This all happens on a 6.2-RELEASE system. The symptoms are easily reproducable in my environment. Is there any known fix for that? If there ain't, can it be fixed? :) -- Jan Srzednicki :: http://wrzask.p

Re: pf(4) using inapropriate timeout values, 6.2-R

On Tue, Nov 20, 2007 at 11:20:56AM +0100, Daniel Hartmeier wrote: > On Tue, Nov 20, 2007 at 10:50:41AM +0100, Jan Srzednicki wrote: > > Note the slight difference, which explains your observations. > > It looks like this change was never backported/merged to RELENG_6. > >

Re: pf(4) using inapropriate timeout values, 6.2-R

On Tue, Nov 20, 2007 at 07:53:34AM +0100, Daniel Hartmeier wrote: > On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote: > > > I'm positively sure it's precisely this value that timeouts this > > conection (which later on get state mismatches). > > W

pf(4) using inapropriate timeout values, 6.2-R

keep state" and "modulate state". Is it some kind of a known issue? Is there any fix avalaible? I didn't test it on any other system than 6.2-R. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November"

Re: reproducable panic with python

On Tue, 19 Mar 2002, Matthew Dillon wrote: > Yes, this has been fixed. Python was using MAP_ANON|MAP_NOSYNC > mmap()'s and this resulted in the possibility of msync() encountering > an optimized vm_map_entry that did not yet have a VM object associated > with it, causing a panic.

ATA suggestion

Hello, Recently I had some problems with my ATA drive; I was using the CMD 649 chipset on auxilary controller card and my system halted several times with errors on resetting the first drive (which was running in UDMA 100 mode). I took a different controler (CMD 649 compatible, different vendor)