7 Oct
2007
7 Oct
'07
5:55 p.m.
On Sunday 07 October 2007 13:38, Tony Duell wrote:
I don't see how software could do anything more.
Nor do I. But I was thinking about approaches other than just software.
> On Saturday 06 October 2007 17:30, Tony Duell
wrote:
> > Again, how on earth cna you know what the fault is if you can't
> > diagnos=
>
> e
I'm wondering what the heck it is that's breaking words, inserting equal
signs, and equal-sign-followed-by-20 in various places in the quoted
material here...
I don't see this anywhere else but in stuff of mine that you're quoting. Odd.
Fixing it gets a little old...
it. You mentioned swapping a DIMM. How can you know if
an intermittant
memory problem is a fault in the DIMM or in the memory controller on
the motherboard?
I've wondered about that for a while now. I've used various memory
diagnostics on different machines over the years, and basically they
all seem to have in common that they write different patterns to memory
and then read it back for comparison. While this is okay as far as it
goes, how DO you deal with the situation you mention there? The purpose of memory is to store data, all the
program can do is say that
it's not doing so correctly.
And maybe get a little specific about where.
To go further, I normally look at the timing of
signals going to the RAM
chips (marginal timing causes all sorts of itneresting prolems), check
supply rails, etc. And then fidn the problem is due to ground bounce.
Seriously, the worst memoery prolems I've had to trace were due to poor
PCB layout.
This sounds more like design flaws than anything else, while my normal
tendency (perhaps erroneously?) is to look for some sort of a component
failure.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin