Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jun 2020 10:42:59 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        David Wolfskill <david@catwhisker.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, current@freebsd.org
Subject:   Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
Message-ID:  <20200611144259.GA32928@raichu>
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).

Since you are preloading some iwm firmware file, it might be worth
trying to revert r362035.  I don't really see how the change could
result in this panic, though.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200611144259.GA32928>