Bug 201351

Summary: BISECTED 5a8361f7ecce: Laptop battery status and lid switches not detected on Asus 1015PX - Intel(R) Atom(TM) CPU N570
Product: ACPI Reporter: Charles Stanhope (charles.stanhope)
Component: Power-BatteryAssignee: Zhang Rui (rui.zhang)
Status: RESOLVED DUPLICATE    
Severity: normal CC: erik.kaneda, jwrdegoede, lenb, rui.zhang
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.16.0 and above Subsystem:
Regression: Yes Bisected commit-id:
Attachments: acpi dump output from Fedora's 4.16.14 kernel
acpi dump output from Fedora's 4.18.7 kernel
Dmesg output for 4.16.14
Dmesg output for 4.18.13
load ecdt at the same time regardless of execute table as method
Dmesg output for 4.19-rc8 with patch applied
Dmesg dump from 4.20-rc1
custom dsdt to dump bat and lid status
Dmesg output for 4.20-rc1 with acpi.debug_level=0x420 and acpi.debug_layer=0x05
Dmesg dump from 4.16.0-rc2 (good) with acpi.debug_level=0x420 and acpi.debug_layer=0x05

Description Charles Stanhope 2018-10-09 03:49:06 UTC
Created attachment 278967 [details]
acpi dump output from Fedora's 4.16.14 kernel

I originally reported this against Fedora[0]. So I will copy some of what I wrote there.

Since Fedora 28 has moved forward with the 4.17 and 4.18 series of kernels, I have not been able to see battery status for my laptop (Asus 1015PX). It consistently shows 100% charged and absurd discharge time. Additionally, the laptop lid doesn't appear to be detected, so closing the lid doesn't cause the machine to suspend. Fedora's 4.16 series did not exhibit this behavior. An example of the erroneous output when running off of battery:

$ acpi
Battery 0: Discharging, 100%, 4200:00:00 remaining

An example of what it should've looked like:

$ acpi
Battery 0: Discharging, 90%, 05:27:57 remaining

After some helpful suggestions from others, I bisected the kernel to try to isolate the trouble. According to the bisection:

5a8361f7ecceaed64b4064000d16cb703462be49 is the first bad commit

This commit seems to cause both problems. Just before this commit, the battery status and laptop lid behave as expected.

I don't know if it will help, but I will attach the same acpi dump that I attached to the Fedora bug report.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1629479
Comment 1 Charles Stanhope 2018-10-09 03:49:45 UTC
Created attachment 278969 [details]
acpi dump output from Fedora's 4.18.7 kernel
Comment 2 Erik Kaneda 2018-10-15 16:58:15 UTC
Please attach the dmesg of the new kernel and older kernel
Comment 3 Charles Stanhope 2018-10-16 03:13:37 UTC
Created attachment 279039 [details]
Dmesg output for 4.16.14
Comment 4 Charles Stanhope 2018-10-16 03:18:11 UTC
Created attachment 279041 [details]
Dmesg output for 4.18.13

I've attacjed dmesg output for Fedora's 4.16.14 and 4.18.13. I don't have 4.18.7 on my system anymore. I've been updating as Fedora iterates on their kernels in hopes of finding that the problem has gone away.
Comment 5 Erik Kaneda 2018-10-16 16:38:37 UTC
Created attachment 279053 [details]
load ecdt at the same time regardless of execute table as method

Give this a try. It seemed to fix a macbook pro issue. Please note that this is not a valid fix.. It's only to test whether if your bug is similar to https://bugzilla.kernel.org/show_bug.cgi?id=200011
Comment 6 Erik Kaneda 2018-10-16 16:48:14 UTC
(In reply to Charles Stanhope from comment #4)
> Created attachment 279041 [details]
> Dmesg output for 4.18.13
> 
> I've attacjed dmesg output for Fedora's 4.16.14 and 4.18.13. I don't have
> 4.18.7 on my system anymore. I've been updating as Fedora iterates on their
> kernels in hopes of finding that the problem has gone away.

It would be great if you could try to build and boot 4.19-rc8 with the patch from comment 5. I think it would be valuable for us to test this. I've seen something similar on a macbook pro.  Let me know if you need any help with this. I would be more than happy to point you to resources.
Comment 7 Charles Stanhope 2018-10-20 13:14:58 UTC
Erik, I apologize for my slow response. I'll do my best to try your suggestion this weekend.
Comment 8 Charles Stanhope 2018-10-21 13:45:45 UTC
Created attachment 279111 [details]
Dmesg output for 4.19-rc8 with patch applied

I was able to try the kernel with the supplied patch. I was indeed able to both read the battery status and suspend the machine by closing the lid. I'm attaching the dmesg output with this kernel and patch in case it is useful. I'm happy to try anything else you might suggest.
Comment 9 Erik Kaneda 2018-10-23 18:20:56 UTC
So this patch helps solve your problem.. Unfortunately we can't upstream this. We need to somehow make this work without this patch... There may be some other issue in linux kernel ec driver. I'll get back to you soon on the next steps..
Comment 10 Erik Kaneda 2018-10-23 20:34:42 UTC
Please try 4.20-rc1 when it releases
Comment 11 Erik Kaneda 2018-11-05 16:13:51 UTC
Hello, 4.20-rc1 is out now so go ahead and give it a try. I've asked Rui to take a look at this bug because it seems like an issue with the EC driver. Please try it and let us know if the issue persists.
Comment 12 Charles Stanhope 2018-11-07 05:33:45 UTC
Created attachment 279369 [details]
Dmesg dump from 4.20-rc1

Thank you for the heads up about the tag. I just tested out 4.20-rc1, and I am seeing the same behavior as before: incorrect battery reading, and the laptop lid switch isn't working.
Comment 13 Zhang Rui 2018-11-27 04:44:05 UTC
So, first of all, please make sure your kernel is built with CONFIG_ACPI_DEBUG=Y, and then boot with kernel parameter "acpi.debug_level=0x420 acpi.debug_layer=0x05", and attach the full dmesg output after boot, for both good and bad kernels.
Comment 14 Zhang Rui 2018-11-27 05:16:23 UTC
Created attachment 279665 [details]
custom dsdt to dump bat and lid status

please apply this customized DSDT and attach
1. output of "grep . /sys/class/power_supply/*/*"
2. dmesg output after step 1
for both good and bad kernels.
Comment 15 Charles Stanhope 2018-12-03 04:58:02 UTC
Created attachment 279809 [details]
Dmesg output for 4.20-rc1 with acpi.debug_level=0x420 and acpi.debug_layer=0x05
Comment 16 Charles Stanhope 2018-12-03 05:34:00 UTC
Created attachment 279811 [details]
Dmesg dump from 4.16.0-rc2 (good) with acpi.debug_level=0x420 and acpi.debug_layer=0x05

I've attached dmesg outputs for the 4.20-rc1 kernel and a 4.16.0-rc2 (7decc66df940f) kernel with the requested kernel boot parameters. The 4.16.0-rc2 came just before the bisection result and appears to be "good". 

I've attempted to apply the dsdt in two ways. I first tried using a cpio file passed at boot time using instructions I found on the Arch wiki[0]. I was attempting to avoid compiling the kernel since I only have a little time to work on things today. (I converted the source code in the .hex to an aml file with some scripting.) I did this while I was waiting for a kernel build. As far as I can tell, this didn't seem to work. There was no kernel message indicating an override.

After the kernel finished building, I also attempted to apply the dsdt in the way probably intended by compiling it in the kernel. However, I am getting compile errors after attempting to configure the kernel build using instructions I found here at the arch wiki and the Intel open source site[1]:

 CC      drivers/acpi/tables.o                                     
drivers/acpi/tables.c: In function ‘acpi_os_table_override’:     
drivers/acpi/tables.c:722:44: error: ‘AmlCode’ undeclared (first use in this function)
   *new_table = (struct acpi_table_header *)AmlCode;                
                                            ^~~~~~~

This was with the 4.16.0-rc2 kernel I used to provide the dmesg output. I can try other commits to see if I have better luck, but it will probably be a little while before I can do that.

[0] https://wiki.archlinux.org/index.php/DSDT
[1] https://01.org/linux-acpi/documentation/overriding-dsdt
Comment 17 Zhang Rui 2018-12-03 06:08:05 UTC
please confirm if the problem is gone with the patch at https://bugzilla.kernel.org/show_bug.cgi?id=200011#c71
Comment 18 Charles Stanhope 2018-12-04 05:33:13 UTC
I confirm. With 4.20.0-rc2 and the above linked patch, the problem goes away. Without the patch, I have the same bugs as before.
Comment 19 Zhang Rui 2018-12-19 15:02:20 UTC
please confirm if the patch at https://bugzilla.kernel.org/show_bug.cgi?id=199981#c34 helps or not
Comment 20 Charles Stanhope 2018-12-24 02:23:20 UTC
I applied the patch https://bugzilla.kernel.org/show_bug.cgi?id=199981#c34 to the same 4.20.0-rc2 as before (after backing out any other patches), and it does enable the battery status and the lid switch.
Comment 21 Zhang Rui 2018-12-27 15:26:48 UTC

*** This bug has been marked as a duplicate of bug 199981 ***
Comment 22 Zhang Rui 2019-01-10 09:44:55 UTC
here is the latest patch,
https://patchwork.kernel.org/patch/10753143/
please apply it on top of 5.0-rc1 and check if it works or not.
Comment 23 Charles Stanhope 2019-01-12 05:43:41 UTC
I applied the patch to 5.0-rc1 and tested. It fixes the battery status and lid switch issue. :)