Re: r336921 broke booting on MBP 2017, EFIRT related

Am 29.08.18 um 16:12 schrieb 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

Hi Kyle,

After Yuri had no success with the patches of kib, I tried your patch on
a DELL Latitude E6520 with BIOS version A21.

Kernel config file contains OPTIONS EFIRT, efi.rt.disabled is commented
out in /boot/loader.conf.

Unfortunately, it also does not work. My trap message is this:


[..snip..]
netmap: loaded module
kbd1 at kbdmux0
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX
platforms 390.77  Tue Jul. 10 21:54:30 PDT 2018
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 0: apic id = 00
fault virtual address  = 0xce09ee60
fault code             = supervisor read data, page not present
instruction pointer    = 0x20: 0xcf58334d
stack pointer          = 0x28: 0xffffffff83252920
frame pointer          = 0x28: 0xffffffff832529a0
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)
trap number            = 12
panic: page fault
cpuid = 0
time = 1
Uptime: 1s
Automatic reboot in 15 seconds ...


Regards,
Rainer Hurling