First time reporting a bug (Hope I have identified the correct subsystem) ACPI doesn't read the battery information in kernel versions 4.20 and later on Toshiba Satellite C870-13D By bisecting the problem I found that the first bad commit on the linux kernel repository is: 8b1cafdcb4b75c5027c52f1e82b47ebe727ad7ed The problem is not just in the front en as the information is unavailable or incorrect (default 0) in /sys/class/power_supply/
Please post an acpidump of your machine https://01.org/linux-acpi/utilities as well as the dmesg
Created attachment 282715 [details] acpidump
Created attachment 282717 [details] dmesg when not working dmesg was run as the first command after reboot on the latest build of arch linux (5.0.13) the bug exists in this version
Created attachment 282719 [details] dmesg when working dmesg was run as the first command after reboot using arch linux lts 4.19.41-1 the bug does not occur in this version, added for a comparison
(In reply to Bjarki Geir Benediktsson from comment #0) > First time reporting a bug (Hope I have identified the correct subsystem) > > ACPI doesn't read the battery information in kernel versions 4.20 and later > on Toshiba Satellite C870-13D > > By bisecting the problem I found that the first bad commit on the linux > kernel repository is: > 8b1cafdcb4b75c5027c52f1e82b47ebe727ad7ed For my own notes, here is the commit log for this commit ID: ACPICA: Never run _REG on system_memory and system_IO These address spaces are defined by the ACPI spec to be "always available", and thus _REG should never be run on them. Provides compatibility with other ACPI implementations. > > The problem is not just in the front en as the information is unavailable or > incorrect (default 0) in /sys/class/power_supply/
Thanks for the info. I need a little more... Please build both old and new with the kernel with CONFIG_ACPI_DEBUG=y and boot with the following command line parameter: "acpi.debug_layer=0xffffffff acpi.debug_level=0x400 log_buf_len=10M"
and I forgot to mention: please post both dmesg logs with the above command.
Created attachment 282749 [details] dmesg with debug info Hope I have managed to pass these parameters correctly
Created attachment 282751 [details] dmesg with debug info when working dmesg log whith acpi debug info I forgot to mention for the previous upload, that was dmesg from the latest kernel build where the bug occurs, this file is from linux-lts where the bug does not occur
I believe the problem has been fixed. Bug closed. Bjarki, please feel free to re-open it if the problem still exists in the latest upstream kernel.
Just built and tested latest upstream kernel, problem exists
can you please check if the problem still exists in the latest upstream kernel, say 5.7 or 5.8-rc?
Just built and tested v5.8-rc3 more specificially commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 Problem exists in that version. When I was configuring the Kernel I accepted all default options but there where a couple that cought my eye as possibly relevant and I thought I'd mention these where all turned off by default. ACPI_HMAT BATTERY_CW2015 SYSTEM76_ACPI are any of them likely to affect the situation ?
Created attachment 293893 [details] Proposed fix I tried digging further into the commit that introduced the bug and wrote a patch that fixes the issue under kernel version 5.10 by reverting part of it.
Created attachment 293953 [details] Minimal patch Minimal code change that fixes the bug.
TBH, I'm confused, $ grep _REG *.dsl dsdt.dsl: Method (_REG, 2, NotSerialized) // _REG: Region Availability Method (_REG, 2, NotSerialized) // _REG: Region Availability { ECFL = One Local1 = RRAM (0x04A0) Local1 |= 0x08 WRAM (0x04A0, Local1) TTPH () ECPH () } 1. There is only one _REG method. 2. The _REG method is located under the EC device node, \_SB.PCI0.LPCB.EC0._REG. 3. The _REG method does not check Arg0 (address space ID) 4. There is no EmbeddedControl OperationRegion defined under EC device node. This explains why you patch makes a difference. First of all, _REG needs to be evaluated. And usually, EC._REG will be evaluated when installing the EC address space handler. But on this specific platform, there is no EC operation region, which means this _REG does not have a chance to get evaluated. Currently, I'm not sure how to fix this. Let me sync with the ACPICA experts and get back later.
It gets evaluated with the patch, though, so I'm wondering how that happens. It can be either via acpi_install_address_space_handler() or through acpi_ev_initialize_op_regions(), so I guess the latter?
Bjarki, As this is actually a firmware issue, which is exposed by the commit you bisected, would you please check if there is any newer BIOS available? and if yes, please check if the problem still exists after upgrading the BIOS.
And please attach the dmidecode output.
As the laptop model is not released for international markets finding BIOS wasn't easy. I found a newer BIOS (released in 2014) but since the laptop is mission critical for my PhD thesis I will not be risking flashing the bios until after I submit, hopefully later this summer. Do I understand correctly that the patch isn't being considered for adoption?
No, we won't apply the proposed fix in this report because the original patch is the right direction, and the issue in this bug report is caused by a BIOS that violates the ACPI spec. And for the current issue, we'd like to generate a quirk patch to force run the _REG method under EC namespace for this specific model, which also solves the problem for you. And that is why I asked for dmidecode of this laptop. Please attach it.
Hi, Bjarki, can you please attach the dmidecode of this laptop so that I can propose a quirk patch for this system?
Created attachment 297099 [details] dmidecode attached the dmidecode
Created attachment 297115 [details] patch: force evaluate EC _REG please apply the patch on top of latest upstream Linux kernel and check if the problem is gone or not.
Patch applied, problem persists
Can you see this line "Detected system needing force evaluating EC _REG." in dmesg after boot, after enabling the dynamic debug for ec.c?
As I have never used dynamic debug before, and found the instructions I could find confusing, I just wanted to make sure I did this correctly I mounted debugfs as root ran "echo -n 'file acpi/ec.c +p' > debugfs/dynamic_debug/control" then rebooted the machine and checked DMESG and the message wasn't there
No, below is how I did this. add this line in drivers/acpi/Makefile diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 700b41adf2db..1597109367d4 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -4,6 +4,7 @@ # ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT +ccflags-$(CONFIG_ACPI_DEBUG) += -DDEBUG # # ACPI Boot-Time Table Parsing And then reboot.
Thanks for the instructions. The message does not appear in DMESG after adding this line and rebooting
I probably also added dyndbg="module acpi +p" in my kernel commandline, but I'm not pretty sure right now. IMO, a simple way is to just change pr_debug("Detected system needing force evaluating EC _REG.\n"); to printk("Detected system needing force evaluating EC _REG.\n"); and confirm.
ping...
Tried adding dyndbg="module acpi +p" to the command line, and still couldn't find the message in dmesg
a simple way is to just change pr_debug("Detected system needing force evaluating EC _REG.\n"); to printk("Detected system needing force evaluating EC _REG.\n"); and confirm. I want to make sure if the quirk is applied first, and if yes, I'd be curious why the quirk does not work for you.
I changed it from pr_debug to printk built, intstalled and rebooted but the line does not appear in dmesg
Good to know. This means that the quirk is not applied successfully for some unknown reason, not the idea of the patch is not working, so it is good news. so below is your system dmidecode Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: TOSHIBA Product Name: SATELLITE C870-13D Version: PSC8AE-019005N5 Serial Number: 5C041590R UUID: c7ccae00-4c0a-81e2-2fcf-e840f2dfcd08 Wake-up Type: Power Switch SKU Number: PSC8AE-019005N5 Family: Type1Family And this is the code in my patch. + { + /* https://bugzilla.kernel.org/show_bug.cgi?id=203563 */ + ec_force_reg, "TOSHIBA SATELLITE C870-13D", { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE C870-13D"),}, NULL}, TBH, I don't see anything wrong here. Can you double check your dmidecode output?
Created attachment 297815 [details] debug patch to dump dmi info Please apply this patch on top, and attach the dmesg output after boot.
Created attachment 297847 [details] dmesg Added the dmesg after applying your patch The print commands don't appear, there is clearly something not right with acpi, it complains about a lack of context,
I'd say the important messages are flushed by these error messages. Do you see these messages in your previous kernel? Better rebuild your kernel and boot with the previous changes reverted, including +ccflags-$(CONFIG_ACPI_DEBUG) += -DDEBUG and kernel commandline dyndbg="module acpi +p"
I have now had a chance to flash the latest BIOS, and the issue no longer presents under Linux 5.13.8-arch-1 (the latest version packaged by Arch Linux) I changed the status to resolved, should we still pursue the quirk patch or leave it as is ?