Greetings,
I've noticed recently that kernels >=2.4.18 on my SMP G4 began to say
this at boottime:
Apr 13 15:03:20 spicymeatball kernel: Memory BAT mapping: BAT2=256Mb,
BAT3=256Mb, residual: 256Mb
Apr 13 15:03:20 spicymeatball kernel: Warning, memory limited to 512 Mb,
use CONFIG_HIGHMEM to reach 512 Mb
Apr 13 15:03:20 spicymeatball kernel: Total memory = 512MB; using 2048kB
for hash table (at c0400000)
This machine has 768M, so I happily checked CONFIG_HIMEM (although I
thought CONFIG_HIMEM was for systems with >2G but I suppose that only
applies on x86), recompiled, and got the full 768M.
Memory BAT mapping: BAT2=256Mb, BAT3=256Mb, residual: 256Mb
Total memory = 768MB; using 2048kB for hash table (at c0400000)
Linux version 2.4.18 (root@spicymeatball) (gcc version 2.95.3 19991030
(prerelease/franzo/20001125)) #2 SMP Sat Apr 13 15:06:45 EDT 2002
A few hours later, I fired up dig to do a query.. it subsequently dumped
a core..
I was a little suprised by this.. so I ran it again.. no crash this
time. Looking around the system, I found a few more core files.. one
from bash here, another from sshd there.. it began to get a little
unnerving.. they all weren't signal 11's either.. Some were SIGILL, some
were SIGTRAP, etc. odd. So, after deleting the various cores.. I
rebooted to the non config_himem kernel and tried to get these utilities
to crash.. no dice.. everything was hunky-dory (except that I only had
512M..) How should I proceed here? So far I've gone back to a
bitkeeper pull of 2.4.18-pre1, which doesn't ask me to use CONFIG_HIMEM,
detects all of my memory and seems rock-solid. Newer kernels that want
CONFIG_HIMEM all behave the same, with seemingly random coredumping
executables.
I'm using glibc-2.2.4, gcc version 2.95.3 19991030
(prerelease/franzo/20001125), BFD 2.11.2
Pleas CC me any replies, as I don't subscribe to the list.
thanks,
Ethan