Every single boot I observe error in the journalctl logs "kernel: ucsi_acpi USBC000:00: ucsi_acpi_dsm: failed to evaluate _DSM 2" My devices specs and dmesg log are in the attachments. Is there a way to get out of the error? If I have to provide additional info please tell me
Created attachment 306237 [details] dmesg-log
Created attachment 306238 [details] system-info
*** Bug 218788 has been marked as a duplicate of this bug. ***
This looks like a symptom caused by an issue in the EC driver. The complete error in your dmesg: ... [ 12.563832] ACPI Error: No handler for Region [ECSI] (000000007b8176ee) [EmbeddedControl] (20230628/evregion-130) [ 12.564906] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20230628/exfldio-261) [ 12.566187] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error (AE_NOT_EXIST) (20230628/psparse-529) [ 12.567909] ACPI Error: Aborting method \_SB.UBTC._DSM due to previous error (AE_NOT_EXIST) (20230628/psparse-529) [ 12.569254] ACPI: \_SB_.UBTC: failed to evaluate _DSM c298836f-a47c-e411-ad36-631042b5008f (0x6) [ 12.569259] ucsi_acpi USBC000:00: ucsi_acpi_dsm: failed to evaluate _DSM 2 ... The handler for the EC operation region is missing, which is very odd, because the EC driver (drivers/acpi/ec.c) has clearly been loaded successfully based on your the same dmesg output. Can you also attach the acpidump output: % acpidump -o my_acpi.dump The ACPI guys should take a look at this. I think this is to core issue here: "ACPI Error: Region EmbeddedControl (ID=3) has no handler"
This issue has been reported earlier (indirectly): https://bugzilla.kernel.org/show_bug.cgi?id=216438.
Created attachment 306240 [details] acpi.dump
Thanks! I can see that "ECSI" EmbeddedControl OpRegion inside the scope of the UCSI device in your tables, which should be fine. I don't think we have a global handler for the EC OpRegion in Linux, which I'm quite certain we really should have - just like we have for the other types: SystemMemory, SystemIO, PCI_Config, etc. This may actually be a missing feature in ACPICA, so other operating systems may also be affected. I'll see if I can get the ACPI/ACPICA guys to take a look at this.
@Heikki Krogerus, Thank you for joining to this report. Appreciate it
Patch has been posted: https://lore.kernel.org/linux-acpi/4926735.31r3eYUQgx@kreacher/ Any chance to try it and see if it helps?
Hi Rafael J. Wysocki Thank you for joining. Looks like the patch did actually help to fix errors in journalctl. Woohoo! With the help of one guy (@loqs) from the Arch forum I was able to get a kernel build (6.8.9) with this patch included, source=( https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/${_srcname}.tar.{xz,sign} $url/releases/download/$_srctag/linux-$_srctag.patch.zst{,.sig} '4926735.31r3eYUQgx@kreacher.patch::https://lore.kernel.org/linux-acpi/4926735.31r3eYUQgx@kreacher/raw' config # the main kernel config file With this custom Kernel I don't see errors anymore and at the first look everything is working as it should be. Many thanks to you folks @Rafael J. Wysocki, @Heikki Krogerus Looking forward to see this patch in a main Kernel branch. (hope I expressed myself correctly).
Feel free if I need to test something specially
Created attachment 306285 [details] dmesq-with-patch-logs
Created attachment 306286 [details] acpi-with-patch.dump
I have added logs with patch included in case you want to take a look. Thanks!
Thanks for testing, much appreciated! However, note that the patch you tested has been replaced with: https://lore.kernel.org/linux-acpi/6046110.lOV4Wx5bFT@kreacher due to concerned related to the handling of some specific cases. Can you please test this one too, just to verify that it still helps?
This patch actually breaks battery and ac on asus gu605. AC reports as always on even if on battery. Not sure if ACPI_ROOT_OBJECT is actually handle since it's defined statically in the header (I might be wrong), and not sure that it must be used when ec == first_ec. In any case, making scope_handle value as it was before recovers battery and ac on gu605.
Created attachment 306431 [details] Using ec->handle rather ACPI_ROOT_OBJECT That patch restores battery and ac readings in sysfs for gu605.
Dear Rafael J. Wysocki, I'm working for LGE. I received an issue that some LG laptops cannot adjust display brightness by Fn + {F2,F3} key in the kernel image your patch applied. As VitliiT's opinion as mentions in Comment 17, using ec->handle can fix my issue. I've got one of debian's kernel-source packge(https://packages.debian.org/bookworm-backports/linux-source-6.9). I also found out your patch applied in the source and reproduced my issue 100%. (Your patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.43&id=96a0e06dfe0c5909dbd1f791f297f2f470e974ad) When my issue happened, below bios error log was shown. "ACPI BIOS Error (bug): Could not resolve symbol [\_TZ.FN00._OFF], AE_NOT_FOUND (20230628/psargs-330)" This error message never displayed when I reverted your patch. I mean that your patch can cause another side-effect issues. It's better the manufacturer, Lenovo, fix "No handler for Region [ECSI] " issue by correcting their UEFI, BIOS or EC firmware rather than changing linux kernel source, in my opinion. Or some quirks can be needed for this kind of ACPI error.