Created attachment 1483762 [details] acpidump output for 4.16.14 kernel Description of problem: Since F28 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. The 4.16 series did not exhibit this behavior. I still have a 4.16.14 kernel on my system since I've used "dnf versionlock" to hopefully prevent it being removed. Version-Release number of selected component (if applicable): All 4.17 series and 4.18 series kernel I have tried show this problem. The last version I tried was 4.18.7. How reproducible: Whenever I boot into the newer kernels, this behavior is experienced. Steps to Reproduce: 1. 2. 3. Actual results: Cannot read battery status, and the system will not suspend when the lid is closed. For example: $ acpi Battery 0: Discharging, 100%, 4200:00:00 remaining Expected results: I should be able to read battery status and suspend when the lid is closed. Example: $ acpi Battery 0: Discharging, 90%, 05:27:57 remaining Additional info: I've attached an acpi dump for the working kernel as well as for a kernel where it doesn't work. I don't know if it is relevant, but I noticed the results were different between the two.
Created attachment 1483763 [details] acpidump output for 4.18.7 kernel
I forgot the kernel version for the working kernel. $ uname -r -v 4.16.14-300.fc28.x86_64 #1 SMP Tue Jun 5 16:23:44 UTC 2018
Hi Charles, It's likely that the battery issue and the lid issue aren't related (although it sounds like both were introduced in 4.17). Can you test the 4.17 development kernels[0] and see which one introduces each bug? The list is sorted by build time so I recommend starting in the middle. Once you find which versions first introduce the problems (it might be the same one) we can figure out what commit is responsible. Thanks! [0] https://koji.fedoraproject.org/koji/search?match=glob&type=build&terms=kernel-4.17.0*
Hello, Jeremy. Thank you for the suggestion. I did a bit of a binary search on those builds. It turns out that 4.17.0-0.rc0.git1 works, but by the time I get to rc0.git4 both the battery status and lid switch are not working. I couldn't test rc0.git2 and rc0.git3 because their builds failed. I'm happy to perform other steps to narrow it down further if I can.
Okay. 4.17.0-0.rc0.git1 corresponds to commit 642e7fd23353e upstream, and 4.17.0-0.rc0.git4 corresponds to commit 38c23685b273. If you bisect the kernel[0] using 642e7fd23353e as the "good" commit and 38c23685b273 as the bad one, you should figure out which commit introduces each problem. [0] https://docs.fedoraproject.org/en-US/quick-docs/kernel/troubleshooting/index.html#_bisecting_the_kernel
I finally found some time to try to work on the bisection. However, I am running F28, which has gcc 8.1.1. By my second kernel compile, I started running into a known kernel compile problem on tools/lib/str_error_r.c[0]. I have been doing "bisect skip" for a while, and I keep hitting it. So I doubt the bisection will be very useful at this point. I only got one bad kernel out of my efforts so far (9eb31227cbcc). As a result, I'm starting the bisection over using that one commit as the bad end. I'm going to try to work around that compile problem by patching that file as necessary. If that doesn't work, I can try setting myself up with a different compiler version, but that will take more effort. I'm just letting people know I'm working on this as I can. [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
Charles, What you can do instead of "bisect skip" is download this file: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=854e55ad289ef8888e7991f0ada85d5846f5afb9 Rename the index.html?id=... file to gcc8-fix.patch and after the bisect bad / good do: "git am gcc8-fix.patch" before building. And *important* then before doing the next "git bisect good" (or bad) do: git checkout HEAD~ to restore the original HEAD from the previous bisect good/bad. I hope this helps. Regards, Hans
Hans, thank you for the suggestion. I wasn't aware I could do that with the cgit interface. I believe I'm doing an equivalent. I generated a patch by diffing between the first kernel I was able to build and one of them that was causing me a problem (just for that file). So I applied that as a patch before building. This seems to be working, and I am careful to restore the repo state to HEAD before proceeding with the bisect. Thanks again! :)
It took less time to do the bisection than I thought, since I managed to test two kernels a day. According to the bisection: 5a8361f7ecceaed64b4064000d16cb703462be49 is the first bad commit It does appear as though this commit caused the problem with both reading the battery status and the laptop lid switch. On the above commit I see both problems I originally reported, and on the commit just before it (7decc66df940fc0b128a642df9ac3d917f1b0c1f) both features are working fine.
Ok so that would be: ACPICA: Integrate package handling with module-level code ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7 IOW deep in the ACPICA code. It probably is best if you file a bug upstream for this against the ACPI code, including a comment that you've bisected it to this exact commit: https://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Once I saw the commit, I figured somebody would say something like that. :) I submitted a bug upstream[0]. Thanks for the help getting me this far. [0] https://bugzilla.kernel.org/show_bug.cgi?id=201351
(In reply to Charles Stanhope from comment #11) > Once I saw the commit, I figured somebody would say something like that. :) > > I submitted a bug upstream[0]. Thanks for the help getting me this far. > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=201351 Thanks, there is not much we can do on the Fedora side about this, so I'm going to close this bug with a resolution of upstream, which means this is not fixed but being looked at upstream.
*** Bug 1643990 has been marked as a duplicate of this bug. ***
*** Bug 1594591 has been marked as a duplicate of this bug. ***