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

Thu May 31 11:31:41 PDT 2018

Thank you Michael for your VERY THOROUGH and INFORMATIVE reply...
The laptop is currently running beautifully and multiple
'inspectors/teachers' were unable to
'nail down' THEE specific cause.

[Quoting Michael Paoli]
>>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.

Indeed...did this as one of the first things it passed 100%

Later someone ran GpuTest_Linux_x64_0.7.0 installed on HD from ~/ and it
found no issues.

>>Try running/booting something else

Did that as well multiple times...the other distro's boot[ed]...

Will let her sail on ~~~[]-|}-> with the K.I.S.S. & I.I.A.B.D.F.I
principals applied

Will try your RAM pulling/swapping 'hack' if/when I get some more...

message ends.
__________________

On Thu, May 31, 2018 at 6:14 AM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> 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.
>>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
>

-- 

*~the quieter you become, the more you are able to hear...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20180531/f3fa1433/attachment.html>