Bug 107679 - i915 display link training after suspend/resume
Summary: i915 display link training after suspend/resume
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Manasi
QA Contact: Intel GFX Bugs mailing list
Whiteboard: ReadyForDev, Triaged
Depends on:
Reported: 2018-08-24 18:37 UTC by freedesktop
Modified: 2019-05-10 18:01 UTC (History)
2 users (show)

See Also:
i915 platform: CFL
i915 features: display/Other

kernel messages while system is trying to turn on the two attached displays (29.76 KB, text/plain)
2018-08-24 18:37 UTC, freedesktop
no flags Details
dmesg from drm-tip (f1c0fce7feaa69409ec8a379fc78ef792f168d28) (917.72 KB, text/x-log)
2018-08-28 17:45 UTC, freedesktop
no flags Details

Description freedesktop 2018-08-24 18:37:11 UTC
Created attachment 141272 [details]
kernel messages while system is trying to turn on the two attached displays

System: Dell XPS 9570 (Coffee Lake i7-8750H)
Kernel: 4.18.1-1.vanilla.knurd.1.fc28.x86_64
Kernel params: i915.enable_fbc=1 i915.enable_psr=1 i915.enable_guc=3

GuC/HuC versions:
kernel: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
kernel: [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
kernel: [drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)

1. Boot system. 
2. Connect to Dell WD-15 dock (Synaptics VMM3332 chip inside).
3. Observe X11 session correctly modesetting two Dell displays connected to the dock to 1920x1200. Laptop display gets disabled, per configuration.
4. Suspend system.
5. Resume system.

Expected behavior:
Both external displays wake up and modeset correctly.

Actual behavior:
Neither display wakes up, laptop display is still on, system is unresponsive except for mouse movement.

Attached is the relevant kernel log from just after the resume.

I have also confirmed this bug on vanilla 4.19-rc0.

Please let me know if there's anything further I can provide, I can consistently reproduce this issue.
Comment 1 James Ausmus 2018-08-24 20:20:05 UTC
Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 2 freedesktop 2018-08-28 17:45:09 UTC
Created attachment 141311 [details]
dmesg from drm-tip (f1c0fce7feaa69409ec8a379fc78ef792f168d28)

drm-tip (f1c0fce7feaa69409ec8a379fc78ef792f168d28) actually does a lot worse.

I observe the following:
1) Log into the user session
2) Plug in the dock with the two displays
3) Flash to black on laptop screen
4) AFAICT one of the two displays wakes up but only shows a mouse pointer on a black display
5) Moving the mouse pointer even a little bit renders it unresponsive (it freezes)
6) Unplugging the dock cable doesn't recover the system

For reasons I don't understand, journalctl was unable to show me these boots (which I had to force-power-off from), so the dmesg is from the following:
1) Log in to the user session
2) Switch to a tty
3) Start dmesg -w | tee 
4) Switch back to user session
5) Plug in dock
6) Wait a bit
7) SysRq emergency sync
8) Force power off

Hope this helps, happy to try out other things too :)
Comment 3 freedesktop 2018-09-06 18:13:45 UTC
Any updates on this?
Comment 4 freedesktop 2018-09-07 17:51:39 UTC
The regression I observed earlier on drm-tip made it into 4.19-rc2. Modesetting completely fails with the two displays now and no image is actually drawn on either screen apart for the cursor. The system also appears to halt with no input being processed (even switches to ttys).

To clarify:
4.19-rc2 is a regression over 4.18 in that modesetting completely fails with dual displays (see logs from drm-tip).
4.18 is broken in that modesetting fails after a suspend/resume but is fine before that.
Comment 5 Manasi 2019-01-09 20:07:41 UTC
Could you double check if this issue exists on 5.0?

Comment 6 Lakshmi 2019-02-27 13:47:49 UTC
Reporter, can you please verify the issue with latest drmtip? 
Comment 7 James Ausmus 2019-05-10 18:01:48 UTC
More than 2 months with no feedback from reporter, closing

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.