Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 11 Jun 2020 16:21:29 +0300
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_at_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 ?
Received on Thu Jun 11 2020 - 11:21:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC