Re: Panic with no keyboard after update to main-n248404-60fb9e10c74c

On Sun, Aug 01, 2021 at 10:32:10AM -0700, David Wolfskill wrote:
> On Sun, Aug 01, 2021 at 05:03:32PM +0300, Konstantin Belousov wrote:
> > On Sun, Aug 01, 2021 at 06:01:56AM -0700, David Wolfskill wrote:
> > > Once I was able to complete the "make installworld" after updating
> > > from main-n248391-f7f76c200a8c to main-n248404-60fb9e10c74c, the
> > > subsequent reboot yielded a panic with the keyboard inoperable.
> > > ... 
> > 
> > It seems you block my home external ip address (or country?).
> 
> I apologize: I believe that's been remedied (recently).
> 
> > Your issue with the kernel.old is that nvidia.ko was rebuilt against newer
> > kernel, so it cannot be loaded together with older kernel.
> 
> OK; effectively copying the modules from /boot/modules.old to
> /boot/modules got past that.  (Should loader be loding modules from
> /boot/modules (vs. /boot/modules.old) if it's booting kernel.old?)
> 
> > Anyway, please update past 1a55a3a729cd4424e17308d3 _and_ apply the following
> > patch:
> > 
> > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > index 8599dc2fa8f6..144b4a522bcc 100644
> > --- a/sys/amd64/amd64/machdep.c
> > +++ b/sys/amd64/amd64/machdep.c
> > @@ -1209,7 +1209,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
> >  	 * Tell the physical memory allocator about pages used to store
> >  	 * the kernel and preloaded data.  See kmem_bootstrap_free().
> >  	 */
> > -	vm_phys_early_add_seg((vm_paddr_t)kernphys, trunc_page(first));
> > +//	vm_phys_early_add_seg((vm_paddr_t)kernphys, trunc_page(first));
> >  
> >  	bzero(physmap, sizeof(physmap));
> >  	physmap_idx = 0;
> > 
> 
> OK; did that; rebuilt.  Subsequent reboot shows (copy/paste from serial
> console, as this is from my headless build machine):
> 
> SMP: passed TSC synchronization test
> TSC timecounter discards lower 1 bit(s)
> Timecounter "TSC-low" frequency 1795879156 Hz quality 1000
> KTLS: Initialized 8 threads
> panic: vm_phys_free_pages: page 0xfffffe00000f4fe8 has unexpected order 0
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82b2ead0
> vpanic() at vpanic+0x187/frame 0xffffffff82b2eb30
> panic() at panic+0x43/frame 0xffffffff82b2eb90
> vm_phys_free_pages() at vm_phys_free_pages+0x27d/frame 0xffffffff82b2ebd0
> kmem_bootstrap_free() at kmem_bootstrap_free+0xfe/frame 0xffffffff82b2ec20
> preload_delete_name() at preload_delete_name+0x70/frame 0xffffffff82b2ec40
> ucode_release() at ucode_release+0x8a/frame 0xffffffff82b2ec60
> mi_startup() at mi_startup+0x1f0/frame 0xffffffff82b2ecb0
> btext() at btext+0x22
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x37: movq    $0,0x127af3e(%rip)
> db> 
> 
> I can leave it as-is for a bit, and poke at it (given sufficient
> clues), if that might be helpful.

No need. Please revert that manual change (commenting out the call to
vm_phys_early_add_seg()), and reproduce the issue anew. I want to see the
updated "allocating kernel page" panic message.

BTW, if you comment out loading nvidia.ko from loader.conf, does the
system boot normally?  If yes, can you kldload nvidia.ko after system
booted?