Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Memory errors on new memory in new system
69 views
Skip to first unread message
Marc Shapiro
Nov 28, 2012, 12:30:01 AM11/28/12
to
Last weekend I put together a new box to replace the one that has been locking up repeatedly. The components are:
Gigabyte 970A-DS3 MB
8GB (2x4GB) Patriot G3 RAM
AMD FX-4100 Quad Core CPU
ASUS DVD/CD Writer
MSI R5450 Graphics Card
Seagate 1TB HD
After assembling the box, but before I even installed the HD (from my old machine), I booted up and ran Memtest86+. Memtest said that there were errors, but I finished the install and everything seemed to run properly. Over the next few days, I got Squeeze installed and did most of my configuration with no apparent problems. I ran Memtest86+ again and again it showed memory errors. I noticed that it also reported the memory as being DDR2, not DDR3. I did some Googling and found that there is a newer version of Memtest86+ (v4.2) and its changelog specifically mentions compatibility with the AMD Fusion (FX) CPU's. I downloaded and burned the new version and yesterday I ran that for almost 2 hours (almost 2 full passes) and Memtest86+ reported 1666 errors when I shut it down.
Today, I returned the memory to Fry's and got two new sticks (no problems with the return). I came home, installed the new memory and fired up Memtest86+. It looked clean for a while, then, on test #5 the errors returned. I let it continue to run and after about 50 minutes total wall time I noticed that it was not doing anything. I waited another five minutes, but there was no change in the percent completed of the pass, or test. The test pattern had not changed either. I rebooted the system and let it try again. It stayed clean until test #5 and then spewed out almost 500 errors.
I powered the system down and changed the memory sticks to the other two slots and rebooted.
Again, no error messages until I got to test #5. About halfway through the test I got 40 errors. Not good, but a LOT fewer errors then before. It is still running now and is almost a quarter of the way through test #8 and there have, so far, been no additional errors.
I find it hard to believe that two sets of Patriot memory would both be bad. This is not a No-Name brand. Also, since changing the memory slots used, while not eliminating the errors, seems to have drastically reduced them I am beginning to wonder if the problem is not with the memory, but with the motherboard. Of course, Gigabyte boards are supposed to be good boards, also.
Has anyone else had similar problems? Is Memtest86+ not as reliable as it used to be? Should I be returning the motherboard next, instead of the memory?
Memtest86+ just finished the first pass with no additional errors, just to 40 that it registered in test #5. I will let it run at least through test #5, again, to see how it fairs before I post this message.
BTW, that first pass took significantly less time than in the past. I assume that the errors really slow it down. Is that correct?
I just noticed that this second pass appears to only be testing 4GB of memory, NOT 8GB.
Just finished test five. This time there were 366 new error, putting the total up to 406, so far.
I don't know what else to check, or what hardware is actually bad. Any and all suggestions cheerfully accepted.
Marc
Gigabyte 970A-DS3 MB
8GB (2x4GB) Patriot G3 RAM
AMD FX-4100 Quad Core CPU
ASUS DVD/CD Writer
MSI R5450 Graphics Card
Seagate 1TB HD
After assembling the box, but before I even installed the HD (from my old machine), I booted up and ran Memtest86+. Memtest said that there were errors, but I finished the install and everything seemed to run properly. Over the next few days, I got Squeeze installed and did most of my configuration with no apparent problems. I ran Memtest86+ again and again it showed memory errors. I noticed that it also reported the memory as being DDR2, not DDR3. I did some Googling and found that there is a newer version of Memtest86+ (v4.2) and its changelog specifically mentions compatibility with the AMD Fusion (FX) CPU's. I downloaded and burned the new version and yesterday I ran that for almost 2 hours (almost 2 full passes) and Memtest86+ reported 1666 errors when I shut it down.
Today, I returned the memory to Fry's and got two new sticks (no problems with the return). I came home, installed the new memory and fired up Memtest86+. It looked clean for a while, then, on test #5 the errors returned. I let it continue to run and after about 50 minutes total wall time I noticed that it was not doing anything. I waited another five minutes, but there was no change in the percent completed of the pass, or test. The test pattern had not changed either. I rebooted the system and let it try again. It stayed clean until test #5 and then spewed out almost 500 errors.
I powered the system down and changed the memory sticks to the other two slots and rebooted.
Again, no error messages until I got to test #5. About halfway through the test I got 40 errors. Not good, but a LOT fewer errors then before. It is still running now and is almost a quarter of the way through test #8 and there have, so far, been no additional errors.
I find it hard to believe that two sets of Patriot memory would both be bad. This is not a No-Name brand. Also, since changing the memory slots used, while not eliminating the errors, seems to have drastically reduced them I am beginning to wonder if the problem is not with the memory, but with the motherboard. Of course, Gigabyte boards are supposed to be good boards, also.
Has anyone else had similar problems? Is Memtest86+ not as reliable as it used to be? Should I be returning the motherboard next, instead of the memory?
Memtest86+ just finished the first pass with no additional errors, just to 40 that it registered in test #5. I will let it run at least through test #5, again, to see how it fairs before I post this message.
BTW, that first pass took significantly less time than in the past. I assume that the errors really slow it down. Is that correct?
I just noticed that this second pass appears to only be testing 4GB of memory, NOT 8GB.
Just finished test five. This time there were 366 new error, putting the total up to 406, so far.
I don't know what else to check, or what hardware is actually bad. Any and all suggestions cheerfully accepted.
Marc
Stan Hoeppner
Nov 28, 2012, 2:20:02 AM11/28/12
to
On 11/27/2012 11:29 PM, Marc Shapiro wrote:
> Last weekend I put together a new box to replace the one that has been
> locking up repeatedly. The components are:
>
> Gigabyte 970A-DS3 MB
> 8GB (2x4GB) Patriot G3 RAM
> AMD FX-4100 Quad Core CPU
> ASUS DVD/CD Writer
> MSI R5450 Graphics Card
> Seagate 1TB HD
...
> Last weekend I put together a new box to replace the one that has been
> locking up repeatedly. The components are:
>
> Gigabyte 970A-DS3 MB
> 8GB (2x4GB) Patriot G3 RAM
> AMD FX-4100 Quad Core CPU
> ASUS DVD/CD Writer
> MSI R5450 Graphics Card
> Seagate 1TB HD
> I don't know what else to check, or what hardware is actually bad. Any and
> all suggestions cheerfully accepted.
is SPD "auto" running them at? If they're 1600 modules try running them
at 1333 with appropriate timings and modifying the CPU clock multiplier
accordingly.
Or you may want to try backing the timings off a bit. If your Patriot
modules are DDR3-1333 with 10.5-7-7-7 timings try 12-8-8-8.
I had a Biostar socket a A mobo with the dual channel DDR400 memory
controller in the nVidia Northbridge and two sticks of Geil DDR400 that
routinely threw memory errors until I backed the timings off SPD by 1
clock. Typically these memory errors are caused by a few "marginal"
transistors in some cells that simply won't function correctly at SPD
timings. I won't go as far as saying this is "common" with consumer
DIMMs, but it's far more frequent than with server modules.
BTW, "Patriot" may not be generic but it's not a tier one player like
Crucial, Hynix, Kingston, Micron, Samsung, Wintec, etc. Over the long
haul companies like Patriot, Geil, G.Skill, etc, tend to have higher in
the field defects and failures than the top players. I try to stick
with DIMMs from Crucial and Micron as the entire product from silicon to
final module is manufactured under "one roof". These companies have
been making DRAM chips and modules decades longer than the new kids and
really know the business inside and out. Performance, quality, and QC
are very high, and warranty service excellent. In summary IMHO they
simply have better overall product.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50B5B8A9...@hardwarefreak.com
Ralf Mardorf
Nov 28, 2012, 2:50:01 AM11/28/12
to
My apologize, but I don't have the time to read everything. I read that
you get errors when running Memtest. Do you have issues using the
computer?
Did you run Memtest from different distros (live media)?
I never have issues when using my computer. If I run the same version of
Memtest from a Parted Magic media everything is ok, but if I run it
(again same version!) from Ubuntu Studio Quantal, I get errors. I
experienced it very often that Memtest claims something is broken, when
nothing is broken.
IMO Memtest is bad software. I don't have issues with the RAM, excepted
of new Linux, that can't access all 4GB when using 64-bit kernels,
everything is ok.
If you should experience that a 64-bit kernel is unable to access the
whole memory, test what happens when using a 32-bit PAE and check BIOS
settings.
Resume:
If you don' have issues using your computer, complete RAM or at least
enough RAM should be accessible and you use the computer several hours a
day, don't turn it off for several days, but nothing bad happens, I
wouldn't take care abut Memtest's claims.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354087940.2528.102.camel@q
you get errors when running Memtest. Do you have issues using the
computer?
Did you run Memtest from different distros (live media)?
I never have issues when using my computer. If I run the same version of
Memtest from a Parted Magic media everything is ok, but if I run it
(again same version!) from Ubuntu Studio Quantal, I get errors. I
experienced it very often that Memtest claims something is broken, when
nothing is broken.
IMO Memtest is bad software. I don't have issues with the RAM, excepted
of new Linux, that can't access all 4GB when using 64-bit kernels,
everything is ok.
If you should experience that a 64-bit kernel is unable to access the
whole memory, test what happens when using a 32-bit PAE and check BIOS
settings.
Resume:
If you don' have issues using your computer, complete RAM or at least
enough RAM should be accessible and you use the computer several hours a
day, don't turn it off for several days, but nothing bad happens, I
wouldn't take care abut Memtest's claims.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Nov 28, 2012, 3:00:03 AM11/28/12
to
On Ma, 27 nov 12, 21:29:19, Marc Shapiro wrote:
> Last weekend I put together a new box to replace the one that has been
> locking up repeatedly. The components are:
>
> Gigabyte 970A-DS3 MB
> 8GB (2x4GB) Patriot G3 RAM
> AMD FX-4100 Quad Core CPU
> ASUS DVD/CD Writer
> MSI R5450 Graphics Card
> Seagate 1TB HD
What about your PSU?
> Last weekend I put together a new box to replace the one that has been
> locking up repeatedly. The components are:
>
> Gigabyte 970A-DS3 MB
> 8GB (2x4GB) Patriot G3 RAM
> AMD FX-4100 Quad Core CPU
> ASUS DVD/CD Writer
> MSI R5450 Graphics Card
> Seagate 1TB HD
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Marc Shapiro
Nov 28, 2012, 10:20:02 AM11/28/12
to
On 11/27/2012 11:09 PM, Stan Hoeppner wrote:
> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>> Last weekend I put together a new box to replace the one that has been
>> locking up repeatedly. The components are:
>>
>> Gigabyte 970A-DS3 MB
>> 8GB (2x4GB) Patriot G3 RAM
>> AMD FX-4100 Quad Core CPU
>> ASUS DVD/CD Writer
>> MSI R5450 Graphics Card
>> Seagate 1TB HD
Andre, the PSU is the one that came with the case. Yes, a cheep case
> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>> Last weekend I put together a new box to replace the one that has been
>> locking up repeatedly. The components are:
>>
>> Gigabyte 970A-DS3 MB
>> 8GB (2x4GB) Patriot G3 RAM
>> AMD FX-4100 Quad Core CPU
>> ASUS DVD/CD Writer
>> MSI R5450 Graphics Card
>> Seagate 1TB HD
and PSU combo. The PSU is only 380W.
> ...
>
>> I don't know what else to check, or what hardware is actually bad. Any and
>> all suggestions cheerfully accepted.
> You didn't state the DIMM speed. Are these 1333 or 1600 sticks? What
> is SPD "auto" running them at? If they're 1600 modules try running them
> at 1333 with appropriate timings and modifying the CPU clock multiplier
> accordingly.
The DIMMS are 1600. According to the BIOS the CPU Timing is at 200 and
>
>> I don't know what else to check, or what hardware is actually bad. Any and
>> all suggestions cheerfully accepted.
> You didn't state the DIMM speed. Are these 1333 or 1600 sticks? What
> is SPD "auto" running them at? If they're 1600 modules try running them
> at 1333 with appropriate timings and modifying the CPU clock multiplier
> accordingly.
the memory is at x8.0 which matches the 1600 speed of the memory. How
would I set that to match 1333?
The timings are 4-5-5-15.
> Or you may want to try backing the timings off a bit. If your Patriot
> modules are DDR3-1333 with 10.5-7-7-7 timings try 12-8-8-8.
>
> I had a Biostar socket a A mobo with the dual channel DDR400 memory
> controller in the nVidia Northbridge and two sticks of Geil DDR400 that
> routinely threw memory errors until I backed the timings off SPD by 1
> clock. Typically these memory errors are caused by a few "marginal"
> transistors in some cells that simply won't function correctly at SPD
> timings. I won't go as far as saying this is "common" with consumer
> DIMMs, but it's far more frequent than with server modules.
>
> BTW, "Patriot" may not be generic but it's not a tier one player like
> Crucial, Hynix, Kingston, Micron, Samsung, Wintec, etc. Over the long
> haul companies like Patriot, Geil, G.Skill, etc, tend to have higher in
> the field defects and failures than the top players. I try to stick
> with DIMMs from Crucial and Micron as the entire product from silicon to
> final module is manufactured under "one roof". These companies have
> been making DRAM chips and modules decades longer than the new kids and
> really know the business inside and out. Performance, quality, and QC
> are very high, and warranty service excellent. In summary IMHO they
> simply have better overall product.
If I have to return these again, I may just go with Crucial, or Kingston.
> modules are DDR3-1333 with 10.5-7-7-7 timings try 12-8-8-8.
>
> I had a Biostar socket a A mobo with the dual channel DDR400 memory
> controller in the nVidia Northbridge and two sticks of Geil DDR400 that
> routinely threw memory errors until I backed the timings off SPD by 1
> clock. Typically these memory errors are caused by a few "marginal"
> transistors in some cells that simply won't function correctly at SPD
> timings. I won't go as far as saying this is "common" with consumer
> DIMMs, but it's far more frequent than with server modules.
>
> BTW, "Patriot" may not be generic but it's not a tier one player like
> Crucial, Hynix, Kingston, Micron, Samsung, Wintec, etc. Over the long
> haul companies like Patriot, Geil, G.Skill, etc, tend to have higher in
> the field defects and failures than the top players. I try to stick
> with DIMMs from Crucial and Micron as the entire product from silicon to
> final module is manufactured under "one roof". These companies have
> been making DRAM chips and modules decades longer than the new kids and
> really know the business inside and out. Performance, quality, and QC
> are very high, and warranty service excellent. In summary IMHO they
> simply have better overall product.
After letting the system run overnight there were quite a few more
errors, as I expected. It seems like the error are all in Test #5. At
least that is what was showing this morning, and is the only test that I
have seen errors appear in on this set of runs.
I switch the sticks back to the original slots this morning and now all
8GB are showing again. I really don't know if this is a memory problem,
or a motherboard problem. The system seems to run OK. I just want all
8GB of memory to be recognized and working properly.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 10:40:02 AM11/28/12
to
In the absence of an updated Debian install (it's wiser not to update a
digital audio workstation too often) I used another install of current
Ubuntu Quantal 64-bit, Memtest86+ v4.20 and instead running it from the
same Parted Magic live CD, I run it from the lastest Parted Magic 64-bit
Live CD, also Memtest 86+ v4.20.
Ubuntu's Memtest still claims that my RAM is broken, Parted Magic's
Memtest still claims that my RAM is ok. Intense RAM usage for more than
8 hours a day and never turning the computer of since several days and I
had not a single RAM issue. I don't had RAM issues for the last
years ;).
So it's very likely that the RAM is ok ;).
Perhaps you should run Memtest86+ from
http://partedmagic.com/doku.php?id=downloads too.
And even if this should fails too, it doesn't mean that RAM is broken.
OTOH if your RAM passes the test there's no guarantee that the RAM is
ok.
Memtest86+ can help to find a broken RAM, but it's not a secure test,
when there's no suspicion for new RAM.
Hth
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354115833.2520.12.camel@q
digital audio workstation too often) I used another install of current
Ubuntu Quantal 64-bit, Memtest86+ v4.20 and instead running it from the
same Parted Magic live CD, I run it from the lastest Parted Magic 64-bit
Live CD, also Memtest 86+ v4.20.
Ubuntu's Memtest still claims that my RAM is broken, Parted Magic's
Memtest still claims that my RAM is ok. Intense RAM usage for more than
8 hours a day and never turning the computer of since several days and I
had not a single RAM issue. I don't had RAM issues for the last
years ;).
So it's very likely that the RAM is ok ;).
Perhaps you should run Memtest86+ from
http://partedmagic.com/doku.php?id=downloads too.
And even if this should fails too, it doesn't mean that RAM is broken.
OTOH if your RAM passes the test there's no guarantee that the RAM is
ok.
Memtest86+ can help to find a broken RAM, but it's not a secure test,
when there's no suspicion for new RAM.
Hth
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gary Dale
Nov 28, 2012, 11:10:03 AM11/28/12
to
On 28/11/12 10:17 AM, Ralf Mardorf wrote:
> In the absence of an updated Debian install (it's wiser not to update a
> digital audio workstation too often) I used another install of current
> Ubuntu Quantal 64-bit, Memtest86+ v4.20 and instead running it from the
> same Parted Magic live CD, I run it from the lastest Parted Magic 64-bit
> Live CD, also Memtest 86+ v4.20.
>
> Ubuntu's Memtest still claims that my RAM is broken, Parted Magic's
> Memtest still claims that my RAM is ok. Intense RAM usage for more than
> 8 hours a day and never turning the computer of since several days and I
> had not a single RAM issue. I don't had RAM issues for the last
> years ;).
>
> So it's very likely that the RAM is ok ;).
>
> Perhaps you should run Memtest86+ from
> http://partedmagic.com/doku.php?id=downloads too.
>
> And even if this should fails too, it doesn't mean that RAM is broken.
> OTOH if your RAM passes the test there's no guarantee that the RAM is
> ok.
>
> Memtest86+ can help to find a broken RAM, but it's not a secure test,
> when there's no suspicion for new RAM.
>
> Hth
> Ralf
I disagree. My experience with MemTest86+ has been that when it detects
> In the absence of an updated Debian install (it's wiser not to update a
> digital audio workstation too often) I used another install of current
> Ubuntu Quantal 64-bit, Memtest86+ v4.20 and instead running it from the
> same Parted Magic live CD, I run it from the lastest Parted Magic 64-bit
> Live CD, also Memtest 86+ v4.20.
>
> Ubuntu's Memtest still claims that my RAM is broken, Parted Magic's
> Memtest still claims that my RAM is ok. Intense RAM usage for more than
> 8 hours a day and never turning the computer of since several days and I
> had not a single RAM issue. I don't had RAM issues for the last
> years ;).
>
> So it's very likely that the RAM is ok ;).
>
> Perhaps you should run Memtest86+ from
> http://partedmagic.com/doku.php?id=downloads too.
>
> And even if this should fails too, it doesn't mean that RAM is broken.
> OTOH if your RAM passes the test there's no guarantee that the RAM is
> ok.
>
> Memtest86+ can help to find a broken RAM, but it's not a secure test,
> when there's no suspicion for new RAM.
>
> Hth
> Ralf
errors, you have a problem.
The other side of the issue is that memory can test OK but that doesn't
mean your memory is being accessed reliably. Klaus Knopper recently
reported, and I can confirm, that sometimes chipsets aren't able to
handle simultaneous disk and memory access at full speed. This isn't a
RAM problem - it's either a chipset problem or a BIOS problem where the
manufacturer pushes the memory timings to the limit only to have them
fail in real use.
I recently also had a problem where a memory stick failed and the
replacement (under warranty) tested OK but wouldn't work with the other
stick in the pair. Each stick tested OK but they failed when used together.
In all cases, slowing the memory speed down can help. The real fix is
for motherboard manufacturers to do better testing when setting the BIOS
timings for different memory types. A clean test with MemTest86+ doesn't
mean that your board will actually work in the real world - especially
as it ages.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Doug
Nov 28, 2012, 11:50:02 AM11/28/12
to
On 11/28/2012 02:32 AM, Ralf Mardorf wrote:
> My apologize, but I don't have the time to read everything. I read that
> you get errors when running Memtest. Do you have issues using the
> computer?
>
> Did you run Memtest from different distros (live media)?
>
> I never have issues when using my computer. If I run the same version of
> Memtest from a Parted Magic media everything is ok, but if I run it
> (again same version!) from Ubuntu Studio Quantal, I get errors. I
> experienced it very often that Memtest claims something is broken, when
> nothing is broken.
>
> IMO Memtest is bad software. I don't have issues with the RAM, excepted
> of new Linux, that can't access all 4GB when using 64-bit kernels,
> everything is ok.
>
> If you should experience that a 64-bit kernel is unable to access the
> whole memory, test what happens when using a 32-bit PAE and check BIOS
> settings.
>
> Resume:
>
> If you don' have issues using your computer, complete RAM or at least
> enough RAM should be accessible and you use the computer several hours a
> day, don't turn it off for several days, but nothing bad happens, I
> wouldn't take care abut Memtest's claims.
>
>
I'm surprised that Memtest gives different results depending on what
> My apologize, but I don't have the time to read everything. I read that
> you get errors when running Memtest. Do you have issues using the
> computer?
>
> Did you run Memtest from different distros (live media)?
>
> I never have issues when using my computer. If I run the same version of
> Memtest from a Parted Magic media everything is ok, but if I run it
> (again same version!) from Ubuntu Studio Quantal, I get errors. I
> experienced it very often that Memtest claims something is broken, when
> nothing is broken.
>
> IMO Memtest is bad software. I don't have issues with the RAM, excepted
> of new Linux, that can't access all 4GB when using 64-bit kernels,
> everything is ok.
>
> If you should experience that a 64-bit kernel is unable to access the
> whole memory, test what happens when using a 32-bit PAE and check BIOS
> settings.
>
> Resume:
>
> If you don' have issues using your computer, complete RAM or at least
> enough RAM should be accessible and you use the computer several hours a
> day, don't turn it off for several days, but nothing bad happens, I
> wouldn't take care abut Memtest's claims.
>
>
disk you run it from, I guess it would be a good idea to download a
stand-alone version and run a sanity check on the download. BTW,
Memtest has been around forever. I think I first saw it around
1990, or maybe even earlier.
How do you check to see how much memory your system has
available to use? Obviously, you have to test that from within the OS.
--doug
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 11:50:03 AM11/28/12
to
errors after a few minutes and from another distro, the same version of
Memtest can run 2 days without reporting an error?
This always will happen, I tried it several times.
Different compiling options?
I don't have issues with my machine, excepted of software issues when
using distros with e.g. Xfce 4.10, but an old Debian is stable, an old
Suse is stable and an old Ubuntu is stable.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 12:20:01 PM11/28/12
to
On Wed, 2012-11-28 at 11:42 -0500, Doug wrote:
> I'm surprised that Memtest gives different results depending on what
> disk you run it from, I guess it would be a good idea to download a
> stand-alone version and run a sanity check on the download. BTW,
> Memtest has been around forever. I think I first saw it around
> 1990, or maybe even earlier.
>
> How do you check to see how much memory your system has
> available to use? Obviously, you have to test that from within the OS.
$ hwinfo --memory | grep Size [1]
> I'm surprised that Memtest gives different results depending on what
> disk you run it from, I guess it would be a good idea to download a
> stand-alone version and run a sanity check on the download. BTW,
> Memtest has been around forever. I think I first saw it around
> 1990, or maybe even earlier.
>
> How do you check to see how much memory your system has
> available to use? Obviously, you have to test that from within the OS.
Memory Size: 3 GB + 512 MB
256MB are missing, since 256 MB are frame buffer for the on-board
graphics. If I mount my NVIDIA with it's own RAM, the output will be +
additional 256 MB, so that still 256 MB are missing. I guess my Debian
(AVLinux) does use a PAE kernel and there no RAM should be missing. I
checked this a long time ago and since I don't have issues and I don't
need the missing RAM, I don't care.
If different versions would cause different results, I wouldn't be
surprised.
[1] This version of hwinfo is broken, I get
process 3804: arguments to dbus_move_error() were incorrect, assertion
"(dest) == NULL || !dbus_error_is_set ((dest))" failed in
file ../../dbus/dbus-errors.c line 282.
This is normally a bug in some application using the D-Bus library.
libhal.c 3483 : Error unsubscribing to signals, error=The name
org.freedesktop.Hal was not provided by any .service files
but in the past I tested it with versions that did not report such
issues and IIRC I also used other commands.
I don't have time to do tests and it's unimportant for me, but I'll keep
in mind to install current Debian version and to run memtest from the
memtest homepage.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gary Dale
Nov 28, 2012, 12:30:03 PM11/28/12
to
MemTest86+ reports an error, it is a good indication that you have a
problem. I've seen this on systems where MemTest86+ reported only a few
problems but the computer locked up intermittently in use. Replacing the
memory with ones that MemTest86+ passed cured the lockups.
I also have a motherboard that was running reliably for 2 years then
started locking up. MemTest86+ reported that the memory was OK but Klaus
Knopper's suggestion that it was a chipset problem seemed reasonable
since the problem occurred during operations where both memory and disk
access were high. The manufacturer meanwhile replaced the board three
times with repaired boards all of which displayed the same problem.
Their repair testing tests components in isolation, which usually is OK
but in this case failed to trigger the real problem.
The problem seems to be more common on modern hardware than on older
systems. I hadn't seen it before but now have seen it on a couple
different motherboards. Slowing down the memory access cures it.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Nov 29, 2012, 2:40:01 AM11/29/12
to
On 11/28/2012 09:24 AM, Gary Dale wrote:
> I'm afraid I can't really answer that. All I can do is repeat that
> when MemTest86+ reports an error, it is a good indication that you
> have a problem. I've seen this on systems where MemTest86+ reported
> only a few problems but the computer locked up intermittently in use.
> Replacing the memory with ones that MemTest86+ passed cured the lockups.
>
> I also have a motherboard that was running reliably for 2 years then
> started locking up. MemTest86+ reported that the memory was OK but
> Klaus Knopper's suggestion that it was a chipset problem seemed
> reasonable since the problem occurred during operations where both
> memory and disk access were high. The manufacturer meanwhile replaced
> the board three times with repaired boards all of which displayed the
> same problem. Their repair testing tests components in isolation,
> which usually is OK but in this case failed to trigger the real problem.
>
> The problem seems to be more common on modern hardware than on older
> systems. I hadn't seen it before but now have seen it on a couple
> different motherboards. Slowing down the memory access cures it.
>
Well, it's not just Memtest86+ that is reporting errors. I decided to
> I'm afraid I can't really answer that. All I can do is repeat that
> when MemTest86+ reports an error, it is a good indication that you
> have a problem. I've seen this on systems where MemTest86+ reported
> only a few problems but the computer locked up intermittently in use.
> Replacing the memory with ones that MemTest86+ passed cured the lockups.
>
> I also have a motherboard that was running reliably for 2 years then
> started locking up. MemTest86+ reported that the memory was OK but
> Klaus Knopper's suggestion that it was a chipset problem seemed
> reasonable since the problem occurred during operations where both
> memory and disk access were high. The manufacturer meanwhile replaced
> the board three times with repaired boards all of which displayed the
> same problem. Their repair testing tests components in isolation,
> which usually is OK but in this case failed to trigger the real problem.
>
> The problem seems to be more common on modern hardware than on older
> systems. I hadn't seen it before but now have seen it on a couple
> different motherboards. Slowing down the memory access cures it.
>
get a second opinion, as it were, and installed memtester from the
Debian repository. I let it run through 5 cycles of its tests. I have
included the results of the first loop below. The other loops were
similar. None of the five loops found any errors in the first 9 tests.
The 'Checkerboard' test found errors in 2 of the 5 tests and only the
first test found errors in the 'Waking zeros' test. As you can see, I
was testing 7GB on an 8GB system. This was running from inside an xterm
while I was cruising the web. As you can see from the results of
running 'free' while the test was going, I had under 80GB (less than 1%
of my total memory) free, so the full memory was getting a workout. I
am just having difficulty with the idea that there are this may memory
errors throughout the range of the RAM and I keep right on working with
no apparent difficulties? Others that I have talked to, who have
actually had memory go bad on them (I never have, before) say that it is
extremely obvious and normal operations are not possible. I believe the
term he used was that "the OS completely wigged out!"
Do I really have bad memory? Or is this some other kind of aberration.
Sunday is the end of my in-store return period. After that I have to
ship things back to manufacturers which is a problem if I don't really
know were the trouble lies.
free
total used free shared buffers cached
Mem: 8179084 8099244 79840 0 22292 199752
-/+ buffers/cache: 7877200 301884
Swap: 8388600 256 8388344
sudo memtester 7G 2>&1 | tee memtester.txt
memtester version 4.1.3 (64-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).
pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 7168MB (7516192768 bytes)
got 7168MB (7516192768 bytes), trying mlock ...locked.
Loop 1:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : testing 1FAILURE: 0xffffffffffffffff !=
0xffffffffffffff at offset 0x04373faf.
FAILURE: 0x00000000 != 0xff00000000000000 at offset 0x04373fb0.
FAILURE: 0xffffffffffffffff != 0xffffffffffffff at offset 0x04373fb1.
FAILURE: 0x00000000 != 0xff00000000000000 at offset 0x04373fb2.
FAILURE: 0xffffffffffffffff != 0xffffffffffffff at offset 0x04373fb3.
FAILURE: 0x00000000 != 0xff00000000000000 at offset 0x04373fb4.
FAILURE: 0xffffffffffffffff != 0xffffffffffffff at offset 0x04373fb5.
FAILURE: 0x00000000 != 0xff00000000000000 at offset 0x04373fb6.
Block Sequential : testing 109FAILURE: 0x6d6d6d6d6d6d6d6d !=
0x6c6d6d6d6d6d6d6d at offset 0x001e71bf.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c0.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c1.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c2.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c3.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c4.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c5.
FAILURE: 0x6d6d6d6d6d6d6d6d != 0x6c6d6d6d6d6d6d6d at offset 0x001e71c6.
Checkerboard : testing 63FAILURE: 0x5555555555555555 !=
0xaa55555555555555 at offset 0x00740b07.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b08.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b09.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b0a.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b0b.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b0c.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b0d.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b0e.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b0f.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b10.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b11.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b12.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b13.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b14.
FAILURE: 0x5555555555555555 != 0xaa55555555555555 at offset 0x00740b15.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x55aaaaaaaaaaaaaa at offset 0x00740b16.
Bit Spread : testing 57FAILURE: 0x500000000000000 !=
0xa00000000000000 at offset 0x083c0420.
FAILURE: 0xfaffffffffffffff != 0xf5ffffffffffffff at offset 0x083c0421.
FAILURE: 0x500000000000000 != 0xa00000000000000 at offset 0x083c0422.
FAILURE: 0xfaffffffffffffff != 0xf5ffffffffffffff at offset 0x083c0423.
FAILURE: 0x500000000000000 != 0xa00000000000000 at offset 0x083c0424.
FAILURE: 0xfaffffffffffffff != 0xf5ffffffffffffff at offset 0x083c0425.
FAILURE: 0x500000000000000 != 0xa00000000000000 at offset 0x083c0426.
FAILURE: 0xfaffffffffffffff != 0xf5ffffffffffffff at offset 0x083c0427.
Bit Flip : testing 14FAILURE: 0x00000002 !=
0xff00000000000002 at offset 0x09cf90bf.
FAILURE: 0xfffffffffffffffd != 0xfffffffffffffd at offset 0x09cf90c0.
FAILURE: 0x00000002 != 0xff00000000000002 at offset 0x09cf90c1.
FAILURE: 0xfffffffffffffffd != 0xfffffffffffffd at offset 0x09cf90c2.
FAILURE: 0x00000002 != 0xff00000000000002 at offset 0x09cf90c3.
FAILURE: 0xfffffffffffffffd != 0xfffffffffffffd at offset 0x09cf90c4.
FAILURE: 0x00000002 != 0xff00000000000002 at offset 0x09cf90c5.
FAILURE: 0xfffffffffffffffd != 0xfffffffffffffd at offset 0x09cf90c6.
FAILURE: 0xfffffffffffffd != 0xfffffffffffffffd at offset 0x09d210c8.
FAILURE: 0xff00000000000002 != 0x00000002 at offset 0x09d210c9.
FAILURE: 0xfffffffffffffd != 0xfffffffffffffffd at offset 0x09d210ca.
FAILURE: 0xff00000000000002 != 0x00000002 at offset 0x09d210cb.
FAILURE: 0xfffffffffffffd != 0xfffffffffffffffd at offset 0x09d210cc.
FAILURE: 0xff00000000000002 != 0x00000002 at offset 0x09d210cd.
FAILURE: 0xfffffffffffffd != 0xfffffffffffffffd at offset 0x09d210ce.
FAILURE: 0xff00000000000002 != 0x00000002 at offset 0x09d210cf.
Walking Ones : ok
Walking Zeroes : testing 61FAILURE: 0x2000000000000000 !=
0x1000000000000000 at offset 0x083e810f.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8110.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8111.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8112.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8113.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8114.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8115.
FAILURE: 0x2000000000000000 != 0x1000000000000000 at offset 0x083e8116.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gary Dale
Nov 29, 2012, 7:40:02 AM11/29/12
to
completely. MemTest86+ and memtester clearly are able to trigger errors
without the system screeching to a halt. Conversely, an entire stick can
fail leading to your system running with less memory than you installed.
In this case, you may not notice any problems except for slower performance.
When it's only certain patterns that fail, a system failure would depend
on that particular byte experiencing that particular pattern shift in a
manner that causes the program to noticeably fail. A bit being flipped
in a data area, for example, may lead to a subtle data error, such as a
glitch in a video, or it may not even show up - such as a bit in an
unused portion of a buffer.
My advice is that if MemTest86+ shows you have a memory problem, believe
it. Even if it doesn't show errors, that doesn't mean that there aren't
memory access issues.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 29, 2012, 8:10:02 AM11/29/12
to
On Wed, 2012-11-28 at 23:38 -0800, Marc Shapiro wrote:
> Do I really have bad memory?
You are using the computer without issues, while your RAM is stressed.
> Do I really have bad memory?
Did you run a RAM test that is not from a Debian distribution?
You RAM could be bad, but it's not likely.
As I've written several times. Here it's the same. Ubuntu's Memtest
(perhaps packages from Debian source) claims my RAM is broken.
My machine is a real-time audio production environment and I don't have
issues!
The same version of Memtest from Parted Magic never reports a single
error, when running it fror more than 24 hours.
I the past I noticed this also with Memtest from other distros.
It's not that the developers are idiots, but they have to keep on track
with new hardware, take a look at the changelog:
http://www.memtest.org/#change
So when I say it's bad software, than I don't mean the coders are less
good, just that it's impossible to write a reliable RAM test
application.
If you know that something is fishy with your RAM, than you can use
memtest for troubleshooting, but just to test new RAM this software is
useless. The results tend to be wrong.
YMMV!
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Nov 29, 2012, 1:30:02 PM11/29/12
to
On 11/28/2012 9:14 AM, Marc Shapiro wrote:
> On 11/27/2012 11:09 PM, Stan Hoeppner wrote:
>> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>>> Gigabyte 970A-DS3 MB
>>> 8GB (2x4GB) Patriot G3 RAM
> On 11/27/2012 11:09 PM, Stan Hoeppner wrote:
>> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>>> Gigabyte 970A-DS3 MB
>>> 8GB (2x4GB) Patriot G3 RAM
> The DIMMS are 1600. According to the BIOS the CPU Timing is at 200 and
> the memory is at x8.0 which matches the 1600 speed of the memory. How
> would I set that to match 1333?
> The timings are 4-5-5-15.
Those timings are not correct for DDR3-1600. The timings you show above
> the memory is at x8.0 which matches the 1600 speed of the memory. How
> would I set that to match 1333?
> The timings are 4-5-5-15.
are for DDR3-800 (PC3-6400).
The fastest DDR3-1600 (PC3-12800) modules have minimum SPD timings of
8-8-8-24. The slowest are 11-11-11-28.
The information you're providing doesn't match reality. With DDR3-1600
and those timings your mobo would simply not POST, and you'd likely get
loud beeps indicating memory failure. If those timings are actually
what your mobo is auto detecting, then you have DDR3-800 sticks, or...
It's possible that you have mismatched DIMMS, one stick of 1600 and one
stick of 800, maybe 1333 ad 800. That would easily explain the memory
problems you're having, as most mobo BIOS don't handle DIMM mismatches
very well, if at all.
Pull your DIMMs, write down the numbers on each, and respond here with
those numbers and we'll go from there. If you have matching DDR3-1600
DIMMs then your mobo isn't reading SPD and setting timings correctly,
though this is very unlikely as I mentioned. If you have two matched
DR3-800 sticks you'll want to try 6-6-6-15 timings. If you have
mismatched DIMMs, one 800 and one 1600, etc, then you'll need to have
them replaced with a matching set.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Dec 1, 2012, 4:20:02 AM12/1/12
to
and I just checked what it said. The line of output said:
Settings: RAM: 400 (DDR-800) / CAS: 4-5-5-15 / DDR3 (64 bits)
The box clearly said that the speed was 1600.
I don't remember if that was for the first set of memory, or for the
second set that I exchanged for. In either case, both sets display the
same symptoms. Two separate sets being bad seems suspicious. Could
Patriot have had a bad batch of sticks. I am thinking of exchanging the
memory again tomorrow for Kingston, or Corsair, depending on what Fry's
has available in my local store.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Dec 1, 2012, 12:20:02 PM12/1/12
to
On 11/29/2012 10:24 AM, Stan Hoeppner wrote:
> On 11/28/2012 9:14 AM, Marc Shapiro wrote:
>> On 11/27/2012 11:09 PM, Stan Hoeppner wrote:
>>> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>>>> Gigabyte 970A-DS3 MB
>>>> 8GB (2x4GB) Patriot G3 RAM
>> The DIMMS are 1600. According to the BIOS the CPU Timing is at 200 and
>> the memory is at x8.0 which matches the 1600 speed of the memory. How
>> would I set that to match 1333?
>> The timings are 4-5-5-15.
> Those timings are not correct for DDR3-1600. The timings you show above
> are for DDR3-800 (PC3-6400).
>
> The fastest DDR3-1600 (PC3-12800) modules have minimum SPD timings of
> 8-8-8-24. The slowest are 11-11-11-28.
>
<SNIP?
>> On 11/27/2012 11:09 PM, Stan Hoeppner wrote:
>>> On 11/27/2012 11:29 PM, Marc Shapiro wrote:
>>>> Gigabyte 970A-DS3 MB
>>>> 8GB (2x4GB) Patriot G3 RAM
>> The DIMMS are 1600. According to the BIOS the CPU Timing is at 200 and
>> the memory is at x8.0 which matches the 1600 speed of the memory. How
>> would I set that to match 1333?
>> The timings are 4-5-5-15.
> Those timings are not correct for DDR3-1600. The timings you show above
> are for DDR3-800 (PC3-6400).
>
> The fastest DDR3-1600 (PC3-12800) modules have minimum SPD timings of
> 8-8-8-24. The slowest are 11-11-11-28.
>
> Pull your DIMMs, write down the numbers on each, and respond here with
> those numbers and we'll go from there. If you have matching DDR3-1600
> DIMMs then your mobo isn't reading SPD and setting timings correctly,
> though this is very unlikely as I mentioned. If you have two matched
> DR3-800 sticks you'll want to try 6-6-6-15 timings. If you have
> mismatched DIMMs, one 800 and one 1600, etc, then you'll need to have
> them replaced with a matching set.
>
How do I set the timings? I have never had problems like this before.
> those numbers and we'll go from there. If you have matching DDR3-1600
> DIMMs then your mobo isn't reading SPD and setting timings correctly,
> though this is very unlikely as I mentioned. If you have two matched
> DR3-800 sticks you'll want to try 6-6-6-15 timings. If you have
> mismatched DIMMs, one 800 and one 1600, etc, then you'll need to have
> them replaced with a matching set.
>
Memory has always worked without errors.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Dec 1, 2012, 1:20:02 PM12/1/12
to
On 11/29/2012 10:24 AM, Stan Hoeppner wrote:
The memory may be telling the BIOS that it is 1600 Mhz, but Memtester86+
says that it is only 800 MHz. If I manually set the Memory Multiplier
to x4.00 (instead of x8.00) then Memtester86+ gets all the way through
test #5 (where all the errors had been coming from) with no errors. I
am now running memtester and it has passed the 'Solid Bits' test and
'Block Sequential' (which were the first that had errors in the past -
every time) with no errors there, either. Not surprisingly, it runs
noticeably slower. I will be pulling the memory and going back to
Fry's, again. I will be exchanging for a different brand of memory this
time. Perhaps Kingston, or Crucial. I think that Patriot had a bad
batch of memory this time, nut just a random bad stick!
Marc
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Christensen
Dec 1, 2012, 2:30:02 PM12/1/12
to
http://lists.debian.org/debian-user/2012/11/msg01468.html
From: Marc Shapiro <marc...@gmail.com>
> Last weekend I put together a new box to replace the one that has
been locking up repeatedly. The components are:
selection tool on their web site to find compatible memory modules.
Your original post provides the motherboard make and part number, but
not the memory part number.
Here are the results using Patriot's "Memory Finder":
Results for GA-970A-DS3 (rev. 1.0)
Recommended Memory
PSD38G1600K
PSD38G1600KH
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
with heatshield
Download Specs
Other Compatible Memory
PSD38G1600K
PSD38G1600KH
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
with heatshield
Download Specs
PSD32G16002
PSD32G16002H
Patriot Signature DDR3 2GB CL11 PC3-12800 (1600MHz) 2 Rank DIMM
Patriot Signature DDR3 2GB CL11 PC3-12800 (1600MHz) 2 Rank DIMM with
Heatshield
Download Specs
What is the part number on your memory modules?
Is it listed above?
If not, return your memory modules and buy one of the above.
If so and you're tried two sets of memory modules, then I'd suggest
trying another motherboard.
I have encountered situations where memory modules recommended by the
manufacturer worked on one motherboard but fail intermittently on
another motherboard. My solution was to leave the modules in the
motherboard where they worked (I was years beyond returning them).
HTH,
David
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50BA57D7...@holgerdanske.com
From: Marc Shapiro <marc...@gmail.com>
> Last weekend I put together a new box to replace the one that has
been locking up repeatedly. The components are:
> Gigabyte 970A-DS3 MB
> 8GB (2x4GB) Patriot G3 RAM
When I purchase memory, I *always* use the memory vendor's memory
> 8GB (2x4GB) Patriot G3 RAM
selection tool on their web site to find compatible memory modules.
Your original post provides the motherboard make and part number, but
not the memory part number.
Here are the results using Patriot's "Memory Finder":
Results for GA-970A-DS3 (rev. 1.0)
Recommended Memory
PSD38G1600K
PSD38G1600KH
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
with heatshield
Download Specs
Other Compatible Memory
PSD38G1600K
PSD38G1600KH
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
Patriot Signature DDR3 8GB (2 x 4GB) CL11 PC3-12800 (1600MHz) DIMM Kit
with heatshield
Download Specs
PSD32G16002
PSD32G16002H
Patriot Signature DDR3 2GB CL11 PC3-12800 (1600MHz) 2 Rank DIMM
Patriot Signature DDR3 2GB CL11 PC3-12800 (1600MHz) 2 Rank DIMM with
Heatshield
Download Specs
What is the part number on your memory modules?
Is it listed above?
If not, return your memory modules and buy one of the above.
If so and you're tried two sets of memory modules, then I'd suggest
trying another motherboard.
I have encountered situations where memory modules recommended by the
manufacturer worked on one motherboard but fail intermittently on
another motherboard. My solution was to leave the modules in the
motherboard where they worked (I was years beyond returning them).
HTH,
David
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Dec 1, 2012, 6:40:02 PM12/1/12
to
the second kit of Patriot Memory. I got a store creidit and went back
to pick out new memory. Fry's does not carry Micron memory, and only
occasionally has Crucial. They were out of the Kingston that I had been
thinking about so I got a pair of 4GB Corsair sticks at 1333 MHz. I
have run them through 2 full passes of Memtest86+ with no errors.
Thank you, everyone, for your input. Thanks especially to Stan for
triggering my memory that I had written down the output from Memtest86+
so that I could see that it did not match what the package, and the
sticks themselves said they were.
I now have a system that is running well and not claiming to have any
errors. It has only taken me two weeks to get to this point, but I'm
there. All is right with the world, or, at least with my new system.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Dec 1, 2012, 10:00:02 PM12/1/12
to
On 12/1/2012 5:34 PM, Marc Shapiro wrote:
> I'm calling this case settled. I went back to Fry's today and returned
> the second kit of Patriot Memory. I got a store creidit and went back
> to pick out new memory. Fry's does not carry Micron memory, and only
> occasionally has Crucial. They were out of the Kingston that I had been
> thinking about so I got a pair of 4GB Corsair sticks at 1333 MHz. I
> have run them through 2 full passes of Memtest86+ with no errors.
Good to hear it's all working now. Curious, the pair of Patriot sticks
> I'm calling this case settled. I went back to Fry's today and returned
> the second kit of Patriot Memory. I got a store creidit and went back
> to pick out new memory. Fry's does not carry Micron memory, and only
> occasionally has Crucial. They were out of the Kingston that I had been
> thinking about so I got a pair of 4GB Corsair sticks at 1333 MHz. I
> have run them through 2 full passes of Memtest86+ with no errors.
with the problem: did that package show signs of being opened before
you bought it? Unscrupulous people will buy memory, swap stickers and
put their old memory in the package and return it. This can happen at
retail, but is very unlikely with Newegg et al as anything returned is
sold as "open box" not new.
> Thank you, everyone, for your input. Thanks especially to Stan for
> triggering my memory that I had written down the output from Memtest86+
> so that I could see that it did not match what the package, and the
> sticks themselves said they were.
> I now have a system that is running well and not claiming to have any
> errors. It has only taken me two weeks to get to this point, but I'm
> there. All is right with the world, or, at least with my new system.
PITA...
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Shapiro
Dec 2, 2012, 1:30:01 AM12/2/12
to
On 12/01/2012 06:55 PM, Stan Hoeppner wrote:
> On 12/1/2012 5:34 PM, Marc Shapiro wrote:
>
>> I'm calling this case settled...
> On 12/1/2012 5:34 PM, Marc Shapiro wrote:
>
> Good to hear it's all working now. Curious, the pair of Patriot sticks
> with the problem: did that package show signs of being opened before
> you bought it? Unscrupulous people will buy memory, swap stickers and
> put their old memory in the package and return it. This can happen at
> retail, but is very unlikely with Newegg et al as anything returned is
> sold as "open box" not new.
No. It was two sets of Patriot memory. After the first pair gave
> with the problem: did that package show signs of being opened before
> you bought it? Unscrupulous people will buy memory, swap stickers and
> put their old memory in the package and return it. This can happen at
> retail, but is very unlikely with Newegg et al as anything returned is
> sold as "open box" not new.
errors, I returned them and got another kit which proceeded to do the
same thing. This time, with another brand, everything seems to be
working correctly.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Dec 2, 2012, 4:30:01 AM12/2/12
to
On Sb, 01 dec 12, 22:19:45, Marc Shapiro wrote:
> No. It was two sets of Patriot memory. After the first pair gave
> errors, I returned them and got another kit which proceeded to do
> the same thing. This time, with another brand, everything seems to
> be working correctly.
It's also other frequency (AFAIR the Patriots were 1600, the Corsairs
> No. It was two sets of Patriot memory. After the first pair gave
> errors, I returned them and got another kit which proceeded to do
> the same thing. This time, with another brand, everything seems to
> be working correctly.
are 1333). You should probably keep this in mind when you change/upgrade
RAM on this board.
Marc Shapiro
Dec 3, 2012, 2:30:01 AM12/3/12
to
On 12/02/2012 01:29 AM, Andrei POPESCU wrote:
> On Sb, 01 dec 12, 22:19:45, Marc Shapiro wrote:
>> No. It was two sets of Patriot memory. After the first pair gave
>> errors, I returned them and got another kit which proceeded to do
>> the same thing. This time, with another brand, everything seems to
>> be working correctly.
> It's also other frequency (AFAIR the Patriots were 1600, the Corsairs
> are 1333). You should probably keep this in mind when you change/upgrade
> RAM on this board.
>
> Kind regards,
> Andrei
Yes, I had intended to get 1600 MHz memory as a replacement, but I
> On Sb, 01 dec 12, 22:19:45, Marc Shapiro wrote:
>> No. It was two sets of Patriot memory. After the first pair gave
>> errors, I returned them and got another kit which proceeded to do
>> the same thing. This time, with another brand, everything seems to
>> be working correctly.
> It's also other frequency (AFAIR the Patriots were 1600, the Corsairs
> are 1333). You should probably keep this in mind when you change/upgrade
> RAM on this board.
>
> Kind regards,
> Andrei
accidentally got the 1333. If I add additional memory I realize that I
will have to used 1333 for that, as well, unless I replace all of it.
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Dec 3, 2012, 4:00:02 AM12/3/12
to
On 12/3/2012 1:23 AM, Marc Shapiro wrote:
> Yes, I had intended to get 1600 MHz memory as a replacement, but I
> accidentally got the 1333. If I add additional memory I realize that I
> will have to used 1333 for that, as well, unless I replace all of it.
Unless you have an integrated GPU that shares system RAM, and play 3D
> Yes, I had intended to get 1600 MHz memory as a replacement, but I
> accidentally got the 1333. If I add additional memory I realize that I
> will have to used 1333 for that, as well, unless I replace all of it.
shooters at high res, you shouldn't notice a difference between 1333 and
1600. You're looking at 21.2 vs 25.6 GB/s with a dual channel setup, or
about 17% difference. Other than 3D games, the applications required to
bring this bandwidth difference to the surface are probably applications
you'll never run. My use of the word "application" here excludes
benchmark programs, such as STREAM or linpack, obviously.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Dec 3, 2012, 4:50:02 AM12/3/12
to
On Du, 02 dec 12, 23:23:48, Marc Shapiro wrote:
> Yes, I had intended to get 1600 MHz memory as a replacement, but I
> accidentally got the 1333. If I add additional memory I realize
> that I will have to used 1333 for that, as well, unless I replace
> all of it.
What I meant was that maybe the change in frequency has some influence
> Yes, I had intended to get 1600 MHz memory as a replacement, but I
> accidentally got the 1333. If I add additional memory I realize
> that I will have to used 1333 for that, as well, unless I replace
> all of it.
on the stability.
Marc Shapiro
Dec 3, 2012, 10:30:03 AM12/3/12
to
On 12/03/2012 01:43 AM, Andrei POPESCU wrote:
> On Du, 02 dec 12, 23:23:48, Marc Shapiro wrote:
>> Yes, I had intended to get 1600 MHz memory as a replacement, but I
>> accidentally got the 1333. If I add additional memory I realize
>> that I will have to used 1333 for that, as well, unless I replace
>> all of it.
> What I meant was that maybe the change in frequency has some influence
> on the stability.
>
> Kind regards,
> Andrei
That is possible. The MB is supposed to be able to handle 1600, I
> On Du, 02 dec 12, 23:23:48, Marc Shapiro wrote:
>> Yes, I had intended to get 1600 MHz memory as a replacement, but I
>> accidentally got the 1333. If I add additional memory I realize
>> that I will have to used 1333 for that, as well, unless I replace
>> all of it.
> What I meant was that maybe the change in frequency has some influence
> on the stability.
>
> Kind regards,
> Andrei
checked that before I bought it, originally, but there could be problems
just the same. Since I now have 1333, I guess I may never know. (or,
really, care).
Marc
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages