On 12/02/14 12:09 AM, Marc Shapiro wrote:
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.On 02/11/2014 06:45 AM, Dave Woyciesjes wrote: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.On 02/11/2014 08:46 AM, Gary Dale wrote: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.On 11/02/14 03:18 AM, Joel Rees wrote:On Tue, Feb 11, 2014 at 3:35 PM, Joel Rees <joel.rees@gmail.com> wrote: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.On Tue, Feb 11, 2014 at 1:58 PM, Gary Dale <garydale@torfree.net> wrote:Not quite what I was trying to suggest. I was oversimplifying significantly.[...] Your suggestion that it is the 8G + 1x4G which is being recognizedAnd, 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.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.Marc