Hello.
> > What and how should I test next?
> > Do I just unplug one of the processors?
>
> Well if you have multiple, that might be an idea. You could remove half
> the ram and half the cpus.
>
[I have 2 processors, and 4 RAM sticks.]
> > Is there some other diagnostics tool which I can run?
>
> Well gcc compiling kernels is amazingly good at finding unstable
> hardware due to the high cpu/memory/io load it puts on the system.
>
> Doing a make clean and starting a new compile after any change to the
> hardware and see if it makes it all the way through. If it does, you
> may have removed the problem hardware. Try swapping around hardware
> until you find out either which cpu or which stick of memory is causing
> problems, and if you are lucky, it isn't the mainboard.
Fortunately, I had the kernel from the install still around.
Under that (UP) kernel, I could compile a new SMP kernel (2.6.13.2).
Booting with that new kernel, I then tried to compile the same exact
kernel, which crashed the system (with "CONCURRENCY_LEVEL" set to 3,
as well as without). [Not even segfault, just frozen: No trace left
in "kern.log".]
Rebooting, passing the "maxcpus=1" kernel parameter, and new compilation
trial; this time it was completed!
Am I right in concluding that the second CPU is the culprit?
Best regards.
Gilles
P.S. Rebooting a dozen times I noticed, from the infos displayed during
the boot process, that some filesystem was "NOT clean" (even after
a clean shutdown). But the text is zooming past too rapidly to read
which filesystem it is. And those lines don't show up in "dmesg".
Is there a way to get at this information afterwards?