On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > 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. I have some private report that this is caused by r362031. Can you confirm that reverting it helps ? If yes, please show me the output of sysctl vm.pmap.Received on Thu Jun 11 2020 - 14:32:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC