The battery indicator stop functioning properly | ASUSTeK FA506IV

I update my Fedora 36 packages via Software Manager yesterday, and my battery indicator stopped working correctly. At each restart of my laptop, the battery indicator is going to display the right value at that point and is not going to update that either if the battery percentage will increase or decrease until the next restart.

What should I do?

inxi -Fzx output:

  Kernel: 5.18.16-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.37-27.fc36 Desktop: GNOME v: 42.4
    Distro: Fedora release 36 (Thirty Six)
  Type: Laptop System: ASUSTeK product: ASUS TUF Gaming A15 FA506IV_FA506IV
    v: 1.0 serial: <superuser required>
  Mobo: ASUSTeK model: FA506IV v: 1.0 serial: <superuser required>
    UEFI: American Megatrends v: FA506IV.319 date: 04/26/2022
  ID-1: BAT1 charge: 58.9 Wh (80.6%) condition: 73.1/90.2 Wh (81.0%)
    volts: 15.7 min: 15.9 model: ASUS A32-K55 status: discharging
  Info: 8-core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64
    type: MT MCP arch: Zen 2 rev: 1 cache: L1: 512 KiB L2: 4 MiB L3: 8 MiB
  Speed (MHz): avg: 1397 high: 1398 min/max: 1400/2900 boost: enabled
    cores: 1: 1397 2: 1397 3: 1397 4: 1397 5: 1398 6: 1397 7: 1397 8: 1397
    9: 1397 10: 1397 11: 1397 12: 1397 13: 1397 14: 1397 15: 1397 16: 1397
    bogomips: 92628
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Device-1: NVIDIA TU106M [GeForce RTX 2060 Mobile] vendor: ASUSTeK
    driver: nvidia v: 515.57 arch: Turing bus-ID: 01:00.0
  Device-2: AMD Renoir vendor: ASUSTeK driver: amdgpu v: kernel
    arch: GCN 5.1 bus-ID: 05:00.0
  Device-3: IMC Networks USB2.0 HD UVC WebCam type: USB driver: uvcvideo
    bus-ID: 3-4:2
  Display: wayland server: X.Org v: with: Xwayland v: 22.1.3
    compositor: gnome-shell driver: X: loaded: amdgpu,nvidia
    unloaded: fbdev,modesetting,nouveau,vesa gpu: amdgpu
    resolution: 1920x1080~144Hz
    renderer: AMD RENOIR (LLVM 14.0.0 DRM 3.46 5.18.16-200.fc36.x86_64)
    v: 4.6 Mesa 22.1.7 direct render: Yes
  Device-1: NVIDIA TU106 High Definition Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 01:00.1
  Device-2: AMD Renoir Radeon High Definition Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 05:00.1
  Device-3: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: N/A
    bus-ID: 05:00.5
  Device-4: AMD Family 17h/19h HD Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 05:00.6
  Sound Server-1: ALSA v: k5.18.16-200.fc36.x86_64 running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.56 running: yes
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: ASUSTeK driver: r8169 v: kernel port: e000 bus-ID: 02:00.0
  IF: enp2s0 state: down mac: <filter>
  Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter
    vendor: AzureWave driver: rtw_8822ce v: N/A port: d000 bus-ID: 03:00.0
  IF: wlp3s0 state: up mac: <filter>
  IF-ID-1: br-49e908d4160f state: down mac: <filter>
  IF-ID-2: br-7346c10d72ae state: down mac: <filter>
  IF-ID-3: br-8d3b9c84d243 state: up speed: 10000 Mbps duplex: unknown
    mac: <filter>
  IF-ID-4: docker0 state: down mac: <filter>
  IF-ID-5: vethfd293af state: up speed: 10000 Mbps duplex: full
    mac: <filter>
  Device-1: IMC Networks Bluetooth Radio type: USB driver: btusb v: 0.8
    bus-ID: 5-1:2
  Report: rfkill ID: hci0 rfk-id: 2 state: down bt-service: enabled,running
    rfk-block: hardware: no software: yes address: see --recommends
  Local Storage: total: 953.87 GiB used: 171.07 GiB (17.9%)
  ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKNW010T8 size: 953.87 GiB
    temp: 29.9 C
  ID-1: / size: 187.77 GiB used: 102.63 GiB (54.7%) fs: btrfs
    dev: /dev/nvme0n1p8
  ID-2: /boot/efi size: 99.8 MiB used: 13.9 MiB (14.0%) fs: vfat
    dev: /dev/nvme0n1p6
  ID-1: swap-1 type: partition size: 16 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p7
  ID-2: swap-2 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
  System Temperatures: cpu: N/A mobo: N/A gpu: amdgpu temp: 35.0 C
  Fan Speeds (RPM): N/A
  Processes: 470 Uptime: 2h 52m Memory: 15.04 GiB used: 3.44 GiB (22.8%)
  Init: systemd target: graphical (5) Compilers: gcc: 12.2.1 clang: 14.0.5
  Packages: 49 note: see --pkg Shell: Bash v: 5.1.16 inxi: 3.3.19
1 Like

Could you please give us more info’s as :

inxi -Fzx in terminal and post the output as </> Preformatted text here.

As workaround see if you can start with an older kernel to see if this happened on the latest kernel update.

I did update the question with that output, also I did try to run the oldest kernel and the issue still persisting also there, which I found weird.

I already use Kernel 5.19.4, did you try on this?

Yes, I’ve just checked, and I am using 5.19.4-200.fc36.x86_64

same issue. We both have same device and same issue

I have same issue too. with the same device

did you find any solution for this?

There is a newer bios/firmware:

I did upgrade my bios with that link and it did not change anything, I still have the same issue

No. Still searching for it

In case that you find something please write a post here with the solution :slight_smile:

sure :wink:

There is a problem with the kernel 5.19.4-200. You need blacklist asus_ec_sensors module or boot with 5.18.19-200.

could you please elaborate on how to downgrade the kernel?!

Liam did not say to downgrade the kernel. He said to boot with the older kernel [from the grub menu].

Yes, I did say it. If you use Fedora, you could choose one of last three kernels from the grub menu. There is a problem with a regression in kernel 5.19.4-200. Many Asus users have problems with the latest update. If you use Manjaro or Arch, the best option could be LTS kernel.

If someone is interested in contribute to testing a kernel patch that could possibly solve the issue (it is from the maintainer of asus_ec_sensors):

But please read my post completely before engaging in testing.

@vildnex @liamklien12

Kernel 5.19.9 contains multiple fixes for the autoload of asus_ec_sensors. The problem you have been experiencing should be fixed after the update to 5.19.9, which will be the next kernel update. This update will come soon; the testing of this kernel for Fedora has already begun.

Therefore, once you update to 5.19.9, you can remove both blacklistings. We would appreciate any feedback if everything works again (or not) on 5.19.9 without blacklisting. I would prefer to have a “real world test case” on Fedora before changing the workaround.