Various KDE and system issues in 40.20241013 and 40.20241014 while device is in Power Saver mode
I'm encountering several strange issues that only seem to manifest after the device has been on for a few hours. These issues only started happenening after updating to version 40.20241014. Basically various parts of the desktop start to lock up like the taskbar and notifications. Soon after the screen stops updating for up to several minutes (the only thing updating being the mouse pointer). Additionally putting the device into sleep mode by closing the lid while this is happening puts the device into an state where the system time, USB devices and various other things start to act inconsistent. Putting the device into sleep mode can also trigger these issues to happen too (usually starting with an unresponsive lock screen).
I do not know what exactly triggers these issues, they happen randomly and even happen when nothing else is open on the device. Usually I have to reboot to fix the issues but rarely they will go away by themselves.
EDIT: I found out that having my device on Power Saver causes these issues to manifest, on both 40.20241013 and 40.20241014 after around an hour of use or randomly when putting the device in sleep mode. However the device hanging on shutdown due to either systemd-journal-flush or ostree-finalize-staged still comes up even if I keep my device on Performance.
I've attached a journalctl from a few minutes before the issues started happening up until I saved the log and rebooted along with an output of rpm-ostree status.
Device specifications:
CPU: Intel i9-13950HX
GPU 1: Intel Raptor Lake-S UHD Graphics
GPU 2: NVIDIA RTX 5000 Ada Generation Laptop GPU
RAM: 128 GB DDR5 5600 Mhz ECC
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.2
51 Replies
I'm seeing similar issue on my legion go since updating. Especially the sleep and unresponsive screen.
If you don't mind configuring plasma again, I would use something like https://github.com/JackPala/KDEnuker to delete all your plasma settings, reboot and start over. Could be some missconfiguration somewhere. I had something similar on my arch instalation and this solved it
GitHub
GitHub - JackPala/KDEnuker: Deletes all KDE related files in the ev...
Deletes all KDE related files in the event that your KDE Plasma install gets broken - JackPala/KDEnuker
I don't know if it's my KDE settings (I barely changed anything at all, only adding Window Rules for Steam and the Discord client so they don't pop over everything) as well as changing the power profile to Power Saver when on battery. Additionally in both 40.20241014 and 40.20241013 the system hangs on shutdown due to systemd-journal-flush or ostree-finalize-staged timing out if it was on long enough (30+ minutes).
this seems to be the same issue I used to have quite a while back, where the cause is actually messing with the power settings
TuneD seems to have a problem with it and cause those issues, but then, back then, I remember they changed the image to use PPD instead, which was when it went away
we're back with TuneD (tbf, I'm glad), which brought the issue back, it seems
Yeah all I went and did was set it to go into Power Saver when on battery. Although using tuned-adm to change the power profile to balanced or powersave also causes it
in particular, from what I remember testing back then, it's specifically to do with making power profile changes occur when certain percentages are reached, all in the KDE Menu
changing brightness values and the like doesn't cause it I think
oh, interesting
so it may just have to do with the profiles themselves?
what's the default profile used, isn't it balanced?
Yeah, but I changed it to be on performance when plugged in
it was set to balanced for everything by default
when I first installed bazzite
right, same here (interestingly, I haven't had the journal flush thing this time around... yet)
right
and back then did the issue occur?
I also tried removing settings one-by-one and even with all settings removed from a profile, it still causes issues
it might be more than just the profiles
no, yeah, I think from the moment you mess with the profiles, if the issue can happen on your hardware (seems like it doesn't apply to everyone), then it will
and, in my experience, only a fresh install where you just don't mess with any of it will fix it
but for sure, there's something else here happening that makes that issue seemingly irreversible
or, at the very least, irreversible so long as TuneD is present (fresh install with no touchy or update to use PPD instead were "solutions")
likely something upstream as well, I believe someone here talked about it also happening on Kinoite
I don't know how the issue could be irreversible like that. I also don't remember encountering the issue back then either (I might not have updated to the build that featured tuned).
But this sounds like a serious bug that Bazzite devs and possibly upstream should be involved in, since it's a very easy issue to encounter
I don't really understand its irreversibility either, might be a simple file that is generated when you manually intervene with TuneD, or something else, but at the point you do, it's seems it's game over
the problem with that is that it apparently only happened to a handful of people back then, it was me and maybe some 3 or 4 others who might've had different issues actually, it was weird
Did eveyrone involved have different types of hardware, like CPU and GPU?
as for whether that's a good representation or not, given that I don't know how many other people are running the same images, on a laptop, messing with the profiles and then also be willing/know to file a report of the issue, rather than ignoring it or otherwise jumping ship
I'm wondering if tuned is enabling a feature not compatible with most consumer hardware
I really don't recall, I was seeing if the post might still be here, but it might've been archived or removed when they switch around the layout of this discord
I went and read through that other post, it was affecting people with different kinds of hardware, like Intel, AMD and Nvidia
A Bazzite dev said not to use Performance at all saying it lowers performance on modern CPUs, yet in my case it would do the opposite
Games would run poorly on Power Saver and Balanced
but run properly on Performance
not sure if it's due to Lenovo doing things different on Thinkpad (I can't change any CPU clock or voltage settings in BIOS for instance)
nor change clockspeed of the RAM
might be that tuned was buggy back then and has been fixed since, or maybe it just reacts differently to different hardware? nonetheless, the fact is that the journal issue persists
Yeah I always get the journald issue if I tru to shutdown immediately after closing applications like the discord client. If I wait a few minutes it doesnt come up
huh, interesting
If an update occurs or the updater is ran once, an ostree finalize service hangs for 5 minutes at shutdown
oh yeah, that happens to me as well
and any time anything is overlayed and the image needs to be rebuilt
Yeah though sometimes it still happens even if nothing has been rebuilt
right, even if it was just an update check
I chalked it up to being the downside of messing with an atomic system, but that certainly doesn't sound normal
I'm wondering why nothing has come out about this from Bazzite devs or Fedora devs, even a simple warning on their discourse would suffice
Heck someone reported the issue on github too
might be that the people suffering from this issue simply aren't enough for this to be vocalized
did they? wow
Yeah, I can send the link in here to the github issue
GitHub
New power manager is tuned too low · Issue #1747 · ublue-os/bazzite
Describe the bug When I set the power profile to anything other than performance, my PC grinds to a halt. Basic functions like opening the application menu take > 10 seconds What did you expect ...
And more people are in this thread having the issue https://discord.com/channels/1072614816579063828/1296151842694107178
interesting, so the issue has become larger and more vocal indeed
And the last post there points to it being a tuned bug
specifically setting variables incorrectly
I hope someone's looking into it, or at the very least aware of the issue and planning to
oh
well then, surely that's being worked on as we speak and will be fixed eventually... right? (my experience with those issues was like 4 months ago...)
If a TuneD github issue hasn't been created for this already, I am going to create one
I'm going to try the workaround you posted and see if it fixes the issue on my laptop
thank you! if you do, could you send a link to it? I want to see if I keep up with it as well
Looks like there is already a pull request to fix this exact issue! https://github.com/redhat-performance/tuned/pull/688
GitHub
Explicitly support vm.dirty_(bytes|ratio) and vm.dirtybackground(...
The options interact within these two pairs: when dirty_bytes is set, dirty_ratio is automatically set to 0 and vice versa. Rollback thus does not work out of the box when setting these options via...
Following the workaround @Turtlewit posted appears to have fixed the issue on my laptop. The easiest way I could reproduce it (moving mouse rapidly over icons in taskbar) while pressing super key no longer causes the lockups. I was changing profiles via tuned-adm since changes in ppd.conf don't seem to apply instantly.
Yep, just added a note about restarting after changing
ppd.conf. Glad it seems to be working!OK I did a bit more testing and encountered the issue again, this time when un-fullscreening an old gamemaker studio 1.x game running through proton. I'm going to try rebooting and see if it still happens after a reboot.
does this also fix the hangup of rpm-ostree/journal, or does it have nothing to do with it?
I'll see if it does, I'm rebooting anyways since an old gamemaker studio 1.x game somehow triggered it even though I applied workaround
hmmm
try running the Updater before rebooting then ig?
just to check
OK, I'm back after a reboot and neither issues occurred (and yes I ran an update during last session)
No ostree service or journalctl service hung
Nice! Hopefully it works now, but it's possible there are other issues with the various profiles. To anyone having issues after workaround, it is worth checking that
cat /proc/sys/vm/dirty_bytes does not print 0 when on balanced or powersave. If it does, the workaround isn't working (the value is failing to be restored to the system default). tuned-adm verify may be helpful when troubleshooting.I ran that command and it sadly returned a non-zero value, however doing the usual test to reproduce the lockup has not resulted in lockup
No, non-zero is good!
zero is bad
oh ok
yeah it is getting set properly when changing between the power profiles
it is zero when in performance and a non-zero value when in balanced or powersave
That is the correct behaviour. Pre-workaround, the value will always be zero after switching to performance for the first time.
What I find interesting is that only certain hardware setups were affected by the bug. Like some people were able to change between different power profiles at will without lockups
Is it because they were using CPUs that could handle the incorrect values better?
I do know that many modern consumer CPUs (expecially high-end ones) are designed with very high power draw, and that they don't function very well if power draw is limited, unlike server and IoT CPUs which are usually far more efficient
I'm not quite sure, the values seem to affect disk write caching behavior, so disk speed and other hardware factors may affect performance when the bug occurs
Yeah that would make more sense, and would also explain the two services that could hang at shutdown once the issue would occur.
It's kind of funny though that even a high-end business laptop was getting affected by this bug. I guess one of the SSDs isn't very great or has strange bugs that this tuned issue was uncovering. That or even high-end business hardware is lowering in quality now despite prices being higher than ever.