I’m opening this thread to understand if it’s just me.
I run opensuse TW, so I get kernel updates quite frequently.
A couple of days ago I decided to give Mario Limonciello’s PPD patch a try (always looking for ways to make my framework run more efficiently, since I’m not happy with battery ATM).
I rebooted, and when I started playing around a bit with my framework not attached to power, I immediately noticed that the cursor was lagging behind. It would follow the movement of my hand for a couple of seconds, then suddenly freeze and jump a few centimeters away. Made the movements completely unpredictable.
I initially thought this had something to do with Mario’s PPD patch I was testing, but then uninstalled it and the problem was still there.
Now I think/hope I’ve finally understood that the actual fix is to rollback to a previous snapshot of my system, which runs 6.6.6 instead.
I had the same problem on my dual boot F39 install (which was on 6.6.8 meanwhile).
I suspect that starting from 6.6.7 something is affecting performance so bad, that the mouse cursor lags behind. And I don’t think it’s just the mouse, because gaming performance took a hit as well, with very noticeable lag in graphics and freezes in audio.
Luckily thanks to tumbleweed snapper I was able to go back in time a week or so, and now my system is snappy as ever.
But I wanted to know if anyone’s noticed anything similar, on any distro, running kernels 6.6.7 and later.
You might want to ask for board version as well as behavior on and off of power.
11th gen, kernel 6.6.8, no issues on or off of power. Maybe it’s an AMD thing. It seems like the kernel, drivers, etc have not yet caught up to the hardware.
Yeah I really hope this hardware gets optimized, because I’ve read wonders about it, and always have been an Intel guy (my 11th gen Dell XPS was working wonderfully under Linux, excellent battery life, too!). So I’m a bit disappointed with the current state of things.
I guess that Windows IS (unfortunately) superior when it comes to supporting newer hardware. Linux gets there eventually and does a better job at maintaining it in the long run. But getting a new platform to run smoothly under Linux can test your patience
I hope that you are able to get things sorted out. As one in line for the FW16, I am following the AMD threads closely in the hope that I have some clue (which would be a first for me) when the machine does arrive. Best of luck getting things sorted out, and happy new year a bit early. Have a great day.
I noticed recently that my CPU frequency can get stuck in the 400-550MHz range. This results in a rather laggy experience, though not strictly touchpad/mouse related.
I haven’t had much time to dig into it yet, but when it does happen, CPU governor and clock frequency min/max shown by cpupower frequency-info look normal, it’s just the line
current CPU frequency: 1.67 GHz (asserted by call to kernel)
that will only show 400MHz or 500MHz regardless of load. The easiest way to see this is with s-tui. Run a stress test and observe that some/all cores are stuck at a low frequency.
The easiest way I found to reproduce this is: set power profile to Power Save (I use KDE but Gnome should have a similar slider), then unplug, then reboot. Now run a test with s-tui and observe core frequencies.
Pluggin in, or adjusting the power profile at this point has no effect on the stuck cores. Only a reboot (typically after setting power profile to balanced/performance) seems to fix it. Even then, sometimes one or two cores get stuck at a lower frequency.
I’m not sure this is the issue you are experiencing, but maybe it gives you something to start from.
Note: I am using Mario’s patched ppd on Fedora 39 KDE, but saw this behaviour prior as well - though I was typically setting the energy_performance_preference manually.
I’m running Arch Linux with linux kernel 6.6.8, and I haven’t experienced this at all. I use stock power-profiles-daemon 0.13, and I only recently switched it from “balanced” to “power-saver”, so I’ll keep an eye out for cores stuck at 400mhz …
Another command you can use to check on core frequencies is turbostat
Running Fedora 39 here (on a FW 13, AMD 7840). Currently on 6.6.8-200. No issues. I can’t remember if I was running 6.6.6 or 6.6.7 before 6.6.8, but I never noticed any lag or touchpad issues.
Just tested a few more times after switching back to power-profiles-daemon-0.13-2.fc39.x86_64 so I can control the setting manually and I don’t think it is related to the epp setting.
base state - platform_profile: balanced, scaling_governor: powersave, epp: power - all cores can reach 4000+MHz. Kernel is 6.6.8-200.fc39.x86_64
Test 1: reboot, still on power, all cores can reach 4000+MHz. epp starts out set to performance. set it back to power
Test 2: reboot, on battery, cores 8-11 stuck at 1666MHz. Changing epp, platform_profile has no effect. Setting scaling_governor to performance lets all cores reach 4000+MHz. Set scaling_governor back to powersave and cores continue working normally.
Test 3: reboot, on battery (epp was performance at time of shutdown) - all cores end up stuck at 544MHz. Toggle scaling_governor from powersave to performance and back to unlock core frequencies.
So far, the only thing I find that makes a difference is whether I’m on battery or not during boot (even this, I think I have not tested enough to prove), but at least epp does not seem to make a difference.
Note: to toggle the scaling_governor: sudo cpupower frequency-set -g performance && sudo cpupower frequency-set -g powersave
I’ll try to test some more this week.
@fw13amd were you able to determine if slow clock speeds are the cause of the lag you experience? I didn’t mean to highjack your thread…
On my end I tested once again yesterday, with a starting condition of TW running 6.6.6 + PPD patch by (super) Mario, a combo that proved its worth for several days prior.
Therefore I tried to take the distro update again (to 6.6.7 plus various other firmware packages), and it seemed all right for my whole working day, but I guess it’s just because I work on AC power. As soon as I took it off the adapter, the touchpad became sluggish again. So that update on my system is a no-go, irrespective of whether I run Mario’s PPD.
I kept an eye on KDE’s System Monitor, and couldn’t observe any cores being stuck (some had a certain tendency to rest more on the 400Mhz/base freq, but eventually even those spiked up to higher values).
For this reason, I think that my problem has a different root cause than the one you reported about frequencies being stuck.
And at this point I dunno if my problem is distro-related (although I noticed the very same symptoms on F39 running 6.6.8, so I suspect that even if my problem is NOT caused by cores being stuck, there is still something fishy in 6.6.7 and/or 6.6.8 that wasn’t there in 6.6.6).
But I think that we are dealing with two distinct problems here
Update: today I saw that 6.6.9 was out for TW, so I gave it another try.
I’m happy to say that the touchpad is back to normal (need to test a bit more, but hasn’t shown any stuttering on battery so far…). So I think that the problem came from some package of my distro and seems to be fixed now.
I’m also keeping Mario’s PPD patch and haven’t noticed any issues with it so far.
Tagging as solved since it’s now a non-issue for me.
@bikefrivolously it’s indeed better for you to open a dedicated thread at this point, if you’re still experiencing that issue.
I read something similar from a Windows user whose cores where stuck at 513Mhz IIRC (until a reboot), running the latest BIOS v03.03. You should find it here:
So, in a somewhat unexpected plot twist, I got the problem again after getting some more distro updates.
Eventually I figured out the culprit: Insync, the app I use to sync my Google Drive on Linux, was broken from a certain opensuse TW snapshot onwards, probably some kind of dependency problem.
To workaround that problem, I would install a different version of this package to play nice with the latest dependencies that came with more recent snapshots, and that package seems to eat up quite some CPU to the point where the cursor becomes laggy. It has nothing to do with the kernel tho, that was just a wrong deduction on my side.
I’ve raised this concern in the insync forums, fingers crossed.
EDIT: it’s about kworkers eating up a lot of CPU or I/O while doing an Insync sync on my home partition which is a Luks2 encrypted btrfs.
The app itself might be abusing I/O, but it may also be linked to btrfs not playing nice with encryption.
I am observing the exact same behavior. Opensuse TW with current kernel as of today (6.6.11-1-default). My system had become almost unusable. Thanks for the workaround by toggling the scaling governor! This unlocks the system for me.
I haven’t been paying enough attention, but occassionally the laptop becomes very “laggy”, this is tryicky to describe, the mouse will go super unresponsive and window animations won’t animate and today I was on a web based video conference call and the audio buzzed as it fell apart.
I think its the issue descibes above, I’m running Fedora 39 with Linux 6.7.7-200.fc39.x86_64 kernel, no nonsense as vanilla as it gets.
Reading above I can’t quite work out how to tell if the cpu has decided to go into a power save or cap the mhz to 500, is there a command?
Given the feedback above people are relating it to going into and coming out of sleep, but for me it just happens whilst I am using the laptop.
Any advice would be great, I’m tempted to go onto Fedora 40 now to get 6.8 and hope that magics a solution, that seems a little too much… Ideally I’d like to diagnose it first.
Update:
Now I’ve looked at s-tui I can see its pretty amazing, will try this next time it goes “laggy” and report back:
