Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 11:47:33 -0700
From:      jd1008 <jd1008@gmail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: why would I get a segmentation fault on one system but not the other?
Message-ID:  <54ECC745.9040303@gmail.com>
In-Reply-To: <20150224024309.GA8251@neutralgood.org>
References:  <20150221224006.GA5501@home.parts-unknown.org> <09da5ec0816e098badc49432c802dc18@sdf.org> <20150222041421.GA36213@home.parts-unknown.org> <20150224024309.GA8251@neutralgood.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 02/23/2015 07:43 PM, kpneal@pobox.com wrote:
> On Sat, Feb 21, 2015 at 08:14:21PM -0800, David Benfell wrote:
>> The system experiencing the segfaults is new--and from a vendor that
>> has previously shipped me a system with bad memory.
>   
>> I haven't stopped the memory test yet. But it has been running for an
>> hour and completed one pass without error. From what I can see on
>> line, that's a pretty good sign.
> Memory testers reporting bad memory means you know you have bad memory.
>
> Memory testers _not_ reporting bad memory tells you nothing.
>
> Don't rely on memory testers to diagnose bad memory. In the past 20 years
> I've seen a number of really weird cases where machines had problems but
> only under certain workloads.
Right.
When running the standalone mem86 tester, the CPU and memory
might not be getting clocked at high clock rates. Sometimes when
the system load gets high and clocking is upped either by the chipset
(I had a system that did that), or by the kernel issuing directives to
the hardware to up the clock, the it is possible for the hardware to
muck up the data read from the RAM (especially when the data
happens to be addresses of user or kernel data).




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54ECC745.9040303>