Bug 25345

This problem has reached a reasonable amount of people and at least 6 bugs have been reported on Launchpad:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/400934
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/445056
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/445719
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/450853
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/475429
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/485576

Steps to reproduce the problem:

1. Just start a session on a newly installed system.

After a few seconds, the X server freezes. When you try to restart it with "Alt + SysRq + E", it starts and freezes soon after.

The mouse and the keyboard does not respond. Only when the whole system is restarted, it becomes usable.

With the default driver (pre-compiled, which is in the repository), the problem seems to happen "randomly".

But it seems that this problem is related to transparency. I think this is because when a tool tip disappears (with an effect of translucency), the X server freezes.

This hypothesis gained strength when I tried to compile a driver and, when tested, the images simply do not have transparency: where would be transparent, was black. And yes, the problem persisted.

Even trying to debug the freeze, no useful log was obtained by any of the users.

In the link posted by the reporter of the bug there are some useful files (logs, etc.) that can help. But the problem seems to be related to the memory address of the video card. Attached is a small table with information from different video cards.

Created attachment 31558 [details]
Comparative table

Hi Peter,

When reporting a bug against the Intel driver, here are some of the
most essential pieces of information:

    * GPU model

    * Driver version

    * Kernel version

A big advantage of submitting bug reports with the Xorg.0.log file is
that it contains all of these.

Anyway, your bug here mentions the GPU (945) but neither the kernel
nor driver version.

I did follow some of the provided links looking for driver versions
and found one mention of driver 2.8.1. Is that the driver used in all
cases? Has anyone attempted using a newer driver, (such as 2.9.0 or
the very recent 2.9.99.901 snapshot?). If so, it would be interesting
to know if there is any change in the behavior there.

-Carl

Sorry about the incomplete info: This is a report #22 from launchpad:


Marco Biscaro  wrote on 2009-11-28:

Exactly the same here. Same graphic card and same problem.

I tried to solve the problem with some combinations of kernel and drivers. And the results:

kernel 2.6.31-15 + default driver set = freeze
kernel 2.6.31-15 + ubuntu-x-swat set = freeze
kernel 2.6.31-15 + xorg-edgers set = freeze
kernel 2.6.32-rc8 + default driver set = freeze
kernel 2.6.32-rc8 + ubuntu-x-swat driver set = freeze
kernel 2.6.32-rc8 + xorg-edgers driver set = freeze

These are the intel driver versions contained in the explanation above:

default driver
2.9.0

xorg-edgers
2.9.0~git20091007.03e8e64f probably to 2.9.0+git20091130.2.6729b508

I read more carefully launchpad bug reports and noticed this report:
-----------------------------------------------------------------------------
As a workaround, I've discovered that switching to EXA acceleration seems to work. To do that, open the file /etc/X11/xorg.conf and make sure you have a section that looks like:

Section "Device"
 Identifier "Configured Video Device"
        Option "AccelMethod" "exa"
EndSection

Then restart X and you should be able to enable desktop effects without a freeze.

Unfortunately, UXA acceleration continues not to work. If there's any information I can provide to figure this out, please let me know.
------------------------------------------------------------------------------
Since I am not hit by this bug I might have been somehow misguided with the launchpad reports. The reports state that this is freeze is happening when desktop effects (Compiz) are activated. Isn't this more related to libdrm-intel or libdrm2?

Created attachment 31668 [details]
Xorg.0.log from the original bug reporter

Created attachment 31669 [details]
dmesg output from the original bug reporter

Created attachment 31670 [details]
glxinfo from original reporter

Created attachment 31671 [details]
lshal drom the original reporter

Created attachment 31672 [details]
lsmod from the original reporter

Created attachment 31673 [details]
lspci from the original reporter

Created attachment 31674 [details]
uname from the original reporter

Created attachment 31675 [details]
xdpyinfo from the priginal reporter

libdrm-intel in Ubuntu 9.10 is 2.4.14

and those that used xorg-edgers repository might have tested with

2.4.15+git20091201.8ffd2e14

Same versions for libdrm2

And adding the system freezes when using any application that involves 3D acceleration (compiz, games, blender, etc).

And the EXA acceleration does not solve (it really is taken into account or is simply discarded?).

Created attachment 31695 [details]
My `lspci -vvnn`output

I am the original reporter of the on Launchpad.  Everything posted above by Petar and Marco is consistent with my experience.

I wold like to add two points that may be useful.  First, I have discovered that when compiz is started with the --indirect-rendering flag, the freeze does NOT occur and the video driver functions with no problem.

Also, to clarify on EXA acceleration issue: I originally stated in the Launchpad bug report that adding 'Option "AccelMethod" "exa"' to xorg.conf solved the problem.  I later realized this was not the case--the X server still ended up freezing shortly after I made that comment in the bug report--and furthermore that according to the Xorg.0.log, the "AccelMethod" option was not even recognized when X started (presumably this option has been deprecated by X in the latest version of Ubuntu; it used to be valid).  So I assume that editing my xorg.conf file didn't actually do anything and there is currently no reason to believe that enabling EXA acceleration solves the problem.  I apologize for the confusion about this.

Please let me know if I can provide any other pertinent information.

(In reply to comment #16)
> I am the original reporter of the on Launchpad.  Everything posted above by
> Petar and Marco is consistent with my experience.
...
> editing my xorg.conf file didn't actually do anything and there is currently no
> reason to believe that enabling EXA acceleration solves the problem.  I
> apologize for the confusion about this.

Thanks for the clarifications.

And Christopher,

I'm delighted to have the original reporter here to track the issue.
We'll leave this bug open as long as you're having issues and close it
when your issues are resolved.

The Xorg.0.log file attached to this bug report shows an Intel driver
version of 2.8.1. Is that really accurate? That's old enough to have
lots of known bugs that have since been fixed.

Have you tested with newer versions of xf86-video-intel, (and libdrm
and the kernel)? If so, could you please report the latest versions
known to exhibit the bug?

Thanks,

-Carl

Carl: I tested the issue tonight using the development build of Ubuntu 10.04.  Unfortunately, the behavior was the same.  On the first try, my desktop froze within ten seconds of logging in.  On the second try, it lasted about two minutes.  Again, both times, it was only X that froze; I was able to ssh in and pull the log files, which I'm attaching here.

I realize that the Ubuntu 10.04 development kernel (2.6.32) and the Intel video driver that ships with Ubuntu 10.04 are not the most up-to-date (even though they are considerably newer than what was previously tested).  If you have reason to believe that the very latest code would solve the problem, let me know and I'll compile a new kernel along with the latest version of X, etc.

Chris

Created attachment 34337 [details]
Xorg.0.log from Ubuntu 10.04 alpha

Created attachment 34338 [details]
dmesg from Ubuntu 10.04 alpha

Created attachment 34339 [details]
uname -a for Ubuntu 10.04 alpha

(In reply to comment #18)
> Carl: I tested the issue tonight using the development build of Ubuntu 10.04. 
> Unfortunately, the behavior was the same.  On the first try, my desktop froze
> within ten seconds of logging in.  On the second try, it lasted about two
> minutes.  Again, both times, it was only X that froze; I was able to ssh in and
> pull the log files, which I'm attaching here.

Thanks for testing.

> I realize that the Ubuntu 10.04 development kernel (2.6.32) and the Intel video
> driver that ships with Ubuntu 10.04 are not the most up-to-date (even though
> they are considerably newer than what was previously tested).  If you have
> reason to believe that the very latest code would solve the problem, let me
> know and I'll compile a new kernel along with the latest version of X, etc.

There are regular bug fixes, so there definitely are advantages to testing the
latest code. You might be able to take advantage of the "xorg-edgers" repository
of packages that exists specifically to help users of Ubuntu test the latest
drivers, etc. (which might be easier than rebuilding everything from scratch).

I don't know if the xorg-edgers repository has a newer kernel or not, but if you
could run with 2.6.34-rc1 then there's a nice feature of the driver where it will
detect a GPU and save the most recent batch-buffer before the error into

/sys/kernel/debug/dri/0/i915_error_state

This assumes that debugfs is mounted which, if not, you can do with:

sudo mount -t debugfs debugfs /sys/kernel/debug

If you can't run 2.6.34-rc1 then you can try to similarly capture an error-
causing batchbuffer by triggering the error and then running the intel_gpu_dump
tool (from the intel-gpu-tools repository on freedesktop.org---I don't know
if Ubuntu packages it or not).

Let us know if you're able to capture a dump through either of those approaches,
(and please clear the NEEDINFO keyword when you do).

Thanks,

-Carl

@Christopher Tozzi

There is a place for downloading newer kernels built for Ubuntu.

The link is
http://kernel.ubuntu.com/~kernel-ppa/mainline/

open it in your webbrowser, choose v2.6.34-rc1/ and manualy download 

linux-headers-2.6.34-020634rc1
linux-image-2.6.34-020634rc1
(i386 or amd64) depending from your system
and also linux-headers that finishes with "all"

If you downloaded the DEB packages to your Desktop, open console, type:
cd ~/Desktop
dpkg -i lin*.deb

That should install the latest kernel that you've downloaded. Reboot the system and do the testing.

I did some tests with kernel 2.6.35-020635rc1-generic. I've added three attachments:

1. VBIOS dump (/sys/devices/pci0000:00/0000:00:02.0/rom)
2. Register Dump (intel_reg_dump)
3. kern.log (the most interesting - there is a call trace at 10:58:43, I think it could help)

Created attachment 36460 [details]
VBIOS dump

Created attachment 36461 [details]
Register Dump

Created attachment 36462 [details]
kern.log

Compressed with bzip. Too big to be posted as plain text.

Additional test info:

kernel version: 2.6.35-020635rc1-generic
OS: Ubuntu 10.04

xorg-video-intel version: 2:2.9.1-3ubuntu5
libgl1-mesa version: 7.7.1-1ubuntu3
xserver-xorg version: 1:7.5+5ubuntu1

/sys/kernel/debug/dri/0/i915_error_state reported no errors (even with debugfs mounted)

Looking through the dmesg, we see the symptom of the hang in that the i915 kernel worker thread and Xorg are both blocked trying to acquire a mutex. This implies that a third unknown process is currently waiting on the GPU. As the hangcheck has not fired, it implies that the GPU is idle. So is this a case of missing interrupts? In which case the recent gen3 page-flipping patches from Jesse Barnes may be of use.

Created attachment 36463 [details] [review]
Don't queue during flip pending

Created attachment 36464 [details] [review]
i945 page-flipping fixes.

I think this is a i945 page-flipping bug which should have been fixed with 2010Q2 and this pair of patches from 2.6.35-rc5:

commit 1afe3e9d4335bf3bc5615e37243dc8fef65dac8f
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 26 10:35:20 2010 -0700

    drm/i915: gen3 page flipping fixes
    
    Gen3 chips have slightly different flip commands, and also contain a bit
    that indicates whether a "flip pending" interrupt means the flip has
    been queued or has been completed.
    
    So implement support for the gen3 flip command, and make sure we use the
    flip pending interrupt correctly depending on the value of ECOSKPD bit
    0.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

commit 83f7fd055eb3f1e843803cd906179d309553967b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Apr 5 14:03:51 2010 -0700

    drm/i915: don't queue flips during a flip pending event
    
    Hardware will set the flip pending ISR bit as soon as it receives the
    flip instruction, and (supposedly) clear it once the flip completes
    (e.g. at the next vblank).  If we try to send down a flip instruction
    while the ISR bit is set, the hardware can become very confused, and we
    may never receive the corresponding flip pending interrupt, effectively
    hanging the chip.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

On kernel 2.6.35-14.19 (Ubuntu Maverick Alpha 3) the freeze still happening. The bug is not fixed yet.

I can confirm that this is still happening with the latest default installation of Maverick (stable release). Happened to me around 10 times since I installed it on Sunday Oct 10, 2010. syslog shows similar output as bug 23589 (task Xorg:xxxx blocked for more than 120 seconds). 

The interesting thing is that out of my three computers that have G945, this is happening on only one - my desktop. I wonder whether the high resolution (1920x1080) of my desktop is causing this to happen. My other two computers are netbooks that run 1024x600. One runs Karmic and the other was recently upgraded to Maverick. I've not seen this problem even once on those machines in more than a year and a half of use. 

My desktop had similar issues even with older versions of Ubuntu, so I had to use Windows on that machine. Windows ran fine fine on the desktop (without rebooting for months) so this is not due to faulty hardware.

Please let me know if you need more information (and what commands to run to get them), I'll be happy to upload logs, dumps and any other helpful information.

Just an addend: Ubuntu 10.10 (kernel 2.6.35-22) still freezing

And there is a keyword NEEDINFO. What kind of info is needed?

Just to be tested on the current stack rather than the ancient one installed by default on Ubuntu Maverick-. Use ppa:xorg-edgers.

sudo add-apt-repository ppa:xorg-edgers
sudo apt-get update
sudo apt-get upgrade
sudo reboot

The packages have been updated. I restarted my system and activated compiz. Some minutes of use and the freeze happened again.

And it is still a page-flipping freeze? Even on a 2.6.36 or later kernel?

(In reply to comment #38)
> And it is still a page-flipping freeze? Even on a 2.6.36 or later kernel?

I've upgraded my kernel to version 2.6.37-rc2 (downloaded from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc2-maverick/).

In three days of use, no freezes until now. Almost sure that the bug is fixed (because with the bug, in some minutes of use the system was froze).

However, I've realized a noticeable preformance lost in graphics rendering (with compiz effects, or watching FLV videos on web with Flash plugin, or even typing this message - there is a delay for the letters appear).

The slow update rate is likely to be related to https://bugs.freedesktop.org/show_bug.cgi?id=30364 which is another variation on the vblank theme. Do you see anything unusual in dmesg?

(In reply to comment #40)
> The slow update rate is likely to be related to
> https://bugs.freedesktop.org/show_bug.cgi?id=30364 which is another variation
> on the vblank theme. Do you see anything unusual in dmesg?

Yep.

[12532.332021] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.

The message above repeats a lot of times.

Ah, in which case we haven't solved the root cause of why those interrupts fail to fire, but the workaround at least prevents the system freeze. :|

*** Bug 26016 has been marked as a duplicate of this bug. ***

The hardware seems to have an issue with generating vblank interrupts whilst in deep C-states. This should be mitigated by:


commit b0b544cd37c060e261afb2cf486296983fcb56da
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jan 9 12:04:40 2011 +0000

    drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU
    
    945 class hardware has an interesting quirk in which the vblank
    interrupt is not raised if the CPU is in a low power state. (We also
    suspect that the memory bus is clocked to the CPU/c-state and not the
    GPU so there are secondary starvation issues.) In order to prevent the
    most obvious issue of the low of the vblank interrupt (stuttering
    compositing that only updates when the mouse is moving) is to install a
    PM QoS request to prevent low c-states whilst the GPU is active.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

As we could not find a true hardware fix, we had to resort to the PM workaround to prevent the chip from descending into a slumber from which it would not wake...