Bug 104300

Summary: Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend
Product: DRI Reporter: Toni Spets <toni.spets>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: FD, harry.wentland, mariusz.g.mazur
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg of a boot with one suspend cycle
none
xrandr output with DC off
none
xrandr output with DC on none

Description Toni Spets 2017-12-17 04:23:14 UTC 
When resuming from suspend on 4.15-rc2 the DC stack *usually* wakes up displays after some waiting on this Polaris card compared to non-DC code which flips them on instantly.

I've encountered the following issues with my dual head setup (native DVI and HDMI->DVI adapter):

 - it takes long (2-5 seconds) for the outputs to come up
 - Xfce thinks both of the display were hotplugged causing all kinds of desktop/windowing related issues
 - sometimes corrupted image on both outputs and the outputs are reset after waiting for 20 seconds or so, sometimes they come up, sometimes the corruption stays, the system is unresponsive to input while that's going on

I have zero issues without DC. Waking up works 100% of the time and Xfce never thinks the displays were hotplugged.

Currently I have no logs from kernel from that time. Hope this description is enough.
Comment 1 Mariusz Mazur 2018-05-12 14:56:22 UTC 
I'm reliably getting monitors waking up be treated as hotplugged on ubuntu 18.04's 4.15 kernels and a build of 4.16.7. More info: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1770836
Comment 2 Harry Wentland 2018-06-28 22:49:07 UTC 
Toni, would you be able to post your dmesg log when this happens?

It looks like in Mariusz's case the DP monitor somehow reports as disconnected when we resume. I wonder if there are issues in our DP enable sequence.
Comment 3 Toni Spets 2018-07-01 11:28:16 UTC 
Created attachment 140414 [details]
dmesg of a boot with one suspend cycle

This dmesg contains a suspend immediately after the system was booted up. After resuming both displays lit up and showed the last image before the system was suspended. The system was completely unresponsible for a while.

Once it was working I had the Xfce hotplug window open and I clicked the extend button which again got the system stuck for the same amount of time. The displays were already correctly arranged so it was unneeded but it also triggered the issue.

As a bonus xrandr shows three outputs connected when I have only two. I'll attach output of both (DC and non-DC).
Comment 4 Toni Spets 2018-07-01 11:30:16 UTC 
Created attachment 140415 [details]
xrandr output with DC off
Comment 5 Toni Spets 2018-07-01 11:30:52 UTC 
Created attachment 140416 [details]
xrandr output with DC on
Comment 6 Mariusz Mazur 2018-07-27 17:30:16 UTC 
I found it! Before I knew 4.14 worked fine and 4.15+ introduced this bug.

Now I know precisely which patches:
- 4.14.35 works correctly
- 4.14.36 exhibits this behavior

There are only a few amdgpu patches in there, one by Bas Nieuwenhuizen @chromium and a few by Alex Deucher @amd. Now I need to figure out how to set up a kernel-building env and test which patch in particular is the one that breaks everything.
Comment 7 Mariusz Mazur 2018-07-27 21:25:37 UTC 
Argh, the failures are inconsistent. Serves me right for jumping the gun…
Comment 8 Mariusz Mazur 2018-08-09 20:05:14 UTC 
Ok, I've managed to narrow down my issue to displayport link training code somehow triggering a monitor disconnect while attempting to wake it up. So my issue is completely unrelated, none of my comments here apply, please ignore (no way to delete them unfortunately).
Comment 9 Martin Peres 2019-11-19 08:27:46 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/278.

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.