Juergen Pfann wrote in part:
>
> In theory, yes. But my personal experience was/is different :
> My BP6 (2xCel.466 not ocl.) used to run VERY stably for months
> (but not more than, say, 15 hours per day - being my private
> "workstation" only).
> That was with 640 MB PC100 (2x256, 1x128), and CAS latency 2.
> After having exchanged the 128 by 256 PC-133, I had to reduce
> to CAS latency 3 - even with 66 MHz bus speed only - ; and
> I still experience occasional (2-3x/week) total crashes with
> instant rebooting (ARRGH !!!) in Linux, NT and FreeBSD.
> I'd swear that's due to a mem timing problem.
It might well be. Instant rebooting is a somewhat unusual
BP6 symptom -- the usual problem is total lockups. The
first thing to do is manually set all slow timings in BIOS.
Or you can try shuffling your SDRAM sticks into different
sockets. It may be that the BIOS only reads _one_ of the
three, and goes by it. If it reads the new PC133 and tries
to apply those timings to the PC100, trouble is likely.
> German magazine "c't" tested various RAM modules this autumn,
> and if I got them right, there's no guarantee that, if your
> PC133 module runs with latency 2 at 133 (mine doesn't - 3 only),
> it will supply a stable, working latency 2 mode at 100 or
I subscribe to c't (in Houston, USA) and this article really
scared me. The brand differences were much larger that I would
hae expected. I wonder how much is sample variation.
> even 66 MHz. That seems to depend how "clean" the SPD EEPROM
> programming is by the manufacturer. The mag. published a
> MSWin-based tool for reading the SPD - but in Linux, the
> "decode-dimms.pl" script coming with the lmsensors package
> will do the same job ;-).
> Unfortunately, I can't read the EEPROM *before* buying a
> module...
Very unfortunate. But you should be able to return/xchg
RAM that isn't up-to-spec. At least in Germany, I thought
customers had some rights. Why else the markup?
> I haven't found APIC errors in my syslogs yet - not even around
> the crashes mentioned above (and I don't use the "noapic" boot
> parameter). These crashes occur even while in my old, but
> maximum customised SuSE 5.1 with UP 2.0.36 kernel - so, I'd
> say, the phenomena I'm talking about here have nothing to do
> with the IO-APIC...
In addition to changing BIOS timings, you might try running a
memory tester like `memtest-86` at least overnight. You might
also try my utilities (burnP6, burnBX and burnMMX). A memory
error might induce the reboot via a triple-CPU-fault.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
