Segfaulting programs with CONFIG_HIMEM on SMP PowerPC

[Ethan]

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