[sf-lug] RAM, etc. checks: Re: [SOLVED..(so far)]>>>Re: [i don't hear 'Hal's' voice...YET]

[Michael Paoli]

Some additional bits I might (at least in general) suggest:

Often one may not have handy spare RAM that is known good and
100% compatible with the target system, so in addition I may
also suggest:

Try running the system with *less* RAM by removing some RAM - though that
might cause other issues or may not even be feasible or possible.  But
sometimes that will cause the problem to (not-so-)"magically" go away,
in which case issue is probably the removed RAM, or something closely
associated with it (e.g. RAM slot, or memory controller thereof).
Note also one may have to remove RAM in pairs/sets, depending upon
the hardware and such.

Try swapping RAM around.  Note also one may need to use/move RAM in
matched pairs/sets.  If the symptoms are highly consistent and
"instantly" reproducible every time, and then one shuffles RAM about,
and the systems go away or substantially change, and then putting
RAM back as it was before and symptoms revert to exactly what they were
earlier ... then likely there's bad (or incorrect) RAM somewhere in there.

Do also keep in mind out-of-spec RAM can be an issue - might seem fine for
quite a while, and end up problematic later or later cause intermittent
issues.

Keep in mind issue could be RAM, or it could be a RAM slot or associated with
such - e.g. memory controller.  Sometimes RAM can be moved around to use
different slots - e.g. changing which are empty, and which aren't, but same
total RAM, same RAM.  However, also, it's not uncommon that some certain
slot(s) must contain RAM or "enough" RAM for the system/hardware to function
at all - sometimes even for Power-On-Self-Test (POST) to successfully
complete.  (E.g. once myself and someone else were working to isolate an
issue on a Linux host ... ran fine with 32-bit, failed horribly on 64-bit
... eventually isolated it to RAM slot (or pair) - likely memory controller
for that slot (or pair) wasn't doing 64-bit properly - same (or any suitable)
RAM anywhere else ran perfectly fine, and likewise if only 32-bit was used.)

When removing and reinserting RAM - "cleaning" is a good suggestion - but do
also be quite careful with that (what's used, how, handling, etc. - I'm not
going to detail more specifically at least presently) - when  
reinserting, don't
merely press/seat it well in - sure, do that too, but as one is inserting it,
gently rock it back and forth a bit, or in-and-out back and forth a bit as
one fully presses/seats it into position.  Notably this has a mostly  
beneficial
effect of doing some wiping of the contacts between RAM and socket and helps
ensure good solid electrical contact (e.g. helps wipe away oxides/contaminants
and make good metal-to-metal conductive contact).  Mostly  :-)  Try to avoid
doing this to excess - a little bit good, too much - bad.  It's a wee bit
'o extra wear and tear, but if it's done a whole lot (for some value of
"whole lot") with the RAM - or socket - that can cause problems (e.g. gold
plating wears through/down/uneven, very tiny bits of loose metal specks are
created, and ... they may eventually end up someplace very problematic, etc.).
But if/as one's dealing with hardware that's already having issue(s), it's a
cost/benefit analysis on how much one does this in-out/rocking on the
reseating/reinsertion ... optimal is typically around some moderate to fair
bit - in case of system exhibiting systems that are quite likely indicative
of failure of RAM or closely associated component(s).  On brand new
system and RAM when first inserting RAM, optimal is generally do a slight
bit 'o rocking 'n such on the initial seating, and then if all checks out
fine, don't muck with it after that.

Try running/booting something else.  E.g. running 64-bit nominally?
Try 32-bit.  Sometimes Linux will flush out and show bugs in hardware
that other operating systems don't "see" at all - because Linux often
quite makes relatively full use of the hardware in many ways that other
operating systems often don't.  Anyway, try running/booting rather to
quite significantly different software / operating system.  Could also be
useful - depending upon available RAM (or lack thereof) to run something
that's much less RAM-hungry - does everything run okay with (much) less
RAM installed and software / Operating System that's (much) less RAM-hungry?
Can also do things like boot single user mode, no GUI, etc. to greatly
reduce RAM demands.

> From: aaronco36 <aaronco36 at SDF.ORG>
> Subject: Re: [sf-lug] [SOLVED..(so far)]>>>Re: [i don't hear 'Hal's'  
> voice...YET]
> Date: Mon, 30 Apr 2018 22:37:02 +0000 (UTC)

> maestro <maestro415 at gmail.com> wrote:
>
>> if anyone thinks of something further i should do/run for the original
>> issue or what it was/is feel free to send it and thanks...
>
>>> watching a live sports feed on t-440p thinkpad running
>>> LInux Mint_Mate_64 screen 'fizzed' out with horizontal
>>> multi-color lines_'ish across display and 'static'
>>> sound while backlighting on keyboard blinked on and off...
>>>
>>> went to boot up said thinkpad after getting it to rest
>>> (complete shutdown) and it won't boot just blinks
>>> backlighting on keyboard NO display.
>
>
> Sometimes I've found that display problems like those described  
> above are from defective, failing, or improperly installed RAM.
> A couple of things to do/run are to
>
> 1st - Remove the RAM sticks, clean the contacts on both the RAM  
> sticks and the motherboard RAM slots, and then _properly_ re-insert  
> the sticks in the motherboard RAM slots.
>
> 2nd - Run a memory-checking program such as memtest86+ from your  
> live media to see if any of the RAM sticks might be scanned as  
> defective.
>
> 3rd - Replace the current RAM sticks with known good RAM sticks, and  
> then see if the display problems then disappear.