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

From: Mark Johnston <markj_at_freebsd.org>
Date: Thu, 11 Jun 2020 12:24:17 -0400
On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote:
> > ...
> > Can you boot into single-user, without loading linux/cuse/nvidia modules.
> > Even, do not load any module at all, and keeping root ro.
> > 
> > If boot succeed, then try to load modules one by one and see which causes
> > panic.
> 
> I commented out each of the "*_load" directives in /boot/loader.conf;
> rebooted; escaped to loader (from the boot menu); used "lsmod" to verify
> that nothing was loaded at that time, then issued "boot -s" -- which did
> succeed.
> 
> Unfortunately, I ran out of time to do further experiments for now; I'll
> need to do some work-related things for a while, but thought that this
> might at least provide some useful information.
> 
> Here is what I commented out:
> 
> g1-55(12.1-S)[2] grep KIB boot/loader.conf
> # KIB coretemp_load="YES"
> # KIB iwn5000fw_load="YES"
> # KIB linux_load="YES"
> # KIB nvidia-modeset_load="YES"
> # KIB cuse_load="YES"
> # KIB geom_eli_load="YES"
> # KIB filemon_load="YES"

Thanks.  I'm able to reproduce a somewhat similar problem in bhyve: if I
preload iwn5000fw.ko, a r362045 kernel fails to boot very early with

---<<BOOT>>---
ACPI: Failed to map RSDT
APIC: Could not find any APICs.
panic: running without device atpic requires a local APIC

Reverting r362035 allows the kernel to boot again, but so does adding a
few printf() calls to the pmap and ACPI code.
Received on Thu Jun 11 2020 - 14:24:23 UTC

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