Re: Enabling NUMA in BIOS stop booting FreeBSD

On Mon, Dec 12, 2016 at 12:15:53AM +0300, Slawa Olhovchenkov wrote:

> On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote:
> > 
> > > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote:
> > > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote:
> > > > 
> > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote:
> > > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote:
> > > > > > 
> > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote:
> > > > > > > 
> > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote:
> > > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD.
> > > > > > > > > Boot stoped after next messages:
> > > > > > > > > 
> > > > > > > > > ===
> > > > > > > > > Booting...
> > > > > > > > > KDB: debugger backends: ddb
> > > > > > > > > KDB: current backend: ddb
> > > > > > > > So at least the hammer_time() has a chance to initialize the console.
> > > > > > > > Do you have serial console ?  Set the loader tunable debug.late_console
> > > > > > > > to 1 and see if any NMI reaction appear.
> > > > > > > > 
> > > > > > > > > ===
> > > > > > > > > 
> > > > > > > > > This is verbose boot.
> > > > > > > > > No reaction to ~^B, NMI.
> > > > > > > > > 
> > > > > > > > > Same for head and 10.3-RELEASE.
> > > > > > > > > 
> > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM.
> > > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ?
> > > > > > > > What if you try to frob it ?
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On slight different hardware
> > > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM)
> > > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled.
> > > > > > > > 
> > > > > > > > I think the only way to debug this is to add printf() lines to hammer_time()
> > > > > > > > to see where does it break.  Note that amd64_kdb_init() call succeeded,
> > > > > > > > so you can start bisect the code from there.
> > > > > > > > 
> > > > > > > 
> > > > > > > Hang in next two lines:
> > > > > > > 
> > > > > > >         msgbufinit(msgbufp, msgbufsize);
> > > > > > > 	fpuinit();
> > > > > 
> > > > > Can you show the verbose dmesg up to the failure point ?
> > > > > In particular, the SMAP lines should be relevant.
> > > > 
> > > > KDB: debugger backends: ddb
> > > > KDB: current backend: ddb
> > > > exit from kdb_init
> > > > KDB: enter: Boot flags requested debugger
> > > > [ thread pid 0 tid 0 ]
> > > > Stopped at      0xffffffff805361eb = kdb_enter+0x3b:    movq
> > > > $0,0xffffffff80dcef20 = kdb_why
> > > > 
> > > > No SMAP print, boot_verbose enabled.
> > > The log above shows that you used boot -d. What are the pristine boot
> > > messages, with debug.late_console set to 0, of course ?
> > 
> > This is stable/11, no debug.late_console.
> 
> Booting HEAD:
> 
> panic: pmap_mapdev_attr: too many preinit mappings
> cpuid = 0
> KDB: stack backtrace:
> #0 0xffffffff80535197 at ??+0
> #1 0xffffffff804eb0f2 at ??+0
> #2 0xffffffff804eaf63 at ??+0
> #3 0xffffffff807b5995 at ??+0
> #4 0xffffffff808479ca at ??+0
> #5 0xffffffff804079ea at ??+0
> #6 0xffffffff8040bb44 at ??+0
> #7 0xffffffff8047e178 at ??+0
> #8 0xffffffff807a47c3 at ??+0
> #9 0xffffffff8028f0a4 at ??+0
> Uptime: 1s

Like this is debug.late_console=0 issuse.
Same panic with NUMA disabled.
Only set debug.late_console=1 allow to boot