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.
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
