From owner-freebsd-current@freebsd.org Fri Aug 17 12:19:56 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 80B79106BC08 for ; Fri, 17 Aug 2018 12:19:56 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id DAF4379CA7 for ; Fri, 17 Aug 2018 12:19:55 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 29296 invoked by uid 89); 17 Aug 2018 12:19:54 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 17 Aug 2018 12:19:54 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180817101306.GG2340@kib.kiev.ua> Date: Fri, 17 Aug 2018 14:19:52 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: <04B03A28-B894-46A6-B75D-C05B55234245@grem.de> References: <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> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180817101306.GG2340@kib.kiev.ua> To: Konstantin Belousov 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 12:19:56 -0000 > On 17. Aug 2018, at 12:13, Konstantin Belousov wrote= : >=20 >> On Fri, Aug 17, 2018 at 10:02:08AM +0100, John Baldwin wrote: >>> On 8/17/18 9:54 AM, Michael Gmelin wrote: >>>=20 >>>=20 >>>>> On 17. Aug 2018, at 08:17, John Baldwin wrote: >>>>>=20 >>>>> On 8/16/18 1:58 PM, Michael Gmelin wrote: >>>>>=20 >>>>>=20 >>>>>>> On 15. Aug 2018, at 15:55, Konstantin Belousov > wrote: >>>>>>>=20 >>>>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov > wrote: >>>>>>>>>=20 >>>>>>>>> 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 si= milar >>>>>>>>> problem is happening again. Since the fix in r334799 (review >>>>>>>>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touch= ed, >>>>>>>>> so maybe this is related >>>>>>>>> (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D334799= ). >>>>>>>>>=20 >>>>>>>>> Please see the screenshot of the panic below: >>>>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 >>>>>>>>>=20 >>>>>>>>> This is me not digging any deeper, hoping that this is something >>>>>>>>> obvious. Please let me know if you need more input. >>>>>>>>=20 >>>>>>>> I do not see how recent mp_machdep.c changes could affect this. >>>>>>>> Can you try newest kernel but old loader ? >>>>>>>=20 >>>>>>> I will try (but that will take a while). Oh, also, it still boots in= save mode/with smp disabled. >>>>>>=20 >>>>>> Right, this is because the access to that address through DMAP is onl= y >>>>>> needed when configuring AP startup resources. >>>>>>=20 >>>>>> Also, I think it is safe to suggest that the bisect is needed. >>>>>=20 >>>>> Using an older loader didn???t help, but I identified the problem: >>>>>=20 >>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D334952 >>>>>=20 >>>>> modified the code you introduced in >>>>>=20 >>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D334799 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Is there an easy way to output the content of physmap at that point (d= ebug.late_console=3D0 doesn???t work) - like an existing buffer I could use,= or would this be more elaborate (I did something complicated last time but d= idn???t save it, so any simple solution would be preferred). >>>>=20 >>>> 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)?= >>>>=20 >>>=20 >>> This is before the system has a working console (part of calling getmem.= ..), disabling late console makes it hang, physmap changes afterwards, so ru= nning kgdb later doesn???t help. Last time I kept a copy of physmap and logg= ed it later to know the original content. I can do that again, I just though= t maybe there is a simple mechanism I???m not aware of that would save me so= me time. >>=20 >> I thought we only modified phys_avail[], but saving a copy of physmap[] a= nd >> dumping it from kgdb is probably the simplest thing to do. > UP boot works ? >=20 Well, I can boot if I remove atop(...) (reverting the patch). If this is wha= t you mean.