In message <14329.4421.847994.918399@trooper.velocet.net>, David
Gilbert writes
:
> In reference to the two crash dumps I've posted, the most interesting
> thing about them is that a non-debug kernel seems to be stable on the
> box. I can't really explain why, but we tried all kinds of things ---
> changing hardware... even exchanging whole guts of machines and those
> two examples of crashes persisted.
>
> Then in a fit of despairation, I recompiled the kernel w/o debug
> symbols and so far (touch wood) the machine has been stable.
>
> Now... the machine has 256M of memory ... so I wouldn't expect that
> kernel size *should* be an issue, but something is not right here.
It sure sounds like memory. I can we assume you tried completely
different memory chips? Even then that's no guarantee. Also try
increasing the memory refresh rate. I had a panic with FreeBSD 2.0.5
was solved by increasing the refresh rate. If that doesn't help try
reducing the memory. Some systems cannot refresh memory fast enough to
be stable under certain memory access patterns.
The quality of memory for PC's has always been scatological, however
now that most memory is non-parity, you don't even get notified of
single bit errors. It may even be worth it to purchase some ECC
memory. IIRC ECC uses the Reed-Solomon algorithm (same as used by NASA
for deep space probes), to detect and correct memory errors, so the
rate of detection and correction of an error burst of 16 bits should
should approach 99.99999%.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message