Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jan 2018 17:36:49 +0000
From:      Dave B <g8kbvdave@googlemail.com>
To:        Valeri Galtsev <galtsev@kicp.uchicago.edu>, freebsd-questions@freebsd.org
Subject:   Re: freebsd-questions Digest, OT: Max system physical memory
Message-ID:  <eb5d205f-88c8-7c68-e856-d4a76e2ff4a6@googlemail.com>
In-Reply-To: <b8ad49f4-59ad-e593-a1b6-ae470a2b0dee@kicp.uchicago.edu>
References:  <mailman.112.1515672002.77530.freebsd-questions@freebsd.org> <0bce5e82-97ba-0a73-e261-c91473837737@googlemail.com> <b8ad49f4-59ad-e593-a1b6-ae470a2b0dee@kicp.uchicago.edu>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Memtest86 is anything but un-stressfull!

It runs a multitude of tests, designed to increase the noise level on
the memory cell sense lines by way of specific address and data
patterns.  DRAM is not unlike older memory technology in that respect,
regarding noise on sense lines due to particular data/address patterns.

Yes, an OS can stress the RAM, but so can this.   That's why it can take
an age to complete one full pass.

I have in the past found it to be the only tool to find single bit
errors in several GByte of RAM.   On one (infamous) occasion, a user
complained that one OS update wouldn’t "take", the system (you know the
one) just tried and tried again over and over.    Other than that, the
"system" as a whole was working just fine.  (The use was music and video
editing, so not exactly a low stress environment!)

When they were able to release the machine to me, after cleaning out all
the coolers etc, I ran Memtest86, and eventually, in the last few % of
the last test, some hours after starting, it flagged a single bit
error.   1 Bit, in over 4G bytes of memory!

If you doubt the stress it puts a system under, just monitor the cooling
exhaust temperatures, and power consumption when tests are running!

Long story short, after identifying which of the 8 memory cards was the
buggy one (by selective removal-relocation and retest etc, several days
later...)  A new part was sourced, installed and tested successfully,
all OK.

The very next full OS boot, the problematic security update ran and
stuck just fine, followed by several others that must have been waiting
for a dependency to be satisfied..

Just to be sure, I swapped that suspect card into another similar
system, that booted and ran OK, but again Memtest86 eventually found a
single bit error, right at the end of the last test.   The memory card
went for recycling along with a load of other WEEE junk.

I'm sure it could happen, but in over 30 years in total that I've been
working on this sort of hardware, professionally and at home, I've yet
to find any OS fail due to RAM errors, that a "Proper" memory diagnostic
tool could not find the cause..

Memtest86 might not be the be all and end all of all RAM tests, and of
course its x86 specific, but it's pretty damn close.   For the price
though, it can't be beaten.  I've seen it find and identify problems
that paid for diagnostics just ignore.  Often allowing me to repair
systems that were declared BER by other (so called) professional data
system engineers.

The downside, is the time it all takes, and of course, time == money.

Regards to All.

Dave B.

>><<

On 11/01/18 15:57, Valeri Galtsev wrote:
>
>
> On 01/11/18 06:14, Dave B via freebsd-questions wrote:
>> That I suspect depends on how many physical address lines are available
>> for it via the memory management system.
>>
>> If the PC documentation says 8G is the max', then that is probably all
>> that'll be seen by the CPU, even if there is 16G installed.
>>
>> There is only one way to find out for sure, at your expense.
>>
>> Personally, I doubt it, and the info at
>> https://support.hp.com/gb-en/document/c03363664  says it wont.
>>
>> If it does see 16G (or more) best park it in a corner and thrash it with
>> a Live Boot Memtest86 CD for some days, to ensure it's working
>> correctly.   (Let it run to full completion, it can take hours for a
>> full test, even for 4G!)
>
> In addition to memtest86 I would also run much more stressful test,
> namely have the machine booted into system, run multiple CPU and RAM
> hungry stuff (make buildworld comes to my mind). The reason for that
> would be: with signals on memory bus marginally out of specs, system
> stress will help them being pushed to the limit, which "unstressful"
> memtest86 will not do and may pass, though the failure on stressed
> system still may happen.
>
> Just my $0.02
>
> Valeri
>
>>
>> But even that, doesn’t fully exercise the memory management system in
>> the same way an OS will.
>>
>> Chances are, if it works at all with the large memory modules, it'll
>> only "See" and be able to use 8G.
>>
>> Have Fun.
>>
>> Dave B.
>>
>>
>>
>> On 11/01/18 12:00, freebsd-questions-request@freebsd.org wrote:
>>> Subject:
>>> OT: Max system physical memory
>>> From:
>>> Aryeh Friedman <aryeh.friedman@gmail.com>
>>> Date:
>>> 10/01/18 14:59
>>>
>>> To:
>>> FreeBSD Mailing List <freebsd-questions@freebsd.org>
>>>
>>>
>>> My computer (HP Pavilion P7-1234, FreeBSD 11.1-RELEASE [amd64]) has
>>> 2 240
>>> pin DIMM (DDR3, PC3-10600) the manual says the max memory is 8 GB
>>> but I see
>>> some 16 GB packages (2x8GB).   If I put one or two of these in will
>>> it see
>>> the extra memory?
>>
>> _______________________________________________
>> freebsd-questions@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to
>> "freebsd-questions-unsubscribe@freebsd.org"
>>
>




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?eb5d205f-88c8-7c68-e856-d4a76e2ff4a6>