Since an update somewhere in the week before Christmas (I think FEDORA-2022-69d193c666) my desktop (and everything related to it) stops updated after a few minutes. I need to explicitly ‘wakeup’ the desktop by clicking on it or alt-tabbing.
Widgets, alerts, clock, notifications, volume controls stop working.
Applications keep functioning normally and seem unaffected.
When using keyboard volume control these error messages appear in journalctl:
plasmashell[2169]: kf.plasma.quick: Couldn’t create KWindowShadow for Osd_QMLTYPE_833(0x7f82ac00c850)
System is a fresh install (1 month) F37/KDE with Freeworld graphics drivers
No permanent yet.
Manually activating desktop solves problem for the next 2-3 minutes.
Tried:
-booting older kernel (6.0.12-6.0.15) - no change
-updating AMD GPU/graphics drivers (AMD GPU not being used (Radeon RX 6700 XT - External / eGPU - Wayland))
-reverting back to default F37 (non-freeworld) drivers - no change
-creating new user, reboot, login as new user, no applications started, wait on blank desktop, after 2-3 minutes desktop freezes.
-waited for today’s Plasma 5.26.5 update, but to no avail.
System has very limited usability in this state, any help is much appreciated!
Thanks!
Forgot to mention that when I select X11 on the login screen I get a black background with only the mouse cursor visible. Haven’t captured any error messages, but there are loads.
That one contains some amdgpu firmware updates, focus on errors related to amdgpu while looking through logs.
Have you tried reverting it to the last known working version (e.g. from linux-firmware | Package Info | koji with that oneliner)?
Also check whether same thing’s happening if you disable Plasma compositing (Alt+Shift+F12).
That’s rather high, unless this device is passively cooled or you had been running something heavier while executing inxi.
I can’t help, because I have a significantly different configuration, BUT I wanted to welcome you to the forum and commend you on your great first post.
@ozeszty
Thanks for your reply!
The system is at the latest available BIOS level and worked fine until the December updates.
Disabling Plasma compositing does not do anything. From what I’ve read that is not an option in Wayland (only X11)
I’ve been looking into roll-back options as you suggested but I’m a bit hesitant as
a) the more changes I make the more difficult diagnosis becomes (the system is now plain F37KDE with the only non-standard thing being the nonfree AMD drivers)
and
b) this is my main system so continuity/availability is an issue.
but I will look into it again and update this thread.
Thanks!
The hint by @ozeszty got me looking further into compositing.
I noticed there is no “rendering backend” option on my System Settings → Display and monitor → Compositor page.
According to the documentation there should be… Never noticed it missing before, maybe someone can comment.
I think this setting was removed a couple of releases ago.
There’s a newer one on the ASUS website and it might (or not) provide something newer amdgpu firmware requires and make it work.
Then your best bet for now is to install the previous linux-firmware - much safer than installing some packages from non-fedora repositories and most likely to actually make your system usable again (if the problem started after this update). That firmware is loaded by devices every time they are initialised, not written to them like BIOS.
It’s hard to say what changes external installers made to your system, you can run dnf dsync --refresh to at least make sure you’re up to date with currently enabled repositories.
Whehey, you’re right!! I checked earlier this week but v5.05. was released on 3-1.
Unfortunately no changelog is provided by Asus.
I’ll update and report back.
Thanks!!
That might also be a hardware issue, does it also happen on live-booted system?
Anyway, look through logs, dnf history and then dnf history info x at when you remember it started.
Mesa was upgraded to a new branch (22.3) also before Christmas, that’s also worth checking out. In general it’s best to (at least start to) debug such regressions as soon as possible, to minimize the amount of suspected packages.
Thanks again for taking the time to look into this, much appreciated!
I booted from the F37 Live USB stick from which I installed this system in November and it ran flawlessly for over half an hour. So that excludes hardware/bios as a possible cause.
The problem started on 22-12, and according to dnf history there were 2 upgrades done that day,most importantly kernel , mesa, firmware, xorg.
This morning I tried:
dnf distro-sync --allowerasing --skip-broken
swapped mesa-va/vdpau from freeworld to default
removed mesa-amdgpu*
reinstalled mesa*
all to no avail
A bit astonished that I cannot find any other mention of this issue anywhere, not as if I have any exotic hard-or software.
I don’t have time to completely wipe and reinstall the system, but I’m afraid it’s the only option left.
But then I still run the risk of the same error occurring after an update.
If there ever was a case for an immutable distribution…
Will be looking into Kinoite.
You could also revert updates from that day one by one (by installing previous versions mentioned in dnf history info x) to check which one is the culprit. Get them from koji, because those are too old to be available in the repositories and supported by dnf history undo or dnf history rollback.
Nonetheless you’ll have to find some hint in the logs pointing the cause, to be able to report and get it fixed.
Thanks for the help, esp. @ozeszty !
But it still leaves questions… boggles me that this bug was not found in testing (either by the Mesa team or the Fedora maintainers)
According to the Phoronix article all recent AMDGPU hardware is affected by this issue and I’ve searched high and low before opening this bug report but no one else seems to have experienced (or reported) this.
This is the first time in over 25 years of daily Linux use that I have had an unusable system (through other than my own fault) so this experience will lead to some contemplation…