Fedora KDE 31 Freezes Too Much

Man, I’m sorry for the late response. I’m actually a little down in the dumps and a little frustrated. I also asked for help on Reddit and the final answer I received was that I better change my distro; that Fedora is not for me. I’m sure they think that Fedora is something very exclusive or premium for the common user.

I had considered upgrading my OS to Fedora 32, but seeing the problems @enrico has had, I don’t see it as an option. Besides, I feel that it is too early to upgrade. I prefer to wait a few weeks for some bugs to be reported and fixed so I can have a more stable OS.

I’m following the thread with @enrico, hoping and trusting that the desired solution will appear.

In my last session of a little more than an hour and a half, I didn’t have any freezing. But the use of my PC is completely limited: no more than two open applications, Firefox with only one tab, no music or video players, etc. A rather poor and boring use.

I will continue to report; any news will be reported immediately. For the time being I’ll keep updating the system every day as I usually do, hoping that in one of those at last everything will be solved and my system will return to normal.

Thank you very much for taking a minute of your time to come and read and try to find a solution. :nerd_face:

Okay, Friday, May 8th. A new freeze. Approximately forty minutes after ignition. CPU between 60 and 70%, RAM in less than 2GB. Three applications in use (Dolphin, KTorrent and Firefox); Firefox with four open tabs (including the Spotify web player).

Here is the only command that gives any results:

journalctl -p3
-- Logs begin at Fri 2020-05-08 07:55:27 -05, end at Fri 2020-05-08 12:59:12 -05. --
may 08 07:55:27 localhost.localdomain kernel: usbhid 4-2:1.1: couldn't find an input interrupt endpoint
may 08 12:55:52 localhost.localdomain auditd[708]: Could not open dir /var/log/audit (No such file or directory)
may 08 12:55:52 localhost.localdomain systemd[1]: Failed to start Security Auditing Service.

It’s only been a few minutes and I’ve had another freeze. This time only two applications in use: Dolphin and KTorrent.

Besides downloading a torrent, I was transferring files to a USB stick.

Here the journalctl -p3:

-- Logs begin at Fri 2020-05-08 08:46:22 -05, end at Fri 2020-05-08 13:49:35 -05. --
may 08 08:46:22 localhost.localdomain kernel: usbhid 4-2:1.1: couldn't find an input interrupt endpoint
may 08 13:46:46 localhost.localdomain auditd[707]: Could not open dir /var/log/audit (No such file or directory)
may 08 13:46:46 localhost.localdomain systemd[1]: Failed to start Security Auditing Service.

This should be easily fixable with a dnf reinstall audit.

For the rest of your issues, have you tried ruling out a hardware problem (power, memory) with tools like memtest86+ and prime95? I would start there.
Our kernel test suite could also help you identify problem areas (you don’t need to submit results).

I was holding myself to suggest a memtest because it was discussed on the devel mailing list that the one in the Fedora images, freeze on recent CPUs. But I guess a Celeron E3400 would not be affected… who knows.

https://bugzilla.redhat.com/show_bug.cgi?id=1815742

To be honest… I doubt the answer will show up in the logs.

@enrico seems to have think he upgraded to F32, but seems he did not yet
Upgrading to F32 seems to me the best option for you.

I see I did not help you understand journalctl… you could read “man journalctl” which is what I do… but guess it would help I give you some hints.

journalctl --list-boots
should give you many boot entries… if it give an error it probably means your log are volatile (are erased at every boot) rather than being persistent. And we should help you fix that if it is the case for you.

journalctl --list-boots
give at first column a negative number… 0 or -0 is your current session,
-1 is the previous session,
-2 is the previous session of the previous session,
etc.

So when you reboots because of a freeze, the log with the session that frozed is in the past… -1 if you just rebooted, -2 if you rebooted twice, etc.

And you do things like:
journalctl -b -1
journalctl -b -2
to see these older sessions.

So you have to make a note to yourself of when freeze happens… and looks in journalctl --list-boots entries to find which one contains the session that have frozen.

And then you could send your logs to fpaste web site, with:
journalctl -b -1 --no-pager | fpaste
the -b -1 would means the session before the current one,
-p4 would limit to error messages
–no-pager would make sure it would not wait for you to press keys
| fpaste would send to paste site for 24h the contents…
that should result in a link that you can first check yourself in the browser to make sure it does not contains something you would not wish to publish

There is a more recent version, which is supposed to have better support for newer models, but the regex on Anitya would not pick it up. I’ve updated the filter and it filed a bug against the package.

When I have no other clues and I suspect faulty hardware, I usually start with memtest86+, because it’s relatively fast and easy on the tested system. However, prime95 can catch memory errors that memtest86+ doesn’t.
For the rest of the errors that prime95 reveals, more often than not, it takes a significant amount of work to pinpoint what’s at fault.

I’d like to share this.

It’s from another distro (Manjaro) and this one is Spanish (sorry about that). In short: exactly the same problem. Same symptoms, everything. I was surprised how perfectly described it is. I could copy/paste almost all the content and just change Manjaro for Fedora.

The thread starts in July 17. The last comment is from January this year: there is no solution.

This leads me to think that the problem is not Fedora’s. And from what I have read, this kernel is the main suspect.

I am a simple, ordinary system user. All I want to do is turn on my PC, surf the Internet while listening to music and then watch a movie or read a book. Many of these hypothetical solutions simply outweigh me; my use of commands is basic and limited. Test the kernel? Man, until recently I didn’t even know which version I had installed.

I’ll keep typing some of these commands, pressing enter, and I’ll bring back the results.

I couldn’t find a solution on Reddit either. It’s okay, maybe it’s something extremely particular.

As always, thank you very much for every input. :nerd_face:

Well… the part mention in english seems to suggest to remove the xf86-video-intel driver… which make some sense at first because I think it would then use glamor… Oh well, I do use it on my computer… I’ll try to remove it and will give feedback… If I am able to use may computer again :wink:

I did: sudo dnf remove xorg-x11-drv-intel

I am back… I see that I still use i915 (that’s in the kernel… I tend to confuse those)… Still on Gnome on Wayland… at first glance I see no change. But I need to investigate a bit more… I don’t fully understand what it change.

I do have:

[paul@localhost ~]$ journalctl -b0 -o short-monotonic|grep glamor
[   46.473104] localhost.localdomain org.gnome.Shell.desktop[1259]: glamor: No eglstream capable devices found
[   64.597533] localhost.localdomain gnome-shell[1815]: glamor: No eglstream capable devices found

but it is unclear it is causing problems.

The page on Glamor:
**PLEASE NOTE: Glamor has been [merged](https://cgit.freedesktop.org/xorg/xserver/commit/?id=1d76b02fac79c0360ae201e4d1a8ba0e9a00e810) into Xorg server 1.16 (released July 2014)**
https://www.freedesktop.org/wiki/Software/Glamor/

So yeah… bug could be in: xorg-x11-drv-intel and you probably don’t need it.

Because I use KDE Plasma, right? :thinking:

No… I don’t think the desktop make a differrence… let me try!

dnf group install "KDE Plasma Workspaces"
systemctl disable gdm
[paul@localhost ~]$ sudo systemctl disable kdm
Failed to disable unit: Unit file kdm.service does not exist.
Oops I meant enable, but it seems to not be installed... let s fix it:
sudo dnf install kdm
sudo systemctl enable kdm
sudo dnf remove xorg-x11-drv-intel
[paul@localhost ~]$ rpm -qa | grep xorg-x11-drv
xorg-x11-drv-nouveau-1.0.15-9.fc32.x86_64
xorg-x11-drv-ati-19.0.1-5.fc32.x86_64
xorg-x11-drv-vmware-13.2.1-11.fc32.x86_64
xorg-x11-drv-evdev-2.10.6-6.fc32.x86_64
xorg-x11-drv-openchrome-0.6.0-10.fc32.x86_64
xorg-x11-drv-wacom-serial-support-0.39.0-2.fc32.x86_64
xorg-x11-drv-wacom-0.39.0-2.fc32.x86_64
xorg-x11-drv-fbdev-0.5.0-5.fc32.x86_64
xorg-x11-drv-libinput-0.29.0-2.fc32.x86_64
xorg-x11-drv-qxl-0.1.5-12.fc31.x86_64
xorg-x11-drv-vesa-2.4.0-8.fc32.x86_64
[paul@localhost ~]$ 
systemctl reboot

Oops, I first choosed Plasma as a session but got a black screen:
sudo journalctl -b -1 -o short-monotonic --no-pager|fpaste
https://paste.centos.org/view/26e72a71

Interesting part:

[  115.095551] localhost.localdomain systemd[1]: dbus-:1.11-org.kde.powerdevil.backlighthelper@0.service: Succeeded.
[  115.096906] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 935, resource id: 6291474, major code: 20 (GetProperty), minor code: 0
[  115.098294] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 936, resource id: 6291474, major code: 20 (GetProperty), minor code: 0
[  115.098447] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 944, resource id: 35651597, major code: 3 (GetWindowAttributes), minor code: 0
[  115.098584] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 962, resource id: 58720257, major code: 18 (ChangeProperty), minor code: 0
[  115.098698] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 979, resource id: 6291498, major code: 18 (ChangeProperty), minor code: 0
[  115.098809] localhost.localdomain kwin_x11[1496]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 989, resource id: 6291474, major code: 20 (GetProperty), minor code: 0
[  115.098919] localhost.localdomain systemd[1224]: Starting XFCE notifications service...

So yeah… don’t try it with KDE.

Made a 3day link:
sudo journalctl -b -1 -o -p5 short-monotonic --no-pager to:
https://paste.debian.net/1145856

1 Like

So I:
sudo dnf install xorg-x11-drv-intel
and KDE now works fine…

And got:
sudo journalctl -b -1 -o short-monotonic --no-pager|fpaste
https://paste.centos.org/view/19f9fe0a

sudo journalctl -b 0 -o short-monotonic -p5 --no-pager > with_intel_drv.txt
https://paste.debian.net/1145858

Still have:

[  108.070481] localhost.localdomain kwin_x11[1506]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 7492, resource id: 6291498, major code: 18 (ChangeProperty), minor code: 0
[  108.071027] localhost.localdomain kwin_x11[1506]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 7496, resource id: 6291457, major code: 18 (ChangeProperty), minor code: 0

Realizing I am kind of hijacking this thread.

Ok, I did some search and I found this:

As I said before: I understand nothing. So, if you can translate this to a basic-user-lenguage, it’ll be appreciated. :nerd_face:

Well… the first link refer to problems in 5.5 kernels that are pretty all fixed in 5.6 kernels.

The other thing talk about is CPU sleep. When the CPU have nothing to do, it can stop executing instructions and wait for something to wake it. C levels indicate how deep it sleep… C0 the CPU is not sleeping… C1 it is a light sleep … C2 is a medium sleep … C3 a deep sleep. It is harder to wake from a deep sleep (like C3) than a light sleep like C1.
The deeper the sleep, the less energy the CPU use.
In fact, in case of a bug, it may be impossible to wake up the CPU in a deep sleep.

So there is a parameter on the kernel line of Grub, that allows to specify how deep the CPU is allowed to sleep. The parameter intel_idle.max_cstate=1 tell the CPU that it is only allowed to light sleeps.

sudo grub2-editenv - list
allows you to list the current variables and their values…
I have:
kernelopts=root=/dev/mapper/fedora_localhost--live-root00

So if I wanted to add intel_idle.max_cstate=1 I would do:
sudo su -
grub2-editenv - set kernelopts='root=/dev/mapper/fedora_localhost--live-root00 intel_idle.max_cstate=1'

You have to be carefull at recopying the root=[old value] part because you won’t be able to boot if you break it… maybe this is not the more secure way to do it?

It is so true that I am unable to reboot my computer in Linux anymore!

Ok, I am back with my system.
I did not preformatted the grub2-editenv line, then copied-paste (I think) from this message, but the -- was transform by this website to a single – character. Which I don’t know what it is. I just change the " to ’ to avoid variables substitions too.

It is more secure to edit boot entries… because you edit just one, and let the rescue entry intact. To do so:
sudo su -
cd /boot/loader/entries/
nano [the entry you want to modify]
at the end of options $kernelopts line, add your additional parameters.
Ctrl-O to write file, Enter to accept the current name
Ctrl-X to exit nano editor

Ctrl-D to quit the sudo shell

I found another two:

Note: if you type “freezes” in the search bar of the subreddit r/linuxquestions, it shows you several entries. The two above where the only ones that said “solved”. Both have the same " solution ".

They basically do in the firware menu (what we used to call BIOS before UEFI) what I am proposing to do in Fedora in the previous message by adding intel_idle.max_cstate=1 to kernel parameters.

Another freeze. So… I quit. I give up. I’m done looking for possible causes of the problem.

From what I’ve found in different places on the web, I know that the problem has to do with kernel. It is not a distro problem, as I have read it from Ubuntu (and his family), Manjaro and Arch.

So I will continue to update my system every day with the dnf upgrade command, and wait for a new kernel to arrive with the problem solved. If not, I will learn to live with it.

I’ve been on Linux since 2016. Until November 2019 I was with Ubuntu/Kubuntu and since December I use Fedora. Until the first week of April 2020, I never experienced a problem of this kind. Never.

I keep my system updated accordingly. And all I do is turn on my PC, surf the internet, listen to music and watch some movies. A basic, simple and quiet use. I’m really exhausted from looking for solutions to a problem I didn’t create.

I will leave the thread published in case someone else has problems of this kind and some discussed or shared here can be useful to them.

Thank you very much to everyone who participated and contributed in some way to finding the causes and a possible solution to the problem.

:nerd_face:

1 Like

Update: a week ago today (Friday, May 15) I downloaded, installed and downgraded my system to the 5.5.9 kernel for Fedora 31. Since then, I haven’t had any more freezes on my PC. I have used it without problems in all possible ways with normal and optimal performance. I keep my system updated with the command dnf upgrade --exclude=kernel* to avoid further kernel updates.

Below I share the links with the information and steps to follow for those who are interested in trying this alternative:

So far it has worked for me with Fedora 31, so I think it would be worth trying with those who have a similar problem with Fedora 32.

I will make weekly reports of the situation until June 15, which is the month of the change. If I complete the 30 days without a freeze, I’ll call it “solved”.

We’ll be in touch.

:nerd_face:

Weekly update: It has been two weeks since the installation of kernel 5.5.9. On Sunday, May 24th, shortly after four hours of use, I had a freeze again. The rest of the week the PC has been running smoothly, with average sessions of three hours. The balance so far: 15 days, one freeze.

I will come back next Friday with a new update.

:nerd_face:

1 Like

Weekly update: On Monday, June 1st I had a freeze with less than an hour of session time. On Tuesday, June 2nd I updated my system completely, that includes the kernel. I am currently using kernel 5.6.15 for Fedora 31, which means that the constant, unbearable freezes are back. So I think the dream is over; changing the kernel was not the solution either. It had to be tried.

This will be the last update. We’re back to step one.