Bug 197925 - [amdgpu_dc][carrizo] multiple monitor handling errors
Summary: [amdgpu_dc][carrizo] multiple monitor handling errors
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-19 18:30 UTC by kwkaess
Modified: 2018-03-12 19:28 UTC (History)
5 users (show)

See Also:
Kernel Version: 4.14+ (4.15 - git)
Subsystem:
Regression: No
Bisected commit-id:


Attachments
pertinent dmesg output (8.58 KB, text/plain)
2017-11-19 18:30 UTC, kwkaess
Details

Description kwkaess 2017-11-19 18:30:13 UTC
Created attachment 260721 [details]
pertinent dmesg output

Not necessarily a bug, since I am running experimental features, but figured I would get the ball rolling.

Running current kernel (commit 1deab8ce2c91e3b16563b7a7ea150f82334262ec) compiled with the following configuration flags:

CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_PRE_VEGA=y
CONFIG_DRM_AMD_DC_FBC=y
CONFIG_HSA_AMD=m

On the following hardware: Toshiba L55D-C with AMD A10-8700P

With: Fedora 27 Workstation on top

This generates a dmesg error on boot:

[    5.350313] [drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!

It also has multiple non-desirable behaviors (which may be gnome- or Fedora-related...)

1) Fails to turn off backlight upon internal monitor shut-off.
2) Fails to turn on external monitor upon resume from idle. This can be remedied by forcing the monitor back on via twiddling of other settings.
3) Fails to turn on either external or internal monitor upon resume from sleep - this one isn't easily remedied, due to no visual feedback.

I am attaching pertinent dmesg lines (dmesg | grep -e amdgpu -e drm -e kfd) > dmesg.txt)
Comment 1 kwkaess 2017-11-21 20:09:52 UTC
From the initial description, 3) does not occur when external monitor is not attached.

Also, the backlight can be adjusted manually.
Comment 2 beniwtv 2017-11-28 09:31:17 UTC
I have similar problems as 2) and 3) on Polaris hardware (AMD RX 480 8GB reference card) since switching to the 4.15 DC implementation (either self-compiled or Kernel provided by Manjaro).

Every time display settings are changed from the default I'm currently running, or if the monitors go to idle (blank), one or more monitors will report "No signal". For me however, no amount of changing settings will get them back (though they will light up shortly after changing a setting).

Previous Kernels + DC patches did not exhibit this issue.
Comment 3 kwkaess 2017-12-01 18:50:36 UTC
running very recent kernel, 4.15.0-rc1-00396-ga0651c7fa2c0 (as automatically labelled), with recent AMD_DC fixes.


Fixes 1 - backlight now shuts off.

Makes 3 worse - It put my internal monitor in a state (blank, backlight cycling on and off) that required a hard power cycle to correct (soft reboots left it in this state I don't know why).  I recommend that you DO NOT put your laptop to sleep with this kernel.


I will report on 2 when I have my external attached.
Comment 4 Miłosz Rachwał 2017-12-01 23:26:47 UTC
I have similar issue on Polaris (RX 580) with DC enabled. After reenabling monitors from powersave one display is cycling on/off every few seconds, each time printing dc_link_detect to dmesg.
On kernels compiled from amd-staging-drm-next tree this issue also occured after wakeup from sleep, but now on 4.15-rc1 whole system crashes after wakeup.
Comment 5 kwkaess 2017-12-02 02:37:30 UTC
Half fixes #2:

On first idle and resume from idle after boot, everything works. Internal monitor backlight shuts off, both screens turn back on. The second time, the internal backlight stays on upon entering idle, and neither monitor turns back on at resume from idle.
Comment 6 Miłosz Rachwał 2017-12-02 10:45:39 UTC
I just tested kernel built from Linus tree and everything works now, so probably it is already fixed.
Comment 7 kwkaess 2017-12-03 23:00:42 UTC
I have confirmed that the bug (with modified behavior as described above) is still present on my hardware (Carrizo, specifically Toshiba L55D-C with AMD A10-8700P), as of 4.15.0-rc2.
Comment 8 kwkaess 2017-12-15 22:41:57 UTC
As of 4.15.0-rc3-00086-g032b4cc8ff84:

#3 is fixed when in single internal monitor configuration. (Yes!)

I will, again, recheck #2 and #3 when I have an external monitor attached.
Comment 9 kwkaess 2017-12-16 02:15:57 UTC
#3 is fixed in both my monitor configurations.

#2 the behavior is still identical to Comment 5.
Comment 10 Charles 2017-12-18 10:18:35 UTC
Hi team,

same error in journalctl when booting archlinux with 4.15-rc3 on a HP Probook 455 G3 with Carrizo A10-8700p rev c5:

[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!

this is not related to X (no X launched).

After a suspend resume in xfce, the sceen is a its max brightness and needs to be adjusted manualy.

(With previous kernels (4.12 4.13 4.14), the screen turned blank during a cold boot (and did not return to a correct state after).
Comment 11 Charles 2017-12-20 09:34:01 UTC
Hi team,

Just to say... same error :

[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!

with 4.15-rc4

(on the same noteboook)
Comment 12 kwkaess 2018-02-07 20:14:58 UTC
Still not fixed v4.15-11781-g413879a10b0b
Comment 13 Harry Wentland 2018-02-27 00:48:49 UTC
kwkaess, are you talking about the error message when saying "still not fixed" or the (arguably more disruptive and important) non-desirable behaviors mentioned in comment 1?
Comment 14 kwkaess 2018-03-10 21:50:48 UTC
(In reply to Harry Wentland from comment #13)
> kwkaess, are you talking about the error message when saying "still not
> fixed" or the (arguably more disruptive and important) non-desirable
> behaviors mentioned in comment 1?

Hey, sorry I didn't get back to this.

I meant the other non-desireable behaviors. Some of them were fixed temporarily, but experienced regressions.

However, I just pulled, built, and am testing the latest 4.16 fixes (ones pulled mainstream - I'm on torvalds/linux.git commit 3266b5bd97eaa72793df0b6e5a106c69ccc166c4). The three problems I already listed (excluding the message, but I don't really care about the message) ~seem~ to be fixed.

There is a new problem. On return from blank screens, the color is all screwy until I log in (when gnome blanks the screen to enter the user session from the gdm login screen).  I consider this minor, since I always have to login anyway, and the color isn't screwy enough to prevent me from doing this.


I will continue to test and report back.
Comment 15 Harry Wentland 2018-03-12 13:32:40 UTC
Thanks for the update.

If all original issues are closed can we mark this resolved? We can open new tickets for new issues. Ideally we have one ticket per problem as some of them are often unrelated and tracking them all on one ticket can get confusing.

Don't rush to close this, though, if you prefer to do more testing.
Comment 16 kwkaess 2018-03-12 19:28:30 UTC
I'm a few days in on this kernel build, and none of these problems have cropped up.

Resolved it is.

Note You need to log in before you can comment on or make changes to this bug.