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.
The latest BIOS for the FW13 tried to fix it like this:
- If the charge limit == 100%, enable the Battery Extender.
- If the charge limit != 100%, disable the Battery Extender.
Except that the case (2) failed to disable the Battery Extender in all edge cases.
The battery extender mitigates the issue of leaving the battery at 100% for extended periods of time. It stress and ages the battery prematurely.
If you have limited the battery to say 80% and leave it at 80% for extended periods of time, it is unlikely to stress and age the battery prematurely, so the battery externder is not needed.
Another feature that is used is the âBattery sustainâ.
It takes a sustain.lower and sustain.upper parameter.
I think the âBattery sustainâ should have three parameters:
sustain.lower
sustain.upper
sustain.discharge.
This would then provide a charge hysteresis between sustain.lower and sustain.upper and a discharge hysteresis between sustain.upper and sustain.discharge.
If one is like me, and donât want the forced discharge to happen at all, I could set the sustain.discharge to > 100% so it would never be activated.
But if you needed force discharge to happen, say for âbattery extenderâ one could set the sustain.discharge to some value below 100%.