Bug 197925
| Summary: | [amdgpu_dc][carrizo] multiple monitor handling errors | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | kwkaess |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | beniwtv, harry.wentland, kbz-me, kwkaess, ylang-ylang |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.14+ (4.15 - git) | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | pertinent dmesg output | ||
From the initial description, 3) does not occur when external monitor is not attached. Also, the backlight can be adjusted manually. 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. 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. 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. 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. I just tested kernel built from Linus tree and everything works now, so probably it is already fixed. 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. 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. #3 is fixed in both my monitor configurations. #2 the behavior is still identical to Comment 5. 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). 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) Still not fixed v4.15-11781-g413879a10b0b 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? (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. 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. I'm a few days in on this kernel build, and none of these problems have cropped up. Resolved it is. |
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)