Lately my PC has started crashing while it plays videos. It freezes completely, screen frozen and not responding to any input (keyboard, mouse), I mean I cannot change TTY (alt + ctrl + F(1-2-…)), and it cannot even respond to alt + PrntScr + REISUB. I have to force power off by holding down the power button.
After I reboot I have tried checking all logs available and I cannot find anything logged right before the incident. Last entries are always different and not indicating anything.
I suspect it has to do with the graphics card but I’m looking for ways that I can dig deeper on that and confirm it or not.
What else should I check? How can I find more info?
OS: Lubuntu 22.04.3 LTS (latest updates) I’m using the nvidia proprietary drivers (nvidia-driver-390)
UPDATE:
First of all thank you all for your input and fresh ideas. Now I’ve already tried some of them and I will continue with the other ones until I get some results.
till now I have tried
- memtest and it didn’t show any errors.
- boot from a live distro and see if problem also occurs. Well it didn’t occur but on the live distro you cannot change the graphics driver. So it was using the open source nouveau driver, also it didn’t happen during the 1 hour I let it play. The thing is that it never was punctual even before. It could happen during the first hour or the third or sometime later.
Next steps are to
- open the case and clean it up to remove the possibility of high temp because of that,
- change my drivers to be the nouveau and try again,
- try with only the onboard GPU on,
- remove extra disks to reduce the load of the PSU
thank you all again.
Boot with a live CD from a different distro. This will split a hardware issue from a software issue.
This! Try this! Don’t go taking your computer apart until you try this. It’s great advice.
thanks! nice idea, i’ll try it
Not really. Distros usually build the same software slightly differently. If the bug is in a piece of software used by all distros such as the Linux kernel, it won’t make a difference.
Test your RAM. I had a machine doing this a few years ago - turns out I had a stick of RAM with a 128k block somewhere in the middle that was dead.
That machine worked fine as long as I didn’t get it doing anything too intensive, then it would crash. A new stick of RAM solved the issue.
This is the most likely issue. To add - test 3-4 passes of Memtest86+. The first pass is shorter and meant for finding egregious RAM problems. It can fail on subsequent full passes. I had my RAM fail on 3rd of 4th pass which passed the 1st. It could even be caused by incompatibility of the size of RAM with the platform. For example in my case AMD supported 2x 8GB sticks of this RAM with no issues. Insert 4x 8GB and it starts producing errors even if each individual stick passes with flying colors.
Seconded. I’d been having issues (random freezes, crashes) for a while but I had attributed then to a lack of RAM. So I bought some more RAM at some point and ran memtest on all RAM together and saw errors. Those bastards, they sold me dodgy RAM, right? Tested the new sticks individually, they were clean. Turns out I had a bad 64kb area on one of my old sticks.
You can tell the kernel to not use the bad area btw if it’s all in one place, so don’t necessarily rush out to replace the bad stick.
thanks. I run memtest for about an hour and no errors. I’ll leave it run more if nothing else shows any progress
I was in a similar situation not too long ago and couldn’t find anything to fix it either at first. One thing that was high on my list was changing my PSU since a defect or weak one often seems to be a problem in such cases. Besides a general hardware failure of course. If it’s the hardware that could be anything really. Motherboard, RAM, GPU, PSU. PSU is the easiest to switch tho, so if you go that route I would try that first.
Anyways, I never had to do this cause in my case, believe it or not, a BIO update fixed my problem. I am still not 100% sure what happened but I think the update fixed the GPU voltage distribution or something similar.
Hope that help at least a little bit.
good idea about the PSU. I hadn’t thought of that. The PSU is not any high-performance/high-quality and is already 5 years old. Being unable to provide the required voltage may be a possibility if we accept that the performance degrades in time. (Was working without issues for 5 years in the same PC configuration).
I think I’ll try by first removing the extra HDDs so reducing the load and check again. Thanks for your input
If your processor/MB has onboard video, it would probably be easier to pull the gpu and test. If you still suspect power management, pulling other components like additional HDDs after adding the gpu back would confirm it.
Can you be more specific when you say “plays videos”?
Like in vlc, or YouTube, or something else? What videos? Like, 4k hevc videos, or literally anything?
mostly on youtube, usually at 720p30fps. I think if I go to 60fps it crashes even faster. Also I’ve tried watching on freetube and on firefox + mpv, but it can crash in all combinations
If you have another pc, ssh from it to the problem machine and run
sudo dmesg -w. That should show kernel messages as they are generated and won’t rely on them being written to disk.i will try it but I’m quite confident that it will be unresponsive/not reachable since if the kernel was listening it would respond to the alt + PrntScr + REISUB by unmounting the drives and I would see it when I examine the logs afterwards
To be clear,
dmesg -wshould be run before you do anything to cause the crash. It will continuously print kernel output until you press ctrl+c or the kernel crashes.In my experience, a crashing kernel will usually print something before going unresponsive but before it can flush the log to disk.
from now on I’m having it open and shown on the screen show if it happens again I’ll see it. thanks
Try this
thanks. I run memtest for about an hour and no errors. I’ll leave it run more if nothing else shows any progress
It should say “PASS” if your rams good. It can take a while depending on your ram speed and amount.
it reached to the point that says “Pass complete, no errors, press Esc to exit” but the test still runs. So yes, I will re-do it for the additional passes, but from a first look, it looked fine.
In that case I’m pretty sure you have a issue with your gpu. Have you tried reseating it in the PCI slot? If you have a second GPU you could test you setup with it instead
yeah, I will try these today…
I think a live boot cd or trying to use an integrated gpu, if available, (both I saw already suggested) are better steps but you could also try blacklisting nvidia and use nouveau. Could point to those drivers if it works ok.
I had a similar problem a while back and it turned out to be my Asus motherboard’s “AI” frequency control hard locking the system. Took me days of troubleshooting and headaches to figure this out. Ended up switching it off in BIOS and everything is stable now. Just my 2c.
Have you checked /var/log/syslog?
If not, see if there’s anything around the time of the crash there that indicates a GFX problem, like “GPU has fallen off the bus”.
yes. As I wrote
After I reboot I have tried checking all logs available and I cannot find anything logged right before the incident. Last entries are always different and not indicating anything.
Just to be certain, you have checked journalctl too?
isn’t this a unified way to present logs that also exist in var/log ? I mean if the logs are saved in var/log I’ve checked them. If there is a possibility that journalctl has more entries, then I need to check this too.
Seems you might know more than me. When I had an obscure crash related to my pc going into C-sleep state, I managed to find a pattern viewing the logs in reverse from the time of the crash.
On my system there is no traditional log files like
kern.logormessage(Not sure about Ubuntu 22.04), I would say it’s worth a try.Try
journalctl --boot -1 -xeorjournalctl --boot -1 -xep3Lubuntu
Maybe for some logs but no, systemd logs are stored in binary format and can only be accessed with journalctl. I would definitely give that command a shot.
will check this too then. Thanks
I read you mentioned firefox. I had a similar experience a while ago, related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1704774#c13
Re seat your RAM modules.