[SOLVED] Re: more than 12G of RAM
On 12/02/14 12:54 PM, Dan Purgert wrote: On 12/02/2014 11:26, Gary Dale wrote: On 12/02/14 07:40 AM, Roberto Scattini wrote: On Wed, Feb 12, 2014 at 2:25 AM, Gary Dale garyd...@torfree.net mailto:garyd...@torfree.net 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. gary, you should check stan's suggestion and update your BIOS to latest version... It already is the latest version. I've reported the problem to Gigabyte. Hopefully they will have a fix but I suspect they will decide the bug in their BIOS is an unsupported configuration. Totally off the wall - but did you try grabbing the chipset drivers from AMD? Granted, it's been ages since I can recall a generic not working ... but doesn't mean it's not possible. Gigabyte insists that it supports the configuration and doesn't seem to want do more than check that the BIOS sees the memory. However, after further experimenting, I found a configuration that worked. The 2x4G modules have to be in the first interleaved channel (DDR3_1 DDR3_2) with the 8G stick in DDR3_4. All other configurations seem to fail. -- 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/5308c59b.9030...@torfree.net
Re: more than 12G of RAM
On Wed, Feb 12, 2014 at 2:25 AM, Gary Dale garyd...@torfree.net 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. gary, you should check stan's suggestion and update your BIOS to latest version... -- Roberto Scattini
Re: more than 12G of RAM
On 12/02/14 07:40 AM, Roberto Scattini wrote: On Wed, Feb 12, 2014 at 2:25 AM, Gary Dale garyd...@torfree.net mailto:garyd...@torfree.net 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. gary, you should check stan's suggestion and update your BIOS to latest version... It already is the latest version. I've reported the problem to Gigabyte. Hopefully they will have a fix but I suspect they will decide the bug in their BIOS is an unsupported configuration. -- 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/52fba0cd.2040...@torfree.net
Re: more than 12G of RAM
On 12/02/2014 11:26, Gary Dale wrote: On 12/02/14 07:40 AM, Roberto Scattini wrote: On Wed, Feb 12, 2014 at 2:25 AM, Gary Dale garyd...@torfree.net mailto:garyd...@torfree.net 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. gary, you should check stan's suggestion and update your BIOS to latest version... It already is the latest version. I've reported the problem to Gigabyte. Hopefully they will have a fix but I suspect they will decide the bug in their BIOS is an unsupported configuration. Totally off the wall - but did you try grabbing the chipset drivers from AMD? Granted, it's been ages since I can recall a generic not working ... but doesn't mean it's not possible. -- 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/52fbb551.4010...@djph.net
Re: more than 12G of RAM
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. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iMvge5R2zw=zo0-0pog19bfyjyg5tweaybhf_lu+se...@mail.gmail.com
Re: more than 12G of RAM
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. -- 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/52fa29c2.20...@torfree.net
Re: more than 12G of RAM
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. -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 Computers have lots of memory but no imagination. The problem with troubleshooting is that trouble shoots back. - from some guy on the internet. -- 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/52fa377b.4020...@sbcglobal.net
Re: more than 12G of RAM
On 2/11/2014 9: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. One other possibility I don't know if anyone has considered (but this test might help show). I was assuming (like I think others were) that one of the 4G modules wasn't being used. But what if only 1/2 of the 8G module is being used instead? Jerry -- 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/52fa3ba6.3000...@attglobal.net
Re: more than 12G of RAM
On 02/11/2014 10:03 AM, Jerry Stuckle wrote: On 2/11/2014 9: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. One other possibility I don't know if anyone has considered (but this test might help show). I was assuming (like I think others were) that one of the 4G modules wasn't being used. But what if only 1/2 of the 8G module is being used instead? Jerry That's along the lines of my thinking... Maybe memtest would show some small errors one one of the 4GB modules. It's not unreasonable to think that an error on one of the 4GB modules could cause the thrashing; and make the OS not see 4GB. I'm not a hardware engineer, but could part of the memory mapping be blocked by a bad location on another module? -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 Computers have lots of memory but no imagination. The problem with troubleshooting is that trouble shoots back. - from some guy on the internet. -- 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/52fa3e2a.6090...@sbcglobal.net
Re: more than 12G of RAM
On 2/11/2014 10:13 AM, Dave Woyciesjes wrote: On 02/11/2014 10:03 AM, Jerry Stuckle wrote: On 2/11/2014 9: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. One other possibility I don't know if anyone has considered (but this test might help show). I was assuming (like I think others were) that one of the 4G modules wasn't being used. But what if only 1/2 of the 8G module is being used instead? Jerry That's along the lines of my thinking... Maybe memtest would show some small errors one one of the 4GB modules. It's not unreasonable to think that an error on one of the 4GB modules could cause the thrashing; and make the OS not see 4GB. I'm not a hardware engineer, but could part of the memory mapping be blocked by a bad location on another module? It's possible. For instance, if one module incorrectly responds to an address, you could have two modules trying to respond to the same address. This could cause all kinds of problems in memory. But I was thinking of possibly the 8G module not responding properly to one or more addresses in the 0-4G or 4-8G range. In this case it could have been disabled by the system. I don't know the internals of Linux memory handling that well, though, so I don't know what would happen. Jerry -- 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/52fa5464.60...@attglobal.net
Re: more than 12G of RAM
On 2/10/2014 10:40 PM, Stan Hoeppner wrote: ... 1. Contact Gigabyte support 2. Buy another identical 8GB DIMM, or exchange this one for two 4s Should have mentioned this sooner. Gary have you flashed the BIOS to the latest rev? As I stated previously, if POST reports 16GB but the e820 map presented to the kernel shows 12GB, this is a BIOS issue. A later BIOS rev may have addressed this, specifically F5. There have been 3 versions for this board, F3/F4/F5. http://www.gigabyte.us/products/product-page.aspx?pid=4642#bios The description for F5: Modified voltage option of NB DRAM compatibility Release date: 08/06/2013 F3 was released in May, F4 in July, F5 in August. The rapid succession of releases, and none since, leads me to believe that most boards probably hit the shelves with the F3 BIOS, and most/all issues were resolved with F5, after most/all board left the factory. If you haven't already, flash the BIOS to F5. -- Stan -- 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/52fab958.3000...@hardwarefreak.com
Re: more than 12G of RAM
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
Re: more than 12G of RAM
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
Re: more than 12G of RAM
On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 Computers have lots of memory but no imagination. The problem with troubleshooting is that trouble shoots back. - from some guy on the internet. -- 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/52f8fd39.3000...@sbcglobal.net
Re: more than 12G of RAM
On 10/02/14 11:24 AM, Dave Woyciesjes wrote: On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. -- 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/52f93335.9010...@torfree.net
Re: more than 12G of RAM
On 02/10/2014 03:14 PM, Gary Dale wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. In your BIOS, have you tried disabling rank and/or channel interleaving? Did Memtest report any error? Try running memtest with only 1 module installed at a time. I'm wondering if one of your memeory modules has gone south. -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 Computers have lots of memory but no imagination. The problem with troubleshooting is that trouble shoots back. - from some guy on the internet. -- 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/52f93713.1050...@sbcglobal.net
Re: more than 12G of RAM
On 2/10/2014 2:14 PM, Gary Dale wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. Apparently you (and everyone else) missed my last post wherein I explained what the problem is here. Here is the explanation a 2nd time: POST displays a message on the screen that 16GB is present. But that subroutine is separate from the BIOS code that generates the e820 memory map that is presented to the kernel, which can be found at the start of your dmesg log, e.g. BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - bddde000 (usable) BIOS-e820: bddde000 - bde0e000 (ACPI data) BIOS-e820: bde0e000 - d000 (reserved) BIOS-e820: fec0 - fee1 (reserved) BIOS-e820: ff80 - 0001 (reserved) BIOS-e820: 0001 - 00083efff000 (usable) POST says one thing, the e820 map another. Which is why neither Debian nor memtest (which uses the Linux kernel) can find the other 4GB. The memory map being presented to Linux is wrong. If the board does not present the correct e820 map in non-interleaved mode witn mismatched stick sizes, then I guess you could call this a BIOS bug. It is possible to work around this by manually creating a proper map. This can be done using kernel command line options. However, for a non kernel hacker this job will require far more time, research, heartache, etc, than the cost of simply swapping modules to allow the board BIOS to work. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: more than 12G of RAM
On Tue, Feb 11, 2014 at 5:14 AM, Gary Dale garyd...@torfree.net wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: [...] Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. I think I agree with Stan. You probably don't want to understand. Digging into the specifics for your motherboard requires a lot of what some people think is the technical equivalent of dowsing. (Using a divining rod, so to speak.) Mind you, I'm only focusing on one of the strange things that go on inside RAM circuits, and I'm way over-simplifying. And the example is a bit dated, although I think it's still relevant. But, if you do, maybe I can point you in the right direction. If you grab stuff from memory 64 bits at a time, your memory should be twice as fast as 32 bits at a time. Right? But if the memory itself is only 32-bits wide, you need two banks. But if the timing for one bank doesn't match the timing for the other, you either have to give up, or you have to slow down a bit. Now, what you have is a pair of matched (hopefully) 4G sticks, and, if I understand your situation right, a single 8G stick with an empty slot where the matched pair would be. Back in the day, the controller would have given up. These days, the controller is smarter. But BIOS knows your motherboard's layout and how to tell the controller it can grab 64 bits at a time from the matched pair and 32 from the lonely guy. The manufacturer didn't budget the engineering expense to tell the Linux community how to make their controller do cute dog tricks, so, without special help from you, Linux gives about half-way through. If I were to guess, I'd guess it's just configuring the whole of memory 32 bits wide, so it's just not seeing one of the 4G sticks at all. (It might seem convenient if the controller would re-map the matched pair so that one is addressed 4G above the other and both can be grabbed 32 bits at a time, separately, but you have to understand that there are limits to what engineers can squeeze into a specific piece of silicon. Or that may be one of the cute dog tricks that the community doesn't have access to, in which case, you might be able, with a lot of trial-and-error, to divine the configurations that would get it to run. But you should take a good look at the path up the mountain, because it sounds like you've never been there before, and there are tricky crossings up there. Metaphorically speaking. I'm not sure how robust today's motherboards are, but back in the day, it would have been easy to toast a motherboard while you were searching for the right timings.) -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iO5tDryX6L2NjpbkdxQh17NQfmaogm4JSr=awn8ogr...@mail.gmail.com
Re: more than 12G of RAM
On 2/10/2014 4:28 PM, Gary Dale wrote: On 10/02/14 03:48 PM, Stan Hoeppner wrote: On 2/10/2014 2:14 PM, Gary Dale wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dalegaryd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. Apparently you (and everyone else) missed my last post wherein I explained what the problem is here. Here is the explanation a 2nd time: POST displays a message on the screen that 16GB is present. But that subroutine is separate from the BIOS code that generates the e820 memory map that is presented to the kernel, which can be found at the start of your dmesg log, e.g. BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - bddde000 (usable) BIOS-e820: bddde000 - bde0e000 (ACPI data) BIOS-e820: bde0e000 - d000 (reserved) BIOS-e820: fec0 - fee1 (reserved) BIOS-e820: ff80 - 0001 (reserved) BIOS-e820: 0001 - 00083efff000 (usable) POST says one thing, the e820 map another. Which is why neither Debian nor memtest (which uses the Linux kernel) can find the other 4GB. The memory map being presented to Linux is wrong. If the board does not present the correct e820 map in non-interleaved mode witn mismatched stick sizes, then I guess you could call this a BIOS bug. It is possible to work around this by manually creating a proper map. This can be done using kernel command line options. However, for a non kernel hacker this job will require far more time, research, heartache, etc, than the cost of simply swapping modules to allow the board BIOS to work. Here's what I get in dmesg re.
Re: more than 12G of RAM
On 10/02/14 10:00 PM, Joel Rees wrote: On Tue, Feb 11, 2014 at 5:14 AM, Gary Dale garyd...@torfree.net wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: [...] Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. I think I agree with Stan. You probably don't want to understand. Digging into the specifics for your motherboard requires a lot of what some people think is the technical equivalent of dowsing. (Using a divining rod, so to speak.) Mind you, I'm only focusing on one of the strange things that go on inside RAM circuits, and I'm way over-simplifying. And the example is a bit dated, although I think it's still relevant. But, if you do, maybe I can point you in the right direction. If you grab stuff from memory 64 bits at a time, your memory should be twice as fast as 32 bits at a time. Right? But if the memory itself is only 32-bits wide, you need two banks. But if the timing for one bank doesn't match the timing for the other, you either have to give up, or you have to slow down a bit. Now, what you have is a pair of matched (hopefully) 4G sticks, and, if I understand your situation right, a single 8G stick with an empty slot where the matched pair would be. Back in the day, the controller would have given up. These days, the controller is smarter. But BIOS knows your motherboard's layout and how to tell the controller it can grab 64 bits at a time from the matched pair and 32 from the lonely guy. The manufacturer didn't budget the engineering expense to tell the Linux community how to make their controller do cute dog tricks, so, without special help from you, Linux gives about half-way through. If I were to guess, I'd guess it's just configuring the whole of memory 32 bits wide, so it's just not seeing one of the 4G sticks at all. (It might seem convenient if the controller would re-map the matched pair so that one is addressed 4G above the other and both can be grabbed 32 bits at a time, separately, but you have to understand that there are limits to what engineers can squeeze into a specific piece of silicon. Or that may be one of the cute dog tricks that the community doesn't have access to, in which case, you might be able, with a lot of trial-and-error, to divine the configurations that would get it to run. But you should take a good look at the path up the mountain, because it sounds like you've never been there before, and there are tricky crossings up there. Metaphorically speaking. I'm not sure how robust today's motherboards are, but back in the day, it would have been easy to toast a motherboard while you were searching for the right timings.) Sorry, but it still makes very little sense. When I turn off interleaving, the BIOS should try to access all the memory 32bits at a time. This would, one should expect, allow the memory to be accessed in full. Your suggestion that it is the 8G + 1x4G which is being recognized leads to an interesting idea - putting the 8G in the same channel as one 4G stick may allow the full memory to be recognized, if only at 32bit speed. I'll have to try it, but I'm not hopeful. If it was the case, why would it lose an entire memory stick? I suspect that nothing about this makes sense and that the BIOS programmers just assumed that an even number of slots would be occupied if you had more than one stick and messed up the 3-stick case. The kernel relies on the BIOS, as Stan Hoeppner reports, and so Linux fails to recognize all the RAM. -- 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/52f9adf1.2000...@torfree.net
Re: more than 12G of RAM
On 10/02/14 11:40 PM, Stan Hoeppner wrote: On 2/10/2014 4:28 PM, Gary Dale wrote: On 10/02/14 03:48 PM, Stan Hoeppner wrote: On 2/10/2014 2:14 PM, Gary Dale wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: On 02/09/2014 10:14 AM, Jerry Stuckle wrote: On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dalegaryd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. Apparently you (and everyone else) missed my last post wherein I explained what the problem is here. Here is the explanation a 2nd time: POST displays a message on the screen that 16GB is present. But that subroutine is separate from the BIOS code that generates the e820 memory map that is presented to the kernel, which can be found at the start of your dmesg log, e.g. BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - bddde000 (usable) BIOS-e820: bddde000 - bde0e000 (ACPI data) BIOS-e820: bde0e000 - d000 (reserved) BIOS-e820: fec0 - fee1 (reserved) BIOS-e820: ff80 - 0001 (reserved) BIOS-e820: 0001 - 00083efff000 (usable) POST says one thing, the e820 map another. Which is why neither Debian nor memtest (which uses the Linux kernel) can find the other 4GB. The memory map being presented to Linux is wrong. If the board does not present the correct e820 map in non-interleaved mode witn mismatched stick sizes, then I guess you could call this a BIOS bug. It is possible to work around this by manually creating a proper map. This can be done using kernel command line options. However, for a non kernel hacker this job will require far more time, research, heartache, etc, than the cost of simply swapping modules to allow the board BIOS to work. Here's what I get in dmesg re. e820: [0.459286] e820:
Re: more than 12G of RAM
On 02/10/2014 11:58 PM, Gary Dale wrote: On 10/02/14 10:00 PM, Joel Rees wrote: On Tue, Feb 11, 2014 at 5:14 AM, Gary Dale garyd...@torfree.net wrote: On 10/02/14 11:24 AM, Dave Woyciesjes wrote: [...] Have you run memtest yet? Yes. After the other comments, I gave it a try. It also only sees 12G. I find this confusing in that the board apparently works with a mixture of interleaved and non-interleaved memory - as witnessed by the fact that I'm running that way. Why should it see the non-interleaved module as only 4G instead of 8G? The board has 4 sockets and according to the specifications supports up to 32G of memory, which means it should support 8G modules. I could understand the problem if it only supported 4G modules, then it might only see part of the extra memory. I could understand it also if the configuration simply didn't work and only showed me 8G total. 12G I don't understand. I think I agree with Stan. You probably don't want to understand. Digging into the specifics for your motherboard requires a lot of what some people think is the technical equivalent of dowsing. (Using a divining rod, so to speak.) Mind you, I'm only focusing on one of the strange things that go on inside RAM circuits, and I'm way over-simplifying. And the example is a bit dated, although I think it's still relevant. But, if you do, maybe I can point you in the right direction. If you grab stuff from memory 64 bits at a time, your memory should be twice as fast as 32 bits at a time. Right? But if the memory itself is only 32-bits wide, you need two banks. But if the timing for one bank doesn't match the timing for the other, you either have to give up, or you have to slow down a bit. Now, what you have is a pair of matched (hopefully) 4G sticks, and, if I understand your situation right, a single 8G stick with an empty slot where the matched pair would be. Back in the day, the controller would have given up. These days, the controller is smarter. But BIOS knows your motherboard's layout and how to tell the controller it can grab 64 bits at a time from the matched pair and 32 from the lonely guy. The manufacturer didn't budget the engineering expense to tell the Linux community how to make their controller do cute dog tricks, so, without special help from you, Linux gives about half-way through. If I were to guess, I'd guess it's just configuring the whole of memory 32 bits wide, so it's just not seeing one of the 4G sticks at all. (It might seem convenient if the controller would re-map the matched pair so that one is addressed 4G above the other and both can be grabbed 32 bits at a time, separately, but you have to understand that there are limits to what engineers can squeeze into a specific piece of silicon. Or that may be one of the cute dog tricks that the community doesn't have access to, in which case, you might be able, with a lot of trial-and-error, to divine the configurations that would get it to run. But you should take a good look at the path up the mountain, because it sounds like you've never been there before, and there are tricky crossings up there. Metaphorically speaking. I'm not sure how robust today's motherboards are, but back in the day, it would have been easy to toast a motherboard while you were searching for the right timings.) Sorry, but it still makes very little sense. When I turn off interleaving, the BIOS should try to access all the memory 32bits at a time. This would, one should expect, allow the memory to be accessed in full. Your suggestion that it is the 8G + 1x4G which is being recognized leads to an interesting idea - putting the 8G in the same channel as one 4G stick may allow the full memory to be recognized, if only at 32bit speed. I'll have to try it, but I'm not hopeful. If it was the case, why would it lose an entire memory stick? I suspect that nothing about this makes sense and that the BIOS programmers just assumed that an even number of slots would be occupied if you had more than one stick and messed up the 3-stick case. The kernel relies on the BIOS, as Stan Hoeppner reports, and so Linux fails to recognize all the RAM. I wonder what Windows would make of this--if you're dual booting. I don't know if that would help solve anything, but it might give somebody a clue. Here's how: http://www.wikihow.com/Check-Computer-RAM --doug -- Blessed are the peacemakers...for they shall be shot at from both sides. --A. M. Greeley -- 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/52f9b1b6.9030...@optonline.net
Re: more than 12G of RAM
On Tue, Feb 11, 2014 at 1:58 PM, Gary Dale garyd...@torfree.net wrote: [...] Sorry, but it still makes very little sense. When I turn off interleaving, the BIOS should try to access all the memory 32bits at a time. This would, one should expect, allow the memory to be accessed in full. Okay, you understand more than I was giving you credit for. Sorry about that. However, Your suggestion that it is the 8G + 1x4G which is being recognized Not quite what I was trying to suggest. I was oversimplifying significantly. leads to an interesting idea - putting the 8G in the same channel as one 4G stick may allow the full memory to be recognized, if only at 32bit speed. Uh, no. Don't do that. I don't know the odds, but it could well result in permanent regrets. I'll have to try it, but I'm not hopeful. If it was the case, why would it lose an entire memory stick? Well, the point I was trying to make is that the circuitry that is sensing and remapping your RAM is pretty complicated. If you have designed memory selection and refreshing circuits in the past, I could point to certain issues like race and current drain and isolation. One map is not so hard, but the RAM slots are supposed to take a variety of sizes and timing, and all of those have to be correctly decoded and refreshed. Even though the sale where you bought the 8G stick is over, I'm thinking I'd see if I couldn't order one of the same type directly from the manufacturer. Unless the manual says 2 and 1 should work, in which case I'd still try to get a mate for that 8. You said elsewhere that the compatibility table didn't list 8G, so what I'm saying is you basically you take what you get. You are outside the specs, so nothing should be surprising. I suspect that nothing about this makes sense and that the BIOS programmers just assumed that an even number of slots would be occupied if you had more than one stick and messed up the 3-stick case. Does your motherboard manual say it'll take a pair-and-single configuration? Put bluntly, I'm not only surprised it doesn't fail POST with 2x4+8, but I would hesitate to run it that way for extended periods of time, unless your manual says it's supposed to handle such a configuration. The kernel relies on the BIOS, as Stan Hoeppner reports, and so Linux fails to recognize all the RAM. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/caar43ipopmayswgutajphkbihpxsj-kmuga52xe3wrvwnvv...@mail.gmail.com
Re: more than 12G of RAM
On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. signature.asc Description: PGP signature
Re: more than 12G of RAM
On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. -- Stan -- 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/52f76b96.9030...@hardwarefreak.com
Re: more than 12G of RAM
On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. -- 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/52f7822c.8030...@torfree.net
Re: more than 12G of RAM
On 2/9/2014 8:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. That page just tells you how to install dual-channel DDR3 sticks. Again, the BIOS detects the full 16G. This shows that the setup does work with the board. Detected and Working memory are two entirely different things. It is perfectly possible for your BIOS to detect 16GB, but 4GB of it not work properly. Both Stan and Efraim have good comments. I suggest you follow them. Jerry -- 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/52f79b68.3040...@attglobal.net
Re: more than 12G of RAM
On 2/9/2014 7:27 AM, Gary Dale wrote: On 09/02/14 06:50 AM, Stan Hoeppner wrote: On 2/9/2014 3:32 AM, Efraim Flashner wrote: On Sat, 08 Feb 2014 10:20:49 -0500 Gary Dale garyd...@torfree.net wrote: I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? It sounds to me like you have some issues between your two sets of ram, the 8G stick and the 2x4G sticks. Is there a difference in timings/speed/voltage? I've never put much stock in people saying that you shouldn't mix different types of ram if the price is right, but you might need to change around the placement order. Assuming the motherboard supports dual-channel ram, I'd make sure you have the 2x4G sticks paired up and the 8G stick on its own channel. According to page 16 of the manual you have an unsupported memory configuration: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-d3p_e.pdf If this combo will ever work, the first step is to verify the 8GB stick is in one channel and the two 4GB sticks in the other. If you still don't see all 16GB then disable rank interleaving. If that doesn't fix it, disable channel interleaving. If that doesn't fix it, you may be of luck, and will need to either swap the 8GB stick for a pair of matched 4GB sticks, or acquire another identical 8GB stick. The devil is always in the details. That page just tells you how to install dual-channel DDR3 sticks. Again, It tells you exactly how to install the sticks, and that each pair needs to match. the BIOS detects the full 16G. This shows that the setup does work with the board. POST displays a message on the screen that 16GB is present. But that subroutine is separate from the BIOS code that generates the e820 memory map that is presented to the kernel, e.g. BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - bddde000 (usable) BIOS-e820: bddde000 - bde0e000 (ACPI data) BIOS-e820: bde0e000 - d000 (reserved) BIOS-e820: fec0 - fee1 (reserved) BIOS-e820: ff80 - 0001 (reserved) BIOS-e820: 0001 - 00083efff000 (usable) This is exactly what is happening in the OP's case--POST says one thing, e820 another. It is possible to manually create a proper map using kernel command line options so the kernel sees all the memory. However, for a non kernel hacker this job will require far more time, research, etc, than the cost of swapping modules. Thus, if moving the DIMMs around doesn't allow the BIOS to create the proper e820 map, the OP's best option is to buy another matching 8GB stick, or swap it for two matching 4GB sticks. -- Stan -- 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/52f80b81.5020...@hardwarefreak.com
more than 12G of RAM
I'm running Jessie on an AMD64 Gigabyte 970A-D3P board with an FX6100 processor. I had 2x4G DDR3 sticks in it but some of the programs I use were causing excessive thrashing. I added a 1x8G DDR3 stick (got a good price on it, much cheaper than adding 2x4G) which resolved the thrashing problem. The BIOS shows I have 16G but free shows only 12G. I also ran free on a machine with 2x8G DDR3 running Wheezy and it showed 16G when I ran free. This suggests that the kernel is handling 16G (as one would expect) in the general case and the issue is likely due to my setup. Since the BIOS shows the full 16G, the problem doesn't seem to be on the mainboard. Is there an issue with running interleaved and non-interleaved RAM together on the Jessie kernels? -- 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/52f64b51.4000...@torfree.net
