cpuburn sometimes uncover memory failures too (especially burnMMX).
But read on, this is most likely not the case for you.
> Graphics Card: Atlantis Sapphire Radeon 9700 Pro
>
> With just one module (same thing with either of them) works ok. As
> soon as I have 2nd module in it crashes at kernel boot (lilo menu
> comes on OK but after selecting kernel it freezes with capslock and
> scrolllock lights on and black screen). Highmem is set to 4G as the
> subject line says. Tried all possible settings as append boot
> parameter (noapic, noacpi, acpi=off, etc) and it worked only when
> vga=ask (I picked 2 values out of them in 2 tests i.e. 0 and 6 and it
> worked ok).
So it works with standard 80x25 text mode? ok...
AFAIK vesa mode 788=0x314 - 800x600 65k colors (5:6:5 r:g:b bits),
am I remembering right?
Did you try other framebuffer modes like 640x480 256 colors?
I suspect they will fail similarly, but worth testing that.
> Put the original settings back in lilo.conf and tried to
> play with the mem setting at boot. Lowest value at which still
> crashes is mem=888M, highest value at which it doesn't crash or give
> any segfault errors is 848M.
This is interesting. Where does your linear framebuffer memory start?
Post dmesg, /proc/iomem. You may do this from mem=848M boot first,
then from crashing one.
I suspect that kernel somehow overlayed RAM and video RAM ;)
> Everything in between these values
> doesn't crash, but gives a huge list of segfaults. It still boots,
> but most modules are down (cannot be loaded due to the huge list of
> segfaults) and is highly unstable.
You can try "mem=exactmap mem=640K@0 mem=nnnM@1M" to make kernel
avoid stomping into video memory.
It's a bug, we'll need to check why does that happen.
> Windows 2000 Pro as second OS with
> dualboot (I know... I know... I hate M$ products but I have to play
> some games which don't work under linux from time to time... :) )
> boots ok and starting a divx encoding with a cache in RAM set to
> 1024MB (to force it use all main RAM and see what happens) still
> didn't crash after 2 hours of encoding, while main unused RAM went
> down to 2.5MB of RAM (didn't go past that, but instead increased the
> swap only).
Let's debug it, and Linux will not crash too.
-- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/