From owner-freebsd-current@freebsd.org Fri Aug 17 09:02:11 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 C6EDF108771A for ; Fri, 17 Aug 2018 09:02:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7057573604 for ; Fri, 17 Aug 2018 09:02:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from dhcp-10-248-98-203.eduroam.wireless.private.cam.ac.uk (global-5-141.nat-2.net.cam.ac.uk [131.111.5.141]) by mail.baldwin.cx (Postfix) with ESMTPSA id AF05010AFD2; Fri, 17 Aug 2018 05:02:09 -0400 (EDT) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) To: Michael Gmelin References: <20180603215020.452a81d8@bsd64.grem.de> <20180603205340.GS3789@kib.kiev.ua> <20180604004632.56ca6afa@bsd64.grem.de> <20180604110654.GA2450@kib.kiev.ua> <20180604231756.2ed2adb9@bsd64.grem.de> <20180605131135.GH2450@kib.kiev.ua> <20180606010625.62632920@bsd64.grem.de> <20180815005106.69402d23@bsd64.grem.de> <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> Cc: Konstantin Belousov , "freebsd-current@freebsd.org" , Matthias Apitz From: John Baldwin Message-ID: <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> Date: Fri, 17 Aug 2018 10:02:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 17 Aug 2018 05:02:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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: Fri, 17 Aug 2018 09:02:12 -0000 On 8/17/18 9:54 AM, Michael Gmelin wrote: > > >> On 17. Aug 2018, at 08:17, John Baldwin wrote: >> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: >>> >>> >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov > wrote: >>>> >>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: >>>>> >>>>> >>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov > wrote: >>>>>>> >>>>>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote: >>>>>>> Reviving this old thread, since I just updated to r337818 and a similar >>>>>>> problem is happening again. Since the fix in r334799 (review >>>>>>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched, >>>>>>> so maybe this is related >>>>>>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). >>>>>>> >>>>>>> Please see the screenshot of the panic below: >>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 >>>>>>> >>>>>>> This is me not digging any deeper, hoping that this is something >>>>>>> obvious. Please let me know if you need more input. >>>>>> >>>>>> I do not see how recent mp_machdep.c changes could affect this. >>>>>> Can you try newest kernel but old loader ? >>>>> >>>>> I will try (but that will take a while). Oh, also, it still boots in save mode/with smp disabled. >>>> >>>> Right, this is because the access to that address through DMAP is only >>>> needed when configuring AP startup resources. >>>> >>>> Also, I think it is safe to suggest that the bisect is needed. >>> >>> Using an older loader didn’t help, but I identified the problem: >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 >>> >>> modified the code you introduced in >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 >>> >>> By correcting units to pages it also broke booting the Chromebook as a side effect - so the previous fix just worked due to a bug it seems. >>> >>> Is there an easy way to output the content of physmap at that point (debug.late_console=0 doesn’t work) - like an existing buffer I could use, or would this be more elaborate (I did something complicated last time but didn’t save it, so any simple solution would be preferred). >> >> How about reverting the commit for now so you get a working console >> and print out the physmap array values along with Maxmem later in >> the boot (or just use kgdb to examine them once the system is running)? >> > > This is before the system has a working console (part of calling getmem...), disabling late console makes it hang, physmap changes afterwards, so running kgdb later doesn’t help. Last time I kept a copy of physmap and logged it later to know the original content. I can do that again, I just thought maybe there is a simple mechanism I’m not aware of that would save me some time. I thought we only modified phys_avail[], but saving a copy of physmap[] and dumping it from kgdb is probably the simplest thing to do. -- John Baldwin