Date: Fri, 21 Oct 2005 19:47:05 +0000 From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: Ade Lovett <ade@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha pmap.c src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c src/sys/ia64/ia64 pmap.c Message-ID: <20051021194705.GA75578@freefall.freebsd.org> In-Reply-To: <200510211942.j9LJghO1030033@repoman.freebsd.org> References: <200510211942.j9LJghO1030033@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 21, 2005 at 07:42:43PM +0000, Ade Lovett wrote: > Specifically panic() in the case where pmap_insert_entry() fails to > get a new pv under high system load where the available pv entries > have been exhausted before the pagedaemon has a chance to wake up > to reclaim some. > > Prior to this, the NULL pointer dereference ended up causing > secondary panics with rather less than useful resulting tracebacks. > This sounds similar to an issue that kris is experiencing on one of his sparc64 SMP devices. It looks likes vm_map_entry_splay() is crashing then while vm_fault is running, it recurses a non-recursable mutex making it difficult to do any debugging. Is it possible that this issue affects sparc64, too? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051021194705.GA75578>