On 3/12/18 12:04 AM, Mike Rapoport wrote:
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 <schmitzmic@xxxxxxxxx> 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.
Correct.
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.
Ah - I had thought that since the ST-RAM chunk was passed over in
parsing the ramchunk bootinfo data, it was not made known to any parts
of the kernel (beyond the ST-RAM allocator) so no need to treat it
special beyond that.
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
m68k used the discontigmem model, which does require memory chunks are
ordered. Not sure whether that is a requirement of the memory model, or
the MMU setup code for m68k. I had looked into this a few years back and
we would have needed a switch to a different memory model (NUMA?) at
that time, which was a bit too much for my taste.
ST-RAM is quite a bit slower than the other kind, but not as bad as with
Zorro-II RAM on Amiga. The system runs noticeably faster with the kernel
in FastRAM where available (in particular on 68060 accelerator cards),
and the larger FastRAM size means users mostly don't miss a little
ST-RAM. Making that bit available to user space again would be nice, but
it's not a priority for me.
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'll try that (at home, where I have the only ARAnyM installation that
seems to honour the SkipSTRAM or LoadToFastRAM options...)
Cheers,
Michael
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
