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 :)?
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?
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.
Forgot to ask for "xrandr --verbose" so that I can see the possible CRTCs.
Created attachment 114446 [details] xrands output Here you go :)
One last little task is to repeat the failure with drm.debug=6 and attach the dmesg; just in case there is a bug.
Created attachment 116115 [details] dmesg with drm.debug enabled
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.
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.
(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.
Created attachment 116201 [details] xrandr --verbose xrandr log, when I tried to enable 3rd monitor + xrandr log with monitors list
Created attachment 116202 [details] Xorg log and Xorg log, please let me know if something else would be useful
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
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
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.
(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.
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.
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.
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...
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 ;))
(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.
We've reworked the code a bunch since the bug report; is this still an issue with the latest kernels?
Yeah, no change.
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.
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?
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
(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.
Jiri, can you comment if see issues with latest update from Ville?
(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.
Jiri, with latest changes to atomic/wm side, can you still reproduce with latest drm-tip?
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
Created attachment 130125 [details] 3 monitors
Created attachment 130126 [details] 2 monitors
Created attachment 130127 [details] full dmesg 4.11.rc1
There's little point in testing upstream since my bifurcation patches haven't been merged.
(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.
(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
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
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.
I am on skylake now, so I can no longer provide the info.
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.