Bug 78293 - [ivo] In a tri-head configuration on a laptop, one of the external screens is not repainted
Summary: [ivo] In a tri-head configuration on a laptop, one of the external screens is...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-05 10:49 UTC by Kirill Müller
Modified: 2014-05-23 07:37 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Log with Option "AllowSHMPixmaps" "true" in /etc/bumblebee/xorg.conf.nvidia (20.00 KB, text/plain)
2014-05-05 11:07 UTC, Kirill Müller
no flags Details
"Normal" i-v-o log (252.91 KB, text/plain)
2014-05-05 11:12 UTC, Kirill Müller
no flags Details
xrandr output for both displays in one file (2.74 KB, text/plain)
2014-05-05 11:13 UTC, Kirill Müller
no flags Details
xrandr output (2.78 KB, text/plain)
2014-05-12 14:54 UTC, Kirill Müller
no flags Details
Disable panning after CRTC off (644 bytes, patch)
2014-05-12 15:06 UTC, Chris Wilson
no flags Details | Splinter Review

Description Kirill Müller 2014-05-05 10:49:49 UTC
This is a relaunch of https://bugs.freedesktop.org/show_bug.cgi?id=76271 .

Ubuntu 13.10, Intel video driver and i-v-o from Git (ef178f7). One of my two external screens is not repainted and does not even show the cursor. In "perf top", heavy usage is shown for nvidia_drv.so and [drm] when running glxgears:

 35.94%  [drm]                               [k] drm_clflush_page
  9.90%  nvidia_drv.so                       [.] 0x000000000007f0a4
  8.88%  [kernel]                            [k] mutex_spin_on_owner
  4.39%  [kernel]                            [k] __sg_page_iter_next.part.9
  3.00%  i965_dri.so                         [.] 0x0000000000032a36
  2.40%  [kernel]                            [k] __sg_page_iter_next
  2.14%  [kernel]                            [k] mspin_lock
  2.04%  intel_drv.so                        [.] memcpy_from_tiled_x__swizzle_9_
  0.87%  [kernel]                            [k] __ticket_spin_lock
  0.87%  perf                                [.] 0x000000000004bb42
  0.81%  libxul.so                           [.] 0x00000000018f56ee
  0.62%  Xorg                                [.] 0x000000000013d3b8
  0.59%  libdrm_intel.so.1.0.0               [.] 0x00000000000066a2
  0.58%  libdricore9.2.1.so.1.0.0            [.] 0x0000000000149852
  0.52%  [i915]                              [k] ivybridge_irq_handler
  0.50%  [drm]                               [k] drm_clflush_sg

No heavy lag anymore.

Things to check:

- Stock video driver (I think this works, but will re-check)
- Setting Option "AllowSHMPixmaps" "true" in /etc/bumblebee/xorg.conf.nvidia (will check)
- Attach debug output from i-v-o
- ?
Comment 1 Chris Wilson 2014-05-05 10:56:28 UTC
Which kernel is that? (Where is all that clflush coming from?!)

Can you capture the i-v-o debug log (change the #if 0 in virtual.c and run with -f)?
Comment 2 Chris Wilson 2014-05-05 10:57:42 UTC
Also xrandr -d :0 and xrandr -d: 8
Comment 3 Kirill Müller 2014-05-05 11:03:45 UTC
Linux vpl-thinkpad10-13 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Comment 4 Kirill Müller 2014-05-05 11:07:10 UTC
Created attachment 98468 [details]
Log with Option "AllowSHMPixmaps" "true" in /etc/bumblebee/xorg.conf.nvidia

Had to kill i-v-o using kill -9
Comment 5 Kirill Müller 2014-05-05 11:12:08 UTC
Created attachment 98469 [details]
"Normal" i-v-o log

One of the external displays is not repainted
Comment 6 Kirill Müller 2014-05-05 11:13:54 UTC
Created attachment 98470 [details]
xrandr output for both displays in one file

( xrandr; xrandr -d :8 ) > xrandr.log
Comment 7 Kirill Müller 2014-05-05 11:21:45 UTC
I've reinstalled stock drivers (Ubuntu 13.10) using

apt-get install xserver-xorg-video-all

Xorg.0.log now shows

SNA compiled: xserver-xorg-video-intel 2:2.99.904-0ubuntu2.1 (Robert Hooker <sarvatt@ubuntu.com>)

The issue persists.

On the other hand, the "stable" version of i-v-o, ecc20fb, still works without fail on the stock drivers.
Comment 8 Kirill Müller 2014-05-05 11:44:38 UTC
The "stable" version of i-v-o also works with the most recent drivers:

intel(0): SNA compiled from 2.99.911-132-gef178f7
Comment 9 Chris Wilson 2014-05-05 11:48:53 UTC
The issue is that the nvidia driver still doesn't like the commands to disable CRTCs and update the panning area.
Comment 10 Chris Wilson 2014-05-05 12:09:58 UTC
This should fix up the errors with enabling ShmPixmaps in the nvidia driver:

commit a93d2d4f910dc66fe7114a4f44bf8098e3f7ae7a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 5 13:03:14 2014 +0100

    intel-virtual-output: Check for errors whilst creating ShmPixmaps
    
    Creating a ShmPixmap may cause an asynchronous BadAccess error, so wrap
    the construction with XSync and check for an error before proceeding.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=78293


commit 5279ebf56449a9b9edd28ff23e9c8a20af792795
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 5 13:06:11 2014 +0100

    intel-virtual-output: Mark ShmPixmap destinations as writeable
    
    In order to prevent a subsequent BadAccess when we try to use it as a
    ShmPixmap, we need to mark the segment as writeable.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=78293

Still puzzling over why everything fails when setting the CRTCs though. Could you please update and attach another failing log? (Minor debug changes)
Comment 11 Chris Wilson 2014-05-07 06:47:10 UTC
Ping for an updated debug log.
Comment 12 Chris Wilson 2014-05-07 06:56:41 UTC
Aha!

commit c5bad6daaaa60fa8970eaf4a1ce485cd4c72c2fd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 7 07:53:11 2014 +0100

    intel-virtual-output: Disable remote CRTC using the remote Display!
    
    Reported-by: Kirill Müller <mail@kirill-mueller.de>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78293
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

That should be the fix.
Comment 13 Kirill Müller 2014-05-07 10:11:21 UTC
Sorry for the delay. I've upgraded my test system to Ubuntu 14.04, and optirun stopped working. Fixed by installing nvidia-319-updates-uvm (which also pulls the driver), but now gnome-shell crashes when I start or end i-v-o. But that's another issue, I guess.

As for the CRTCs, in my setup now the contents of the second display are replicated on the third display, even if it is set as rotated. Which logs would you be interested in?

Didn't test with the SHM setting yet.
Comment 14 Kirill Müller 2014-05-07 10:13:25 UTC
Update: gnome-shell segfaults, even when using the "stable" version of i-v-o mentioned earlier.

Which nvidia drivers can you recommend? nvidia-current doesn't seem to work (anymore) on 14.04.
Comment 15 Kirill Müller 2014-05-07 10:14:51 UTC
I installed 331, not 319. Now trying to remove the -uvm module.
Comment 16 Chris Wilson 2014-05-07 10:17:35 UTC
That sounds like panning is broken again. In the rotated configuration, a quick xrandr -d :0, xrandr -d :8 should suffice to confirm the same symptoms as before. After that a debug log will help to check for new X11 errors.
Comment 17 Chris Wilson 2014-05-07 10:18:20 UTC
Oh, yes, I know mutter has a nasty bug(s) in its randr handling.
Comment 18 Chris Wilson 2014-05-12 13:26:16 UTC
Hi Kirill, could you paste the xrandr -d :0 and -d :8 of the failing configuration?
Comment 19 Kirill Müller 2014-05-12 14:54:18 UTC
Created attachment 98930 [details]
xrandr output

( xrandr; xrandr -d :8 ) > xrandr.log

After running i-v-o, gnome-shell crashes. After automatic restart, adjusted displays by rotating the third; still, contents of second display are replicated to the third.

ad01e1c8700caeaf0288 after make clean && make && sudo make install && reboot .
Comment 20 Chris Wilson 2014-05-12 15:04:55 UTC
Right, the bad panning is back. Can you please try:

diff --git a/tools/virtual.c b/tools/virtual.c
index d792957..8175944 100644
--- a/tools/virtual.c
+++ b/tools/virtual.c
@@ -457,7 +457,7 @@ static int disable_crtc(Display *dpy, XRRScreenResources *res, RRCrtc crtc)
                if (XRRSetCrtcConfig(dpy, res, crtc, CurrentTime, 0, 0, None, RR_Rotate_0, NULL, 0) != Success)
                        return 0;
 
-               if (XRRSetPanning(dpy, res, crtc, memset(&panning, 0, sizeof(panning))) != Success) {
+               if (0 && XRRSetPanning(dpy, res, crtc, memset(&panning, 0, sizeof(panning))) != Success) {
                        DBG(("%s failed to clear panning on CRTC:%ld\n", DisplayString(dpy), (long)crtc));
                        if (EXTRA_DBG) {
                                XRRCrtcInfo *c;
Comment 21 Chris Wilson 2014-05-12 15:06:02 UTC
Created attachment 98931 [details] [review]
Disable panning after CRTC off

Attached rather than pasted in case the paste mangled the lines.
Comment 22 Kirill Müller 2014-05-12 15:10:23 UTC
Thanks. I need to reboot and find time, that's why it sometimes takes a while. Please let me know if you might need further information so I can collect it in one sweep.
Comment 23 Chris Wilson 2014-05-15 16:08:20 UTC
Hmm, I only have a single screen I can conveniently attach to the nvidia card. That doesn't seem to suffer the panning failure when I switch it on/off, rotate it, and move it around. Will see if I can grab another screen to attach.
Comment 24 Chris Wilson 2014-05-15 20:52:40 UTC
In case it is significant, I am using

[   390.189] (II) NVIDIA dlloader X Driver  331.67  Fri Apr  4 11:24:40 PDT 2014
[   390.190] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
Comment 25 Chris Wilson 2014-05-16 16:10:16 UTC
Found an old monitor.

root@ivybridge:~# xrandr -d :0
Screen 0: minimum 8 x 8, current 4864 x 1280, maximum 32767 x 32767
LVDS1 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080      60.0*+
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
VIRTUAL2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1920x1080      60.0* 
   1280x1024      75.0     60.0  
   1152x864       75.0  
   VIRTUAL2.642-1024x768   75.0  
   1024x768       60.0  
   800x600        75.0     60.3  
   640x480        75.0  
   VIRTUAL2.647-640x480   59.9  
VIRTUAL3 connected 1024x1280+3840+0 right (normal left inverted right x axis y axis) 0mm x 0mm
   1280x1024      60.0*    75.0  
   VIRTUAL2.642-1024x768   75.0  
   VIRTUAL3.649-1024x768   72.0  
   VIRTUAL3.650-1024x768   70.1  
   1024x768       60.0  
   800x600        75.0     60.3  
   VIRTUAL3.651-800x600   72.2  
   VIRTUAL3.652-800x600   56.2  
   640x480        75.0  
   VIRTUAL3.653-640x480   72.8  
   VIRTUAL2.647-640x480   59.9  
   VIRTUAL3.654-640x400   70.1  
   VIRTUAL3.655-640x360   70.0  
VIRTUAL4 disconnected (normal left inverted right x axis y axis)
VIRTUAL5 disconnected (normal left inverted right x axis y axis)
root@ivybridge:~# xrandr -d :8
Screen 0: minimum 8 x 8, current 2944 x 1280, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080      60.0*+
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   640x480        75.0     59.9  
DVI-I-1 connected 1024x1280+1920+0 right (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1024x768       75.0     72.0     70.1     60.0  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  
   640x400        70.1  
   640x360        70.0  
HDMI-0 disconnected (normal left inverted right x axis y axis)

Not seeing the panning issue at all.
Comment 26 Kirill Müller 2014-05-16 17:00:10 UTC
Great you found a third monitor. I can share some details of my test system, let me know if you need more:

- Lenovo T430
- nvidia-331-uvm package installed (some problems with nvidia-331-updates-uvm made me uninstall it)
- Intel driver and i-v-o from Git
- Ubuntu GNOME 14.04
- Third display rotated

I will try again next week.

I really appreciate your efforts, I have to make sure multi-monitor support works well before upgrading my production system to 14.04.
Comment 27 Chris Wilson 2014-05-18 12:49:04 UTC
Marly, if you can help with testing by installing form xf86-video-intel.git and apply

diff --git a/tools/virtual.c b/tools/virtual.c
index d107617..fd42ece 100644
--- a/tools/virtual.c
+++ b/tools/virtual.c
@@ -65,7 +65,7 @@
 #include <fcntl.h>
 #include <assert.h>
 
-#if 0
+#if 1
 #define DBG(x) printf x
 #define EXTRA_DBG 1
 #else

to generate the debug output from i-v-o, that would be very useful.
Comment 28 Kirill Müller 2014-05-19 09:10:22 UTC
Now, aclocal-1.13 is missing on my Ubuntu 14.04 system, it offers aclocal-1.14 .

~/xf86-video-intel$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/muelleki/xf86-video-intel/missing aclocal-1.13  -I m4
/home/muelleki/xf86-video-intel/missing: line 81: aclocal-1.13: command not found
WARNING: 'aclocal-1.13' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [aclocal.m4] Error 127

~ aclocal-1.13
No command 'aclocal-1.13' found, did you mean:
 Command 'aclocal-1.14' from package 'automake' (main)
 Command 'aclocal-1.11' from package 'automake1.11' (main)
 Command 'aclocal-1.10' from package 'automake1.10' (main)
aclocal-1.13: command not found

# apt-get install automake
Reading package lists... Done
Building dependency tree       
Reading state information... Done
automake is already the newest version.
automake set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Comment 29 Kirill Müller 2014-05-19 09:13:41 UTC
I was able to fool it by saying

/usr/bin# ln -s aclocal-1.14 aclocal-1.13
/usr/bin# ln -s automake-1.14 automake-1.13

Not nice, though.
Comment 30 Kirill Müller 2014-05-19 09:20:37 UTC
After another round of

make clean && make -j4 && sudo make install

everything looks peachy now. There is again a heavy lag on the external displays, the lag is not as heavy on the primary display. For example, it is noticeable when typing at a very quick speed in gedit.

Shall I open a new issue?
Comment 31 Chris Wilson 2014-05-19 09:38:50 UTC
Please, let's tackle that drm_cflush_page() issue separately, i.e. the lag. I think that is a kernel bug fixed in recent kernels.

Can you double check that everything is fine but just too slow? In particular, rearranging the screens (modulo mutter blowing up sporadically when it tries to dereference a NULL pointer - not my bug! ;-)?
Comment 32 Kirill Müller 2014-05-22 07:23:28 UTC
I've tried some combinations of arrangement and rotation of both external displays, including a few really weird ones. All of them worked as expected.

Since you mentioned the mutter bug -- I'm experiencing crashes when starting and terminating i-v-o. Could you give a hint on how to avoid it -- is there a bugfix in some PPA, or a configuration to avoid the bug? This is still a showstopper for me. I'm using gnome-shell, don't know if this is the same.

Thanks a lot for your efforts. Keep up the good work!
Comment 33 Kirill Müller 2014-05-22 07:24:01 UTC
...on the most recent Git tip as of now, 00d9396f6bf0bbbdfca7c .
Comment 34 Chris Wilson 2014-05-22 07:53:03 UTC
Yes, gnome-shell uses mutter. The bug is

https://github.com/GNOME/mutter/blob/master/src/backends/x11/meta-monitor-manager-xrandr.c#L522

does not handle the case with no modes i.e. it tries to dereference a NULL pointer. Filed as https://bugzilla.gnome.org/show_bug.cgi?id=730551

Please do let me know if performance is subpar, or if any other issues arise. Thanks.
Comment 35 Kirill Müller 2014-05-22 08:52:44 UTC
Please excuse my ignorance -- but do you see any chance to work around this bug in mutter in i-v-o and/or the Intel driver?
Comment 36 Chris Wilson 2014-05-22 09:14:11 UTC
Not sure. The problem is if I leave a fake mode in there, gnome-shell will try to extend the desktop to it, which is also undesirable.
Comment 37 Chris Wilson 2014-05-22 11:33:47 UTC
Actually, how about:

diff --git a/tools/virtual.c b/tools/virtual.c
index 8f707b7..956fabb 100644
--- a/tools/virtual.c
+++ b/tools/virtual.c
@@ -927,6 +927,10 @@ static RROutput claim_virtual(struct display *display, char *output_name, int nc
        XRRDeleteOutputMode(dpy, rr_output, id);
        XRRDestroyMode(dpy, id);
 
+       /* And hide it again */
+       res = XRRGetScreenResources(dpy, display->root);
+       if (res == NULL)
+               XRRFreeScreenResources(res);
 out:
        XUngrabServer(dpy);
Comment 38 Chris Wilson 2014-05-22 19:57:46 UTC
I think this should hid the connected + 0 modes from gnome-shell:

commit 8d1e9afb60a61bf490a282a16db1c15a9ad7d077
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 22 12:34:05 2014 +0100

    intel-virtual-output: Probe after claiming virtual output
    
    Rerun a detection cycle after claiming the virtual output so that it is
    hidden again.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=78293
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 39 Kirill Müller 2014-05-23 07:37:22 UTC
Sweet! Works for me, ready for Trusty now. Again, thanks a lot for your efforts and your quick response, very much appreciated!


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.