Bug 201519
Summary: | Using direct-complete with radeon breaks system-wide suspend - HP ProBook 4540s | ||
---|---|---|---|
Product: | Power Management | Reporter: | Ярослав Семченко (ukrkyi) |
Component: | Hibernation/Suspend | Assignee: | Rafael J. Wysocki (rjw) |
Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | kdavrn, rui.zhang |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=199693 | ||
Kernel Version: | v4.17 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
suspend log
direct_complete debug patch suspend log with direct_complete patch direct_complete debug without direct_complete propagation suspend log with second patch radeon: Set DPM_FLAG_NEVER_SKIP |
Description
Ярослав Семченко
2018-10-25 09:55:15 UTC
Whoops, patch is truncated in original message. Here it is: diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index a690fd400260..ad827119c280 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1944,7 +1944,7 @@ static int device_prepare(struct device *dev, pm_message_t state) unlock: device_unlock(dev); - if (ret < 0) { + if (ret < 0 || dev->power.no_pm_callbacks) { suspend_report_result(callback, ret); pm_runtime_put(dev); return ret; Please try to do (as root) # echo devices > /sys/power/pm_test # echo mem > /sys/power/state without reverting commit c62ec4610c40bcc44f and see if you get back to the command prompt after that (after several seconds). Yes, I am returned to command prompt after 5 seconds. I also tried to write another options into /sys/power/pm_test, all are working fine except 'none'. OK, so please do (as root): # echo 1 > /sys/power/pm_debug_messages # echo 1 > /sys/power/pm_print_times # echo devices > /sys/power/pm_test # echo mem > /sys/power/state # dmesg > suspend.log and attach suspend.log to this bug entry. Created attachment 281051 [details]
suspend log
Created attachment 281055 [details]
direct_complete debug patch
Thanks, but I still need more information.
Please apply this patch (on top of 5.0-rc5, for example), repeat the steps from the previous comment and attach the log.
Created attachment 281061 [details]
suspend log with direct_complete patch
Here it is (patch applied on top of 4.20.4 kernel version).
I've also checked suggestion that suspend isn't working with kernel versions before v4.15, but it is working fine with both v4.14.39 and v4.14.98, none of them include 08810a4119aa commit. (In reply to Ярослав Семченко from comment #8) > I've also checked suggestion that suspend isn't working with kernel versions > before v4.15, but it is working fine with both v4.14.39 and v4.14.98, none > of them include 08810a4119aa commit. In my asus zenbook ux331ual almost the same problem with resume. The difference is in type of sleep. S2Idle is set by default - and with it my laptop suspends and wakeups good. But if I manually set echo deep > /sys/power/mem_sleep and then push device to sleep (by lid or Fn+F1) it starts to slowly blink by led, but then if I try to wake it up - led on power button activates, then led on F2 (flight mode) blinks ones and then nothing happens, no reaction on anything except long press on power button. But, if AC power cable is plugged the "deep" sleep pass well as well resume. The cable must be plugged all stages. If I put laptop to deep sleep and unplug cable - then resume is never happens. I checked kernels 4.14.98 and the latests - always the same behaviour Created attachment 281101 [details]
direct_complete debug without direct_complete propagation
Thanks!
Please apply this patch (instead of the previous one), repeat the previous steps and attach the resultant log.
Also please check if full suspend/resume work with this patch applied.
(In reply to Ярослав Семченко from comment #8) > I've also checked suggestion that suspend isn't working with kernel versions > before v4.15, but it is working fine with both v4.14.39 and v4.14.98, none > of them include 08810a4119aa commit. Well, according to your report, setting direct_complete for devices without PM callbacks is the source of the problem. However, that used to be done in the mainline before commit 08810a4119aa (or in the stable kernels without it), so they also should fail in theory. Now, if they don't, this indicates that there's an additional change needed to trigger the failure that was made in the meantime. Created attachment 281115 [details]
suspend log with second patch
Here is the log, and with this patch full suspend/resume works correctly.
Created attachment 281131 [details]
radeon: Set DPM_FLAG_NEVER_SKIP
Please check if suspend works with this patch applied (and without the previous patches).
Yes, it works correctly with this patch. Good, thank you! Let me add a changelog to this patch and post it, then. Patch submitted: https://patchwork.kernel.org/patch/10813959/ |