Message-ID: <9681a1f6-9c1a-4299-b4f1-dc451bc418ee@gmx.de>
Date: Sat, 20 Dec 2025 13:56:32 +0100
From: Armin Wolf <W_Armin@....de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux ACPI <linux-acpi@...r.kernel.org>,
 Linux PM <linux-pm@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v1 0/2] PCI: ACPI: PM: Rework root bus wakeup notification
 setup and wakeup source registration

Am 10.12.25 um 02:56 schrieb Rafael J. Wysocki:

> On Wed, Dec 10, 2025 at 1:29 AM Armin Wolf <W_Armin@....de> wrote:
>> Am 09.12.25 um 23:18 schrieb Rafael J. Wysocki:
>>
>>> On Tue, Dec 9, 2025 at 11:00 PM Armin Wolf <W_Armin@....de> wrote:
>>>> Am 09.12.25 um 14:56 schrieb Armin Wolf:
>>>>
>>>>> Am 09.12.25 um 12:31 schrieb Rafael J. Wysocki:
>>>>>
>>>>>> On Mon, Dec 8, 2025 at 9:01 PM Armin Wolf <W_Armin@....de> wrote:
>>>>>>> Am 08.12.25 um 13:09 schrieb Rafael J. Wysocki:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Patch [1/2] updates the registration of PCI root bus wakeup
>>>>>>>> notification setup
>>>>>>>> in order to simplify code in pci_acpi_wake_bus() and to prepare for
>>>>>>>> the other
>>>>>>>> change.  This is not expected to affect functionality.
>>>>>>>>
>>>>>>>> Patch [2/2] modifies the ACPI PM notifier registration to add
>>>>>>>> wakeup sources
>>>>>>>> under devices that are going to be affected by wakeup handling
>>>>>>>> instead of
>>>>>>>> registering them under ACPI companions of those devices (rationale
>>>>>>>> explained
>>>>>>>> in the patch changelog).  This will change the sysfs layout (wakeup
>>>>>>>> source
>>>>>>>> devices associated with PCI wakeup are now going to appear under
>>>>>>>> PCI devices
>>>>>>>> and the host bridge device), but it is not expected to affect user
>>>>>>>> space
>>>>>>>> adversely.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>> I tested both patches, and the sysfs layout changes as expected:
>>>>>>>
>>>>>>> $ readlink /sys/class/wakeup/wakeup*/device
>>>>>>> ../../../device:00
>>>>>>> ../../../device:1a
>>>>>>> ../../../device:1f
>>>>>>> ../../../device:20
>>>>>>> ../../../0000:00:08.1
>>>>>>> ../../../device:36
>>>>>>> ../../../device:31
>>>>>>> ../../../device:32
>>>>>>> ../../../device:3c
>>>>>>> ../../../0000:01:00.0
>>>>>>> ../../../device:3d
>>>>>>> ../../../PNP0C02:00
>>>>>>> ../../../0000:02:00.0
>>>>>>> ../../../device:3e
>>>>>>> ../../../device:3f
>>>>>>> ../../../device:46
>>>>>>> ../../../0000:04:00.0
>>>>>>> ../../../device:47
>>>>>>> ../../../0000:05:00.0
>>>>>>> ../../../device:57
>>>>>>> ../../../0000:05:08.0
>>>>>>> ../../../device:59
>>>>>>> ../../../device:01
>>>>>>> ../../../0000:05:09.0
>>>>>>> ../../../device:5b
>>>>>>> ../../../0000:05:0a.0
>>>>>>> ../../../device:5d
>>>>>>> ../../../0000:05:0b.0
>>>>>>> ../../../device:5f
>>>>>>> ../../../0000:05:0c.0
>>>>>>> ../../../device:74
>>>>>>> ../../../0000:05:0d.0
>>>>>>> ../../../device:5a
>>>>>>> ../../../device:3a
>>>>>>> ../../../device:5c
>>>>>>> ../../../device:60
>>>>>>> ../../../device:75
>>>>>>> ../../../LNXVIDEO:00
>>>>>>> ../../../device:22
>>>>>>> ../../../PNP0C02:02
>>>>>>> ../../../device:25
>>>>>>> ../../../device:2b
>>>>>>> ../../../device:24
>>>>>>> ../../../device:37
>>>>>>> ../../../0000:00:01.1
>>>>>>> ../../../PNP0A08:00
>>>>>>> ../../../LNXPWRBN:00
>>>>>>> ../../../AMDI0010:00
>>>>>>> ../../../AMDI0030:00
>>>>>>> ../../../00:02
>>>>>>> ../../../alarmtimer.0.auto
>>>>>>> ../../../PNP0C0C:00
>>>>>>> ../../../0000:0b:00.0
>>>>>>> ../../../AMDIF031:00
>>>>>>> ../../../PNP0C14:00
>>>>>>> ../../../device:0a
>>>>>>> ../../../PNP0C14:01
>>>>>>> ../../../PNP0C14:02
>>>>>>> ../../../PNP0C14:03
>>>>>>> ../../../0000:0e:00.3
>>>>>>> ../../../0000:0e:00.4
>>>>>>> ../../../0000:0f:00.0
>>>>>>> ../../../5-2
>>>>>>> ../../../1-5.3
>>>>>>> ../../hidpp_battery_0
>>>>>>> ../../../device:44
>>>>>>> ../../../0000:00:02.1
>>>>>>> ../../../device:76
>>>>>>> ../../../device:0b
>>>>>>>
>>>>>>> turns into:
>>>>>>>
>>>>>>> $ readlink /sys/class/wakeup/wakeup*/device
>>>>>>> ../../../0000:00:00.0
>>>>>>> ../../../0000:00:04.0
>>>>>>> ../../../0000:00:08.0
>>>>>>> ../../../0000:00:08.1
>>>>>>> ../../../0000:00:08.1
>>>>>>> ../../../0000:00:08.3
>>>>>>> ../../../0000:00:14.0
>>>>>>> ../../../0000:00:14.3
>>>>>>> ../../../0000:01:00.0
>>>>>>> ../../../0000:01:00.0
>>>>>>> ../../../0000:02:00.0
>>>>>>> ../../../0000:00:00.2
>>>>>>> ../../../0000:02:00.0
>>>>>>> ../../../0000:03:00.0
>>>>>>> ../../../0000:03:00.1
>>>>>>> ../../../0000:04:00.0
>>>>>>> ../../../0000:04:00.0
>>>>>>> ../../../0000:05:00.0
>>>>>>> ../../../0000:05:00.0
>>>>>>> ../../../0000:05:08.0
>>>>>>> ../../../0000:05:08.0
>>>>>>> ../../../0000:05:09.0
>>>>>>> ../../../0000:00:01.0
>>>>>>> ../../../0000:05:09.0
>>>>>>> ../../../0000:05:0a.0
>>>>>>> ../../../0000:05:0a.0
>>>>>>> ../../../0000:05:0b.0
>>>>>>> ../../../0000:05:0b.0
>>>>>>> ../../../0000:05:0c.0
>>>>>>> ../../../0000:05:0c.0
>>>>>>> ../../../0000:05:0d.0
>>>>>>> ../../../0000:05:0d.0
>>>>>>> ../../../0000:08:00.0
>>>>>>> ../../../0000:00:01.1
>>>>>>> ../../../0000:09:00.0
>>>>>>> ../../../0000:0b:00.0
>>>>>>> ../../../0000:0c:00.0
>>>>>>> ../../../0000:0e:00.0
>>>>>>> ../../../0000:0e:00.1
>>>>>>> ../../../0000:0e:00.2
>>>>>>> ../../../0000:0e:00.3
>>>>>>> ../../../0000:0e:00.4
>>>>>>> ../../../0000:0e:00.6
>>>>>>> ../../../0000:0f:00.0
>>>>>>> ../../../0000:00:01.1
>>>>>>> ../../../pci0000:00
>>>>>>> ../../../LNXPWRBN:00
>>>>>>> ../../../AMDI0010:00
>>>>>>> ../../../AMDI0030:00
>>>>>>> ../../../00:02
>>>>>>> ../../../alarmtimer.0.auto
>>>>>>> ../../../PNP0C0C:00
>>>>>>> ../../../0000:0b:00.0
>>>>>>> ../../../AMDIF031:00
>>>>>>> ../../../PNP0C14:00
>>>>>>> ../../../0000:00:02.0
>>>>>>> ../../../PNP0C14:01
>>>>>>> ../../../PNP0C14:02
>>>>>>> ../../../PNP0C14:03
>>>>>>> ../../../0000:0e:00.3
>>>>>>> ../../../0000:0e:00.4
>>>>>>> ../../../0000:0f:00.0
>>>>>>> ../../../5-2
>>>>>>> ../../../1-5.3
>>>>>>> ../../hidpp_battery_0
>>>>>>> ../../../0000:00:02.1
>>>>>>> ../../../0000:00:02.1
>>>>>>> ../../../0000:00:02.2
>>>>>>> ../../../0000:00:03.0
>>>>>>>
>>>>>>> The remaining ACPI devices are likely caused by device drivers based
>>>>>>> upon struct acpi_driver.
>>>>>>> I was unable to test the wakeup itself since suspend is currently
>>>>>>> broken due to issues with
>>>>>>> cpuidle,
>>>>>> Have you reported those?  What cpuidle driver is involved?
>>>>>>
>>>>>> If you happen to be using the ACPI idle driver, there is a regression
>>>>>> between 6.18-rc7 and final 6.18 due to a missing revert, but final
>>>>>> 6.18 should be as expected.
>>>>> If i remember correctly the official 6.18 kernel was not affected by
>>>>> this, i used the the bleeding-edge
>>>>> branch when building the test kernel.
>>>>>
>>>>> I will do some further debugging once i am back home.
>>>>>
>>>>> Thanks,
>>>>> Armin Wolf
>>>>>
>>>> Well, it turned out that the cpuidle driver was not involved in this, i just got confused
>>>> by a separate stacktrace caused by the hid-roccat driver (i already reported that).
>>>>
>>>> This seems to be the real issue:
>>>>
>>>> [  514.910759] ACPI Error: Aborting method \M402 due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
>>>> [  514.910810] ACPI Error: Aborting method \_SB.PCI0.GPP0.M241 due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
>>>> [  514.910890] ACPI Error: Aborting method \_SB.PCI0.GPP0.M237._OFF due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
>>> It looks like there is a problem with turning a power resource off.
>>>
>>>> Sleeping itself works, it just takes a long time for the machine to actually suspend due to the timeout.
>>>> I attached the acpidump of the affected machine in case you are interested.
>>>>
>>>> Since 6.18 is not affected by this i will wait till 6.19-rc1 is released before i start debugging this issue.
>>>> Do you think that this approach is OK?
>>> It should be fine although you may as well check my pm-6.19-rc1,
>>> acpi-6.19-rc1 and thermal-6.19-rc1 tags on top of 6.18.  If the
>>> problem is in one of them, it should be possible to find it quicker
>>> than by dealing with the entire 6.19-rc1.
>> I tested all three tags atop of 6.18, and all can suspend just fine. I will thus wait for 6.19-rc1
>> before doing any further debugging.
> Sounds reasonable to me.

Well, after two failed bisects caused by the fact that the resulting kernel unexpectedly changed his name,
i will try again later. Sorry for taking so long, but i am quite inexperienced when it comes to performing
such a large bisect.

Thanks,
Armin Wolf

Powered by blists - more mailing lists