On 02/11/2014 06:45 AM, Dave Woyciesjes wrote:
On 02/11/2014 08:46 AM, Gary Dale wrote:
On 11/02/14 03:18 AM, Joel Rees wrote:
On Tue, Feb 11, 2014 at 3:35 PM, Joel Rees <joel.r...@gmail.com> wrote:
On Tue, Feb 11, 2014 at 1:58 PM, Gary Dale <garyd...@torfree.net>
wrote:
[...]
Your suggestion that it is the 8G + 1x4G which is being recognized
Not quite what I was trying to suggest. I was oversimplifying
significantly.
And, now that I've been out for a walk, to see my wife's mom, it
occurs to me that the more likely scenario is the one that I think
others have implicitly assumed.
That is, that there is enough logic for the controller to *recognize*
the 8G stick, but not enough to fully *decode* it. Particularly, if
your compatibility table doesn't mention 8G, there would be no
surprise if the motherboard were able to see that it's an 8G stick and
decode just half of it. And if that's the case, getting a mate to the
8 you have would leave you able to read the lower half (or maybe the
upper half) of both 8G sticks, so you'd be able to access 16G, but not
24.
And I can think of a particular decoding arrangement where an 8G stick
all by itself could be fully decoded, but when you add more in the
second pair of slots there wouldn't be enough decode circuitry to
fully map both pairs of slots.
Thus the need to use a full set of diagnostics tests if you really
want to see what's happening.
The compatibility table doesn't show any 8G sticks but the manual and
advertising all state the board can handle 32G. This would require
the ability to handle sticks larger than 4G. It is possible that it's
8G that is causing the problem but the manual doesn't mention any
limitation on memory sizes.
Nor does the compatibility table show any 16G sticks. I suspect that
the compatibility table values are just the sticks they tested and
they didn't anticipate people using larger sticks. Anyway, apart from
the size, the 8G stick is the same as smaller sticks that are listed.
Gigabyte web support still isn't working, so I can't get any help
there yet.
This is all very interesting, but I'm still curious as to the
results of running memtest when only one module is installed at a
time. Sure, that's 3 runs which will take time...
In my years, I have seen situations similar to this. You have a
pair installed which look to be working. Odd issues start popping up,
so you reasonably think more RAM will help. You add a third which BIOS
sees all of, yet the OS doesn't. Turns out memtest shows errors on one
of the modules. Replace that and all is well. And yes, your new module
could be faulty.
I'm tending toward possibly faulty RAM, as well. I have a Gigabyte
AMD64 970A-DS3 and I had memory problems when I built this system. I was
installing 2x4G, so I knew that the configuration was acceptable. I had
never had memory problems before and I was beginning to suspect the new
MB. I don't remember the details of how much memory was reported where,
but the end result was that I the memory was apparently not running at
its stated speed. I replaced the sticks and the same thing happened. I
replaced the sticks again, with a different brand. This time everything
worked fine. It would seem that an entire batch of memory sticks from
whatever brand I tried originally (I don't remember what brand it was)
had issues with running at the stated speed. Checking the memory sticks
individually sounds like a good idea, and costs you nothing but some
time. You will then have verified that either the memory sticks ARE the
problem, or they ARE NOT the problem. Either way, you will know for
sure. If they are the problem, you will also know WHICH stick(s) is faulty.
Marc
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fb0209.4070...@gmail.com
