Date: Thu, 11 Jun 2020 16:46:58 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: David Wolfskill <david@catwhisker.org>, current@freebsd.org Subject: Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045 Message-ID: <20200611134658.GM48478@kib.kiev.ua> In-Reply-To: <20200611132924.GX1392@albert.catwhisker.org> References: <20200611130500.GW1392@albert.catwhisker.org> <20200611132129.GL48478@kib.kiev.ua> <20200611132924.GX1392@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > > ... > > The link times out. > > Sigh. Sorry about that; I have copied the images to > freefall:~dhw/head/r362045/ . > > > There is not much to access in futex_xchgl_resolver() except for the > > data segment. Without full panic message and disassemble of your instance > > of futex_xchgl_resolver() it is not possible to ee what is going on. > > > > Just in case, can you try clean build, if you did -DNO_CLEAN ? > > .... > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > can certainly clean out /usr/obj/* & start a new build (just before I > head out for a bike ride). That, and also rebuild all third-party modules you use. Definitely nvidia.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200611134658.GM48478>