| Bug ID | 104300 |
|---|---|
| Summary | Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=3D1 has trou= ble waking up displays after suspend |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | toni.spets@iki.fi |
| CC | mariusz.g.mazur@gmail.com |
| CC | mariusz.g.mazur@gmail.com |
I'm reliably getting monitors waking up be treated as hotplugg= ed on ubuntu 18.04's 4.15 kernels and a build of 4.16.7. More info: ht= tps://bugs.launchpad.net/ubuntu/+source/linux/+bug/1770836
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 a= nd 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 corrupt= ion 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 ne= ver thinks the displays were hotplugged. Currently I have no logs from kernel from that time. Hope this description = is enough.
Toni, would you be able to post your dmesg log when this happe=
ns?
It looks like in Mariusz's case the DP monitor somehow reports as disconnec=
ted
when we resume. I wonder if there are issues in our DP enable sequence.
Created a=
ttachment 140414 [details]
dmesg of a boot with one suspend cycle
This dmesg contains a suspend immediately after the system was booted up. A=
fter
resuming both displays lit up and showed the last image before the system w=
as
suspended. The system was completely unresponsible for a while.
Once it was working I had the Xfce hotplug window open and I clicked the ex=
tend
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).
Created attachment 140=
415 [details]
xrandr output with DC off
Created attachment 1404=
16 [details]
xrandr output with DC on
I found it! Before I knew 4.14 worked fine and 4.15+ introduce= d 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.
Argh, the failures are inconsistent. Serves me right for jumpi= ng the gun=E2=80=A6
Ok, I've managed to narrow down my issue to displayport link t= raining 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).
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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.