Bug 71171

Summary:	[GM45 SNA] No screen updates in some programs on Ubuntu 13.10
Product:	xorg	Reporter:	Paul Donohue <freedesktop-bugs>
Component:	Driver/intel	Assignee:	Chris Wilson <chris>
Status:	RESOLVED NOTOURBUG	QA Contact:	Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Paul Donohue 2013-11-02 19:35:19 UTC

Just updated from Ubuntu 13.04 to 13.10, and I'm having issues running any terminal emulator.  xterm, xvt, and gnome-terminal generally won't display anything except my shell prompt unless I resize the window, but occasionally will display a few characters scattered across the window if large quantities of text are printed by a program.  Firefox, chrome, and gvim all seem to work ok.  My gvim window occasionally becomes completely corrupted (displaying a mostly random pattern), but I'm assuming that is a separate issue.

I'm using xserver-xorg-video-intel 2:2.99.904-0ubuntu2 with kernel 3.11.0-12-generic in Ubuntu 13.10.  In 13.04, I was using xf86-video-intel git commit 504b18b079e0a12a9d18b46418411805ef1d8377 (because the xserver-xorg-video-intel package that came with 13.04 had other corruption problems).  Reverting my Ubuntu 13.10 system to using commit 504b18b079e0a12a9d18b46418411805ef1d8377 seems to fix most of the problems (I still get an occasional line or two of text in the terminal that doesn't update properly, or a line that gets repeated numerous times when it shuold only be displayed once ... I did not observe such behavior when I used this commit under Ubuntu 13.04, so there are obviously other components of the system involved here as well).

I'll update this bug report with more information as I experiment further.

Comment 1 Chris Wilson 2013-11-02 20:35:02 UTC

Just a few log files would be a good start towards system identification. This is the first report of such serious calamity that I would be inclined to look at what else is broken on your system first.

Comment 2 Paul Donohue 2013-11-02 21:47:19 UTC

I've found the problem.

I always run X via `startx` from a terminal instead of using a graphical login manager.  In 13.04, ConsoleKit was used to manage session-based permissions, and /etc/X11/Xsession.d/90consolekit took care of preparing a ConsoleKit session via `ck-launch-session` when X is started via `startx` instead of a graphical login manager.  In 13.10, ConsoleKit was replaced with systemd-logind, but nothing was done to ensure that X sessions started via `startx` are properly managed via systemd-logind.

Everything works fine (with either the old or new xf86-video-intel) after replacing my /etc/X11/xinit/xserverrc with:
#!/bin/bash
TTY="${TTY:-$(tty)}"
TTY="${TTY#/dev/}"
if [[ $TTY != tty* ]]; then
  printf '==> ERROR: invalid TTY\n' >&2
  exit 1
fi
printf -v VT 'vt%02d' "${TTY#tty}"
exec /usr/bin/X -nolisten tcp -dpi 100 "$VT" "$@"

(This script came from http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html)

Reverting to the original xserverrc brings back the previous rendering issues again, so I'm confident that this is the issue.

I'm not sure how PolicyKit has anything to do with rendering, but clearly it does.  (If anything, I would expect hardware rendering to fail entirely ... not to fail in some cases and work fine in others.)  Is PolicyKit known to impact rendering behavior like this?

Comment 3 Chris Wilson 2013-11-02 21:51:04 UTC

I haven't heard of anything quite like that before. My expectation was that you ended up with either the wrong ddx or the wrong GL driver. I'm guessing that it was failing to set up permissions on /dev/dri/card0 - but again I'm not aware of this exact failure mode.

Comment 4 Paul Donohue 2013-11-02 22:10:47 UTC

Among other things, yes, it definitely wasn't setting perms on /dev/dri/card0.  But the weird thing is nothing abnormal showed up in Xorg.0.log (I see "xfree86: Adding drm device (/dev/dri/card0)", but no errors or anything)...

Regardless ... thanks for reading and responding so quickly.

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.