r336921 broke booting on MBP 2017, EFIRT related

[Kyle Evans]

On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov <yuripv at yuripv.net> wrote:
>
> Yuri Pankov wrote:
> > Konstantin Belousov wrote:
> >> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> >>> Hi,
> >>>
> >>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> >>> 20180802) fail to boot on MBP 2017:
> >>>
> >>> kbd0 at kbdmux0
> >>> netmap: loaded module
> >>> nexus0
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 2: apic id = 02
> >>> fault virtual address  = 0x74c64a50
> >>> fault code             = supervisor read data, page not present
> >>> instruction pointer    = 0x20: 0x7abece31
> >>> stack pointer          = 0x28: 0xffffffff82b2f7c0
> >>> frame pointer          = 0x28: 0xffffffff82b2f810
> >>> code segment           = base 0x0, limit 0xfffff, type 0x1b
> >>>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> processor eflags       = interrupt enabled, resume, IOPL = 0
> >>> current process        = 0 (swapper)
> >>> [ thread pid 0 tid 100000 ]
> >>> Stopped at      0x7abece31:    calll   *0x18(%rax)
> >>> db>
> >>>
> >>> Sadly, there's no support for internal keyboard yet (it's connected via
> >>> SPI), and external USB one stops working.
> >>>
> >>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> >>>
> >>> Some questions here:
> >>> - is this something that can/should be fixed?
> >>> - can we print some "enabling EFIRT" message to the console to make
> >>>     guesses about the problem source a bit easier?
> >>
> >> It is not in 'enabling'.  Looking at the faulting VA, I believe that
> >> it occurs inside the BIOS code.
> >>
> >> Disable efirt by removing the kernel option, then try to load the module
> >> at runtime.  Does it still fault ?  Also, get the efi mem map for the
> >> machine and look at which region the faulting address and the faulting
> >> instruction belong.
> >
> > kldload'ing the efirt module gets the same fault.  Several top lines of
> > backtrace:
> >
> > kernphys() at 0x7abece31
> > efi_get_time() at efi_get_time+0xd9
> > efirtc_probe() at efirtc_probe+0x17
>
> For the efi mem map, if I'm understanding it correctly, there's the
> following:
>
> ...
>     BootServicesData 00007421d000 000000000000 00000a8b UC WC WT WB
> ...
> RuntimeServicesCode 00007ab9f000 000000000000 00000070 UC WC WT WB
> ...
>

Hi,

I guess this patch might do it:
https://people.freebsd.org/~kevans/efi-bootmap.diff

Linux commit messages depict a tale in which they used to also only
map RUNTIME entries, but they were effectively forced to back down on
that because of buggy firmware that does exactly what you've described
and they later reintroduced the restrictive mapping for i386-only
where they'd not found such bugs.

Thanks,

Kyle Evans