Date: Mon, 18 Sep 2006 12:34:16 +0300 From: Danny Braniss <danny@cs.huji.ac.il> To: Gary Jennejohn <garyj@jennejohn.org> Cc: Christos Zoulas <christos@zoulas.com>, freebsd-amd64@FreeBSD.org, am-utils@fsl.cs.sunysb.edu Subject: Re: mlockall() failes on amd64 Message-ID: <E1GPFW4-000CHJ-ED@cs1.cs.huji.ac.il> In-Reply-To: <200609180911.k8I9BZjS001141@peedub.jennejohn.org> References: <200609180911.k8I9BZjS001141@peedub.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Danny Braniss writes: > > > > On Sep 16, 7:17pm, danny@cs.huji.ac.il (Danny Braniss) wrote: > > > > -- Subject: Re: mlockall() failes on amd64 > > > > > > > > | > On Sep 16, 2:55pm, danny@cs.huji.ac.il (Danny Braniss) wrote: > > > > | > -- Subject: mlockall() failes on amd64 > > > > | > > > > > | > | with am-utils 6.1.5, on a amd64 6.1-STABLE kernel i see: > > > > | > | Couldn't lock process pages in memory using mlockall() > > > > | > | while it's ok on a i386: > > > > | > | Locked process pages in memory > > > > | > | > > > > | > > > > > | > We should really fix amd to print the errno string when system calls > > > > | > fail; now we can only scratch our heads. > > > > | > > > > > | > christos > > > > | sorry, here is the full message: > > > > | Couldn't lock process pages in memory using mlockall(): Resource tempor > > arily > > > > | unavailable > > > > | > > > > | or error = EAGAIN (ED :-) > > > > > > > > heh! > > > > > > > > FreeBSD's vm system is very different from NetBSD's, and I am not familia > > r > > > > with it. The first and easiest thing to do is to check if the resource li > > mit > > > > for locked memory is set too low. Then hunt in the kernel sources for mlo > > ckall > > > > and print the arguments it passes to the vm system. Anyway, the error is > > not > > > > fatal, and amd should keep working after that. > > > > > > > > christos > > > > > > im trying to figure out why it core dumped, for the very first time, > > > (and i don't have the core :-(, and the only thing that was special > > > on this host, is that we are trying out postgres with allot of memory > > > requierements, so i thought that maybe it's memory ... > > > oh well, bug-hunting hat still on :-) > > > > some more information: > > an am-utils child will exit on signal 11 > > (so far can't get the core) whenever memory gets tite. > > > > Maybe you need to set kern.sugid_coredump to 1? no luck :-(, and btw amd is not set-uid, it's just run as root. danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1GPFW4-000CHJ-ED>