Bug 101865

(In reply to nutrinfnon from comment #0)
> Resume from hibernation fails with linux kernel 4.13.0-rc1
>
Hello, 
Is this a regression? Could you please attach dmesg with drm.debug=0xe parameter on grub?
Thanks.

Created attachment 132825 [details]
dmesg output

I think it is a regression, I always used hibernation with 4.11.0. Since 4.12.x starts this resume problem.

I done test with drm.debug=0xe:
 first time, I executed "systemctl hibernate" and at kernel time [53.314063] resume fails, system is working but screen is off;
 second time, I executed "systemctl hibernate" and at kernel time [431.539799] resume fails too. This time, system is always working but screen is on with dirty image, no ctrl-alt-f1 possible;

in attach dmesg.





Thanks

P.S. I changed hardware for do better test.

Created attachment 133602 [details]
dmesg log with drm.debug

I also experience this issue on my Thinkpad x230.
Screen stays black(off) after resume if it was off during start of hibernation.

To reproduce:
xset dpms force off; sleep 2; systemctl hibernate

I have attached dmesg log with drm.debug=0xe

To make screen work without reboot: 1. Suspend to ram 2. Resume 3. Restart X server.

(In reply to nutrinfnon from comment #2)
> Created attachment 132825 [details]
> dmesg output
From dmesg:
[    7.073381] [drm:intel_device_info_dump [i915]] i915 device info: platform=HASWELL gen=7 pciid=0x0402 rev=0x06
Changing platform.

Created attachment 133626 [details]
dmesg output of 4.11.9-1 with hibernation working

Created attachment 133627 [details]
dmesg output of 4.12.0-1 with black screen after resume

I can confirm that it is a regression.
4.11.9-1-ARCH - hibernation works fine
4.12.0-1-ARCH - screen is off after resume

I've attached both dmesg outputs.

Created attachment 133644 [details]
dmesg output

For me, I isolated the cause of the problem:

Hibernation and following resuming fails when XOrg is in "dpms off".
At console or XOrg without "xscreensaver Power Management" active, resume works fine.

I tested 4.13.0-rc6:
 I executed "xset dpms force off";
 then I executed "systemctl hibernate" from network.

at resuming, the screen remains off, view dmseg output in attach.

xrandr does not solve the situation:

xrandr --output VGA-1 --off 
xrandr: Configure crtc 0 failed

xrandr --output VGA-1 --mode 1024x768 
xrandr: Configure crtc 0 failed

Thanks

Hello, latest tip has some relevant S3/S4 patches merged, could you re-test with it? Thank you. https://cgit.freedesktop.org/drm-tip

Created attachment 135095 [details]
test 4.14.0-rc6

Hello,

among the latest S3/S4 patches are:

2017-10-04	drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2809,6 +2809,9 @@ static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool resume
 
 	/* 6. Enable DBUF */
 	gen9_dbuf_enable(dev_priv);
+
+	if (resume && dev_priv->csr.dmc_payload)
+		intel_csr_load_program(dev_priv);
 }
2017-10-04	drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7933d1b..3791c3f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2809,6 +2809,9 @@ static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool resume
 
 	/* 6. Enable DBUF */
 	gen9_dbuf_enable(dev_priv);
+
+	if (resume && dev_priv->csr.dmc_payload)
+		intel_csr_load_program(dev_priv);
 }


These patches are already merged in linux-4.14.0-rc6, so I tried it.

My test with 4.14.0-rc6 still shows the presence of the problem, blank screen after resume.

In attach dmesg output.

Thanks.

(In reply to nutrinfnon from comment #12)
> Created attachment 135095 [details]
> test 4.14.0-rc6
>...
> My test with 4.14.0-rc6 still shows the presence of the problem, blank
> screen after resume.
> 
> In attach dmesg output.
> 
> Thanks.
Attachment is empty, could you please re-attach dmesg?? Thank you.

Created attachment 135136 [details]
dmesg output

(In reply to nutrinfnon from comment #12)
> Created attachment 135095 [details]
> test 4.14.0-rc6
> 
> Hello,
> 
> among the latest S3/S4 patches are:
> 
> 2017-10-04	drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2809,6 +2809,9 @@ static void cnl_display_core_init(struct
> drm_i915_private *dev_priv, bool resume
>  
>  	/* 6. Enable DBUF */
>  	gen9_dbuf_enable(dev_priv);
> +
> +	if (resume && dev_priv->csr.dmc_payload)
> +		intel_csr_load_program(dev_priv);
>  }
> 2017-10-04	drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 7933d1b..3791c3f 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2809,6 +2809,9 @@ static void cnl_display_core_init(struct
> drm_i915_private *dev_priv, bool resume
>  
>  	/* 6. Enable DBUF */
>  	gen9_dbuf_enable(dev_priv);
> +
> +	if (resume && dev_priv->csr.dmc_payload)
> +		intel_csr_load_program(dev_priv);
>  }
> 
> 
> These patches are already merged in linux-4.14.0-rc6, so I tried it.
> 
> My test with 4.14.0-rc6 still shows the presence of the problem, blank
> screen after resume.

No surprise there, given that the the above changes are only relevant for Cannonlake.

I suspect this might be fixed by the following two commits:

commit b6b178a77210055b153dbc175e4468bd3c7122df
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Oct 19 17:13:41 2017 +0200

    drm/i915: Calculate ironlake intermediate watermarks correctly, v2.

commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Thu Oct 19 17:13:40 2017 +0200

    drm/i915: Do not rely on wm preservation for ILK watermarks

I tried to use mentioned patches, but the first one refers to missing function intel_atomic_get_old_crtc_state.

Search does not help.

I don't know usage of drm-tip, so I think to wait next week for next release.

Thanks.

Could you try to do bisecting? That could help.

I'm trying (no much time for):

bisect start (good=v4.11, bad=v4.12)

test of v4.11-7904-g2bd804017435 is good (roughly 13 steps);
test of v4.11-11905-g85d604902eb2 is bad
test of v4.11-10417-gc6a677c6f37b is bad
test of v4.11-11129-gbf5f89463f5b is bad
test of v4.11-9227-ge87d51ac61f8 is bad
test of v4.11-8548-ge579dde654fc is bad
test of v4.11-rc5-271-gc034a43e72dd is good (roughly 8 steps)

I will continue as I have time.

Hi,

the tests show that the problem has been introduced with commit 2f34c1231bfc9f2550f934acb268ac7315fb3837 (v4.11-6543-g2f34c1231bfc).

commit a3719f34fdb664ffcfaec2160ef20fca7becf2ee (v4.11-4715-ga3719f34fdb6) is good.

Thanks

Linux 4.15.0-rc1 has fixed this problem!

Thanks.