Re: [MiNT] FreeMiNT 1.15.1

[Odd Skancke <oskancke@online.no>]

 Hi, everybody.

 After extensively testing the latest kernel, I'm back to 1.15.1 beta 1.1.
I'm using a Hades060, and at first I had some memoryproblems that was
caused by bad simms. But those problems are over and done with now ;-)

 Ok, in my Hades I now have 40Mb RAM, all reported to the system as
ST-RAM. Kernels up to beta 1.1 seems to be working very well with this
configuration. But with the latest kernel, I get loads of problems with
this configuration, where all my 40Mb is seen as ST-ram. At bootup,
everything seems OK. But if I try to compile something with gcc, I get
loads of errors saying that Kmalloc fails (Frank, you have my
debug-stuff). Now, it seems to me that this happends as soon as more
memory than 16Mb is needed by running apps, which indicates that the
kernel somehow can't handle more than 16Mb RAM typed ST-RAM. Maybe it gets
confused by the fact that more RAM is actually there, but none of this RAM
is in the Fastram pool.

 I have no idea how the kernel handles such things, and I don't read C
well enough to understand the sources. But I got the impression that
"kmalloc"-routines handle alternate/TT/Fastram, while other routines
handle the ST-RAM pool. Is this anywhere near the truth? It seems that the
kernel insists that "16Mb ST ram is already used, let's try the TT-ram",
and this always fails. The above might sound like a load of crap to the
developers, but thats how I imagine things up in my head :)

 There is a program called "splitram.prg" for the Hades, that divides the
available memory into 16Mb ST-ram and the rest = TT-ram. Now, if I
understood Bernd correctly, the intent behind this program was mainly to
prevent applications writing to 24-bit I/O addresses (as seen in original
Atari hardware) by splitting (i.e., "disable" the RAM between $E00000 -
$FFFFFF) so that 24-bit addressing apps dont overwrite things that
happends to run/be in that area. I don't like the idea of this being
the "fix" to this problem, as earlier kernels don't have this problem.

 Also, I have seen the symptoms that Mario Becroft describes (using
splitram.prg). And altho I haven't seen all the symptoms that Martin-Eric
Racine is describing, this whole thing leads me to believe that there IS a
serious problem with the latest kernels memory-managing routines.
Since things work better with splitram.prg, but not at all without, it
surely looks like it.

 Summary - Kernel versions up to, including 1.15.1 beta 1.1 does not have
these problems. I have not tested beta 1.2 and 1.3 myself, but I did test
beta 1.4 and, ofcourse, the latest 1.15.1 release, and both of them acts
identically on my Hades.



 Well.. that's all. Until this is fixed, I will stick with beta 1.1.



Odd skancke - ozk@atari.org