Re: i386 on VirturalBox boot failed

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Wed, Nov 30, 2016 at 13:34:16 +0300, Valery Ushakov wrote:

> On Wed, Nov 30, 2016 at 04:58:40 +0300, Valery Ushakov wrote:
> 
> > On Wed, Nov 30, 2016 at 08:53:02 +0900, Jun Ebihara wrote:
> > 
> > > VirtualBox 5.0.30 on CentOS6.8:
> > > 
> > > use nyftp iso image:
> > > 
> > > NetBSD 7.99.42 GENERIC.201611131540Z ... boot fine.
> > > 
> > > dmesg:
> > >  https://github.com/ebijun/NetBSD/blob/master/dmesg/i386/VirtualBox
> 
> Sorry I managed to miss this part.
> 
> > > NetBSD 7.99.42 GENERIC.201611271450Z: ... stucked.
> > > NetBSD 7.99.43 GENERIC.201611291610Z: ... stucked.
> > > 
> > > kernel: supervisor trap page fault, code=0
> > > uvm_fault(0xc12bc400,0xc153000,1) -> 0xe
> > > fatal page fault in supervisor mode
> > > trap type 6 code 0 eip c0153468 cs 8 eflags 10282 cr2 c153300 ilevel 8 esp c0f41cfd
> > > curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14c92c0
> > > kernel: supervisor trap page fault, code=0
> > >    :
> > > 
> > > and stucked.
> 
> The problem starts with
> 
> cpu0 at mainbus0uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 0 eip c013135c cs 8 eflags 10287 cr2 c1534020 ilevel 8 esp c0f44d79
> curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
> kernel: supervisor trap page fault, code=0
> uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 0 eip c0153468 cs 8 eflags 10286 cr2 c1534300 ilevel 8 esp c0f41cfd
> curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
> kernel: supervisor trap page fault, code=0
> ...
> 
> - and then the latter repeats.
> 
> 
> The first fault is in cpu_attach() accessing lapic_cpu_number() in
> sys/arch/x86/x86/cpu.c line 389:
> 
>         aprint_naive(": %s Processor\n",
>             caa->cpu_role == CPU_ROLE_SP ? "Single" : "Boot");
>         ci = &cpu_info_primary;
> #if NLAPIC > 0
>         if (cpunum != lapic_cpu_number()) ...
> 
>         call    aprint_naive            # ": %s Processor\n" ...
>         mov     0xc125de80, %eax        # local_apic_va
>         mov     0x20(%eax), %eax        # LAPIC_ID
> 
> 
> That second, repeating fault is i82489_icr_wait(), also accessing
> local_apic_va.
> 
> 
> So I'd guess the problem is the fallout from this commit:
> 
>   http://mail-index.netbsd.org/source-changes/2016/11/25/msg079344.html
> 
> 
> I don't know much about x86 to tell whether it's vbox problem :).

I guess that change exposed an old bug.  Previously, the lapic page
was statically pre-allocated and so it was always there.  Even if
lapic wasn't initialized, we could still read (garbage) from that
page.  Now the page is allocated dynamically, so when we try to read
uninitialized data, we get a fault.

A quick workaround for now is to check "Enable I/O APIC" in VM's
preferences in the System settings.

-uwe