This is going to be out best bet to spot where it’s happening.
1 Like
I appreciate this is a reddit post, but it seems people with the Steam Deck, which I understand to be similar hardware also have experienced the CPU locking to 400Mhz:
Update on my end, no issues so far, but I thought the above might be interesting.
CPU throttling is triggered by the EC, it is not equatable across vendors or even models within a vendor.
Ok, so the lagging started again, and I got these screenshots from s-tui suggesting its not the mhz cap.
The top graphs were going red, but not all the time… any advice?
See if the GPEs are going up excessively while it happens (/sys/firmware/interrupts). If so it would suggest that there is a sensor the EC is reading that is high and while it’s high the EC is asserting the SCI so frequently it slows the machine down.
And by chance does this happen with a dock recently connected or disconnected? There is another thread that has found a correlation to excessive GPE with a dock connect/disconnect.
I do not use a dock.
Now I am making a mental note of when it occurs, it could be soon after plugging in a usb-c power supply of which I use 2 in different locations, a UGREEN 65W USB C Charger Plug 2-Port GaN Type C and an ASUS USB C that came with an ASUS ZenBook.
The other result of the lagging is after the reboot, the screen brightness is set at its lowest. This could be a result of the auto brightness not take effect during the “laggy” period and its just a cumulative result of not being able to be set or something else.
Anything else you can think of I can attempt to run during a “laggy” phase to help diagnose?
You can add the patches for the cros-ec driver and then use the EC tool to get an EC console log when this occurs and share that with Framework support.
Can you direct me to where to find instructions for that.
Also, this morning Fedora 39 upgraded to Linux 6.7.9-200.fc39.x86_64, I was on 6.7.7 before when I experienced the lagging. So have experienced the lagging on both kernel versions at least.
If you haven’t already I suggest installing the bios 3.03b which has an updated EC. Its conceivable to be a similar manifestation as the DPC violation in windows which was fixed in 3.03b.
This is the GPE that other people have complained maybe it’s this?
This thread has the patches and tool I talked about for getting EC console log.
Ok, given I don’t have the mental capacity to handle the EC tool scenario and I only want to change one thing at a time in the spirit of the scientific method I decided to try the 3.03b, will report back should the laggyness emerge.
Still using Beta Bios 3.03b, Linux 6.7.9-200.fc39.x86_64 on Fedora 39, Gnome 45.5 I got the laggyness again.
I had just rebooted after a “Software Update” and was simply web browsing using Firefox, the laptop was charging from about 70%.
Here is the s-tui screenshots a minute apart whilst the laggyness is happening.
I plan to go on the Fedora 40 Beta once that is released, its pretty soon, but I haven’t got my head around the Fedora Schedule as it looks like the Beta date has been moved a few times.
For reference this is what s-tui looks like when its running normally:
Ciao everyone,
as the OP of this thread I think it should be renamed as it’s now being used to discuss issues of stuck cores which, as it later turned out, were different than my root cause (which I have identified here in a 3rd party app: [TRACKING] [FW 13 AMD 7840U] Did kernels >=6.6.7 make your system/touchpad/mouse laggy? - #18 by fw13amd)
It would be a pity to lose the history that built up over time, so I guess that keeping the discussion going on here is the best course of action and also avoids wasting precious MOD time to move messages to another thread.
—
@Matt_Hartley I would just kindly ask, if possible, to copy paste this message at the beginning of my OP, for new visitors/Googlers to see, and rename to somethink like [FW 13 AMD 7840U] Cores stuck at low frequency and system lag. Thanks! 
Checking in.
It’s been a week and I’ve upgraded to Fedora 40 Beta with 6.8 kernel (Linux 6.8.1-300.fc40.x86_64) on Friday 22nd (a bit early, but honestly Fedora Betas are more stable that most production OSes).
No sign of the “lagging”, as I think about it I wonder if its related to “Suspend”. The only occassion I see Suspend happen is when I haven’t explicitly triggered it is after a reboot and I haven’t logged in… I’ve disabled close lid suspend.
So potentially the issue is caused by a post unsuspeded state after I’ve absent mindedly logged in… not the greatest scientific data, apologies.
First instance of the “laggyness” since Fedora 40 beta installed.
It happened after leaving the machine on over night (which I don’t normally do) and apparently going to XKCDs “Machine” in Firefox
Here is a screenshot I managed to get in the lag:
Linux 6.8.4-300.fc40.x86_64
Immediately post install of the 3.05 bios I had the “lagging”.
I’m going to do a fresh install of Fedora 40 once that is out of the beta.
My concern is some of the recommended tweaks for the things like sg_display and mesa drivers are too many variables to make for a fair clean reproducible test.
I try not to get too gnarley with my linux configs & tweaks, and I do like to track them, the only other slightly off piste thing I do is configure the laptop not to sleep when closing the lid which is controlled here /etc/systemd/login.conf I can’t imagine that has any impact, but given the tapestry of libraries and configs I can’t be sure.
For completeness:
Regarding the CPU getting stuck at 0.54GHz I do believe it’s related to ppd. I have switched to auto-cpufreq and haven’t seen it re-occur.
This behavior was sort of fixed for me for a while, but it’s back now (or at least a similar behavior). Frequency is not hard capped this time, but will stay below 1 GHz generally, with short spikes to up to 1.7 GHz. Power as measured by ryzenadj does not exceed 11.7 W. I’m using ryzenadj to monitor only, I’m not actually tweaking anything. Needless to say, performance is badly capped in this state.
It’s difficult for me to pinpoint which change brought this behavior back. I am on OpenSUSE Tumbleweed, so I get regular kernel updates. I also moved to PPD not so long ago and upgraded the FW. PPD definitely had a beneficial effect on battery life and in general works well. The system only seems to gets stuck in this low-power state after suspend-resume cycles.
To get the system unstuck, I tried changing the power profile, stopping or re-starting the PPD service, setting scaling_governor (this used to fix it for me) or energy_performance_preference manually, plugging or un-plugging power supply, suspending and resuming (both on AC and on battery), to no avail.
This is and AMD FW13 (7840U) on Kernel 6.8.8, power-profiles-deamon 0.21, FW 3.05.
Any hints on what to try to get the system unstuck? I know a reboot will fix it, but that’s not an acceptable solution while working. Hibernating and waking the system back up works to fix the frequency scaling, but then Wifi is broken…