Solved OS freezes with Firefox and image-intesive use

[s.ar]

Hi there,

I have set up a FreeBSD desktop (14.1) on fairly old hardware (AMD FX-8370, GeForce GTX960).
Everything works alright, except one thing: I'm experiencing sporadic freezes. These freezes are permanent.
Input does not work, images are still. Only hard reset helps.

This happens when I have Firefox open (occasionally MOC for music) and browse image intesive sites (e.g. comics).

Something like this happened a few years ago, with the same hardware.
Then I suspected graphics driver but it was faulty RAM.

This time RAM is OK, I checked with memtest, so that seems out of the question.

How would I go about debugging this?

 

[Argentum]

I have set up a FreeBSD desktop (14.1) on fairly old hardware (AMD FX-8370, GeForce GTX960).
Everything works alright, except one thing: I'm experiencing sporadic freezes. These freezes are permanent.
Input does not work, images are still. Only hard reset helps.

Try to log in from another machine over ssh. See if you can log in access the system and processes. Can you ping the machine? There is the possibility that this (old) GPU hangs, but the system itself is still working.

 

[s.ar]

Try to log in from another machine over ssh

Excellent suggestion. I will try this out and get back here.

 

[Phishfry]

If that pans out OK then tell us what version of the Nvidia driver you are using.
Also how is your power supply?

 

[s.ar]

tell us what version of the Nvidia driver you are using.

I've installed nvidia-driver-550.54.14 from pkg.

Also how is your power supply?

I've not measured stability, but I think it should be able to supply needed voltage (it's a 600W power supply).

 

[sidetone]

Thread limiting-and-dedicating-memory-cpu-usage.89545. By this, userland programs including Firefox don't take over all of the memory, which the kernel can keep using.

Also, I use x11/sxkhd to set the Shift key plus a Hot key to automatically pkill Firefox. This way, if it starts crashing, and it's not too late, I can terminate it more easily than having to wait for the computer to respond to my mouse.

 

[astyle]

BTW, how much RAM do you have?

Usually, it's the DE that experiences freezes like that when RAM is full and active to the point of swapping. Having a lot of tabs open in firefox can be a culprit.

I know how convenient it can be to leave a few tabs open and come back next day for them.

 

[s.ar]

Thread limiting-and-dedicating-memory-cpu-usage.89545. By this, userland programs including Firefox don't take over all of the memory, which the kernel can keep using.

Thanks for this. I will read through it and apply it to my case. I don't think that it will solve my problem but it won't hurt
I have looked into x11/sxhkd (with bspwm) but I'm too lazy to set it up initially (I'm using i3 for some years now).

This way, if it starts crashing, and it's not too late, I can terminate it more easily than having to wait for the computer to respond to my mouse.

Unfortunatly, when I'm experiencing it it probably is too late, since no input works, at all. Only hard-reset will have an effect (ssh method suggested above still pending).

BTW, how much RAM do you have?

This setup has 24GB of RAM so I'm fairly certain that it should be able to continue working, albeit at a snail's pace when many tasks are to be done.

Having a lot of tabs open in firefox can be a culprit.

I'm guilty of this one, although I have cleansed many of my open tabs from Firefox


I have a hunch that this is an issue with the graphics, although (sorry to say this) in between running FreeBSD I ran Linux and did not experience such a freeze.

 

[Argentum]

I have a hunch that this is an issue with the graphics, although (sorry to say this) in between running FreeBSD I ran Linux and did not experience such a freeze.

I think this is not a problem. Just counted, I have 27 tabs open and other tasks running. Also compiling a large port at the same. Still it is all good. 9.7GB memory occupied of 32. Nothing swapped.

Can be hardware fault. Check the logs /var/log/messages. What happened before the new boot? Search logs for ---<<BOOT>>--- and see what happened before. Post it here. Check also the last /var/log/Xorg.1.log log. What was there?

And last, but not least, ping the machine from outside. Is the kernel still running or is it dead. Sometimes happens when GPU is faulty, the system may still remain running.

Try with another video card, known to be good.

 

[astyle]

Try with another video card, known to be good.

Yeah, I'd also recommend making sure the GPU occupies a working 16x PCIE slot (there's probably only one such slot on the mobo). Sticking the GPU into an 8x slot might work, but has the potential to slow the GPU down.

 

[s.ar]

And last, but not least, ping the machine from outside.

Will try this as soon as it happens again.

Check the logs /var/log/messages

I took a look at them but nothing suspicious turned up before and after boot.

Try with another video card, known to be good.

This will be tricky, since I do not have an additional card.

Yeah, I'd also recommend making sure the GPU occupies a working 16x PCIE slot

Will check this on the next occasion.

 

[Argentum]

I took a look at them but nothing suspicious turned up before and after boot.

This will be tricky, since I do not have an additional card.

This all seems a hardware issue. FreeBSD itself does not hang when hardware is OK. Driver can crash the system, but this will usually happen when there is HW fault. In case this is HW fault, you still need to replace some parts.

A probably cheaper option is to try to rebuild graphics/nvidia-drm-kmod from ports. If reinstalling from ports does not help, this must be your GPU hardware.

 

[s.ar]

This all seems a hardware issue

It certainly seems that way.

Maybe it is time to buy a different graphics card (no nVidia, mind you).

Driver can crash the system, but this will usually happen when there is HW fault

This has been in the back of my head , even if I could not articulate it like so.

Just to get it into my head: could this be the/a reason why with Linux something like that has not happened?
Since the driver used there was the nouveau driver, and the driver in FreeBSD is the official (albeit patched?) driver from nVidia? They would exhibit different behaviour?

 

[bsduck]

Your issue reminds me a lot of mine:

Solved - Random system crashes while using Firefox

Hello, Since a few weeks, I experience regular crashes of the system while browsing the web with Firefox. I couldn't find a pattern of when this occurs, it seems random to me, the only constant is that it happens together with an action from me (clicking on a link or button, hovering over an...

forums.freebsd.org

By any chance, do you use x11-wm/picom?

 

[Cath O'Deray]

Usually, it's the DE that experiences freezes like that when RAM is full and active to the point of swapping. …

In my experience, not with Plasma on FreeBSD-CURRENT.

Eight months ago I didn't notice any significant drop in performance until 15G of 16G of swap on a slow HDD was used (but not thrashed), whilst use of real memory was high (good, not excessive). Three screenshots from the time:

• 05:02, note the gkrellm view of memory and swap
• 05:36, whilst Firefox was quitting
• 05:37, Firefox no longer using swap (quit probably complete).

 

[T-Aoki]

First of all, nouveau driver does not exist (it does not support) on FreeBSD, at least currently.

Did you try Ctrl-Alt-F1 (or Ctrl-Alt-F2 through Ctrl-Alt-F8)?
If it get you to CUI (vty) screen and it works, you can kill firefox from there.

And I've already filed PR 280772 for upgrading x11/nvidia-driver, x11/linux-nvidia-libs and graphics/nvidia-drm-[510|515|61]-kmod to 550.107.02 production branch of driver. It also allow you to test new feature branch of driver 560.35.03 (560 series of driver adds some new files, so simply overriding the version as usual is not enough). You can try it if you want.

 

[s.ar]

By any chance, do you use x11-wm/picom?

No, did not install that and it does not seem to be pulled in as dependency.

In my experience, not with Plasma on FreeBSD-CURRENT.

You can try it if you want.

Nice desktop But as I said, I run a pretty minimal setup with x11-wm/i3. The only graphics-intesive activities are browsing and watching movies :^)

First of all, nouveau driver does not exist

Sorry, if I was not clear. I did not mean to imply that I used that on FreeBSD (it was used on Linux).

Did you try Ctrl-Alt-F1 (or Ctrl-Alt-F2 through Ctrl-Alt-F8)?

Yep, did try that. USB keyboard seems to be powered but no input is accepted.

You can try it if you want.

That probaly means building from ports? Like Argentum suggested in #12?

 

[T-Aoki]

That probaly means building from ports? Like Argentum suggested in #12?

Of course.
The patch is not yet accepted, thus, not in official ports tree.
You need to apply the patch to your local working ports tree and build yourself.

And kernel modules depends on "actually running" kernel.
How deep it depends upon (and how strictly the version is checked by) kernel could be different per driver, so even if some of modules from ports still runs without rebuilding, some would stop working.
Generally speaking, kernel modules depending on linuxkpi-related modules strongly depends on running kernel version and strictly checked its version depending onto.

 

[Argentum]

And kernel modules depends on "actually running" kernel.
How deep it depends upon (and how strictly the version is checked by) kernel could be different per driver, so even if some of modules from ports still runs without rebuilding, some would stop working.
Generally speaking, kernel modules depending on linuxkpi-related modules strongly depends on running kernel version and strictly checked its version depending onto.

Agree. And therefore it is a general recommendation to rebuild all loadable kernel modules after upgrade. I have seen that after minor version upgrade the DRM for example may keep working without rebuild, but just for precaution, its is always better to rebuild (IMHO).

 

[s.ar]

Of course.
The patch is not yet accepted, thus, not in official ports tree.
You need to apply the patch to your local working ports tree and build yourself

Alright.

I'm swamped right now and the "phenomenon" has not happened in the meantime (yay ), so I'll try to postpone the rebuilding as far as possible but I'll get back.

Should I close this thread or mark it as "solved" or something like that?

 

[Cath O'Deray]

… it is a general recommendation to rebuild all loadable kernel modules after upgrade. …

No, that can be unnecessarily time-consuming.

 

[Cath O'Deray]

… mark it as "solved" …

If the issue is consistently no longer reproducible by you: yes, please.

 

[s.ar]

If the issue is consistently no longer reproducible by you: yes, please.

Thanks for the pointer. The issue is tricky as I was not able to cause it willingly.
(Also, maybe related: In the meantime, there were some updates to FreeBSD.
Maybe something changed?).

Now that I have some good tips on how to proceed I'll think of it as solved.

Thanks everyone!