On Thu, 2019-01-17 at 20:34 +0100, Maxime Villard wrote:
> Le 17/01/2019 à 19:50, Michał Górny a écrit :
> > On Thu, 2019-01-17 at 18:51 +0100, Maxime Villard wrote:
> > > Le 17/01/2019 à 18:05, Michał Górny a écrit :
> > > > Hi,
> > > >
> > > > [...]
> > > >
> > > > After a lot of bisecting, and comparing stable 8 branch (which works)
> > > > with trunk, I've came to the conclusion that the commit 'Limit the size
> > > > of the direct map with a 2MB granularity' [2] is actually causing
> > > > the fault. I haven't been able to revert it on top of current trunk;
> > > > however, I've been able to verify that with a later size fix included
> > > > ([3]), the commit preceding it works and this one starts failing.
> > >
> > > Please add some printfs like these right after 'va = efi_getva(pa)':
> > >
> > > printf("pmap_direct_base = %p\n", (void *)pmap_direct_base);
> > > printf("pmap_direct_end = %p\n", (void *)pmap_direct_end);
> > > printf("va = %p\n", (void *)va);
> > > printf("pa = %p\n", (void *)pa);
> >
> > pmap_direct_base = 0xffffd43127800000
> > pmap_direct_end = 0xffffd431f1799000
> > va = 0xffffd431f18d9f18
> > pa = 0xca0d9f18
>
> Obviously, you are outside of the direct map, that's why it crashes.
>
> The reason you're outside is because the max number of segments is 32, therefore
> the kernel truncates your physical memory. Because of the truncation, the efi
> table is not in the kernel phys map. And because the direct map has been sized
> down to chunks of 2MB, the associated VA is not mapped anymore. On NetBSD-8, by
> luck, the direct map 1GB padding covers the table, that's why you don't see a
> crash.
>
> I've increased the max number to 64, so now it should work, please test. I
> guess it is worth a pullup-8, relying on luck is not a particularly good idea.
Thank you a lot. I can confirm that it works now.
--
Best regards,
Michał Górny
Attachment:
signature.asc
Description: This is a digitally signed message part