[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d713393c-5d08-4b7f-8d5a-1a65f6f29f59@gmx.de>
Date: Sun, 23 Mar 2025 22:55:32 +0100
From: Armin Wolf <W_Armin@....de>
To: Naveen Kumar P <naveenkumar.parna@...il.com>
Cc: linux-acpi@...r.kernel.org, rafael@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: ACPI Error: AE_AML_LOOP_TIMEOUT in \_SB.PCI0.SBUS.RDWD &
\_SB.PCI0.SBRG.ADP1._PSR
Am 22.03.25 um 16:40 schrieb Naveen Kumar P:
> On Sat, Mar 22, 2025 at 3:02 AM Armin Wolf <W_Armin@....de> wrote:
>> Am 19.03.25 um 12:29 schrieb Naveen Kumar P:
>>
>>> Hi all,
>>>
>>> I am encountering repeated AE_AML_LOOP_TIMEOUT errors in the ACPI RDWD
>>> & \_SB.PCI0.SBRG.ADP1._PSR methods. Below are relevant log entries
>>> from my system running Linux kernel 6.13.0+:
>>>
>>> [77998.038653]
>>> Initialized Local Variables for Method [RDWD]:
>>> [77998.038691] Local1: 00000000d0fe9fee <Obj> Integer
>>> 0000000000000015
>>> [77998.038862] Local6: 00000000f41c1645 <Obj> Integer
>>> 0000000000000000
>>> [77998.039031] Local7: 0000000040665c5c <Obj> Integer
>>> 000000000000AA55
>>>
>>> [77998.039237] Initialized Arguments for Method [RDWD]: (2 arguments
>>> defined for method invocation)
>>> [77998.039273] Arg0: 00000000397dc53d <Obj> Integer
>>> 0000000000000014
>>> [77998.039442] Arg1: 000000001099e334 <Obj> Integer
>>> 0000000000000002
>>>
>>> [77998.039673] ACPI Error: Aborting method \_SB.PCI0.SBUS.RDWD due to
>>> previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [77998.040455] ACPI Error: Aborting method \_SB.PCI0.SBRG.ADP1._PSR
>>> due to previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [77998.043659] ACPI: \_SB_.PCI0.SBRG.ADP1: Error reading AC Adapter
>>> state: AE_AML_LOOP_TIMEOUT
>>>
>>> [78028.442980]
>>> Initialized Local Variables for Method [RDWD]:
>>> [78028.443019] Local1: 00000000898a9a7e <Obj> Integer
>>> 0000000000000017
>>> [78028.443192] Local6: 000000000cf0c853 <Obj> Integer
>>> 0000000000000000
>>> [78028.443362] Local7: 00000000bb4aa65f <Obj> Integer
>>> 000000000000AA55
>>>
>>> [78028.443569] Initialized Arguments for Method [RDWD]: (2 arguments
>>> defined for method invocation)
>>> [78028.443606] Arg0: 00000000ef8d445b <Obj> Integer
>>> 0000000000000016
>>> [78028.443775] Arg1: 000000006cacc887 <Obj> Integer
>>> 0000000000000003
>>>
>>> [78028.444006] ACPI Error: Aborting method \_SB.PCI0.SBUS.RDWD due to
>>> previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [78028.446366] ACPI Error: Aborting method \_SB.PCI0.SBRG.ADP1._PSR
>>> due to previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [78028.451179] ACPI: \_SB_.PCI0.SBRG.ADP1: Error reading AC Adapter
>>> state: AE_AML_LOOP_TIMEOUT
>>>
>>> [78032.877472]
>>> Initialized Local Variables for Method [RDWD]:
>>> [78032.877509] Local1: 00000000cf6291ae <Obj> Integer
>>> 0000000000000017
>>> [78032.877682] Local6: 0000000026aa8a7a <Obj> Integer
>>> 0000000000000003
>>> [78032.877851] Local7: 00000000acfa20e0 <Obj> Integer
>>> 000000000000AA55
>>>
>>> [78032.878058] Initialized Arguments for Method [RDWD]: (2 arguments
>>> defined for method invocation)
>>> [78032.878094] Arg0: 00000000a186096f <Obj> Integer
>>> 0000000000000016
>>> [78032.878262] Arg1: 00000000d0e1eefe <Obj> Integer
>>> 0000000000000003
>>>
>>> [78032.878492] ACPI Error: Aborting method \_SB.PCI0.SBUS.RDWD due to
>>> previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [78032.881011] ACPI Error: Aborting method \_SB.PCI0.SBRG.ADP1._PSR
>>> due to previous error (AE_AML_LOOP_TIMEOUT) (20240827/psparse-529)
>>> [78032.883061] ACPI: \_SB_.PCI0.SBRG.ADP1: Error reading AC Adapter
>>> state: AE_AML_LOOP_TIMEOUT
>>>
>>>
>>> This issue appears randomly, affecting the RDWD method, which is
>>> likely responsible for reading data from a bus, and consequently
>>> causing the _PSR method (power state read) to fail.
>>>
>>>
>>> Questions:
>>> 1. What typically causes AE_AML_LOOP_TIMEOUT errors?
>> AFAIK this error is caused by a while loop taking too long to finish. I suspect that
>> the ACPI bytecode tries to wait for a non-responsive hardware device.
>>
>>> 2. Could these ACPI errors impact PCI device access?
>>> Since the error originates from _SB.PCI0.SBUS.RDWD, could this failure
>>> affect PCI device communication or cause failures when accessing PCI
>>> devices?
>> I do not think so, the SBUS device is likely just a SMBus controller attached to the PCI bus.
>>
>>> 3. Could this be a firmware/BIOS issue?If so, what tools or steps
>>> should I use to verify and debug the ACPI tables?
>> It is either a hardware issue or a BIOS bug. Can you share the output of the "acpidump" utility
>> provided by the ACPICA project? Many Linux distributions already package ACPICA in their package repositories.
> I have attached the acpi.tar.gz file as requested. This archive
> contains the output from the "acpidump" utility. Below is a list of
> the files included in the archive:
>
> ls -ltr acpi
> total 760
> -rw-rw-r-- 1 murphy murphy 205609 Mar 19 18:30 acpi_tables.txt
> -rw-r--r-- 1 root root 60 Mar 19 18:31 mcfg.dat
> -rw-r--r-- 1 root root 132 Mar 19 18:31 apic.dat
> -rw-r--r-- 1 root root 656 Mar 19 18:31 ssdt2.dat
> -rw-r--r-- 1 root root 66 Mar 19 18:31 uefi.dat
> -rw-r--r-- 1 root root 36402 Mar 19 18:31 dsdt.dat
> -rw-r--r-- 1 root root 260 Mar 19 18:31 lpit.dat
> -rw-r--r-- 1 root root 378 Mar 19 18:31 ssdt3.dat
> -rw-r--r-- 1 root root 268 Mar 19 18:31 facp.dat
> -rw-r--r-- 1 root root 68 Mar 19 18:31 fpdt.dat
> -rw-r--r-- 1 root root 1891 Mar 19 18:31 ssdt1.dat
> -rw-r--r-- 1 root root 332 Mar 19 18:31 csrt.dat
> -rw-r--r-- 1 root root 56 Mar 19 18:31 hpet.dat
> -rw-r--r-- 1 root root 64 Mar 19 18:31 facs.dat
> -rw-r--r-- 1 root root 890 Mar 19 18:31 ssdt4.dat
> -rw-r--r-- 1 root root 141 Mar 19 18:31 ssdt7.dat
> -rw-r--r-- 1 root root 1075 Mar 19 18:31 ssdt5.dat
> -rw-r--r-- 1 root root 351 Mar 19 18:31 ssdt6.dat
> -rw-rw-r-- 1 murphy murphy 5919 Mar 19 18:31 apic.dsl
> -rw-rw-r-- 1 murphy murphy 8131 Mar 19 18:31 csrt.dsl
> -rw-rw-r-- 1 murphy murphy 337832 Mar 19 18:31 dsdt.dsl
> -rw-rw-r-- 1 murphy murphy 10103 Mar 19 18:31 facp.dsl
> -rw-rw-r-- 1 murphy murphy 1368 Mar 19 18:31 facs.dsl
> -rw-rw-r-- 1 murphy murphy 1802 Mar 19 18:31 fpdt.dsl
> -rw-rw-r-- 1 murphy murphy 1863 Mar 19 18:31 hpet.dsl
> -rw-rw-r-- 1 murphy murphy 7523 Mar 19 18:31 lpit.dsl
> -rw-rw-r-- 1 murphy murphy 1524 Mar 19 18:31 mcfg.dsl
> -rw-rw-r-- 1 murphy murphy 9996 Mar 19 18:31 ssdt1.dsl
> -rw-rw-r-- 1 murphy murphy 7692 Mar 19 18:31 ssdt2.dsl
> -rw-rw-r-- 1 murphy murphy 4296 Mar 19 18:31 ssdt3.dsl
> -rw-rw-r-- 1 murphy murphy 8290 Mar 19 18:31 ssdt4.dsl
> -rw-rw-r-- 1 murphy murphy 16968 Mar 19 18:31 ssdt5.dsl
> -rw-rw-r-- 1 murphy murphy 2843 Mar 19 18:31 ssdt6.dsl
> -rw-rw-r-- 1 murphy murphy 1337 Mar 19 18:31 ssdt7.dsl
> -rw-rw-r-- 1 murphy murphy 1383 Mar 19 18:31 uefi.dsl
>
>
> Please let me know if you need any further details or additional
> information to assist in debugging the ACPI tables.
>
> Thank you for your help.
Alright, it seems that the ACPI bytecode is trying to access the charger using the smbus interface.
For some reason this takes over 30 seconds which causes the ACPI interpreter to throw this error.
Can you check how long it normally takes to read the "online" sysfs attribute of the charger located
under "/sys/class/power_supply/ADP1"?
Also please share the output of "lspci -v".
Thanks,
Armin Wolf
>>> 4. Is there a recommended workaround to mitigate this issue?
>> You can check if a BIOS update is available for your device.
>>
>>> 4. How can I debug this further?I can enable additional ACPI debugging
>>> logs or provide dumps of ACPI tables if necessary.
>> I can take a look at the \_SB.PCI0.SBUS.RDWD method inside the ACPI table dumps
>> to see where the error is coming from.
>>
>> Thanks,
>> Armin Wolf
>>
>>> Any guidance on resolving or further diagnosing this issue would be
>>> highly appreciated.
>>>
>>> Best regards,
>>> Naveen
>>>
Powered by blists - more mailing lists