Bug 104934 - Sometimes does not detect 60Hz Full HD mode for external display, switching to 60 Hz with interlace
Summary: Sometimes does not detect 60Hz Full HD mode for external display, switching t...
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-04 11:15 UTC by Martin Steigerwald
Modified: 2018-05-11 12:37 UTC (History)
2 users (show)

See Also:
i915 platform: SNB
i915 features: display/DP

Attachments
Xorg log with what I believe is todays output (39.51 KB, text/x-log)
2018-02-04 11:15 UTC, Martin Steigerwald 		no flags Details
kern.log with Intel driver not using fullhd 60hz mode on external display (379.21 KB, text/plain)
2018-04-07 11:01 UTC, Martin Steigerwald 		no flags Details
kern.log with Intel driver using fullhd 60hz mode after plugging dp cable to other port (539.50 KB, text/plain)
2018-04-07 11:02 UTC, Martin Steigerwald 		no flags Details
View All

Description Martin Steigerwald 2018-02-04 11:15:05 UTC 
Created attachment 137163 [details]
Xorg log with what I believe is todays output

On Linux 4.15.0-tp520-btrfstrim+ (4.15 + a small patch to fix BTRFS SSD trimming, compiled with gcc 7.3.0 for full generic retpoline) on a ThinkPad T520 with Intel Sandybridge graphics sometimes on rebooting or also after a resume from hibernate to disk or suspend to RAM the external 24 inch Fujitsu P24T-7 LED display connected via ThinkPad Minidock display port shows the screen with visible flickering.

In this case xrandr shows:

DP-3 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 531mm x 299mm
   1920x1080i    60.00*   50.00    59.94  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  

When disconnecting the DisplayPort cable and reconnecting it or with disconnecting the laptop from the dock and putting it back on it, Intel DRM/KMS eventually recognizes again that the display and cable are capable of doing 1920x1080 with 60 Hz. After switching the resolution via Plasma´s Systemsettings or directly via xrandr this looks like:

DP-3 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 531mm x 299mm
   1920x1080     60.00 +  50.00    50.00    59.94  
   1920x1080i    60.00*   50.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08 


I am testing meanwhile with the third DisplayPort cable, which should be able to even transfer UltraHD 4K resolutions.

Some kernel and X.org releases back this issue never happened. I did not report it immediately as its again a "it happens sometimes" issue with no clear pattern to reproduce it.

In the failure case I usually see nothing in dmesg. Today I saw:

[191597.165942] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder B
[191597.165952] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun

I don´t know whether this is related.

I attach a trimmed Xorg.0.log with what I believe is todays output.



Some hardware information:

% inxi -v1 
System:    Host: merkaba Kernel: 4.15.0-tp520-btrfstrim+ x86_64 bits: 64 Console: tty 6
           Distro: Debian GNU/Linux buster/sid
CPU:       Dual core Intel Core i5-2520M (-MT-MCP-) speed/max: 845/3200 MHz
Graphics:  Card: Intel 2nd Generation Core Integrated Graphics Controller
           Display Server: X.Org 1.19.6 driver: modesetting Resolution: 1920x1080@60.00hz, 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile version: 3.3 Mesa 17.3.3
Drives:    HDD Total Size: 780.2GB (58.8% used)
Info:      Processes: 348 Uptime: 5 days Memory: 4809.4/15825.4MB Client: Shell (zsh) inxi: 2.3.56

% phoronix-test-suite system-info
[…]
  GRAPHICS:           Intel Sandybridge Mobile 1536MB (1300MHz)
    OpenGL:           3.3 Mesa 17.3.3
    Display Driver:   modesetting 1.19.6
    Monitor:          P24T-7 LED
    Screen:           3840x1080
[…]
Comment 1 Martin Steigerwald 2018-02-04 11:17:09 UTC 
Hmmm, X.org is using modesetting driver, so I likely put it into the wrong category. Sorry. I see no modesetting component for DRI, so… not sure where to assign it. Please reassign.
Comment 2 Jani Saarinen 2018-03-29 07:11:06 UTC 
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 3 Martin Steigerwald 2018-03-29 07:44:49 UTC 
(In reply to Jani Saarinen from comment #2)
> First of all. Sorry about spam.
> This is mass update for our bugs. 
> 
> Sorry if you feel this annoying but with this trying to understand if bug
> still valid or not.

As of 4.16-rc6 this bug is still valid.

I found a work-around. When I move the DisplayPort cable from DP2 to DP3 or wise versa *while* the session is running, the 60 Hz resolution is always detected and I can activate it again.

What can also happen that one Plasma session gets is right and when I open up another Plasma session via SDDM in the other one only the interlaced mode is detected. So the one session has the 60 Hz resolution, while the other just has the interlaced one, yet still with the same cable and at the same time (minus delay for switching between sessions via Ctrl-Alt-F7/8).

I tried with four cables already. However, I have a cable where this appeared more rarely (no scientific measurement, just personal impression). Curiously it was the longest one with 5 meters. So I ordered another cable like this, but just 2 meters and will test it as well. Since for a long time with previous kernels I did not see this issue and since the issue always goes away when moving the Displayport cable between DP2 and DP3, I still think that it is not or at least not solely a cabling issue.
Comment 4 Jani Nikula 2018-03-29 08:50:18 UTC 
Please add drm.debug=14 module parameter, and attach dmesg from boot to reproducing the problem. Thanks.
Comment 5 Martin Steigerwald 2018-04-07 10:57:04 UTC 
(In reply to Jani Nikula from comment #4)
> Please add drm.debug=14 module parameter, and attach dmesg from boot to
> reproducing the problem. Thanks.

I booted with that module parameter and it appears that the driver detects the mode but thinks its clock would be too high:

Apr  7 12:38:52 merkaba kernel: [    6.825185] [drm:drm_mode_debug_printmodeline [drm]] Modeline 74:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
Apr  7 12:38:52 merkaba kernel: [    6.825189] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH
Apr  7 12:38:52 merkaba kernel: [    6.825194] [drm:drm_mode_debug_printmodeline [drm]] Modeline 107:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
Apr  7 12:38:52 merkaba kernel: [    6.825198] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH
Apr  7 12:38:52 merkaba kernel: [    6.825203] [drm:drm_mode_debug_printmodeline [drm]] Modeline 76:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1089 1095 1125 0x40 0xa
Apr  7 12:38:52 merkaba kernel: [    6.825207] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH
Apr  7 12:38:52 merkaba kernel: [    6.825211] [drm:drm_mode_debug_printmodeline [drm]] Modeline 93:"1920x1080" 0 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
Apr  7 12:38:52 merkaba kernel: [    6.825215] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH
Apr  7 12:38:52 merkaba kernel: [    6.825219] [drm:drm_mode_debug_printmodeline [drm]] Modeline 80:"1680x1050" 0 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6
Apr  7 12:38:52 merkaba kernel: [    6.825223] [drm:drm_mode_prune_invalid [drm]] Not using 1680x1050 mode: CLOCK_HIGH

However when I do the plug the displayport cable to the other port trick it again accepted the 70 Hz mode:

Apr  7 12:42:15 merkaba kernel: [  210.505175] [drm:drm_mode_debug_printmodeline [drm]] Modeline 79:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
Apr  7 12:42:15 merkaba kernel: [  210.505183] [drm:drm_mode_debug_printmodeline [drm]] Modeline 115:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
Apr  7 12:42:15 merkaba kernel: [  210.505190] [drm:drm_mode_debug_printmodeline [drm]] Modeline 102:"1920x1080i" 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
Apr  7 12:42:15 merkaba kernel: [  210.505197] [drm:drm_mode_debug_printmodeline [drm]] Modeline 120:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
Apr  7 12:42:15 merkaba kernel: [  210.505204] [drm:drm_mode_debug_printmodeline [drm]] Modeline 82:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1089 1095 1125 0x40 0xa
Apr  7 12:42:15 merkaba kernel: [  210.505212] [drm:drm_mode_debug_printmodeline [drm]] Modeline 101:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
Apr  7 12:42:15 merkaba kernel: [  210.505219] [drm:drm_mode_debug_printmodeline [drm]] Modeline 103:"1920x1080i" 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15

I will attach two kern.log files, one with a boot into the broken state, another one which in addition has the log messages for replugging the displayport cable to the other port.

Please note that it does not matter whether the system boots with display connected DP-2 or DP-3. It shows the issue with both ports. But when I replug the cable from DP-2 to DP-3 or DP-3 to DP-2 depending on where it was connected during boot it always accepts the Full HD 60 Hz modes. And these work very stable.

Also note: After a suspend to ram or a hibernation cycle the 60 Hz mode still works. It appears to me that the directly after boot mode detection is broken.

Is there a way to override the maximum usable CLOCK as a work-around? I know it works. :)
Comment 6 Martin Steigerwald 2018-04-07 11:01:13 UTC 
Created attachment 138674 [details]
kern.log with Intel driver not using fullhd 60hz mode on external display
Comment 7 Martin Steigerwald 2018-04-07 11:02:43 UTC 
Created attachment 138675 [details]
kern.log with Intel driver using fullhd 60hz mode after plugging dp cable to other port
Comment 8 Martin Steigerwald 2018-04-07 11:08:32 UTC 
The tests I did with drm debugging switch on have been with final 4.16 kernel as released by Linus.
Comment 9 Jani Saarinen 2018-04-25 11:15:31 UTC 
Ville, any advices from you?
Comment 10 Ville Syrjala 2018-04-25 14:24:13 UTC 
[    6.553805] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:69:DP-2] Link Training failed at link rate = 162000, lane count = 4
[    6.816030] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:69:DP-2] Link Training failed at link rate = 270000, lane count = 2
etc.

So the link appears to be somewhat marginal, sometimes it succeeds in training sometimes not. When it fails we drop it down to 2 x 1.62 Gbps, which means there isn't quite enough bandwidth for 1080p60.

Unfortunately I don't have a good theory as to why it would be flaky after boot but then somehow keep working if the cable is swapped to the other port.
Comment 11 Martin Steigerwald 2018-04-25 16:13:34 UTC 
(Removing NEEDINFO, as I think I provided the requested information.)

As I described in my initial mail, on some, rare boot attempts sddm and then usually Plasma shows the non interlaced 1920 x 1080 mode. So sometimes it is not necessary to replug the display port cable to the other port. But so far in case it showed the interlaced mode replugging the display port cable to the other port worked in 100% of the cases (but means I had to duplicate some Plasma desktop configuration to work in either case).

The issue still happens with 4.16.3.
Comment 12 Martin Steigerwald 2018-05-11 08:59:17 UTC 
I did not see this with 4.17-rc4, so probably this issue has been fixed.

I am setting as WORKSFORME, since I can not confirm that there has been a fix in the code.
Comment 13 Jani Saarinen 2018-05-11 12:37:29 UTC 
Good enough, thanks!

Closing, please reopen if re-occurs.

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.