From owner-freebsd-current@freebsd.org Wed Aug 29 14:12:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCDA7108B548 for ; Wed, 29 Aug 2018 14:12:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6BA8EDA1 for ; Wed, 29 Aug 2018 14:12:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 186B914B42 for ; Wed, 29 Aug 2018 14:12:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id c21-v6so4430275lfh.3 for ; Wed, 29 Aug 2018 07:12:51 -0700 (PDT) X-Gm-Message-State: APzg51AuKkorcZuEofwS2FIyQHEzqzrVQpgD0bk7ljRyKmoyo5CYRizo EcOh3gmjOf/0IQy6Q2+Vu71et/i/ZReDTlPk6EU= X-Google-Smtp-Source: ANB0VdbZSmqK7Q59MKKJaWMC4nkBu2e24VRE0ziTz5CKiHRqV2r91OV/D3mYxfGfydPG1Yol7fn9pyXnhanHUD4BPYM= X-Received: by 2002:a19:ca09:: with SMTP id a9-v6mr4417962lfg.120.1535551969569; Wed, 29 Aug 2018 07:12:49 -0700 (PDT) MIME-Version: 1.0 References: <499f05f4-4fab-9b31-5d37-83ecb554013c@yuripv.net> <20180829102727.GD2340@kib.kiev.ua> In-Reply-To: From: Kyle Evans Date: Wed, 29 Aug 2018 09:12:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: r336921 broke booting on MBP 2017, EFIRT related To: yuripv@yuripv.net Cc: Konstantin Belousov , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 14:12:52 -0000 On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov 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