| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <99b0d755-3e18-4bba-b8e7-ab344e6c2592@gmx.de>
Date: Tue, 9 Dec 2025 22:59:04 +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 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)
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?
Thanks,
Armin Wolf
>>> but i suspect that this has nothing to do with the patch series.
>> Right, cpuidle is entirely orthogonal to this.
>>
>>> So for the whole series:
>>> Reviewed-by: Armin Wolf <W_Armin@....de>
>> Thank you!
View attachment "acpidump.log" of type "text/x-log" (1420865 bytes)
Powered by blists - more mailing lists