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 uvm_map_p
On Sun, 09 Dec 2012 00:26:35 +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 wrote:
> >> On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
> >>
> >>> The problem seems to be in uvm_map_pageable_all() function
> >
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 wrote:
> > >>On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin w
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 wrote:
> >>On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
> >>
> >>>The problem seems to be in uvm_map_pageable_all() function
>
On 11/09/12 08:56, Gerhard Roth wrote:
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst 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
Hi Mark,
could you please also review my patch? It fixes a problem,
which is not related to RLIMIT thing described by mickey.
On Thursday 08 November 2012 14:30:07 Mark Kettenis wrote:
> > Date: Thu, 8 Nov 2012 13:08:24 +
> > From: Stuart Henderson
> >
> > Oh talking of RLIMIT reminds me...ca
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst 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 mapped memo
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 act
> Date: Thu, 8 Nov 2012 13:08:24 +
> From: Stuart Henderson
>
> 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
vm_ssize by PAGE_S
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
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?
I did a similar change recently
(http://marc.info/?l=openbsd-cvs&m=135055003602935&w=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
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
13 matches
Mail list logo
