On 12/02/14 12:09 AM, Marc Shapiro wrote:
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
Sorry everyone, but the memory sticks all work fine. Memtest+ shows 8G
working when I run it against the 2x4G and the 1x8G. My system runs
fine, except for the thrashing, with 8G. It's one application that
causes the thrashing and Free shows the heavy swap use when it's
running. With 12G, the thrashing pretty much stops.
--
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/52fb05e6.2050...@torfree.net
