I’m a Tumbleweed user since a long ago and recently Firefox turns slow or freeze. Firstly I thought it was something with my user profile. I’ve created a new one and after a few tabs opened it freezes again or sometimes turns slow as it was some connection issue (as partial DNS unresponsiveness, for exemple - some parts of a site load and others not). I decided to make an all new OS install since there’s a lot of time since my original one. After login to my FF account and recover my previous sessions, the symptoms comes again. So I took another machine to test a completely new system. I downloaded the last build of Tumbleweed and update the all system with zypper dup. Just after login to my FF account and back to my work (for about 6 or 8 pages oppened), it slow down or freezes again. So I removed my FF account and test it with a new profile, new machine, new installation and no sync account and it happened again.
The symptons are so creepy because to total amount of CPU stills available although the cores monitoring shows it in full throttle. Whatching to the System Monitor, there’s no zombie process even no application consuming the CPU at critical level.
Another symptom I realized is FF can’t join Google Meet conferences anymore or it takes a very long to do it. MConf conferences starts to show issues too, as can’t joining audio resources. This issues collections comes since beginning of october.
Chromiun runs without problems
Someone can help me to track these issues? There’s another pals facing the same?
A few of us have experienced and reported issues like you describe since a few weeks ago. This has been discussed in the forum. As I understand something is not going smooth with FF 93.0. However, it is my impression that some patches have been installed in the last couple of weeks that may have improved the situation. We may hope that these issues will be resolved soon as work progresses with FF.
Journalctl can bring up journal entries from past boots, for example:
% journalctrl --boot -2
(Once in journalctl, the > (greater-than) key is a quick way to get to the end and then work backwards.)
Other files worth looking at immediately after a crash:
replacing foo with who ever was logged in at the time. After a crash you could login as someone other than “foo” and take a look at foo’s log without overwriting it.
This next file should be the Xorg log from the previous boot:
The ones dated nearest the crash would be most interesting.
If the desktop just appears to be frozen, you may be able to login remotely by using ssh from another PC (or even a tablet or phone) and look at the current log files. Maybe also check the output from dmesg, but that’s normally in the journal anyway.