On 28/11/12 11:29 AM, Ralf Mardorf wrote:
On Wed, 2012-11-28 at 11:08 -0500, Gary Dale wrote:
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
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.
Do you have an idea why Memtest 86+ v4.20 from one distro does report
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.
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.
--
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/50b648db.7050...@rogers.com
