Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 26 Aug 2018 16:04:35 +0300
Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> > Now, with the patch applied correctly, the machine actually boots.
> > 
> > Before calling init_ops.mp_bootaddress in
> > getmemsize (machdep.c), physmap looks like this:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x30000 0x30
> > 2 0x40000 0x40
> > 3 0x9e400 0x9e
> > 4 0x100000 0x100
> > 5 0xf00000 0xf00
> > 6 0x1000000 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x100000000 0x100000
> > 9 0x100600000 0x100600
> > 10 0x0 0x0
> > 
> > With your patch, it looks like this now
> > (after calling getmemsize)
> > 
> > 0 0x0 0x0
> > 1 0x30000 0x30
> > 2 0x40000 0x40
> > 3 0x9e400 0x9e
> > 4 0x100000 0x100
> > 5 0xf00000 0xf00
> > 6 0x1000000 0x1000
> > 7 0x7bf77000 0x7bf77
> > 8 0x100000000 0x100000
> > 9 0x100600000 0x100600
> > 10 0x0 0x0
> > PAGETABLES is 0x7bf77000
> > 
> > So I guess this means that the gap is now at the last three pages
> > of [0x1000, 0x7bf7a[.
> > 
> > If this is what was intended, I guess it's good, as the machine
> > boots okay now.  
> 
> It triggered the new code to chomp at the end of the suitable range,
> instead of the start. Anyway, to do that, it must evaluated the start
> of the range as intersecting with the kernel text, which I interpret
> as success.
> 
> I put a review with the change at D16907.
> 
> > 
> > Sorry again for the extra roundtrip, the patched file was simply in
> > the wrong path.  
> 
> No problem.

Just to close the loop on this: This was fixed in r338858, thanks to
kib@ for analyzing the problem and creating a patch and to jhb@ for
reviewing it.

Yours,
Michael

-- 
Michael Gmelin