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_at_ for analyzing the problem and creating a patch and to jhb_at_ for reviewing it. Yours, Michael -- Michael GmelinReceived on Wed Aug 29 2018 - 07:21:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC