Yes, I’m running Fedora 41. Also, running upower-1.90.8-1.fc41.x86_64 which seems to be the culprit like you noted. Thank you!
3 Likes
If unsure you can refer to my previous post to downgrade upower and mark 1.90.8 as version to be excluded from updates.
2 Likes
Thanks. It would be useful, for Debian, Ubuntu, Mint etc. to have the corresponding apt commands - though on Mint (my OS), at least, I’m still on upower 1.90.3. There is apt-mark hold <package-name> but I do not know whether, using apt, one can block a particular version of a package.
People that have been having the upower issue, an update for that has been pushed, Arch users can already take advantage of it, I’ve had it for a couple days and it works fine, maybe I’ll update to 3.08 and not risk my battery swelling since my pc stays plugged most of the day
2 Likes
Hello !
I’ve had the same issue on Manjaro 25.0.0 with a Framework 16 (BIOS 0.0.3.5) when doing heavy tasks on the computer, but upgrading upower from 1.90.8 to 1.90.9 completely fixed the issue for me.
Thank you very much for the help everyone, you saved me ! 
1 Like
I imagine it’s ‘normal’ to see occasional discharging even when plugged in (as both AC & battery provide power for peak draw)
It’s not just that - during use, the laptop is cycling between charging at ~32 W for ~5 minutes (60% to 70%) and then discharging at ~6 W for ~45 minutes (70% to 60%). This can’t be good for the battery, either.
Ignoring the issue of peak power draw, I expect the laptop to stop charging the battery when the charge limit has been reached. Instead, it’s disabling the AC entirely and discharging the battery.
I guess “hybrid power mode” is only used when the battery is charging. Otherwise it’s “battery power only”.
Just want to point out that AFAIK the upower 1.90.9 fix does not address the fact the the battery alternates between Charging & Discharging (visible with watch -n1 "cat /sys/class/power_supply/BAT1/status") on the Framework 13 AMD once the battery limit has been reached. Using official Framework charger, top-left expansion port in my case.
The upower 1.90.9 fix only addresses the problem that upower would decide that the AC adapter was unplugged if the battery was in a discharging state for a little bit, so you’d hear the OS chime notification, switch power modes, etc… And then it would think AC was re-plugged in once the battery switched back to Charging state, OS chime again, back and forth
The alternating between charging & discharging still happens … but upower 1.90.9 simply no longer interprets that as Ac power disconnect & reconnect.
I would like to understand from Framework staff if this discharging/charging flapping is expected as a result of their charging logic.
4 Likes
This is the behavior I am seeing as well. Are the upower folks aware of this?
1 Like
I don’t think the flapping charging/discharging has anything to do with upower. That’s reporting directly from the battery in /sys/class/power_supply/BAT1/status. Only the flapping AC disconnect & plugged in events were upower related. And it did come up on the GitLab issue’s comments.
It’s Framework’s charging logic and/or the fact that the 60W can’t deliver the necessary power all the time IMO
upower was just trying to use a heuristic & time threshold to go ‘hmm, the battery has been reporting as discharging for X number of seconds, we can assume this must mean AC has been disconnected, let’s switch upower’s state to on-battery: yes and send a d-bus event for AC unplugged.’
This heuristic & assumption was inaccurate for cases where laptop was plugged in AND discharging, and it is what was fixed/removed in 1.90.9. Because there are cases where it’s normal for this to occur, notably gaming laptops. Dell Hybrid Power, Lenovo Hybrid Power (paragraph under image)
I don’t know if discharge while on AC power is normal for the FW13. And it doesn’t happen when I charge my FW13 with a Satechi 100W charger. The battery status will remain solidly at ‘Charging’ (with a charge rate of 0W) when I use the Satechi charger and I’m at the battery charge limit. I’m still on 3.05.
2 Likes
I’m still on 3.07 beta and started experiencing the occasional charge/discharge loop (made even more annoying by the connect/disconnect system sound) regardless of charge limit setting.
It started occurring after I updated to the latest Bluefin image which included upower being updated from 1.90.7-1 to 1.90.8-1.
1 Like
I’ve seen such behavior too sometimes battery status was incorrect (charging instead of not actually being in charge but it wasn’t very impactful for usage)
1 Like
Respectfully to everyone discussing, I think going down the rabbit hole of why the FW13 battery seems to flip-flop between charging & discharging might be outside the scope of this particular thread since it is also happening on BIOS versions earlier than 3.08. So it wasn’t introduced by the 3.08 BETA.
My apologies if I contributed to going down this rabbit hole in this thread.
@Quin_Chou do you have any idea what the next steps are to promote 3.08 from BETA to stable release?
4 Likes
Unfortunately, the first post in this thread says they found another issue with the battery charge limits and this release will not be promoted to stable.
It sounds like it’s only an issue when both the battery charge limit and battery extender are used and they are working to fix it.
2 Likes
oh I had no idea battery extender and charge limit are designed to work together.. I always think it is one or the other.
1 Like
Fedora 42 has updated upower “naturally” so my orchestral charging noises are now supressed.
The nuances of the other issues with the firmeware and linux it way over my head.
upower.x86_64 1.90.9-1.fc42
1 Like
Was going to share this as well. Upgraded to Fedora 42 today and upower has gone up to 1.90.9. So far I haven’t observed any regressions with 42, so for Fedora folk this might be an alternative option to excluding 1.90.8 through DNF.
FWIW 1.90.9 has also made it to stable in F41 so no need to rush to F42, unless you want to upgrade anyway of course.
1 Like
Yep, looks like this release has been held 
To framework engineers, is there any chance we could incorporate @James3 's excellent work fixing bugs in the charging logic (and elsewhere) in 3.09?
2 Likes
The description of battery extender implies it’s function is to stop the battery staying at 100% for more than a few days.
Therefore, the way I see it, they are definitely not supposed to be used together.
However the BIOS settings seem to let you use them together!
And, even more confusing, with BIOS 3.07 you seemed to need to enable the battery extender if you wanted the user specified charge limit to work!
So if you were unsure, you might now assume you need to use the two together.
The only way I see that would make sense for the two to be used together is if the battery charge limit is used to inform what “100%” means to the battery extender. If the charge limit is set to 80% then the battery extender should use 80% as the reference point, and go as low as 65% after 7 days.
For example, if the charge limit were 100%, then, as per Framework’s first post in this thread we should have have:
| Battery Extender Duration | Battery State of Charge |
|---|---|
| 0-5< Days | 99% → 100% |
| 5-7 Days | 90% → 95% |
| >7+ Days | 85% → 87% |
If, however, the charge limit was set to 80% then the above would translate to:
| Battery Extender Duration | Battery State of Charge |
|---|---|
| 0-5< Days | 79% → 80% |
| 5-7 Days | 70% → 75% |
| >7+ Days | 65% → 67% |
From what people have reported so far this doesn’t appear to be the case and I don’t think Framework ever commented on the interaction between the two. Even then, with the addition of the 5% floating range, the benefits of the above scenario would be questionable, though still “nice to have” feature.
I agree. If the above outlined scenario is not how they are intended to work when enabled together, then the BIOS should be designed such that enabling one disables the other.
At the very least a note should be added to whichever one takes precedence.
Since the charge limit clearly allows for a concrete, and presumably with any sense more conservative setting, IMO enabling it (i.e. setting it to anything < 100) should take precedence and disable + grey out the battery extender.