Bug 107082

Summary: With 4.18 rc kernel stop working video output on AMD GPU Vega 56
Product: DRI Reporter: mikhail.v.gavrilov
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: harry.wentland
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
[PATCH] drm/amd/display: Convert 10kHz clks from PPLib into kHz for Vega none

Description mikhail.v.gavrilov 2018-07-01 12:55:00 UTC 
- when monitor plugged via display port after boot I see blank screen, but system react on Ctrl-Alt-Delete and I could connect via ssh and reboot system by init 6 command.
- when monitor plugged via HDMI was system hang during boot.

More detail provided in downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1592110

Also I bisecting kernel for investigating problem:

$ git bisect log
# bad: [4c5e8fc62d6a63065eeae80808c498d1dcfea4f4] Merge tag 'linux-kselftest-4.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
# good: [2837461dbe6f4a9acc0d86f88825888109211c99] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect start '4c5e8fc62d6a63065eeae80808c498d1dcfea4f4' '2837461dbe6f4a9acc0d86f88825888109211c99'
# good: [b5d903c2d656e9bc54bc76554a477d796a63120d] Merge branch 'akpm' (patches from Andrew)
git bisect good b5d903c2d656e9bc54bc76554a477d796a63120d
# bad: [a0b2ac29415bb44d1c212184c1385a1abe68db5c] drm/amdgpu: fix the missed vcn fw version report
git bisect bad a0b2ac29415bb44d1c212184c1385a1abe68db5c
# bad: [0b19fdc45feffd7569c081fe32a258df3c8ebb9b] drm/amd/display: fix dscl_manual_ratio_init
git bisect bad 0b19fdc45feffd7569c081fe32a258df3c8ebb9b
# bad: [4c6530fd66399182d0332c5ed821ea473bdcd7c3] drm/amdgpu: remove unnecessary scheduler entity for VCN
git bisect bad 4c6530fd66399182d0332c5ed821ea473bdcd7c3
# bad: [10dd2b865393bb45526ca342fe69207341f89fd5] drm/amd/display: Fix wrong latency assignment for VEGA clock levels
git bisect bad 10dd2b865393bb45526ca342fe69207341f89fd5
# bad: [adea72c5046f7faffff969ece04c3f31e669edf4] drm/amdgpu: vcn_v1_0_is_idle() can be static
git bisect bad adea72c5046f7faffff969ece04c3f31e669edf4
# bad: [bfdec234047889f4f6af1ec45c7c502a4405b3fb] drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency
git bisect bad bfdec234047889f4f6af1ec45c7c502a4405b3fb
# first bad commit: [bfdec234047889f4f6af1ec45c7c502a4405b3fb] drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency
Comment 1 Nicholas Kazlauskas 2018-07-11 19:27:39 UTC 
This should be fixed with: https://patchwork.freedesktop.org/patch/233283/
The fix is also availble if you use amd-staging-drm-next.
Comment 2 Michel Dänzer 2018-07-12 07:58:46 UTC 
(In reply to Nicholas Kazlauskas from comment #1)
> This should be fixed with: https://patchwork.freedesktop.org/patch/233283/
> The fix is also availble if you use amd-staging-drm-next.

Since the regression happened in the 4.18 cycle, the fix needs to go to 4.18.
Comment 3 Harry Wentland 2018-07-12 13:58:05 UTC 
Created attachment 140594 [details] [review]
[PATCH] drm/amd/display: Convert 10kHz clks from PPLib into kHz for Vega

Don't think the other patch would apply to 4.18 but this one should. There's been a bunch of work on the powerplay/DC interface, so this looks different for 4.18 and amd-stg.
Comment 4 mikhail.v.gavrilov 2018-07-13 03:52:27 UTC 
(In reply to Harry Wentland from comment #3)
> Created attachment 140594 [details] [review] [review]
> [PATCH] drm/amd/display: Convert 10kHz clks from PPLib into kHz for Vega
> 
> Don't think the other patch would apply to 4.18 but this one should. There's
> been a bunch of work on the powerplay/DC interface, so this looks different
> for 4.18 and amd-stg.

I can confirm that this patch fix the issue.

But I did not like one thing:
I decided to check how work VEGA GPU through HDMI and connected the second monitor via HDMI.

The first that I did not like was that on the first monitor which was connected via DisplayPort, the scaling setting was reset from 200% to 100%.

The second that I did not like was that when I tried to set the scaling at 200% through gnome-settings, my computer was hung. I even could not connect through ssh to look at the kernel log.

I tried to repeat this case but unsuccessfully, but unpleasant residue still remained.
Comment 5 Michel Dänzer 2018-07-13 07:50:41 UTC 
(In reply to mikhail.v.gavrilov from comment #4)
> The first that I did not like was that on the first monitor which was
> connected via DisplayPort, the scaling setting was reset from 200% to 100%.

Sounds like a GNOME issue. The kernel driver doesn't do any implicit scaling, it's all up to userspace.
Comment 6 mikhail.v.gavrilov 2018-07-13 09:23:09 UTC 
(In reply to Michel Dänzer from comment #5)
> 
> Sounds like a GNOME issue. The kernel driver doesn't do any implicit
> scaling, it's all up to userspace.

I don't believe that sshd can hang because of gnome-shell bug.
Comment 7 Michel Dänzer 2018-07-13 09:25:19 UTC 
(In reply to mikhail.v.gavrilov from comment #6)
> I don't believe that sshd can hang because of gnome-shell bug.

Sure, I'm only talking about the scaling reset.
Comment 8 Martin Peres 2019-11-19 08:42:50 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/439.

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.