Bug 25091

Summary: 845G: Graphics on new 9.10 install appears to freeze consistently after about 20 mins, except for mouse pointer
Product: xorg Reporter: David M. Karr <davidmichaelkarr>
Component: Driver/intelAssignee: Carl Worth <cworth>
Status: RESOLVED DUPLICATE QA Contact: Xorg Project Team <xorg-team>
Severity: blocker    
Priority: medium CC: andrej, moikkis
Version: unspecifiedKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Output from dmesg
none
Output from xrandr --verbose
none
xorg.log
none
lspci verbose
none
intel_gpu_dump file none

Description David M. Karr 2009-11-14 11:24:08 UTC 
Created attachment 31202 [details]
Output from dmesg

System environment:
-- chipset: 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
-- system architecture: 32-bit
-- xf86-video-intel:
-- xserver: 1.6.4-2ubuntu4
-- mesa: NA
-- libdrm: NA
-- kernel: 2.6.31-14-generic
-- Linux distribution: Ubuntu 9.10 Karmic Koala
-- Machine or mobo model: Dell
-- Display connector:

My new 9.10 installation (intel graphics) is freezing, requiring reboot, after about 20 minutes, every single time. Only the mouse pointer moves when it freezes, nothing else responds. I've tried installing the latest xorg PPA and driver. I investigated turning on kernel modesetting. I'm about to give up on this, perhaps replacing the intel graphics card with an nvidia card, but I don't know what else to try.

When I come back to the computer after leaving it for a while, the screen is either black or fully displayed. When it's black nothing responds at all, but when it's not black, I can move the mouse pointer, but that's all.  Nothing else responds.  This is extremely consistent.  The only time I came back to it later and it was still alive was when I ran XChat running in the #ubuntu channel, which was continually displaying throughout the time it was running.  I don't know whether that's relevant.

I tried looking in several system log files.  In "kern.log", I noticed this:
-------------------
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752046] INFO: task i915/0:227 blocked for more than 120 seconds.
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752054] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752059] i915/0 D c08145c0 0 227 2 0x00000000
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752068] f6a61f04 00000046 f6a40cbc c08145c0 f6a40f28 c08145c0 7af12304 00000125
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752080] c08145c0 c08145c0 f6a40f28 c08145c0 7af100e8 00000125 c08145c0 f5f0e000
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752090] f6a40c90 f6872c14 f6872c18 ffffffff f6a61f30 c056f776 c0748e80 f6872c1c
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752101] Call Trace:
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752119] [<c056f776>] __mutex_lock_slowpath+0xc6/0x130
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752125] [<c056f690>] mutex_lock+0x20/0x40
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752171] [<f822bc0a>] i915_gem_retire_work_handler+0x2a/0x70 [i915]
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752184] [<c0157a7e>] run_workqueue+0x6e/0x140
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752207] [<f822bbe0>] ? i915_gem_retire_work_handler+0x0/0x70 [i915]
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752216] [<c0157bd8>] worker_thread+0x88/0xe0
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752225] [<c015c280>] ? autoremove_wake_function+0x0/0x40
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752231] [<c0157b50>] ? worker_thread+0x0/0xe0
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752237] [<c015bf8c>] kthread+0x7c/0x90
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752243] [<c015bf10>] ? kthread+0x0/0x90
Nov 14 00:13:09 davidkarr-desktop kernel: [ 2520.752251] [<c0104007>] kernel_thread_helper+0x7/0x10
----------------------

I also noticed in "daemon.log", there were events like this, all through the night, right up to when I found it apparently dead in the morning.

Nov 14 03:14:55 davidkarr-desktop wpa_supplicant[898]: CTRL-EVENT-SCAN-RESULTS 

So this seems to show that the system wasn't dead, just unresponsive.

I'll attach several files that might be relevant, according to <http://intellinuxgraphics.org/how_to_report_bug.html>.
Comment 1 David M. Karr 2009-11-14 11:25:03 UTC 
Created attachment 31203 [details]
Output from xrandr --verbose
Comment 2 David M. Karr 2009-11-14 11:26:19 UTC 
Created attachment 31204 [details]
xorg.log
Comment 3 David M. Karr 2009-11-14 11:27:45 UTC 
When I next find it frozen, right after I reboot, would it be useful to attach the output from "intel_gpu_dump"?
Comment 4 David M. Karr 2009-11-14 12:41:52 UTC 
Well, curiously, after I saw the screen had blanked and was frozen (no response), I then cycled power, then logged in, and then ran "intel_gpu_dump > intel_gpu_dump.txt".  Two seconds after pressing enter, the display was entirely frozen, including the mouse pointer.  I cycled power after waiting for it to do something for 20 minutes.  The output file was empty after I rebooted again.
Comment 5 Elmo R 2009-12-29 11:12:40 UTC 
Created attachment 32356 [details]
lspci verbose
Comment 6 Elmo R 2009-12-29 11:15:34 UTC 
Created attachment 32358 [details]
intel_gpu_dump file
Comment 7 Chris Wilson 2010-03-02 10:06:51 UTC 
It looks like the gpu dump in c6 contains illegal floating point values in the vertex data - which suggests a driver older than

commit 2cc1f3cb6034dddd65b3781b0cde7dff4ac1e803
Author: Keith Packard <keithp@keithp.com>
Date:   Sat Sep 19 17:30:57 2009 -0700

    i8xx: Format projective texture coordinates correctly.

But there is nothing that suggests a connection between that comment and the original bug report. There is no information here to identify which of the many fixed i8xx bugs this might be, or if it is the remaining CPU/GPU coherency issue.
Comment 8 Chris Wilson 2010-03-29 03:17:16 UTC 
Actually the currently executing instruction is not contained within that batch buffer. It is most likely to be the i845 GTT incoherency - or rather since that bug is so prevalent it tends to crash the GPU before any other bug can manifest...

*** This bug has been marked as a duplicate of bug 26345 ***

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.