[Gllug] Wrong "mem=XXXm" makes kernel *slow*?

[John Winters]

I've just experienced something odd on one of my machines, a 1 GHz
Duron.  It had 512M of RAM in a single DIMM and I added another one to
bring it to 1024M.  It booted up fine but was using only 900M-ish.
"Aha!", I thought, "Time to compile a himem kernel".  So I did that.
Same kernel version (2.6.8) and only the one setting changed.

When it eventually finished compiling it I installed it and re-booted.
The system locked up fairly early in the boot process.  This I've seen
before, where the kernel mis-reads the amount of available RAM from the
BIOS, especially where some RAM is being snatched back for on-board
video.  The BIOS is set to reserve 8M of RAM so I tried booting again
with "mem=950m" and it ran fine.

So - I set out to find the maximum value I could use.  1024m - 8m is
1016m, so I tried that next.  Again, it locked up early in the boot
process.  OK - try a bit more reserved.  Next I tried 1008m.  This
booted, but very slowly.  Lines which normally scroll by at speed
appeared one by one with several seconds between.  There were no error
messages - just a very slow boot.

Reducing the memory further (to 992m - i.e. 32m reserved) got the system
to boot normally.  Now, I can understand why not reserving enough causes
the system to crash, but I can't imagine why it would cause the system
to run very slowly.  Anyone know why?

TIA,
John

(The extra 512M DIMM came from another identical box where it has been
working fine for quite a long time, so I don't think faulty RAM is an
issue.  Besides which, the system did a long kernel compiler (about 3
hours) using the new RAM without a hiccup.)

-- 
John Winters <john at sinodun.org.uk>

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug