Hi Kars,
On Fri, Feb 24, 2023 at 11:41 AM Kars de Jong <jongk@xxxxxxxxxxxxxx> wrote:
Op do 23 feb. 2023 om 15:05 schreef Kars de Jong <jongk@xxxxxxxxxxxxxx>:
Op do 23 feb. 2023 om 13:39 schreef Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>:
So this has been broken for the last 15 years?
Yes, looks like this commit broke it:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/arch/m68k/mm/motorola.c?id=12d810c1b8c2b913d48e629e2b5c01d105029839,
so slightly longer than 15 years :-).
I found the original thread where I reported this here:
https://marc.info/?t=117175647600006&r=1&w=2, including a version of
this same patch, created by Roman Zippel:
https://marc.info/?l=linux-m68k&m=117184910524555&w=2. This was still
in CVS times.
Apparently I used to work around this issue by subtracting 1 from the
memory size in my boot loader.
;-)
Now I just need to figure out why the last page of memory is excluded.
Do you also see this on other machines?
Zone ranges:
DMA [mem 0x00000000fc000000-0x00000fffffffefff]
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000fc000000-0x00000000ffffefff]
Initmem setup node 0 [mem 0x00000000fc000000-0x00000000ffffefff]
I don't see that on ARAnyM or on qemu-system-m68k, but those
don't have memory at the end of the address space.
ISTR something about not mapping the last page of RAM, if it's at the
end of the address space, to avoid wrap-around while prefetching?
[searching]
I think it's a side-effect of:
static inline phys_addr_t memblock_cap_size(phys_addr_t base,
phys_addr_t *size)
{
return *size = min(*size, PHYS_ADDR_MAX - base);
}
with
#define PHYS_ADDR_MAX (~(phys_addr_t)0)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
