Ah, OK . . . yes, I think there is a line in grub for that . . . but, at 32GB RAM I don’t think I am using more than a few GB of it, so even if there is a “misfire” on RAM stick number two . . . ??? But, for the keeks I will check it at some point . . . .
Doesn’t matter, needs to be eliminated, I would suggest sooner rather than later, new memory sticks die too…
So, rebooted to grub menu, grub & osprober are handled by TW . . . and no listing for “memtest86” is showing, only UEFI settings . . . went in there and nothing obvious about testing memory, other than it showing the 32GB of RAM . . . . Any other ways of checking it?? xnxi??
@non_space So is memtest86+ installed?
It is now. Installed it in TW and rebooted into the test, ran it for 16 mins to test #6 . . . no errors reported. Looks like it would have kept running the test for another half an hour??? Showed “Pass” 49% at 80% of test #6 . . . . Showing “27.8GB” on the two “16GB” sticks.
Would not something “obvious” show up in the first couple of test runs?? In this case it worked thru the RAM one GB at a time for 6 repetitions . . . no errors.
@non_space I would suggest just leaving it running over night just to be sure.
LOL . . . OK . . . that is the bane of this world, “needing to be sure” . . . . Every electron of power that I use is billed to me, so I don’t leave my machine running 24/7 . . . they get shut down.
Here’s another way of looking at it, the problem is similar to the knurpht thread, where within a few seconds of logging in, the problem(s) happen . . . so why would it be that running the test for hours would show something relevant to a problem that when it occurs happens in less than the 15 mins that I ran the test??? Not saying it’s “impossible” that the problem is RAM related, but in the world of electronics the hardware is either working or it isn’t . . . ??? Perhaps at some idle hour in the day, the test could be run, but I don’t see support for running it “all night long” . . . sorry to be frank about it.
If the test had shown some flashing red light quickly then it might support a longer test . . . I believe the trail leads elsewhere, where??? Not yet known.
No problem, but it’s just eliminating a potential issue that may be over looked…
The other option is to use Prime95 to stress the system and see how it goes.
Experience is why, zero errors until 4th or 6th or later pass. One bit near edge of spec can be working perfectly 99.99% of the time, but that .01% can trash a project, and do it at a most inopportune time.
Because that’s how memory works. With electronics where voltage variances cause intermittent issues, it’s never as simple as “either it works or it doesn’t.”
The more complex the electronics, the more a voltage spike or other variation in current can cause an issue that’s intermittent.
I’ve run servers that ran for years fine that had an NMI memory error cause the system to crash - NMIs are always hardware-related. Sometimes the error doesn’t happen immediately again, but it can be days, weeks, or months before it happens again. Or it can happen on the next reboot - but most often, it doesn’t.
That doesn’t mean there isn’t a hardware fault.
Run the memory test, just to remove it. There’s nothing worse than trying to troubleshoot an intermittent problem when one of the more common things that makes intermittent things is eliminated due to a lack of knowledge or experience.
Gents: I have read the rebuttals . . . I did “run the test” to the #6 pass of it . . . . And, sure, “voltage spikes” could be happening . . . while I was reading hendersj’s post . . . the power went down, due to “light rain” in the area?? So, anything is “possible,” but then in my work with human health, usually the “obvious” is somewhat “overt.” Are the clues leading us in a direction or they are not??
The problem was “exclusive” to Leap 16 starting some weeks back, possibly further, in that once I saw a pattern I started writing it down, so that a week later when I came back to that system I could confirm the problem. When that happened three times I posted it on the forum. Then in the discussion on it the problem seemed to increase in frequency, on Leap . . . wasn’t happening in my other installs.
Then, as this thread has continued I can see it happening in a few other installs . . . . Unlike hendersj’s “it was running fine for YEARS” this is a machine under one year . . . .
But, sure, let’s rule it out as a factor . . . . What is the common consensus on how long the memtest86+ should be run to eliminate ALL question as to the veracity of the RAM??? 10 passes or 24 hours of testing?? It’s not just a matter of the number of passes made, but over time the repeated passes have to be done to find a problem with it???
The main clue is that the issue seems to be intermittent, and not dependent on which distro you’re running. That points to either something hardware-related or something common in code. Memory problems are also often intermittent.
As for amount of time, I’d recommend overnight, as others have. Longer if you have more memory, because how much memory you have (perhaps obviously) determines how long it takes to test it all. 6 passes is not often long enough in my experience.
Further to Jim, Malcolm, and Felix’s excellent advice, it’s possible that another hard-to-diagnose hardware issue is at play. Poor voltage regulation or excessive ripple from a PSU can definitely cause intermittent problems. Voltage dips or high-frequency noise can interfere with sensitive components like the CPU, RAM, or GPU, and such issues may be exacerbated when the graphics card is under load, for example.
@deano_ferrari That’s why I suggested Prime95, that will give everything a good workout…
Alrighty, meeting you gents “half way” I ran the test long enough to cycle through the tests to the point where it posted “PASS” in large letters on the screen. I took a cell shot of it, if I need to provide proof of it. Willing to again to meet the hardware as the source of the problem “half way” on the “prime95” gambit . . . likely also not installed yet . . . .
Indeed the “electrical source” could be an avenue of impurity . . . but, not really convince this is a “hardware issue” when we ALL know that there are bugs to be found in code . . . and many linux distros share these problems . . . .
So you have potentially eliminated that by the sounds.
So what about running Prime95 to stress the system?
In the system BIOS is there voltage options for the RAM, if so are they correct for the installed RAM?
Do you run off a UPS or Surge Protected power point?
All my Desktop systems run off UPS’s here I have two, I only have one Desktop running Leap 16.0 with GNOME, no issues seen, Laptop is fine as well on GNOME, other systems run headless no desktop environment and just do their thing.
Haven’t had the chance to get to the Prime95 gambit yet. Have not played with the BIOS voltage settings for anything, so whatever is stock for that is likely where it is. I’m not trying to push the CPU “clock” or hot up the voltage to the RAM . . . box stock is where it is, as it has been for the 9 or so months of its “life.”
My '12 Mac Pro and the previous machines I had all plugged into a surge protector, but then the new machine’s power cord couldn’t reach it. I read something about how “today’s power supplies can handle surges,” and over the 25 years of owning that surge protector, it never once flipped the breaker from a surge. Here more likely is the power goes off, as it did today.
I have my Ryzen machine plugged into a circuit breaker power strip, but no it’s not a surge protector, juts has a circuit breaking switch on it.
I am in Leap 16 today, ran “prime95” through a YaSt search and it showed “no results” then ran it via a zypper in . . . . I recall that I might have installed prime95 on my Mac Pro some time back when working through a problem thread, possibly suggested here . . . but is that a “Windows” app?? Or an OSX app, because it doesn’t appear to be in my options . . . possibly because I have only two or so repos activated??
:~> sudo zypper in prime95
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
'prime95' not found in package names. Trying capabilities.
No provider of 'prime95' found.
Resolving package dependencies...
Nothing to do.
@non_space Just dowload the tarball, extract and run there.
https://prime95.net/download/
./mprime --help
So, it’s become more clear that the typing problem is recurring in the Google Voice messaging box, with some consistency . . . odd behaviors mentioned before with cursor not typing, esp the letter “p” which seems to be tabbing around on the desktop icons, rather than typing the letters.
Been a couple of weeks without the problem happening in Leap 16 . . . today it hit in Manjaro, but it seems like the commonality is the Voice message box . . . ??? Which would point to either the Google server being overwhelmed, or some FF issue in that particular site??
When it happens it is a pain . . . but then not typing in that app every day. And that could explain why it has “branched out” to the other distros . . . .