On Sat, Dec 01, 2018 at 11:51:52AM +1300, Michael Schmitz wrote:
> Andreas,
>
> Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
> >On Dez 01 2018, Michael Schmitz <schmitz...@gmail.com> wrote:
> >
> >>Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
> >
> >There's way more than the kernel that must fit in 14 MB.
>
> I realize that. I only said to try and load the kernel to ST-RAM, not to
> switch off FastRAM entirely. Anything beyond a very minimal (or old) user
> space won't fit in 14 MB anymore, running out of VM even before swapon can
> run.
>
> The 'skipping memory chunk 0:e00000 before the first chunk' to me means the
> bootstrap has reordered memory chunks so FastRAM comes before ST-RAM. It
> only does that when the kernel was loaded to FastRAM. Shortcomings of the
> old memory model caused the mis-ordered ST-RAM chunk then not to be mapped
> in kernel VM space at all. We still need ST-RAM for video framebuffer and
> DMA-able memory on Falcon, so I provided a dedicated ST-RAM allocator
> (similar to what Geert did for Zorro2-RAM) that will map a pool of ST-RAM
> and use that to satisfy the needs of atafb, atari_scsi and the like.
>
> I had looked over Mike's patches to check that handling of such reserved
> memory hasn't changed, but I have evidently missed something. Since kernels
> with 'normal' ram chunk ordering work fine, the alternate ordering code path
> is my prime suspect.
If I understand correctly, there are two types of RAM on Atari/ARAnyM:
ST-RAM and FastRAM. The ST-RAM resides at the physical range 0x0 - 0xe00000 and
FastRAM takes a range somewhere above.
When the kernel is loaded into the FastRAM, bootloader sets the first entry
in the memory info to the FastRAM and the second one to ST-RAM and thus
m68k_memory becomes something like:
[0] = {
<FastRAM start>, <FastRAM size>,
},
[1] = {
0x0, 0xe00000,
}
In the paging_init() the ST-RAM chunk is essentially removed from the
m68k_memory, but it still can be used via the dedicated ST-RAM allocator.
Yet, my patch surely didn't take such reordering into account, and, more
importantly, I didn't take care of the removal of an entry from
m68k_memory. As the result, memblock sees ST-RAM as available and will
allocated memory from there, but this memory is not yet mapped.
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
would be just inform memblock that the ST-RAM is not available to it:
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf3..0bda2c4 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -233,6 +233,7 @@ void __init paging_init(void)
printk("Ignoring memory chunk at 0x%lx:0x%lx before the
first chunk\n",
m68k_memory[i].addr, m68k_memory[i].size);
printk("Fix your bootloader or use a memfile to make
use of this area!\n");
+ memblock_remove(m68k_memory[i].addr,
m68k_memory[i].size);
m68k_num_memory--;
memmove(m68k_memory + i, m68k_memory + i + 1,
(m68k_num_memory - i) * sizeof(struct
m68k_mem_info));
> I've tried to reproduce the bug by attempting to get the kernel loaded to
> FastRAM. Doesn't work for me - with or without -s option I get the same
> ordering of memory chunks (ST-RAM first) so the kernel clearly still runs in
> ST-RAM.
>
> Hence my question - how did you get the kernel loaded to FastRAM? What
> version of ARAnyM do you use? What's the size of your kernel (uncompressed)?
>
> Cheers,
>
> Michael
>
--
Sincerely yours,
Mike.
