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

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sun, 26 Aug 2018 16:04:35 +0300
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.
Received on Sun Aug 26 2018 - 11:04:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC