Bug 90043 - [BDW DP] 4k@60Hz pipe underruns -> corruption & hangs
Summary: [BDW DP] 4k@60Hz pipe underruns -> corruption & hangs
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) All
: highest normal
Assignee: Marat Bakeev
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-15 21:58 UTC by Marat Bakeev
Modified: 2017-07-24 22:47 UTC (History)
2 users (show)

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


Attachments
xrandr --verbose (13.18 KB, text/plain)
2015-04-15 21:58 UTC, Marat Bakeev
no flags Details
dmesg output after xrandr --output DP1 --off (19.25 KB, text/plain)
2015-04-15 21:59 UTC, Marat Bakeev
no flags Details
xrandr --output DP1 --mode 3840x2160 --rate 60 (13.79 KB, text/plain)
2015-04-15 22:30 UTC, Marat Bakeev
no flags Details

Description Marat Bakeev 2015-04-15 21:58:44 UTC
Created attachment 115096 [details]
xrandr --verbose

I have a ThinkPad T550 with Philips Brilliance 288P monitor, connected to mini displayport.

I'm trying to use 3840x2160 mode at 60hz refresh, which should work through MST.
But i'm not getting any DP1-1 DP1-2 devices for MST virtual display panels.

I'm running archlinux with 4.0.0-rc7-drm_intel_nightly_20150411 kernel (i've tried   3.19.3-3-ARCH, and 4.0.0-1 mainline kernel)
xf86-video-intel-git 2.99.917.265.g37ce4dd-1
libdrm-git 2.4.60.31.g6f90b77-1

I'm attaching xrandr --verbose output and dmesg with drm.debug after doing xrandr --output DP1 --off to motivate monitor to switch to MST mode. DisplayPort 1.2 in monitor properties is enabled.
Comment 1 Marat Bakeev 2015-04-15 21:59:34 UTC
Created attachment 115097 [details]
dmesg output after xrandr --output DP1 --off
Comment 2 Chris Wilson 2015-04-15 22:12:24 UTC
Hmm, I thought it was a composite panel. What does the drm.debug dmesg say when you try to enable the 60Hz 4k mode?
Comment 3 Marat Bakeev 2015-04-15 22:30:39 UTC
Created attachment 115098 [details]
xrandr --output DP1 --mode 3840x2160 --rate 60

This is logged in dmesg when I try to use 60hz.

The whole system can hang occasionally at this point (but not all the time, one in ten attempts)
Comment 4 Chris Wilson 2015-04-16 07:51:26 UTC
My earlier statement was completely wrong, it definitely is acting as a single 4k@60Hz stream. The bandwidth is right at the edge of the available clocks, and it would seem we are not quite generous enough with our fifo allocation.
Comment 5 Marat Bakeev 2015-05-21 21:04:12 UTC
Any chance this will be fixed anytime soon? 
I'm willing to run any tests necessary.
Comment 6 Jani Nikula 2015-05-22 05:15:18 UTC
Does i915.enable_ips=0 module parameter help?
Comment 7 Jani Nikula 2015-05-22 05:16:53 UTC
On second thoughts, that may be a bogus suggestion, but no harm in trying...
Comment 8 Marat Bakeev 2015-05-22 07:13:16 UTC
(In reply to Jani Nikula from comment #6)
> Does i915.enable_ips=0 module parameter help?

Thanks for the suggestion, but I'm actually using this parameter right now, without it the monitor won't even work properly. 
Should have mentioned it on the bug report..
Comment 9 Marat Bakeev 2015-06-07 20:36:36 UTC
Seems to be fixed now, in intel nightly kernel.

Linux 4.1.0-rc6-drm_intel_nightly_20150605

DP1 connected primary 3840x2160+2880+0 (normal left inverted right x axis y axis) 621mm x 341mm
   3840x2160     60.00*+  30.00
Comment 10 Marat Bakeev 2015-06-09 20:55:07 UTC
The monitor works, but it still requires i915.enable_ips=0 flag, and a GPU hang occurs occasionally (and was unable to catch the dump). 

Should this bug remain open? Or should I file a new one when I get the dump from hanged GPU?
Comment 11 Ander Conselvan de Oliveira 2015-08-06 07:42:50 UTC
(In reply to Marat Bakeev from comment #10)
> The monitor works, but it still requires i915.enable_ips=0 flag, and a GPU
> hang occurs occasionally (and was unable to catch the dump). 
> 
> Should this bug remain open? Or should I file a new one when I get the dump
> from hanged GPU?

The following two patches were merged to drm-intel-nightly after that above comment was made. Could you check if you can remove the i915.enable_ips=0 flag with those?

commit 066cf55b9ce35f1f90dde9fcec01431a9243a949
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Fri Jun 26 13:55:54 2015 -0700

    drm/i915: Fix IPS related flicker

commit 8cfb340774744438dea08a32072bea4a162dd132
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Jun 3 15:45:11 2015 +0300

    drm/i915: Don't enable IPS when pixel rate exceeds 95%
Comment 12 Marat Bakeev 2015-08-10 03:19:28 UTC
(In reply to Ander Conselvan de Oliveira from comment #11)
> The following two patches were merged to drm-intel-nightly after that above
> comment was made. Could you check if you can remove the i915.enable_ips=0
> flag with those?
> 

With linux-drm-intel-nightly 20150810 (Linux 4.2.0-1-drm-intel-nightly) it is possible to boot and use the monitor without the i915.enable_ips=0 flag.
But the monitor now defaults to 30 hz refresh rate, although it is still possible to switch it to 60hz through xrandr (but it's a small annoyance).
Comment 13 Marat Bakeev 2015-08-26 00:12:02 UTC
With linux-drm-intel-nightly-docs 20150810 the kernel log is filled with messages: [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)!
Comment 14 Jani Nikula 2015-10-07 13:27:02 UTC
(In reply to Marat Bakeev from comment #13)
> With linux-drm-intel-nightly-docs 20150810 the kernel log is filled with
> messages: [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt
> lied (SDE)!

That's bug 92084.

(In reply to Marat Bakeev from comment #12)
> With linux-drm-intel-nightly 20150810 (Linux 4.2.0-1-drm-intel-nightly) it
> is possible to boot and use the monitor without the i915.enable_ips=0 flag.

This part is fixed.

> But the monitor now defaults to 30 hz refresh rate, although it is still
> possible to switch it to 60hz through xrandr (but it's a small annoyance).

Is this the only remaining problem? Please file a new bug about that to not conflate this one. Thanks.
Comment 15 cprigent 2015-10-08 16:29:21 UTC
Bug scrub:
Marat Bakeev, do you confirm the bug is fixed?
Comment 16 Marat Bakeev 2015-10-08 21:04:08 UTC
Yes, the issue I reported is definitely fixed now. Thanks!


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.