Bug 89661 - [ivb] Unable to configure 3rd pipe (e.g. LVDS + DP + DP)
Summary: [ivb] Unable to configure 3rd pipe (e.g. LVDS + DP + DP)
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-18 16:55 UTC by Jiri Slaby
Modified: 2018-09-10 07:32 UTC (History)
3 users (show)

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


Attachments
xorg log (106.16 KB, text/plain)
2015-03-18 16:55 UTC, Jiri Slaby
no flags Details
xrands output (17.21 KB, text/plain)
2015-03-18 17:38 UTC, Jiri Slaby
no flags Details
dmesg with drm.debug enabled (34.32 KB, text/plain)
2015-05-28 13:35 UTC, Adam Taciak
no flags Details
xrandr --verbose (1.88 KB, text/plain)
2015-06-01 13:51 UTC, Adam Taciak
no flags Details
Xorg log (27.05 KB, text/plain)
2015-06-01 13:53 UTC, Adam Taciak
no flags Details
xrandr log (2.10 KB, text/plain)
2015-06-02 07:00 UTC, Adam Taciak
no flags Details
dmesg (70.71 KB, text/plain)
2015-06-02 08:57 UTC, Adam Taciak
no flags Details
complete dmesg (140.52 KB, text/plain)
2015-06-02 09:10 UTC, Adam Taciak
no flags Details
3 monitors (241.37 KB, text/plain)
2017-03-08 17:26 UTC, Elio
no flags Details
2 monitors (13.12 KB, text/plain)
2017-03-08 17:26 UTC, Elio
no flags Details
full dmesg 4.11.rc1 (241.37 KB, text/plain)
2017-03-08 17:27 UTC, Elio
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Slaby 2015-03-18 16:55:21 UTC
Created attachment 114445 [details]
xorg log

I tried a setup of LVDS, TV over HDMI and monitor over DP. I cannot use all three simultaneously. Only LVDS+HDMI or LVDS+DP works (haven't tried HDMI+DP). If I try to enable all three, I get this:
[640670.088] (EE) intel(0): failed to set mode: Invalid argument [22]
to Xorg.log.

I am on 2.99.917-174-g3e390ec41105 with SNA.

Is this a bug or feature :)?
Comment 1 Chris Wilson 2015-03-18 17:19:23 UTC
I think it is a Feature. The 3rd PLL on Ivybridge is limited - only we have no way yet of knowing if the user configuration is valid ahead of time and no way of telling RandR of the limits.

If you did

$ xrandr --output LVDS1 --off --output HDMI1 --off --output DP2 --off
$ xrandr --output DP2 --preferred
$ xrandr --output HDMI1 --preferred --right-of DP2
$ xrandr --output LVDS1 --preferred --right-of HDMI1

do you get 3 pipes lit up?
Comment 2 Jiri Slaby 2015-03-18 17:30:36 UTC
xrandr --output LVDS1 --off --output HDMI1 --off --output DP2 --off
xrandr --output DP2 --preferred
xrandr --output HDMI1 --preferred --right-of DP2 --output LVDS1 --off
xrandr --output LVDS1 --preferred --right-of HDMI1 --output DP2 --off

Yes, If I put the 3rd off                          ^^^^^^^^^^^^^^^^^^

Otherwise it fails to change.
Comment 3 Chris Wilson 2015-03-18 17:34:49 UTC
Forgot to ask for "xrandr --verbose" so that I can see the possible CRTCs.
Comment 4 Jiri Slaby 2015-03-18 17:38:25 UTC
Created attachment 114446 [details]
xrands output

Here you go :)
Comment 5 Chris Wilson 2015-03-18 18:33:52 UTC
One last little task is to repeat the failure with drm.debug=6 and attach the dmesg; just in case there is a bug.
Comment 6 Adam Taciak 2015-05-28 13:35:57 UTC
Created attachment 116115 [details]
dmesg with drm.debug enabled
Comment 7 Adam Taciak 2015-05-28 13:40:55 UTC
I would like to refresh this issue. I have the same problem. My current configuration is laptop panel + 2 x DP monitors. On Windows everyting is working fine. When I use two displays, no problem. When I tried to enable 3rd I got

(EE) intel(0): failed to set mode: Invalid argument [22]

I added drm.debug=1 param to kernel. Debug file I just added as attachment.
Hope it helps.
Comment 8 Adam Taciak 2015-05-28 13:47:24 UTC
I forgot to add that the log file which I attached is only a part which I extracted, based on extra kernel logs:

echo "XRANDR BEGIN" > /dev/kmsg ; xrandr --output DP2 --auto ; echo "XRANDR END" > /dev/kmsg

Now I have a huge amound of logs generated by drm. I tried to copy only a part which has been logged during 3rd monitor enabling action.
Comment 9 Chris Wilson 2015-05-29 18:22:11 UTC
(In reply to Adam Taciak from comment #7)
> I added drm.debug=1 param to kernel. Debug file I just added as attachment.
> Hope it helps.

Nope, wrong debug mode. You need something like drm.debug=0xf to capture all the relevant information...

However, just a xrandr --verbose + Xorg.0.log would be a good clue as to which failure you see.
Comment 10 Adam Taciak 2015-06-01 13:51:04 UTC
Created attachment 116201 [details]
xrandr --verbose

xrandr log, when I tried to enable 3rd monitor + xrandr log with monitors list
Comment 11 Adam Taciak 2015-06-01 13:53:20 UTC
Created attachment 116202 [details]
Xorg log

and Xorg log, please let me know if something else would be useful
Comment 12 Chris Wilson 2015-06-01 15:31:45 UTC
Ok, that does actually confirm it is the same bug and not a slightly different MST one. In this case, you want something like:

xrandr --output LVDS1 --off --output DP1 --off --output DP2 --off
xrandr --output DP1 --preferred --output LVDS1 --preferred --right-of DP1 --crtc 2 --output DP2 --preferred --right-of LVDS1
Comment 13 Chris Wilson 2015-06-01 15:56:23 UTC
Hmm, to get around the kernel limitation, I suspect we actually need to do the LVDS configure last. So

xrandr --output LVDS1 --off --output DP1 --off --output DP2 --off
xrandr --output DP1 --preferred --primary -pos 0x0 -output DP2 --pos 3520x0
xrandr --output LVDS1 --preferred --pos 1600x0
Comment 14 Adam Taciak 2015-06-02 07:00:55 UTC
Created attachment 116230 [details]
xrandr log

Chris, I tried both methods. The first one, failed with the same error message in Xorg.log (Invalid argument [22]). The second, didn't cause error message, but 3rd monitor (DP2) won't power on. I added --verbose to xrandr command, results are in the attachment.
Comment 15 Chris Wilson 2015-06-02 08:18:32 UTC
(In reply to Adam Taciak from comment #14) 
> Chris, I tried both methods. The first one, failed with the same error
> message in Xorg.log (Invalid argument [22]). The second, didn't cause error
> message, but 3rd monitor (DP2) won't power on. I added --verbose to xrandr
> command, results are in the attachment.

Forgot to give DP2 a mode...

echo 0xe > /sys/modules/drm/parameters/debug
xrandr --output LVDS1 --off --output DP1 --off --output DP2 --off
xrandr --output DP1 --preferred --primary -pos 0x0 -output DP2 --preferred --pos 3520x0
xrandr --output LVDS1 --preferred --pos 1600x0
echo 0 > /sys/modules/drm/parameters/debug

If that doesn't work, please attach the dmesg.
Comment 16 Adam Taciak 2015-06-02 08:57:24 UTC
Created attachment 116233 [details]
dmesg

This time LVDS1 failed but DP1 and DP2 worked:

[root@LDZ9343N taciaka]# ./monitors.sh 
crtc 0: disable
crtc 1: disable
screen 0: 8x8 2x2 mm 101.60dpi
screen 0: 5440x1200 1360x300 mm 101.60dpi
crtc 0:    1920x1080  60.00 +0+0 "DP1"
crtc 1:    1920x1200  59.95 +3520+0 "DP2"
crtc 2:     1600x900  59.98 +1600+0 "LVDS1"
xrandr: Configure crtc 2 failed
crtc 0: disable
crtc 1: disable
crtc 2: disable
crtc 3: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert
crtc 3: revert
[root@LDZ9343N taciaka]# 

I added dmesg as attachment.
Comment 17 Adam Taciak 2015-06-02 09:10:35 UTC
Created attachment 116234 [details]
complete dmesg

ehh I unnecessarily removed dmesg records which has been stored before xrandr command. Mayby some useful logs has been stored during kernel booting.
Sorry for confuision. I added complete dmesg.
Comment 18 Chris Wilson 2015-06-02 09:53:23 UTC
Oh. Forgot one important detail, iirc that is, in order to get the third output working (without eDP), at least 2 of the outputs must share the same clocks - they have to share a PLL.

Try:
xrandr --output LVDS1 --off --output DP1 --off --output DP2 --off
xrandr --output DP1 --mode 1920x1080 --primary --output LVDS1 --preferred --right-of DP1 --output DP2 --mode 1920x1080 --right-of LVDS1

Can you look at what configuration you get with Windows? If they are able to driver all 3 at their preferred resolution, they know more tricks than we do...
Comment 19 Adam Taciak 2015-06-02 11:17:13 UTC
It fail even when I try to set something like:

xrandr --output DP1 --mode 1920x1080 --primary --output LVDS1 --mode 1024x768 --right-of DP1 --output DP2 --mode 1920x1080 --right-of LVDS1 --verbose

I assume that at least on two monitors should be the same refresh rate. Am I right? In this case I tried to set the same refresh ratio on all three. 

[taciaka@LDZ9343N ~]$ ./mon.sh 
crtc 0: disable
screen 0: 8x8 2x2 mm 101.60dpi
screen 0: 4864x1080 1216x270 mm 101.60dpi
crtc 0:    1920x1080  60.00 +0+0 "DP1"
crtc 1:     1024x768  60.00 +1920+0 "LVDS1"
crtc 2:    1920x1080  60.00 +2944+0 "DP2"
xrandr: Configure crtc 2 failed
crtc 0: disable
crtc 1: disable
crtc 2: disable
crtc 3: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert
crtc 3: revert
[taciaka@LDZ9343N ~]$

On Windows all 3 monitors have its native resolution, the biggest one (1920x1200) is left rotated, but I think is not relevant.

I can add that DP1 (monitor 1920x1080) is connected via DP <==> VGA converter. 
According this page http://www.intel.com/support/graphics/sb/CS-033714.htm (What three independent display configurations are supported? > View information for the Intel® HD Graphics 4000/2500 of 3rd Generation Intel... > View a comprehensive table of supported configurations and notes), my graphic card should supports such configuration DP + DP + LVDS.

Maybe there is somthing wrong with DP <==> VGA converter... In a few hours I will try to check this configuration with 3rd monitor connected directly via DP.
I will also try to provide more information from Windows (if it is possible ;))
Comment 20 Chris Wilson 2015-06-02 11:24:45 UTC
(In reply to Adam Taciak from comment #19)
> It fail even when I try to set something like:
> 
> xrandr --output DP1 --mode 1920x1080 --primary --output LVDS1 --mode
> 1024x768 --right-of DP1 --output DP2 --mode 1920x1080 --right-of LVDS1
> --verbose
> 
> I assume that at least on two monitors should be the same refresh rate. Am I
> right? In this case I tried to set the same refresh ratio on all three. 
> 
> [taciaka@LDZ9343N ~]$ ./mon.sh 
> crtc 0: disable
> screen 0: 8x8 2x2 mm 101.60dpi
> screen 0: 4864x1080 1216x270 mm 101.60dpi
> crtc 0:    1920x1080  60.00 +0+0 "DP1"
> crtc 1:     1024x768  60.00 +1920+0 "LVDS1"
> crtc 2:    1920x1080  60.00 +2944+0 "DP2"
> xrandr: Configure crtc 2 failed
> crtc 0: disable
> crtc 1: disable
> crtc 2: disable
> crtc 3: disable
> screen 0: revert
> crtc 0: revert
> crtc 1: revert
> crtc 2: revert
> crtc 3: revert
> [taciaka@LDZ9343N ~]$
> 
> On Windows all 3 monitors have its native resolution, the biggest one
> (1920x1200) is left rotated, but I think is not relevant.
> 
> I can add that DP1 (monitor 1920x1080) is connected via DP <==> VGA
> converter. 
> According this page http://www.intel.com/support/graphics/sb/CS-033714.htm
> (What three independent display configurations are supported? > View
> information for the Intel® HD Graphics 4000/2500 of 3rd Generation Intel...
> > View a comprehensive table of supported configurations and notes), my
> graphic card should supports such configuration DP + DP + LVDS.

I can remember eDP being special (iirc that is!), but it all boils down to whether it uses the CPU or PCH PLL. The configure failure (comment 16) seemed to be when we couldn't find a PLL to use. It seems like we have a handful of bogons in that code.
Comment 21 Jani Nikula 2016-04-21 12:30:15 UTC
We've reworked the code a bunch since the bug report; is this still an issue with the latest kernels?
Comment 22 Jiri Slaby 2016-05-17 15:31:48 UTC
Yeah, no change.
Comment 23 xuan--2010--bugs.freedesktop.org 2016-08-24 20:25:06 UTC
I, too, encounter this bug on HD 4000. Note that this bug only seems to surface with LVDS+DP+DP, even if both DP pixel clocks are identical. It does not happen with LVDS+DVI+DVI or LVDS+HDMI+HDMI (where the DVI or HDMI pixel clocks are identical). (However, HDMI is not an option due to the lack of HDMI inputs at my monitors and the need for a high pixel clock due to high monitor resolution. The HDMI pixel clock limit seems to be around 225 MHz, while the effective DP pixel clock limit seems to be around 395 MHz.)

Apparently, PLL sharing works for HDMI+HDMI, but PLL sharing does not work for DP, while it should also work for DP+DP.
Comment 24 Lars Ivar Igesund 2016-10-07 11:08:44 UTC
I have a Dell XPS 15 laptop with a HD4600 integrated graphics (and an Nvidia discrete GPU which I normally don't use). I now run Kubuntu 16.04.1, but I had issues with this also on 14.04.

The laptop screen is 4k, and then there is a HDMI out and a mini DP out. I have a 4k Philips UltraClear and a Dell 1920x1200. The laptop came with a DisplayLink docking station which initially made it possible to use these external screens, but with a bunch of caveats and bugs. After the upgrade to 16.04, it just didn't work anymore.

So both before and after the upgrade, I've tried to use the outputs in the laptop directly.

Before that upgrade;
The 1920x1200 generally worked over the HDMI, but the 4k didn't. I remember actually finding this bug report while trying it out, but in the end the DisplayLink stuff worked well enough for it to not be worth it.

After the upgrade;
Everything actually just worked (although I took the laptop screen down to a 1920x1080), so I had eDP1 + DP1 + HDMI1 all working together, with different resolutions. This was before the summer. 

Then after the summer I had to disconnect the HDMI monitor (at 1920x1200) as it messed up the desktop, but presumably that was a bug in plasma.

After that again, the 4k monitor over mini DP has worked, but had occasional (and quite serious) flickering issues.

Then, two days ago, the 4k monitor decided to no longer want to be part, and now it seems to be back to the issue seen here, with the same type of errors as mentioned by Jiri:

failed to set mode: Invalid argument [22]

I did not run upgrade in the days preceding this last change.

Anecdote: Connecting the 1920x1200 screen over HDMI now works flawlessly.

Is there something I can do to help debug/diagnose this?
Comment 25 Ville Syrjala 2016-10-10 15:11:58 UTC
The problem is that we may end up using 1.62 link rate for one DP port, and 2.7 for the other DP port, leaving no free DPLLs for the non-DP port.

Fixing this requires that we'd consider the failure to find a DPLL as a reason to retry in the bw_constrained mode (or some similar mode) and made the DP link rate selection try to pick a common rate for all ports.

I have a branch [1] that cleans up some of the retry logic to better deal with FDI bifurcation (another common reason for failed 3 pipe configuration on IVB), but it doesn't deal with this DPLL issue. IIRC one problem is that we do the DPLL computation way too late to retry easily. I think we'd have to move it a bit, which would also allow us to use the accurate clock in various check functions. And then we'd need to adjust the DP compute_config logic to pick a common rate somehow (just go for the max?). Anyways, I think my bifurcation branch might be a decent first step in making the retry logic nicer.

[1] git://github.com/vsyrjala/linux.git ivb_bifurcation_atomic_7
Comment 26 Ville Syrjala 2016-11-07 14:05:47 UTC
(In reply to Ville Syrjala from comment #25)
> The problem is that we may end up using 1.62 link rate for one DP port, and
> 2.7 for the other DP port, leaving no free DPLLs for the non-DP port.
> 
> Fixing this requires that we'd consider the failure to find a DPLL as a
> reason to retry in the bw_constrained mode (or some similar mode) and made
> the DP link rate selection try to pick a common rate for all ports.

I was a bit bored the other day and decided to see if I could hack this thing up. Didn't turn out to be too painful. I've not really tested it myself since I don't have an IVB with two DP ports. But at least it didn't seem to explode too badly when I tried it with a machine that has one DP port.

git://github.com/vsyrjala/linux.git ivb_bifurcation_atomic_9

I'd be interested to know if it actually works.
Comment 27 Jani Saarinen 2016-12-09 09:30:15 UTC
Jiri, can you comment if see issues with latest update from Ville?
Comment 28 Jiri Slaby 2017-01-16 09:42:30 UTC
(In reply to Jani Saarinen from comment #27)
> Jiri, can you comment if see issues with latest update from Ville?

Built & tried, but as soon as I configure the 3rd output, X freezes. There are traces neither in Xorg.log, dmesg, nor I can strace or attach gdb to X (via ssh) which is spinning with CPU at 100 %. strace and gdb just hang up on attaching to process 1234. cat /proc/1234/stack shows only f's, so it must be spinning in userspace.

I also tried running X -core, but X does not crash obviously, it is just spinning.
Comment 29 Jani Saarinen 2017-03-08 07:38:16 UTC
Jiri, with latest changes to atomic/wm side, can you still reproduce with latest drm-tip?
Comment 30 Elio 2017-03-08 17:22:36 UTC
I just tried with 4.11 rc1 having the same results, i'm able to connect just another external monitor.  eDP + VGA or DP (only this options in my hardware). But as soon as i tried the 3rd one i lost one monitor output. It seems that the system is just able to take the smaller one. 
If i tried to boot up with 3 monitors UI never appears. Sharing dmesg and xrandr --verbose output
Comment 31 Elio 2017-03-08 17:26:09 UTC
Created attachment 130125 [details]
3 monitors
Comment 32 Elio 2017-03-08 17:26:31 UTC
Created attachment 130126 [details]
2 monitors
Comment 33 Elio 2017-03-08 17:27:11 UTC
Created attachment 130127 [details]
full dmesg 4.11.rc1
Comment 34 Ville Syrjala 2017-03-08 17:48:16 UTC
There's little point in testing upstream since my bifurcation patches haven't been merged.
Comment 35 Elizabeth 2017-08-01 15:35:56 UTC
(In reply to Jani Saarinen from comment #29)
> Jiri, with latest changes to atomic/wm side, can you still reproduce with
> latest drm-tip?
Hello Jiri,
Any update on this case?
Thank you.

(In reply to Ville Syrjala from comment #34)
> There's little point in testing upstream since my bifurcation patches
> haven't been merged.
Hello Ville, 
Are this patches going to be upstream or they still need to be worked on?
Thank you.
Comment 36 Jiri Slaby 2017-08-14 11:01:03 UTC
(In reply to Jani Saarinen from comment #29)
> Jiri, with latest changes to atomic/wm side, can you still reproduce with
> latest drm-tip?

Yes, it changed in no way:
+ xrandr --output LVDS-1 --off --output HDMI-1 --off --output DP-2 --off
+ xrandr --output DP-2 --preferred
+ xrandr --output HDMI-1 --preferred --right-of DP-2
+ xrandr --output LVDS-1 --preferred --right-of HDMI-1
xrandr: Configure crtc 2 failed
Comment 37 Jiri Slaby 2017-08-14 11:04:39 UTC
FWIW, with this head:
commit 7a620d02bd0a7015fe8f6fc8ae830d47b101394d (HEAD -> drm-tip, drm-tip/drm-tip)
Author: Mika Kuoppala <mika.kuoppala@intel.com>
Date:   Mon Aug 14 12:27:48 2017 +0300

    drm-tip: 2017y-08m-14d-09h-26m-51s UTC integration manifest
Comment 38 Jani Saarinen 2018-03-29 07:12:02 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 39 Jiri Slaby 2018-09-09 07:42:44 UTC
I am on skylake now, so I can no longer provide the info.
Comment 40 Lakshmi 2018-09-10 07:32:12 UTC
As we can not get logs anymore with latest drmtip. Closing now.
Reopen if you still have the issue. 

When you reopen, ensure that issue is with latest drmtip. (https://cgit.freedesktop.org/drm-tip)

Attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.


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.