Bug 105721

Hi

Since the kernel 4.x series, my battery is not detected at boot time.
dmseg | grep batt returns :
ACPI: Battery Slot [BAT0] (battery absent)

but today I compiled an "old" kernel version 3.19.0 and this is what  get :
$ dmesg | grep batt
[    0.335464] ACPI: Battery Slot [BAT0] (battery present)

it's the same .config file so there is no changes between the two kernel versions

I tried everything from BIOS upgrade to switching distros, but the problem is still the same

please advise if you need further informations

regards

There is no code change for battery driver between v3.19 and v4.0, so perhaps some other changes caused this problem. I would say please git bisect to find the offending commit :-)

first i'll try to find the exact kernel version where this happens

please check if the problem still exists if you boot with kernel parameter acpi_osi="!Darwin".

BTW, are you using a Macbook?

OK I'll try with Kernel version 4.2.1 with acpi_osi="!Darwin" when I'm back from work this evening
The computer is a Dell Inspiron Series 7000 model 7437
the thing is that it has always worked flawlessly until around kernel 4.1 I think
I'll get more details tonight

if it is not a macbook, acpi_osi="!Darwin" may not help.
But anyway, please give it a try and please attach the acpidump as well.

Hi again
as a matter of fact adding acpi_osi="!Darwin" a grub cmd line has no effect

the strange thing is, if I press BRTUP key (brightness up) or BRTDN my battery level appears, and the folder /sys/class/power_supply/BAT0 gets created

also to be noted, when I boot with my AC adapter plugged in the battery level is not displayed either

for the moment I run with kernel 3.19 which is working fine

I'll try to post details about kernel 4.0 and 4.1 to see which kernel is misbehaving :)

cheers :)

Created attachment 190071 [details]
acpidump_kernel-4.2.1

tanki # acpidump > acpidump.txt
Wrong checksum for FADT!

I had this error message, don't know if it matters so I put it here...

I tested Kernel 3.19, 4.0.1 and 4.1.2 and all kernel behave normally
so it appears the problem is only present in kernel 4.2 and onwards

please advise if you need further details

my grub cmd line contains acpi_osi=Linux

(In reply to Tanki from comment #10)
> I tested Kernel 3.19, 4.0.1 and 4.1.2 and all kernel behave normally
> so it appears the problem is only present in kernel 4.2 and onwards
> 
> please advise if you need further details
> 
> my grub cmd line contains acpi_osi=Linux

Why use acpi_osi=Linux? Does it change anything if you didn't add that?

I use acpi_osi=Linux because I always did
nevertheless, if I take it off it doesn't change anything

If you do not add acpi_osi=Linux to kernel cmdline, will kernels before v4.2 still work regarding battery?

Hi
I've just been booting without the acpi_osi=Linux kernel cmdline and for all the kernel, /sys/class/power_supply/BAT0 is missing

it's as if kernels 4.2 and onwards do not acknowledge the acpi_osi=Linux kernel cmdline

tell me if you need more details

rgds

hi

I've been using kernel 4.2.3 and nothing has changeed...
I took a glance at drivers/acpi/batery.c and drivers/acpi/osl.c but it's all greek to me

I'm out of ideas...

Looks like starts from v4.2, _REV will return 2 instead of 5, which affects the battery _STA control method's value when acpi_osi is set to Linux.

See this:

+       acpi_rev_override [ACPI] Override the _REV object to return 5 (instead
+                       of 2 which is mandated by ACPI 6) as the supported ACPI
+                       specification revision (when using this switch, it may
+                       be necessary to carry out a cold reboot _twice_ in a
+                       row to make it take effect on the platform firmware).

So I think you can work around this by adding:
acpi_osi=Linux acpi_rev_override
to kernel cmdline. To verify if you have successfully done this, there should be a message in dmesg:
Overriding _REV return value to 5

And then test the battery again.

Hi

I tried adding the acpi_rev_override to my kernel cmdline, dmesg shows it's been taken into account bu it has no effect
I saw a thread on alsa mailing list stating about blacklisting certain types of platforms, especially the Dell XPS 13 (2015) (see: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-May/092038.html)
i'll try and add my platform to the blacklist.c and see if it has any effect...

Rgds

Howdy

I added my platform to blacklist.c and it's not changed a thing
so I reverted to default and I pray for a miracle

thanks for your attention anyways

I have a Dell XPS13 and I just booted v4.3-rc5, my battery is there.

Note that
"
it may be necessary to carry out a cold reboot _twice_ in a row to make it take effect on the platform firmware
"

The _STA of battery is:

                        Method (_STA, 0, NotSerialized)  // _STA: Status
                        {
                            Local0 = (MIS0 & 0x02)
                            If (Local0)
                            {
                                Return (0x1F)
                            }

                            Return (0x0F)
                        }

Which means the status depends on MIS0.

MIS0 is assigned a value here:

    Method (SOST, 0, NotSerialized)
    {
        ... ...
        If (_OSI (LNX))
        {
            Local1 = _REV /* \_REV */
            If ((Local1 == 0x05))
            {
                Local0 = 0x40
            }
        }

        If ((Local0 == 0x40))
        {
            MIS0 = SMI (0x98, Zero)
            MIS0 &= 0x13
        }
        ... ...
    }

So it's only assigned a value when _OSI responds true to Linux query(which is accomplished by adding acpi_osi=Linux) and when _REV returns 5(which is accomplished by adding acpi_rev_override).

I have no idea why adding the two parameters still doesn't work...

Allright

I'm pretty pissed
I think I'm missing something but I can't seem to put my finger on it...
If it works for you and not me it must be because my .config if utter crap
would you mind passing your XPS 13 .config along so I can make a diff and see where I did wrong ?

I installed 4.3.0-rc6 and I added (again) acpi_rev_override to my kernel cmdline but /sys/class/power_supply/BAT0 still isn't created

TIA

Sooooooo

I managed to forget this option in my .config :
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE

which, once activated allow me to use acpi_rev_override thus allowing my kernel to create /sys/class/power_supply/BAT0

so it happens this was not a bug but a misconfiguration (hence a feature ;)

Thank you very much for all the efforts you put into this

I might sleep better at night now that this is fixed :)

(In reply to Tanki from comment #21)
> Sooooooo
> 
> I managed to forget this option in my .config :
> CONFIG_ACPI_REV_OVERRIDE_POSSIBLE

I should have mentioned this, sorry for the time wasted.

> 
> which, once activated allow me to use acpi_rev_override thus allowing my
> kernel to create /sys/class/power_supply/BAT0
> 
> so it happens this was not a bug but a misconfiguration (hence a feature ;)
> 
> Thank you very much for all the efforts you put into this
> 
> I might sleep better at night now that this is fixed :)

Good to know this, thanks!
I'll close the bug as "documented" as there is no "work around" available.

Is there any way to fix this issue other than recompiling the kernel or moving back to Windows? I don't think Dell is changing their ACPI behavior any time soon and having to go through the hassle of rebuilding a kernel every time there is an update is extremely frustrating and getting into my way. I think Dell Inspiron laptops are quite popular among Linux community (also because they're sold with Linux preinstalled). Is it possible to add exception for Dell 7537 and other affected platforms? I don't think any other vendors have issues with _REV value...

FWIW, CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is default enabled in Ubuntu's kernel.
Also, a quirk for Inspiron 7537 is in commit 2cff319e9666f534a7538aa1f4178d1f799b068a