r336921 broke booting on MBP 2017, EFIRT related
Toomas Soome
tsoome at me.com
Wed Aug 29 12:13:31 UTC 2018
> On 29 Aug 2018, at 15:05, Toomas Soome <tsoome at me.com> wrote:
>
>
>
>> On 29 Aug 2018, at 14:53, Yuri Pankov <yuripv at yuripv.net <mailto: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
>> …
>
> if my math is correct, this RTS code area will end at 0x000000007abe5000 and if 0x000000007abece31 is fault location, its just after that RTS code area, that is, 7 pages after… meaning you would need to get the next entry:)
>
ya well, my math does suck because its 0x70 pages, not 70:D
rgds,
toomas
More information about the freebsd-current
mailing list