This is a bug report taken from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/445056. If you follow the reports from the link above at least three of the users are having the same problem. The problem is that their desktops freeze as soon as they log in. This is their lspci output: 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) Subsystem: Foxconn International, Inc. Device 0d4b Flags: bus master, fast devsel, latency 0 Capabilities: <access denied> Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) Subsystem: Foxconn International, Inc. Device 0d4b Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fea80000 (32-bit, non-prefetchable) [size=512K] I/O ports at dc00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fea40000 (32-bit, non-prefetchable) [size=256K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 ------------------------------------------------------------------------ 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) Subsystem: Elitegroup Computer Systems Device 2624 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fea80000 (32-bit, non-prefetchable) [size=512K] I/O ports at dc00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fea40000 (32-bit, non-prefetchable) [size=256K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 ------------------------------------------------------------------------- 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) Subsystem: Hewlett-Packard Company Device 2a60 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information <?> Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) Subsystem: Hewlett-Packard Company Device 2a60 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at ffa40000 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 ------------------------------------------------------------------------------ I on the other hand have NO FREEZING PROBLEMS AT ALL! This is my lspci output: 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 3140 Flags: bus master, fast devsel, latency 0 Capabilities: <access denied> Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 3140 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fdf00000 (32-bit, non-prefetchable) [size=512K] I/O ports at ff00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fdf80000 (32-bit, non-prefetchable) [size=256K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 -------------------------------------------------------------------------------- As far as i can tell the only difference is in the "Memory at" and "I/O ports at" portions of lspci. I don't have a clue about drivers or anything but I wonder if this might be of any relevance to the bug.
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...
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.