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.