Bug 216390
Summary: | Could not resolve symbol [\_SB.PCI0.LPC0.EC0.AC._PSR.AFN4], AE_NOT_FOUND (20220331/psargs-330) | ||
---|---|---|---|
Product: | ACPI | Reporter: | arthur (arthur.widetschek) |
Component: | BIOS | Assignee: | Mark Pearson (mpearson-lenovo) |
Status: | RESOLVED ANSWERED | ||
Severity: | normal | CC: | agurenko, aros, mario.limonciello |
Priority: | P1 | ||
Hardware: | AMD | ||
OS: | Linux | ||
Kernel Version: | 5.19.2 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
acpidump FIle
acpixtract added |
Description
arthur
2022-08-21 13:23:43 UTC
As this is caused by a firmware upgrade, it should be reported to Lenovo to fix. I doubt they consider it as high priority. But i will try it. perhaps this issue can be remain open. Some people may have similar problems. perhaps it is also related to the kernel. i also had messages after the kernel upgrade but this was an uefi issue. You could add an acpidump to this issue to point out exactly where the bug is. At a glance it's probably trying to use a variable that isn't in scope. Depending upon what the variable is used for it may cause that method to fail or it may just be cosmetic. Created attachment 301618 [details]
acpidump FIle
acipdump.txt added
I added the acpidump File. Many thanks in advance Created attachment 301619 [details]
acpixtract added
acpixtract added
The DSDT refers to an external method AFN4(): External (_SB_.PCI0.LPC0.EC0_.AFN4, MethodObj) // 1 Arguments It then makes use of this twice in the function that showed the unable to resolve: If (((Local0 != ACDC) || (ACDC == 0xFF))) { CreateWordField (XX00, 0x00, SSZE) CreateByteField (XX00, 0x02, ACST) SSZE = 0x03 ACDC = Local0 If (ACDC) { AFN4 (0x01) ACST = 0x00 } Else { AFN4 (0x02) ACST = 0x01 } ALIB (0x01, XX00) } However nowhere in the DSDT or any of the SSDTs that you shared does AFN4 actually exist. This is a BIOS bug and the kernel can't do anything about it. Thanks a lot. I think the kernel team cannot do anything so i close this issue. Thanks for your help ok its already resolved. thanks is it better to downgrade the bios or are these errors just cosmetic? (In reply to arthur from comment #10) > is it better to downgrade the bios or are these errors just cosmetic? Mario Limonciello said: "Depending upon what the variable is used for it may cause that method to fail or it may just be cosmetic." Just ignore them. I have yet to find a system which doesn't have ACPI errors/warnings under Linux. thanks a lot > Just ignore them. I have yet to find a system which doesn't have ACPI > errors/warnings under Linux. I don't think this is the correct attitude. This very well may be the reason for bugs like https://bugzilla.kernel.org/show_bug.cgi?id=216347 for all you know. Every time the ACPI interpreter reports a bug it should be fixed; either by the firmware or by the kernel (if the kernel is being too strict). Perhaps fwupd can do something: https://github.com/fwupd/firmware-lenovo/issues/262. I did not find any lenovo instance to report a bug. Its frustrating. I asked the community: https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile-Workstations/ACPI-BIOS-Error-Bug-after-Bios-Upgrade/m-p/5165148?page=1#5723090 Flagged to FW team (Internal ticket # LO-1974) Mark (In reply to Mario Limonciello (AMD) from comment #13) > I don't think this is the correct attitude. This very well may be the > reason for bugs like https://bugzilla.kernel.org/show_bug.cgi?id=216347 for > all you know. > > Every time the ACPI interpreter reports a bug it should be fixed; either by > the firmware or by the kernel (if the kernel is being too strict). In a perfect world, yes, however you alone cannot do that and lots of systems continue to have ACPI errors/warnings and other kernel hackers couldn't care less. For instance there's this bug which affects literally millions of systems, a patch was suggested five (!) ago, yet seemingly no one gives a f: https://bugzilla.kernel.org/show_bug.cgi?id=201885 It's "cosmetic" per se, but considering how simple the patch was and the fact that no one has upstreamed it, it all looks quite sad. And it affects my AMD X570 system as well. > For instance there's this bug which affects literally millions of systems, a > patch was suggested five (!) ago, yet seemingly no one gives a f: I think this is guaranteed cosmetic though due to the difference of how Windows and Linux handle the ACPI-WMI repository currently. It's well contained and understood. > It's "cosmetic" per se, but considering how simple the patch was and the fact > that no one has upstreamed it, it all looks quite sad. Please feel free to take over and finish the fixups and send it! This is the remaining comment: " I think you also need to audit all the users of wmi_block_list for duplicate handling. For example, wmi_install_notify_handler() probably needs a break statement inside the if (memcmp(...)). " For the P14s this has been fixed in BIOS R1MET51W/R1NET53W. Release is scheduled for mid-October (it goes thru internal testing etc and delays can happen if issues are found) Pretty sure I'm next gonna be asked 'what about other platforms' - I'm asking on those but _usually_ fixes get propagated to other platforms and it just takes time. Mark https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=134038b075cb1dae21623499d765973d286ac94a should improve this too (in 6.1). FW is on LVFS - let me know if you still see problems Mark Thanks a lot. Yes errors are gone, but there are new errors: https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile-Workstations/ACPI-BIOS-Error-Bug-after-Bios-Upgrade-Failure-creating-named-object/m-p/5181338 https://bugzilla.kernel.org/show_bug.cgi?id=216677 |