Bug 105721 - Battery not detected at boot on Dell Inspiron Series 7000 model 7437 with v4.2
Summary: Battery not detected at boot on Dell Inspiron Series 7000 model 7437 with v4.2
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Battery (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_power-battery
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-09 18:37 UTC by Tanki
Modified: 2017-06-02 05:18 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump_kernel-4.2.1 (390.84 KB, text/plain)
2015-10-12 15:55 UTC, Tanki
Details

Description Tanki 2015-10-09 18:37:45 UTC

    
Comment 1 Tanki 2015-10-09 18:44:05 UTC
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
Comment 2 Aaron Lu 2015-10-12 01:56:32 UTC
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 :-)
Comment 3 Tanki 2015-10-12 05:13:32 UTC
first i'll try to find the exact kernel version where this happens
Comment 4 Zhang Rui 2015-10-12 05:52:33 UTC
please check if the problem still exists if you boot with kernel parameter acpi_osi="!Darwin".
Comment 5 Zhang Rui 2015-10-12 05:55:20 UTC
BTW, are you using a Macbook?
Comment 6 Tanki 2015-10-12 06:34:45 UTC
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
Comment 7 Zhang Rui 2015-10-12 12:59:28 UTC
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.
Comment 8 Tanki 2015-10-12 15:20:51 UTC
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 :)
Comment 9 Tanki 2015-10-12 15:55:24 UTC
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...
Comment 10 Tanki 2015-10-12 15:57:42 UTC
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
Comment 11 Aaron Lu 2015-10-13 01:46:32 UTC
(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?
Comment 12 Tanki 2015-10-13 09:09:50 UTC
I use acpi_osi=Linux because I always did
nevertheless, if I take it off it doesn't change anything
Comment 13 Aaron Lu 2015-10-14 01:46:14 UTC
If you do not add acpi_osi=Linux to kernel cmdline, will kernels before v4.2 still work regarding battery?
Comment 14 Tanki 2015-10-14 15:55:32 UTC
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
Comment 15 Tanki 2015-10-21 17:45:16 UTC
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...
Comment 16 Aaron Lu 2015-10-22 01:53:41 UTC
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.
Comment 17 Tanki 2015-10-22 12:16:36 UTC
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
Comment 18 Tanki 2015-10-22 16:50:40 UTC
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
Comment 19 Aaron Lu 2015-10-23 01:29:43 UTC
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...
Comment 20 Tanki 2015-10-23 06:11:07 UTC
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
Comment 21 Tanki 2015-10-23 14:52:43 UTC
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 :)
Comment 22 Aaron Lu 2015-10-26 01:27:56 UTC
(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.
Comment 23 Dominik Gronkiewicz 2016-11-29 15:11:28 UTC
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...
Comment 24 Kai-Heng Feng 2017-06-02 05:18:32 UTC
FWIW, CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is default enabled in Ubuntu's kernel.
Also, a quirk for Inspiron 7537 is in commit 2cff319e9666f534a7538aa1f4178d1f799b068a

Note You need to log in before you can comment on or make changes to this bug.