Created attachment 83842 [details] dmesg with drm.debug=0xe Linux Kernel 3.11-rc4 Hardware: Lenovo Thinkpad X230 (Ivy Bridge) docked in MiniDock 3 with 2xDVI. When both DVI displays are attached only one DVI display and LVDS are enabled during boot (console). When trying to start X server it segfaults with (full backtrace in attached dmesg): srp 08 16:03:39 x230 kernel: WARNING: CPU: 0 PID: 2886 at drivers/gpu/drm/i915/intel_display.c:8284 check_crtc_state+0x58f/0xa20() srp 08 16:03:39 x230 kernel: pipe state doesn't match! With only one DVI display attached everything works as expected. Also on older stable kernels 3.9.x, 3.10.x everything works and all three displays can be used as expected.
Created attachment 83885 [details] [review] more debug output for pll sharing Please apply the attached patch and grab a new dmesg with drm.debug=0xe set.
Note to self: pll sharing seems to work as intended on my ivb with 2x hmdi and 1x vga in all cases (i.e. different pipes and hdmi outputs either sharing dpll A or B).
Created attachment 85384 [details] dmesg with patch and drm.debug=0xe Hi Daniel, please find the dmesg with your patch applied (3.11.0 with latest drm-fixes and your patch). Since last time I see small improvement - all displays are lit during boot (i915 kms) and also Wayland/Weston works as expected. Xorg still crashes with same error. Regards,
(In reply to comment #3) > please find the dmesg with your patch applied (3.11.0 with latest drm-fixes > and your patch). Since last time I see small improvement - all displays are > lit during boot (i915 kms) and also Wayland/Weston works as expected. Xorg > still crashes with same error. Have you upgraded the kernel? I'm a bit confused that it magically fixed itself. For the Xorg crash we need to have the Xorg.log file. But looking at the logfiles it seems like Xorg wants to set up a shared 1024x768 config. But since it leaves the other 2 outputs enabled we'll then run out of display PLLs and fail the modeset. Of course X shouldn't crash if this happens, but picking the 1024x768 config is the expected behaviour in some configurations since this resolution is the only common one shared by all 3 outputs. Kernel/Wayland work better since they pick the native resolution by default. Note that if you disable (manually) the 2 hdmi outputs first and then enable them at 1024x768 it would also work. Unfortunately we don't yet have an atomic modeset interface to make this possible for X startup and similar places.
Created attachment 85491 [details] Xorg.0.log 3.11.0 + drm_fixes (In reply to comment #4) > Have you upgraded the kernel? I'm a bit confused that it magically fixed > itself. Yes, I am sorry I forgot to mention upgrade from 3.11-rc4 to 3.11.0. In 3.11-rc4 wayland nor kernel doesn't work. In 3.11.0 does. > For the Xorg crash we need to have the Xorg.log file. But looking at the > logfiles it seems like Xorg wants to set up a shared 1024x768 config. I dumped Xorg.0.log along with the last dmesg dump. It is attached along with this comment so you can take a look. > But since it leaves the other 2 outputs enabled we'll then run out of display > PLLs and fail the modeset. Of course X shouldn't crash if this happens, but > picking the 1024x768 config is the expected behaviour in some configurations > since this resolution is the only common one shared by all 3 outputs. > Kernel/Wayland work better since they pick the native resolution by default. > Note that if you disable (manually) the 2 hdmi outputs first and then enable > them at 1024x768 it would also work. Unfortunately we don't yet have an > atomic modeset interface to make this possible for X startup and similar > places. I'm using X.org configuration automagic (no xorg.conf/no snippets) as I travel a lot between various workplaces. I can reproduce this only at work where I have this Advanced MiniDock 3, attached monitors are 2x 1600x1200 native Sun 21"s and my LVDS is 1366x768 so I don't see why X.org tries to set 1024x768. On the other hand with 3.9.* is 1024x768 default when X.org starts (on all three displays screen is centered small square 1:1) and I have to reconfigure using xrandr to 1600x1200 leftof 1600x1200 leftof 1366x768. Thanks for this workaround. I'm not sure if I'll be able to disable all external outputs in configuration snippet to reenable them using xrandr once Xorg is up - if I understand that workaround correctly. Would you please share some info on how to do that? (xorg.conf <Monitor> option "Enable" seem to not work for me).
Chris, can you pls enlighten me where the patch for more robuts ScreenInit is stuck and reassign the bug? Or is this something only SNA can do? Wrt the Xorg default that's just how X rolls: It tries to set up a cloned config on as many outputs as possible, but with the exact same resolution on all of them. I agreee that it's not the most sensible default and most distros/login managers have their own pile of stuff on top ...
Robust? More like doesn't commit suicide. SNA will install a minimal configuration if the intial modeset fails in: commit 986e13a56a8544d5b32dbcaacbc0ee9cf5d47e27 [2.20.16] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Dec 10 17:29:08 2012 +0000 sna: Try installing a fallback config on VT enter in case full desiredMode fails X tries to not wimp out in: commit 6703a7c7cf1a349c137e247a0c8eb462ff7b07be [xorg-server-1.13.99.902] Author: Keith Packard <keithp@keithp.com> Date: Tue Jan 8 20:24:32 2013 -0800 hw/xfree86: Require only one working CRTC to start the server. Also note that if you are using SNA, it will try to maintain the exact setup it inherits from fbcon before the DE take over.
Fyi enabling SNA can be done with the following xorg.conf snippet: Section "Device" Identifier "igd" Driver "intel" Option "AccelMethod" "SNA" EndSection With that everything should work, and with an updated Xorg server even UXA shouldn't commit suicide.
Thanks! With Option "AccelMethod" "SNA" works as expected, also native resolution for all outputs is set.
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.