Date: Wed, 29 Aug 2018 15:13:09 +0300 From: Toomas Soome <tsoome@me.com> To: Yuri Pankov <yuripv@yuripv.net> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: r336921 broke booting on MBP 2017, EFIRT related Message-ID: <E5A9F1C9-997F-460C-9BD4-459ACA8BE1A9@me.com> In-Reply-To: <93CBBDD1-A874-44E7-9E01-6807ABF4D651@me.com> References: <499f05f4-4fab-9b31-5d37-83ecb554013c@yuripv.net> <20180829102727.GD2340@kib.kiev.ua> <b767f852-6e1a-1c02-11eb-5548aea26afe@yuripv.net> <a8611843-8fbc-c5d2-2246-1853fa4ca1b7@yuripv.net> <93CBBDD1-A874-44E7-9E01-6807ABF4D651@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 29 Aug 2018, at 15:05, Toomas Soome <tsoome@me.com> wrote: >=20 >=20 >=20 >> On 29 Aug 2018, at 14:53, Yuri Pankov <yuripv@yuripv.net = <mailto:yuripv@yuripv.net>> wrote: >>=20 >> Yuri Pankov wrote: >>> Konstantin Belousov wrote: >>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote: >>>>> Hi, >>>>>=20 >>>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1, >>>>> 20180802) fail to boot on MBP 2017: >>>>>=20 >>>>> kbd0 at kbdmux0 >>>>> netmap: loaded module >>>>> nexus0 >>>>>=20 >>>>> Fatal trap 12: page fault while in kernel mode >>>>> cpuid =3D 2: apic id =3D 02 >>>>> fault virtual address =3D 0x74c64a50 >>>>> fault code =3D supervisor read data, page not present >>>>> instruction pointer =3D 0x20: 0x7abece31 >>>>> stack pointer =3D 0x28: 0xffffffff82b2f7c0 >>>>> frame pointer =3D 0x28: 0xffffffff82b2f810 >>>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b >>>>> =3D DPL 0, pres 1, long 1, def32 0, gran = 1 >>>>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >>>>> current process =3D 0 (swapper) >>>>> [ thread pid 0 tid 100000 ] >>>>> Stopped at 0x7abece31: calll *0x18(%rax) >>>>> db> >>>>>=20 >>>>> Sadly, there's no support for internal keyboard yet (it's = connected via >>>>> SPI), and external USB one stops working. >>>>>=20 >>>>> A (not so quick) bisect is pointing at r336921, which enabled = EFIRT. >>>>>=20 >>>>> 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? >>>>=20 >>>> It is not in 'enabling'. Looking at the faulting VA, I believe = that >>>> it occurs inside the BIOS code. >>>>=20 >>>> 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 >>=20 >> For the efi mem map, if I'm understanding it correctly, there's the = following: >>=20 >> ... >> BootServicesData 00007421d000 000000000000 00000a8b UC WC WT WB >> ... >> RuntimeServicesCode 00007ab9f000 000000000000 00000070 UC WC WT WB >> =E2=80=A6 >=20 > 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=E2=80=A6 meaning you = would need to get the next entry:) >=20 ya well, my math does suck because its 0x70 pages, not 70:D rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E5A9F1C9-997F-460C-9BD4-459ACA8BE1A9>