Rainer Hurling wrote: > 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. Sorry, I accidentally took the discussion off-list, where Konstantin provided some more patches. I'm attaching the one that finally worked for me. It also adds some diagnostic prints which require bootverbose to be enabled.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC