Messages in this thread | | | Date | Wed, 7 Feb 2024 12:16:26 +0100 | From | Marek Szyprowski <> | Subject | Re: [PATCH v1] PM: sleep: Restore asynchronous device resume optimization |
| |
On 07.02.2024 11:38, Rafael J. Wysocki wrote: > On Wed, Feb 7, 2024 at 11:31 AM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> On 09.01.2024 17:59, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki<rafael.j.wysocki@intel.com> >>> >>> Before commit 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core >>> system-wide PM code"), the resume of devices that were allowed to resume >>> asynchronously was scheduled before starting the resume of the other >>> devices, so the former did not have to wait for the latter unless >>> functional dependencies were present. >>> >>> Commit 7839d0078e0d removed that optimization in order to address a >>> correctness issue, but it can be restored with the help of a new device >>> power management flag, so do that now. >>> >>> Signed-off-by: Rafael J. Wysocki<rafael.j.wysocki@intel.com> >>> --- >> This patch finally landed in linux-next some time ago as 3e999770ac1c >> ("PM: sleep: Restore asynchronous device resume optimization"). Recently >> I found that it causes a non-trivial interaction with commit >> 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement >> for unbound workqueues"). Since merge commit 954350a5f8db in linux-next >> system suspend/resume fails (board doesn't wake up) on my old Samsung >> Exynos4412-based Odroid-U3 board (ARM 32bit based), which was rock >> stable for last years. >> >> My further investigations confirmed that the mentioned commits are >> responsible for this issue. Each of them separately (3e999770ac1c and >> 5797b1c18919) doesn't trigger any problems. Reverting any of them on top >> of linux-next (with some additional commit due to code dependencies) >> also fixes/hides the problem. >> >> Let me know if You need more information or tests on the hardware. I'm >> open to help debugging this issue. > If you echo 0 to /sys/power/pm_async before suspending the system, > does it still fail?
In such case it works fine.
Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
| |