Date: Thu, 11 Jun 2020 16:21:29 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: current@freebsd.org Subject: Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045 Message-ID: <20200611132129.GL48478@kib.kiev.ua> In-Reply-To: <20200611130500.GW1392@albert.catwhisker.org> References: <20200611130500.GW1392@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote: > Build machine (mini-tower) performed the update (r362008 -> r362045) > without issue, but my laptop panicked quite early on -- before the dump > device was configured. > > I have taken and placed a couple of screen shots in > http://www.catwhisker.org/~david/FreeBSD/head/r362045/ > > Looking at the displayed backtrace, I see: > > --- trap 0xc ... > futex_xchgl_reslover() > elf_reloc_internal() > link_elf_reloc_local() > link_elf_link_preload_finish() > linker_preload() > mi_startup() > > Any clues? I'm hapy to poke at it or try patches. > > Booting from kernel.old (r362008) still works: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300097 1300097 The link times out. 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 ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200611132129.GL48478>