[S3] Battery Indicator not showing

[qzed]

Discussed in #607

^{Originally posted by dannyhutch2511 October 18, 2021}
Hi I am currently running the newest update on my Surface 3 (5.14.11-surface) but I still can't see the battery indicator
I've already installed an acpi and the acpi -b command doesn't work for me
Any help would be appreciated.

Let's discuss this here as that's a real issue and not really well suited for a discussion.

[qzed]

In reply to the dmesg log posted on the discussion:

@dannyhutch2511: There are a bunch of ACPI errors. Any chance you're not on the latest firmware version? Can you try updating that (you probably need Windows for that, not sure if the Surface 3 is supported under Linux).

The ACPI errors:

1. Error evaluating _CRS of some USB controller, probably unrelated to battery.

   [    0.284273] ACPI Error: Cannot assign type [Device] to [BufferField] (must be type Int/Str/Buf) (20210604/exstoren-90)
   [    0.284309] No Local Variables are initialized for Method [_CRS]
   [    0.284315] No Arguments are initialized for method [_CRS]
   [    0.284322] ACPI Error: Aborting method \_SB.PCI0.UOTG._CRS due to previous error (AE_AML_OPERAND_TYPE) (20210604/psparse-529)
   [    0.284362] ACPI Error: Method execution failed \_SB.PCI0.UOTG._CRS due to previous error (AE_AML_OPERAND_TYPE) (20210604/uteval-68)
   

   That happens here. The \_SB_.PCI0.OTG1 name shadows the \OTG1 field (note \ as the root element in the path). I'm not entirely sure if ACPI has separate namespaces for devices, but I don't think so. If it doesn't then that's a bug in ACPI code that we can't easily work around. In any case, the guys at https://github.com/acpica/acpica might know more.

2. The rest are all repetitions of this sequence, which is related to the battery:

   [    4.904338] i2c 0-0055: Error reading serial no: -121
   [    4.904411] ACPI Error: Unknown exception code: 0xFFFFFF87 (20210604/utexcep-41)
   [    4.904484] ACPI Error: UNKNOWN_STATUS_CODE, Returned by Handler for [GenericSerialBus] (20210604/evregion-281)
   [    4.904594] ACPI Error: Aborting method \_SB.BAT0.RSPB
   [    4.904603] ACPI Error: Unknown exception code: 0xFFFFFF87 (20210604/utexcep-41)
   [    4.904719]  due to previous error (UNKNOWN_STATUS_CODE) (20210604/psparse-529)
   [    4.906104] ACPI Error: Aborting method \_SB.BAT0._BIX
   [    4.906119] ACPI Error: Unknown exception code: 0xFFFFFF87 (20210604/utexcep-41)
   [    4.906248]  due to previous error (UNKNOWN_STATUS_CODE) (20210604/psparse-529)
   [    4.907144] ACPI Error: Unknown exception code: 0xFFFFFF87 (20210604/utexcep-41)
   [    4.907923] ACPI: \_SB_.BAT0: _BIX evaluation failed: UNKNOWN_STATUS_CODE
   [    4.907946] ACPI: \_SB_.BAT0: _BIF evaluation failed: AE_NOT_FOUND
   

   This seems to be going wrong when accessing an I2C device. Note that unsigned 32 bit 0xFFFFFF87 equals signed 32 bit -121, which isn't a known status code to ACPI but is -EREMOTEIO, so a known kernel error value. The failure happens in \_SB.BAT0.RSPB, which is called in \_SB.BAT0._BIX, the method providing static battery information. IIRC, that method is called when the battery driver probes (and provides essential information), so due to that failing the battery driver isn't loading.

   The error ultimately originates in the kernel as the RSPB is essentially a wrapper to call mshw0011_space_handler(), which happens to deal with I2C I/O. That in turn calls mshw0011_bix() which just so happens to have an error handling path emitting the Error reading serial no line we see in the log.

   The weird thing here is that communication seems to work at first, reading design capacity and full charge capacity fields, but fails attempting to read the serial number. Based on the error code, this has to come somewhere from inside the I2C controller driver. It usually indicates that something went wrong with communication (maybe the data length is different than expected).

   I'm not entirely sure how to debug this. You'd probably have to try and talk to the I2C device (should be possible from user-space) and check if that call fails from there. Haven't really done that so you'll have to figure that out yourself, sorry.

One thing you could try is trying to manually (re-)load the battery driver and re-load the surface3_power module. So try running

echo "PNP0C0A:00" | sudo tee /sys/bus/acpi/drivers/battery/unbind    # this will likely fail as the driver didn't bind
sudo modprobe -r surface3_power
sudo modprobe surface3_power
echo "PNP0C0A:00" | sudo tee /sys/bus/acpi/drivers/battery/bind

If things work after that it's some temporary failure at boot.

[qzed]

According to IRC it's not a temporary failure, but also happens when re-loading the module and attempting to re-bind the driver.

[qzed]

#60 (comment) reports there was a firmware update necessary to get the driver working. The issue is exactly the same as described here according to the logs.

[aflyingpumpkin]

Hi, I would just like to say that I am running into the exact same issue, in case this helps here are some details about my Surface 3:
firmware version: 1.51116.238 (this is the very latest, I updated in an attempt to fix the issue.)
kernel release: 5.15.5-arch1-1-surface
Distro: I use arch, btw
Running the commands sent to reload the module did not help, though when running the commands I got the error for all commands involving tee (I do use opendoas instead of sudo, though I doubt this changes anything):

tee: /sys/bus/acpi/drivers/battery/unbind: No such device

surface3_power module is on my system.

[urbient]

i chime in with the same problem , all the parameters of aflyingpumpkin are set with me, apart from using sudo and that my 64GB nand memory has died so i boot from usb . latest firmware and surface3_power is there while the firmware date shows 2015 wich is odd as the last update was 2019. maybe someone can confirm this. i know battery worked some kernel itterations 2-4 month ago with the same firmware .

[qzed]

Hans de Goede has submitted a fix for this: https://patchwork.kernel.org/project/platform-driver-x86/patch/20220224101848.7219-1-hdegoede@redhat.com/. I'll pull this into our next release.

[jwrdegoede]

Note the fix for this is also on its way to the mainline 5.17-rc# kernels and should get added to the stable series from there:

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=fixes
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=fixes&id=21d90aaee8d5c2a097ef41f1430d97661233ecc6

[hsghost]

Reporting this has finally been fixed upon today's kernel update, on my not-so-recent firmware. Well done!

[qzed]

Thanks for the confirmation! Closing this then.