Battery indicator not working properly | ASUS TUF Gaming A15 FA506IH

I have recently changed my os from windows 11 to fedora 36 gnome42. And once while working on it the battery indicator kept showing 89% quite for a long. As I was new and not experienced I thought may be it started consuming a lot less, but I was wrong. Then while showing 89% it just suddenly turned off. Then I realized that the battery indicator not showing the right percentage. Then when I plugged it in it also showed 0% quite for a long. As I restarted my pc then it showed 41% immediately. Now it has been showing 56% since I restarted it again after that. So there seems to be an isssue with the battery indicator. Does anyone have any idea about what a hell is going on?

1 Like

It sounds like either you have a faulty battery or the ACPI system isn’t working right in your kernel. Did it charge/discharge correct on Windows or if you boot to an older kernel?

Can you give us the output of inxi -SMCIGB in preformatted or code block format?


Yes! I did not have any such issues on windows 11 and it was working well. Here is what you asked for, thanks for replying. I thought I would not get that fast reply.

Host: ali Kernel: 5.19.4-200.fc36.x86_64 arch: x86_64 bits: 64
Desktop: GNOME v: 42.4 Distro: Fedora release 36 (Thirty Six)
Type: Laptop System: ASUSTeK product: ASUS TUF Gaming A15 FA506IH_FA506IH
v: 1.0 serial:
Mobo: ASUSTeK model: FA506IH v: 1.0 serial:
UEFI: American Megatrends v: FA506IH.316 date: 03/12/2021
ID-1: BAT1 charge: 33.3 Wh (90.0%) condition: 37.0/48.2 Wh (76.9%)
volts: 11.8 min: 11.9
Info: 8-core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64
type: MT MCP cache: L2: 4 MiB
Speed (MHz): avg: 1493 min/max: 1400/2900 cores: 1: 1397 2: 1397 3: 1400
4: 1400 5: 1400 6: 1400 7: 1400 8: 1400 9: 1400 10: 1400 11: 1400 12: 1400
13: 2900 14: 1400 15: 1400 16: 1400
Device-1: NVIDIA TU117M driver: nvidia v: 515.65.01
Device-2: AMD Renoir driver: amdgpu v: kernel
Device-3: IMC Networks USB2.0 HD UVC WebCam type: USB driver: uvcvideo
Display: wayland server: X.Org v: with: Xwayland v: 22.1.3
compositor: gnome-shell driver: gpu: amdgpu resolution: 1920x1080~60Hz
renderer: AMD RENOIR (LLVM 14.0.0 DRM 3.47 5.19.4-200.fc36.x86_64)
v: 4.6 Mesa 22.1.7
Processes: 814 Uptime: 11m Memory: 15.05 GiB used: 2.92 GiB (19.4%)
Shell: Bash inxi: 3.3.19
1 Like

Well, a question that remains is if there is a hardware issue (and if not, is it Fedora-specific or Linux). To identify if this is a Fedora-related issue, you can get a live image from another Linux distro and check if the problem is the same there (e.g., Ubuntu). You do not have to install it, just start the live system and check for a while how it develops, reboot once again with the live image and test it again. Does the behavior of the battery status remain such erratic within and between the live tests?

An exhausting but clear proof about hardware would be a test with Windows: If you reinstall Windows for a few hours, does it happen there, too? Just in case this test is easily possible with the affected system!

If it is Linux or Fedora-related, I agree with Scott that it has to be related to ACPI.

Btw, some sys logs would be interesting to find out if some errors / unintended occurrences are there that might explain the issue: e.g., sudo journalctl --boot=0 and sudo journalctl --boot=-1 if that is ok for you. This would contain the current and the last boot. Ensure that these contain the problem, and some time indication when the erratic jumps happen would be very helpful, too! Feel free to randomize content if you consider something inside as private (e.g., user names).

I don’t think it is the origin, but as there are links between ACPI and graphics cards/drivers, and as proprietary NVIDIA drivers have already created interesting behaviors in the past, it might be also relevant to see if the problem remains if you change the driver / graphics card (you have an integrated AMD graphics additionally to the NVIDIA), especially if you use the proprietary NVIDIA driver (the Device-1 line indicates you use the proprietary one).


Btw, I have recently changed from Integrated graphics to nvdia. I will try changing it back to the integrated one.

I have the same exact problem, it seems to be a kernel issue.

My laptop is a Huawei D15 Intel

Output of inxi -SMCIGB

Host: holoiso.lan Kernel: 5.18.19-200.fc36.x86_64 arch: x86_64 bits: 64
Desktop: GNOME v: 42.4 Distro: Fedora release 36 (Thirty Six)
Type: Laptop System: HUAWEI product: BOD-WXX9 v: M1040
Mobo: HUAWEI model: BOD-WXX9-PCB v: M1040 serial:
UEFI: HUAWEI v: 1.14 date: 06/07/2021
ID-1: BAT1 charge: 5.2 Wh (13.9%) condition: 37.3/41.6 Wh (89.8%)
volts: 11.8 min: 11.5
Info: quad core model: 11th Gen Intel Core i5-1135G7 bits: 64 type: MT MCP
cache: L2: 5 MiB
Speed (MHz): avg: 1230 min/max: 400/4200 cores: 1: 1213 2: 1203 3: 1201
4: 1191 5: 1282 6: 1201 7: 1261 8: 1293
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
Device-2: IMC Networks HD Camera type: USB driver: uvcvideo
Display: wayland server: X.Org v: with: Xwayland v: 22.1.3
compositor: gnome-shell driver: X: loaded: modesetting gpu: i915
resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel Xe Graphics (TGL GT2) v: 4.6 Mesa 22.1.7
Processes: 336 Uptime: 7m Memory: 7.56 GiB used: 3.15 GiB (41.6%)
Shell: Bash inxi: 3.3.19

This issue happened after I upgraded to the 5.19.4-200.fc36 kernel. Currently I’m on kernel 5.18.19-200.fc36 (the only other option in GRUB) and the issue disappeared.

Sleep also seems to be broken in the latest kernel.


Great! Actually, I’ve also started to have this issue very recently. Could you please help on how to downgrade the kernel?!

1 Like

Be careful with deriving such holistic conclusions. The issue is not very widespread. So it cannot be the kernel alone that causes this issue. It is the interaction of the kernel with something else.

It cannot be excluded that the current kernel causes it when interacting with a specific piece of hardware. But it can also be the case that the second part is not hardware but another piece of software, which in conjunction with the current kernel causes an ACPI issue.

@kquote03 do you also use proprietary NVIDIA driver?
@ali-guest01 have you tested your system with the integrated AMD graphics? Or with the non-proprietary default NVIDIA driver? Does the issue change?

Generally, for such cases, Fedora keeps the recent 3 kernels, so that you can just switch if one causes problems.

@ali-guest01 when booting your system, you can choose in grub between different kernels. Just step back to the last one. However, if you just installed Fedora, it is possible that you have just the current one (which causes the issue) and a very old one that should no longer be used → be aware that sticking with old kernels forever/for long is never a good idea: on one hand, sometimes the kernel gets security patches, on the other hand, all other updates assume that you have the current kernel. So this is both stability and security related. Using the recent two kernels should not be an issue except one was replaced because of a security patch, but don’t stick with older ones for long.

If such an issue rises just by updating one kernel release and if it does not affect many machines, you have good chances that it will disappear with the next kernel. So keep updating the kernel and check out the next release! 5.19.6 is already on its way (some packages are already ready but not all) :slight_smile: I guess the next kernel update to 5.19.6 is in between several hours and tomorrow. So my suggestion is wait this short time and check out 5.19.6 before manually installing a downgrade.

@ali-guest01 @kquote03 Let us know if it remains even after the next kernel update.

Then we will have to further investigate as persistently remaining with the old 5.18.19 cannot be a solution…


@ali-guest01 @kquote03 Supplement: the new kernel is released :slight_smile: If you don’t get immediately the update with dnf update you can do dnf update --refresh (usually, dnf is just refreshing the update repo every 6 hours)

Hopefully, this will solve the problem.


Thank you, I never thought about it this way.

My system only has the integrated Intel GPU.

I am trying to update the kernel but it seems the mirrors are 404ing… probably a separate issue

1 Like

Are you using dnf update --refresh ? What is the exact output if I may ask?

That obviously excludes the NVIDIA driver as problem origin for you.

1 Like

Yes I’ve tried it, this is the output Ubuntu Pastebin

BTW I have disabled the fastmirror option and it seems to work now, seems the faster mirrors still didnt update yet.

1 Like

Let me know if the kernel update makes a difference :+1:

1 Like

Sadly it seems that the issue still exists.
Meanwhile here’s the dmesg output

1 Like

It seems this advice here worked for me

I blacklisted the module and rebooted, now the battery percentage works and sleep seems to work as well

1 Like

Interesting. So the second part of the problem seems to be asus_ec_sensors.

This is what we are talking about:

Hopefuly, this will be solved in future releases.


have you tried to boot with the oldest kernel available

1 Like

They tried an older kernel, that worked. But this is not a long term solution if the problem persists in new kernel releases.

Given the functions provided by asus_ec_sensors, I suggest to rather blacklisting asus_ec_sensors than sticking with an obsolete kernel for a long time. But I still suggest to keep observing what is related to these functions and try to get rid of the blacklisting over time.

1 Like

If that is the case best way is to report bugzilla redhat and provide them device info so they can determine what is wrong with the drivers i find asus is workibg on new driver so kernel have removed older drivers this maybe related to that not sure but bugzilla is way to go

1 Like

There is already a bug report: 2121844 – Battery percentage gets stuck at a certain level (asus_ec_sensors locks ACPI mutex)

The two kernels of the two topics we have about this are both nvidia-tainted like the one in the report, so I think this would not add value. But now that you say it, @kquote03 added a third one and noted that he uses default Intel graphics.

@kquote03 Can you check the output of cat /proc/sys/kernel/tainted? Maybe some information from an untainted system can help if you would be willing to provide logs. If the value of the “tainted” file is 0, your kernel is not tainted.

If the output of the command is 0 and if you are willing to provide information for this, you would have to re-create the problem (so, remove the asus_ec_sensors from blacklist), reboot, and if you then experience the problem again, get the output within the affected boot with journalctl --no-hostname -k > dmesg.txt → this dmesg.txt file is what we could provide to the bug report.