Is 10.3 i386 jinxed ?

[Polytropon]

On Wed, 4 May 2016 12:41:06 +0530, Manish Jain wrote:
> On 05/04/16 10:35, Warren Block wrote:
> > On Wed, 4 May 2016, Manish Jain wrote:
> >
> >> What is printed underneath is NE56R14l-B9502G32Mnks
> >>
> >> I can't be sure whether the l is actually l or I or 1
> >
> > Looks like this one:
> > http://in.gateway.com/gw/en/IN/content/model/NX.Y1USI.005
> >
> > Which does not have a separate GPU, and means that the bad memory 
> > would be in one of the removable DIMMs.
> >
> >
> 
> 
> Something to cheer about, at last. But then why does not memtest86+ pick 
> up any errors in 65 passes ?

As I mentioned earlier, this is a "false-negative" result. The portions
of the RAM dedicated for the GPU are "cut away" quite eary, so memtest
can only test what's left for "normal RAM". And those portions don't seem
to have the error. The "GPU RAM" portions cannot be tested with memtest
because it cannot access them: To the memtest access routine, the situation
is as follows: Let's say there are 4 GB RAM, 1 GB dedicated for GPU, so
for memtest there's 3 GB RAM to check. _Where_ this is located - well,
that depends on how the system BIOS/EFI decides on where to place the
GPU RAM segment ("internal addressing"). Let's assume you have two chips
of 2 GB each, this _could_ be the layout:

	        +--------------------+
	Bank 0: |VVVFVVVVVV          | 2 GB
	        +----------^---------+
	                   RAM address 00000000 here

	        +--------------------+
	Bank 1: |                    | 2 GB
	        +--------------------+

Then memtest will check from 00000000 to the end of the 3 GB RAM, and
the fault (F) is within the GPU RAM (V). It won't be tested.

Maybe you could just swap the modules an re-run the test. However, it's
hard to say _where_ the GPU RAM will end up, maybe at the beginning of
bank 1? Maybe a "random choice"? Or maybe it isn't even one contiguous
memory space?


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...