Hi,
just wanted to notice that the difference in locking and resource counting
algorithms is not fixed yet. That means that mlockall() in 5.3 is still
broken.
Given that src tree is unlocked now, is there any chance that it will be
fixed?
By the way, we're using the patched version of
On 11/09/12 08:56, Gerhard Roth wrote:
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst t...@tedunangst.com wrote:
On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
The problem seems to be in uvm_map_pageable_all() function
(sys/uvm/uvm_map.c). This function is a special case of
On Sun, Dec 09, 2012 at 12:26:35AM +0100, Ariane van der Steldt wrote:
On 11/09/12 08:56, Gerhard Roth wrote:
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst t...@tedunangst.com wrote:
On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
The problem seems to be in uvm_map_pageable_all()
On Sun, Dec 09, 2012 at 08:28:08AM +0100, Otto Moerbeek wrote:
On Sun, Dec 09, 2012 at 12:26:35AM +0100, Ariane van der Steldt wrote:
On 11/09/12 08:56, Gerhard Roth wrote:
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst t...@tedunangst.com wrote:
On Thu, Nov 08, 2012 at 13:34, Ilya
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst t...@tedunangst.com wrote:
On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
The problem seems to be in uvm_map_pageable_all() function
(sys/uvm/uvm_map.c). This function is a special case of uvm_map_pageable,
which tries to mlockall() all
Hi list,
after upgrade on OpenBSD 5.2 we observe the following message from ntpd:
Oct 22 17:20:13 gg74 ntpd[2918]: ntpd 4.2.6p2@1.2194-o Tue Oct 16 20:26:47 UTC
2012 (1)
Oct 22 17:20:13 gg74 ntpd[10103]: mlockall(): Cannot allocate memory
Oct 22 17:20:13 gg74 ntpd[10103]: signal_no_reset: signal
I did a similar change recently
(http://marc.info/?l=openbsd-cvsm=135055003602935w=2). Therefore I
think that Ilya's patch is valid and should be applied.
If anyone is willing to ok, I can commit it.
Gerhard
On 11/08/2012 01:34 PM, Ilya Bakulin wrote:
Hi list,
after upgrade on OpenBSD 5.2 we
Oh talking of RLIMIT reminds me...can someone who knows this area take
a look at http://thread.gmane.org/gmane.os.aeriebsd.general/100 please?
On 11/08/2012 02:08 PM, Stuart Henderson wrote:
Oh talking of RLIMIT reminds me...can someone who knows this area take
a look at http://thread.gmane.org/gmane.os.aeriebsd.general/100 please?
To me the fix looks reasonable. Limiting the stack size below
the current usage shouldn't be allowed.
Date: Thu, 8 Nov 2012 13:08:24 +
From: Stuart Henderson s...@spacehopper.org
Oh talking of RLIMIT reminds me...can someone who knows this area take
a look at http://thread.gmane.org/gmane.os.aeriebsd.general/100 please?
Change looks reasonable, but I think that instead of multiplying
On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
The problem seems to be in uvm_map_pageable_all() function
(sys/uvm/uvm_map.c). This function is a special case of uvm_map_pageable,
which tries to mlockall() all mapped memory regions.
Prior to calling uvm_map_pageable_wire(), which actually
11 matches
Mail list logo
