Battery indicator not working properly | ASUS TUF Gaming A15 FA506IH

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
https://bugzilla.redhat.com/

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.

4 Likes
$ cat /proc/sys/kernel/tainted
0

My system seems to be holy, so here’s the output of dmesg.txt (I removed some MAC addresses for obvious reasons, I also removed the blacklist and rebooted, the problem appeared again as expected) Ubuntu Pastebin

Another note, suspend DOES work if I manually click suspend, but it doesn’t suspend when closing the lid.

Btw I’m very pleasantly surprised by the amount of effort from your side to fix this, that’s freaking awesome. Thank you so much!

2 Likes

Thanks @kquote03 → I have updated the bug report and added the logs of your holy kernel :wink:

2 Likes

Hi. I am burakdede from the Bugzilla bug report. I have the same laptop with the original poster here.

I tried Windows, it works as intended.
I tried kernel 5.19.6, the problem exist in that version.

I can provide any info you need here or Bugzilla.

1 Like

Connecting related topics:

I don’t merge the topics to not mix the elaborations in order to keep it comprehensible.


Hi Burak,

Thanks for providing more information!

I think we provided what we can so far :slight_smile: I forwarded the issue to the maintainer of the driver (see bugzilla). Let’s wait if he or our kernel team need further information from us. For now, I would say our job is done.

1 Like

@kquote03 @ali-guest01 @burakdede

The maintainer suggested to try a patch that is for a similar issue. Maybe it will solve this issue as well. It is up to you if you are interested in testing it and report in order to finally get rid of it in future kernels. There is no obligation! And be aware: if you do, you make your system to a testing environment, which means unintended behavior cannot be excluded - be prepared for that (have a live usb stick with Fedora ready, backup). I don’t expect it in this case but in testing you should always be prepared. Therefore, no worries if you prefer to not do this. But maybe you have fun in making such experiences :wink:

See the bugzilla report if you are interested 2121844 – Battery percentage gets stuck at a certain level (asus_ec_sensors locks ACPI mutex) and I suggest to use 5.19.6 for testing (and don’t forget, when testing, to remove the driver from blacklist):
Testing Patches :: Fedora Docs

(Just in case: open a new topic with reference to this one if there are issues with preparing/conducting testing!)

Alternatively, it seems likely that this patch ends up in a future kernel anyway as it solves the issue it originally was developed for. So in this case, we can re-test it later once the kernel with the patch has been released. Might be easier if you prefer to not engage in testing.

4 Likes

A post was split to a new topic: Error in setting up environment for testing kernel patch for bugzilla report

To be honest I have no idea what is blacklisting the module and how to do that. Could you please explain what it is and how to do that, that would be very nice of you) I need to learn a lot since I am very new!!! It has not even been two weeks since I moved from windows 11 to fedora 36(to linux as a whole).

Sadly, updating did not help

You are not the only one
me too

First, please focus your question in one thread. This avoids that we have to do double work here.

Second, I suggest to not downgrade in this case. Using a previous kernel is something you do to jump over one kernel that causes troubles when released, so a short time thing. And even in this case it should be checked if the kernel you are reverting to has security issues.

So, you should use the blacklist option for now. You can find our “official” workaround for this bug here: Battery charge indicator broken on certain ASUS motherboards, automatic suspend doesn't work

When playing with commands like those in the workaround, especially when you have no other menu entries you can revert to, always have a USB stick or such with a live Fedora system prepared to use it to revert the steps in case of unintended outcomes!

With the commands and information of the steps you can find much more information about these issues with your preferred search engine.

However, I strongly suggest to try it again without blacklisting with each future kernel update! The issue is known and likely to be fixed in the next kernel update or the one after that. Removing the blacklisting is explained in the workaround link as well. Although this module is not critical, I suggest to not keep it disabled for all time. It is one of those that can cause you trouble if you forget about its blacklisting at some point but want to retrieve (or if an application wants to retrieve) information it provides without remembering why it is not provided that.


Supplement: another related thread: Power indicator state not working in kernel 19.4-200

3 Likes

why does it say :

bash: cd: /boot/loader/entries/: Permission denied

It has to be done with sudo. I corrected that. My bad.

2 Likes

I think it is my bad that I even could not figure out this myself

should it give back any kind of output? I do not see any output:

base) [Ali@ali ~]$  sudo cd /boot/loader/entries/ 
(base) [Ali@ali ~]$  sudo cd /boot/loader/entries/

No. cd = change directory. Within the directory, you have to check out the content, e.g., using ls. And then, when you know the file names in the directory, you can use an editor to change the respective file (don’t forget sudo). Alternatively, you can skip the cd, just write sudo <editor> /boot/loader/entries/ but without clicking the enter button, then you push twice TAB and then it will show you the contained files. Fill the command with the respective file name, and then enter.

Also, we are currently working on creating a more comprehensible workaround for this:
https://discussion.fedoraproject.org/t/battery-charge-indicator-broken-on-certain-asus-motherboards-automatic-suspend-doesnt-work/77252

1 Like

That command does not give an output.
Please follow the remaining steps, but remember that sudo will be required for each command there.

1 Like
    ce21487341ce4655b07216365eaa994a-5.19.6-200.fc36.x86_64.conf     Modified  





















^G Help      ^O Write Out ^W Where Is  ^K Cut       ^T Execute   ^C Location
^X Exit      ^R Read File ^\ Replace   ^U Paste     ^J Justify   ^/ Go To Line

@ computersavvy I suppose there has to be a bunch of code lines, am I right, oh?

Using a default F36 KDE live (the relevant data is equal to F36 Workstation) with 5.19.6, the 5.19.6 file could be opened with sudo nano /boot/loader/entries/d239886fa9ec440db73734aeb26fa5a6-5.19.6-200.fc36.x86_64.conf → be aware that the exact file names are different in each case, only the ending is constant.

The content of the file is by default

title Fedora Linux (5.19.6-200.fc36.x86_64) 36 (KDE Plasma)
version 5.19.6-200.fc36.x86_64
linux /boot/vmlinuz-5.19.6-200.fc36.x86_64
initrd /boot/initramfs-5.19.6-200.fc36.x86_64.img
options root=live:CDLABEL=Fedora-KDE-Live-36-1-5 rd.live.image quiet rhgb
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

You have to work in the options line, which is line 5.

Don’t adjust your file to my example! Just focus on the instructions I made above, or on the proposed common issue workaround.

In nano, this would look like this:

With your preferred search engine, you can find many HowTo’s, tutorials and guides for nano or other editors (vi, vim, mc, …). Also, you can check man nano (or generally, man <editor> if it is installed)

1 Like