Date: Wed, 29 Aug 2018 14:53:29 +0300 From: Yuri Pankov <yuripv@yuripv.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: r336921 broke booting on MBP 2017, EFIRT related Message-ID: <a8611843-8fbc-c5d2-2246-1853fa4ca1b7@yuripv.net> In-Reply-To: <b767f852-6e1a-1c02-11eb-5548aea26afe@yuripv.net> References: <499f05f4-4fab-9b31-5d37-83ecb554013c@yuripv.net> <20180829102727.GD2340@kib.kiev.ua> <b767f852-6e1a-1c02-11eb-5548aea26afe@yuripv.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a8611843-8fbc-c5d2-2246-1853fa4ca1b7>