[iQ35] Blank screen, unresponsive console when starting full-screen OpenGL apps

[Daniel Richard G.]

Binary package hint: xserver-xorg-video-intel

This concerns xserver-xorg-video-intel 2:2.4.1-1ubuntu10 in Intrepid.

I have a bog-standard Dell Optiplex 755 corporate PC with Intel onboard video. When I start a full-screen OpenGL application, such as Openarena or Kobo Deluxe (in GL driver mode), sometimes the screen goes black and the console becomes unresponsive (Ctrl+Alt+F2, Ctrl+Alt+Backspace, Alt+Sysrq+B, Caps/Num/Scroll Lock). The system still accepts SSH logins, however, and otherwise continues to run.

I've observed a couple of different failure modes so far:

Kobo Deluxe: Screen goes black, console unresponsive. Application can be killed with SIGHUP. X server then maxes out the CPU, and /var/log/Xorg.0.log begins to grow very quickly, about four megabytes per second. (Note that this is with the program configured to use its OpenGL driver, and run full-screen.)

Openarena: Screen goes black, white "text-area" cursor appears in center of screen after a couple seconds, pointer and console remain unresponsive. X server is pegging the CPU; log file is ballooning in size.

In either case, the runaway X server can be killed with SIGQUIT. It restarts, and I get an "Ubuntu is running in low-graphics mode" dialog. A few more clicks gets GDM back up, and I can log in again as usual, but the video hardware is in a strange state thereafter: If I switch to a virtual terminal, the screen turns black with white "snow" all over, and thicker "snow" wherever text should be. (You can sort-of see the login prompt at the top left, and when you log in, you see the snow-ified MOTD, etc.). Switching back to VT7 does not return to X; in fact, the X server is nowhere to be found. No error message in Xorg.0.log, etc.---the only clue is a bizarre message from GDM in daemon.log: "WARNING: Display :0 is busy. There is another X server running already."

I will attach some Xorg.0.log* files, the error dialog, and the output of "lspci -vvnn".

Note: I have experience with GDB and other such tools, but not with X.org's internals. I would be happy to provide telemetry on this if I am told where to look.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller [8086:29b0] (rev 02)
     Subsystem: Dell Device [1028:0211]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02)
     Subsystem: Dell Device [1028:0211]

[Daniel Richard G. (skunk)]

The program was started right before the "Error in I830WaitLpRing()" line.

[Daniel Richard G. (skunk)]

Again, look for the "Error in I830WaitLpRing()" line.

[Daniel Richard G. (skunk)]

This time, the server at least behaved. This log file is not truncated.

[Daniel Richard G. (skunk)]

A few more details that may be of interest:

* All the above results were obtained without a desktop environment, or even a window manager. Programs were invoked from a lone XTerm, launched from a bare-bones ~/.xsession script.

* The OpenGL programs start without a problem in the first X11 session after booting. After you log out, log back in, and start the same program again, however, *then* you run into the above-described behavior. (Something about the hardware not being re-initialized correctly...?)

* Tested with Armagetron Advanced; fails the same as Kobo Deluxe. (Probably a better program to test with, as no prior configuration is needed)

* In the Openarena failure mode, the application program exits shortly after starting. (The program's terminal output doesn't suggest anything amiss, however.)

[Bryce Harrington (bryce)]

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

[Daniel Richard G. (skunk)]

Okay, I pulled the following packages from the PPA:

libdrm2 (2.4.1-0ubuntu7~intrepid)
libdrm-intel1 (2.4.1-0ubuntu7~intrepid)
xserver-xorg-video-intel (2:2.5.1-1ubuntu5~intrepid)

Bug is CONFIRMED in these newer packages. Console unresponsiveness is still observed, although I'm not seeing the X server peg the CPU as before.

I didn't investigate the failure modes as thoroughly this time, but I did find one helpful little tidbit: glxgears, running in a window, triggers the problem. As before, it runs fine in the first X11 session, but in a second session, the window comes up black and the console goes bye-bye (for about a minute, until the screen blanks and the Ubuntu error dialog appears). The Xorg.0.log file produced from this is interesting, and is attached above.

[Bryce Harrington (bryce)]

Thanks for testing those drivers, too bad they didn't have an effect on the issue.

Since this is a 3D problem with OpenGL, my next guess is that perhaps the newer mesa in jaunty may make a difference. Please grab a Jaunty Alpha-2 (or newer) image and see if you can reproduce the problem in a LiveCD environment. If you can, we should forward this bug upstream.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.