Ok, but I’m curious if versions previous to 1.90.7 have the issue as well? Where is the space that this became a thing?
Definitely a upower thing, I got the issue on BIOS 3.05(AMD 7040 Series)
1 Like
I’m seeing the battery swapping between charging & discharging on a fresh, fully updated install of Ubuntu 24.04. upowerd is version 1.90.3.
BIOS 3.05 with battery limit at 80% Using the official Framework 60W charger.
If you do:
watch -n 2 "acpi -b"
And just watch it while doing normal activities you’ll see it switch from “Charging” to “Discharging” intermittently. And the little lightning icon next to Ubuntu’s battery icon in the top panel will disappear and reappear.
Tested with a 100w charger I have and this doesn’t occur. Never switches to discharging, even when I run stress -c 12 to simulate heavy load.
@Matt_Hartley for visibility as Ubuntu LTS is officially supported.
I think some of the upower GitLab commits between 1.90.3 and 1.90.8 are about detecting situations where a “low-power” charger is connected so maybe at 1.90.3. So perhaps I don’t have some of the fixes for that scenario (one of which may have caused the issue at 1.90.8)?
I would love to have more clarity over the intended behavior from Framework staff. For the battery limit, charge behavior while on AC, etc…
In this old post Kieran mentions the mainboard runs in a “hybrid power” mode where it will draw from AC and the battery when it’s plugged-in to allow for higher performance envelope. So maybe it’s expected it’s discharging while on AC?
All,
For us to track and address this, we need specifics. The initial gitlab post has “Arch Linux on a Framework laptop” which lacks critical information.
All affected, please provide, using this flow (please keep it short and to the flow below):
Framework Model:
(Please be specific; Framework Laptop 13 AMD Ryzen 7040 Series, Framework Laptop 16 AMD, Framework 13 , Framework Laptop 13 13th Gen Intel Core, etc - because this is a FW13 forum thread, likely only affecting FW13 folks, but we need details on which hardware is affected)
Distribution and release affected:
(Arch users, just provide the kernel used and the last time you updated)
Your upower version:
(This is the version you are running, after fully being updated with your packages and confirming the behavior still exists)
BIOS version:
(This means we expect you are fully up to date here)
Confirming yes or no you are using stock power management:
(Confirming there is no additional governor, TLP, etc is use - your running a stock configuration. For Arch users, you are using TuneD-PPD or PPD only.)
Power adapter used:
(Framework provided or if its yours own, we need brand, model and power specs)
Which expansion bay are you connected to for power:
(As this is for FW13 models, with the laptop facing you, please indicate if it is top left/ top right, bottom left/ bottom right.
I acknowledge this started out as FW13, Arch in this thread. But I suspect this may be affecting other platforms as well, hence the details above.
Please do not skip over any of these details, I need all of this to have something actionable to pass along to engineering. Thanks
1 Like
cc @Jesse_Darnley to monitor and track.
2 Likes
Framework Model:
Framework Laptop 13 AMD Ryzen 7040 Series
Distribution and release affected:
Ubuntu 24.04, fully updated as of this moment
Kernel 6.11.0-21-generic
Your upower version:
1.90.3
BIOS version:
3.05 - due to ongoing bugs with battery limit & inability to downgrade I haven’t updated yet, and won’t until at least 3.08 is out of Beta.
Battery limit in BIOS set to 80%
Confirming yes or no you are using stock power management:
- stock power management on Ubuntu 24.04.
- Power Mode: Balanced in GNOME’s power profile picker
Power adapter used:
- Framework 60W power adapter - switching between discharing & charging occurs during normal usage.
- Satechi 100w ST-UC100WSM w/Anker 100w USB-C cable - when I first plug in this charger it toggles between charging/discharging a few times rapidly, I hear Ubuntu’s unplug notification sound. After a few back and forths it then stays stable without any further alternating to discharging. USB-C PD negotiating charge rate?
Which expansion bay are you connected to for power:
top left
Repro Info
- Set battery limit of 80% in BIOS
- Let FW13 charge to battery limit of 80% on Framework official 60w charger
- Run
watch -n 2 "acpi -b"in terminal - Open Firefox & watch YouTube
- Observe terminal.
acpi -boutput will alternate between: “Charging, 80%, HH:MM:SS until charged”, “Discharging, 80%, HH:MM:SS remaining”, “Charging, 80%, charging at zero rate - will never fully charge” - Observe Ubuntu’s battery icon at the top-right on the top panel. Lighting bolt icon will appear & disappear.
For Step 4, even just opening a moderately complex website in a new browser tab causes the acpi -b output to toggle to ‘Discharging’ briefly before returning to ‘Charging’. CPU boosting briefly & overall power draw exceeding 60w charger output?
NOTE - while the acpi -b ouput is flipping for me, the on-battery field of upower -d output remains stable at on-battery: no
1 Like
Thank you so much for looking into this!
I am also seeing this problem. KDE audibly signals flipping between charging/discharging a few times, but it’s inconsistent. Sometimes it happens >2 times, sometimes it happens only once or twice. There’s a period of anywhere from 2-10 minutes (roughly) between cycles. I noticed this began on Apr 7 2025. I am not having issues with keeping my computer charged. My workload consists of running a few docker containers with VIM and a few browser tabs. Not very heavy.
(I am coming from the 3.08 BIOS Thread)
Framework Model:
Framework Laptop 13 AMD Ryzen 7040 Series (7840U)
Distribution and release affected:
Arch Linux (6.13.8, last updated Sunday, Apr 6)
Your upower version:
(This is the version you are running, after fully being updated with your packages and confirming the behavior still exists)
UPower client version 1.90.8
UPower daemon version 1.90.8
BIOS version:
(This means we expect you are fully up to date here)
3.05, for same reasons as pgroheIO.
3.05 - due to ongoing bugs with battery limit & inability to downgrade I haven’t updated yet, and won’t until at least 3.08 is out of Beta.
Confirming yes or no you are using stock power management:
Yes, I am using stock power management. I am using PPD. TLP is not installed, powertop is but only for monitoring.
Power adapter used:
Anker 715 Charger (Nano II 65W)
Which expansion bay are you connected to for power:
Top Left / Top Right
I just started experiencing this issue today after doing the latest round of Fedora updates. FW13 keeps flipping between charging and not charging and sometimes completely freezes. This was NOT occurring yesterday.
Yes because fedora pushed the update upower package to Fedora 41 yesterday/today.
upower developer should cancel the useless update
If it ain’t broke don’t fix it
Framework Model:
Framework Laptop 16 AMD Ryzen 7040 Series
Distribution and release affected:
Archlinux 6.12.21-1-lts
I had to rollback to the lts because the GPU doesn’t work anymore correctly on the latest versions of the kernel. But that is a separate issue.
Your upower version:
1.90.8-1
BIOS version:
Fully up to date according to fwupdmgr
0.0.3.5
Confirming yes or no you are using stock power management:
- stock power management on KDE.
Power adapter used:
Dock dell WD19S
Which expansion bay are you connected to for power:
top right
Repro Info
- Let battery get full
- Do not have any heavy workload
- Observe that the power delivery/battery switch irregularly
This wasn’t happening before with the same hardware. This is a recent regression.
Its the distros packager that would downgrade it. This also usually doesn’t happen in Fedora.
Quickly checked and there was no single comment on any of the package updates about this issue or bad karma (on fedoras bodhi that is) so no wonder it was just pushed through
The GitLab issue is pretty active with comments so work is happening on a fix. If you’re affected on 1.90.8 and want to assist you can build the fix branches from source & provide feedback there.
I think a Framework EC engineer adding a comment on the GitLab issue clarifying the EC logic for when it reports charging & discharging would help as the upower maintainer had some questions about that in the issue comments:
Anyway,
Does someone also file an issue to the framework?
They have to give us a summarized battery status when they are doing some features on your battery, rather than only charging/discharging when the line power is attached. Otherwise, it confuses the user, and the upper layer > applications are difficult to process such kind of battery status information.
1 Like
I tested the proposed, merge requested fix over in GitLab and it seemed to resolve the issue on my FW13. This was on a fresh, fully updated Fedora 41 install running upower 1.90.8 that was experiencing the problem prior to using the upowerd built from the WIP branch.
Hopefully they can get that fix out soon. Looks like they’re still validating the fix with users of laptops from other manufacturers.
Framework Model:
Laptop 13 AMD 7840U
Distribution and release affected:
Fedora 41
Your upower version:
upower-1.90.8-1.fc41.x86_64
BIOS version:
3.05
Confirming yes or no you are using stock power management:
Yes
Power adapter used:
Xiaomi AD65G
Which expansion bay are you connected to for power:
Top right, top left, bottom right, bottom left
Note: only affects display, the performance 53W fast, 35W slow, 30W STAPM power are all unaffected
upower fix merged and released upstream. It should start filtering out to distros soon. Fedora should be getting it soon as the upstream code author seems to also be the package maintainer for it.
3 Likes
When I get a mo I am going to play with the EC code to experiment with different behaviours:
- change it so that it never switches to battery while the psu is plugged in. I just don’t like its current behaviour and I think it is causing some of the battery cycling behaviour.
- the battery continually recalibrates itself so using battery percentages to decide whether to charge or not is doomed. The calculations need to be deterministic and use hysteresis.
- implement state transition counters and report them in the ectool chargecontrol command, so we can keep track of even the really short charge/discharge events that would otherwise go unnoticed.
- analyse why it appears to overcharge (above configured charge limit) while suspended with the psu plugged in.
- stop it from setting the CHARGE flag when it is idle and not charging.
- the EC source code for charging is a bit spidery and difficult to understand, so the above 5 things could take a while.
- if there is a mode where both the battery and psu is supposed to be on at the same time, powering the cpu, then i will add a state for that so one can see when it happens by looking at the counters.
I have found a way to play safely with the EC code without risking a bricked laptop. I have a modified version of the ec firmware writer that helps make it safe to use and not accidentally write bricked code.
Essentially, I only ever write to the RW second image in the firmware, and if anything goes wrong I can easily force it back to RO. Simply powering off resets it to RO.
3 Likes
Awesome, good luck! I really appreciate all the work you do for this community! 
I will add: Is there anything we can do to support you?
1 Like
Looking through the source code, I have spotted what might be bugs, not 100% sure yet, but something that would help is people reporting which slot the PSU charger was plugged into when problems are observed. The EC code follows a different code path depending on which slot the PSU is plugged into.
As per the slot numbering here:
The EC source code is a little confusing, because it numbers all the slots differently to that web page, but I can map between the two.
Summary:
What I am looking for is people reporting the problem when charging in slot 1,2 but not 5,6.
Something like that.
1 Like
It’s very odd, in Arch Linux KDE (I charge with Port 1), I see the charging widget flapping between Charging, Discharging, and occasionally, Fully Charged. Sometimes it displays Time to Full or Time Remaining respectively as absurdly high numbers (dozens-hundreds of hours).
I am running the following system:
$ uname -r
6.14.2-arch1-1
$ upower --version
UPower client version 1.90.9
UPower daemon version 1.90.9
Checking the system monitor, I sometimes see a small power draw or small charge put on the battery. I don’t know if that’s normal “floating” behavior (I have the charge limit set to 90%) or is undesirable “micro-cycles.” I do not hear an audible jingle, and the charge icon is always present, but this behavior is a little concerning if I’m being honest. Is this happening simply because upower isn’t getting the correct signals from the EC?
