[arrandale] deadlock in i915_gem_madvise_ioctl

[Dagfinn Ilmari Mannsåker]

Binary package hint: xserver-xorg-video-intel

Occasionally X hangs completely, not even SAK will kill it, however SAK followed by ctrl-alt-del successfully switches to the shutdown splash.

When this happens, the following shows up in dmesg:

[ 5169.457964] INFO: task i915:302 blocked for more than 120 seconds.
[ 5169.457970] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5169.457974] i915 D 00000000ffffffff 0 302 2 0x00000000
[ 5169.457981] ffff88022e0d9d20 0000000000000046 0000000000015bc0 0000000000015bc0
[ 5169.457988] ffff88022f791ab0 ffff88022e0d9fd8 0000000000015bc0 ffff88022f7916f0
[ 5169.457994] 0000000000015bc0 ffff88022e0d9fd8 0000000000015bc0 ffff88022f791ab0
[ 5169.458000] Call Trace:
[ 5169.458015] [<ffffffff8153f867>] __mutex_lock_slowpath+0xe7/0x170
[ 5169.458021] [<ffffffff8153f75b>] mutex_lock+0x2b/0x50
[ 5169.458063] [<ffffffffa00d5550>] intel_idle_update+0x60/0x1d0 [i915]
[ 5169.458085] [<ffffffffa00d54f0>] ? intel_idle_update+0x0/0x1d0 [i915]
[ 5169.458095] [<ffffffff81080777>] run_workqueue+0xc7/0x1a0
[ 5169.458101] [<ffffffff810808f3>] worker_thread+0xa3/0x110
[ 5169.458107] [<ffffffff81085320>] ? autoremove_wake_function+0x0/0x40
[ 5169.458113] [<ffffffff81080850>] ? worker_thread+0x0/0x110
[ 5169.458117] [<ffffffff81084fa6>] kthread+0x96/0xa0
[ 5169.458124] [<ffffffff810141ea>] child_rip+0xa/0x20
[ 5169.458129] [<ffffffff81084f10>] ? kthread+0x0/0xa0
[ 5169.458133] [<ffffffff810141e0>] ? child_rip+0x0/0x20
[ 5169.458154] INFO: task Xorg:1364 blocked for more than 120 seconds.
[ 5169.458157] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5169.458160] Xorg D 0000000000000000 0 1364 1263 0x00400004
[ 5169.458166] ffff88020bd13ca8 0000000000000082 0000000000015bc0 0000000000015bc0
[ 5169.458172] ffff880208c74890 ffff88020bd13fd8 0000000000015bc0 ffff880208c744d0
[ 5169.458177] 0000000000015bc0 ffff88020bd13fd8 0000000000015bc0 ffff880208c74890
[ 5169.458183] Call Trace:
[ 5169.458189] [<ffffffff8153f867>] __mutex_lock_slowpath+0xe7/0x170
[ 5169.458195] [<ffffffff8153f75b>] mutex_lock+0x2b/0x50
[ 5169.458214] [<ffffffffa00c3435>] i915_gem_madvise_ioctl+0x55/0x160 [i915]
[ 5169.458231] [<ffffffffa006de2a>] drm_ioctl+0x27a/0x480 [drm]
[ 5169.458250] [<ffffffffa00c33e0>] ? i915_gem_madvise_ioctl+0x0/0x160 [i915]
[ 5169.458256] [<ffffffff81085320>] ? autoremove_wake_function+0x0/0x40
[ 5169.458264] [<ffffffff81152a92>] vfs_ioctl+0x22/0xa0
[ 5169.458269] [<ffffffff81152d41>] do_vfs_ioctl+0x81/0x380
[ 5169.458274] [<ffffffff811431df>] ? vfs_read+0x12f/0x1a0
[ 5169.458279] [<ffffffff811530c1>] sys_ioctl+0x81/0xa0
[ 5169.458286] [<ffffffff810131b2>] system_call_fastpath+0x16/0x1b

[Dagfinn Ilmari Mannsåker (ilmari)]

ilmari@nurket:~/x-hang$ dpkg -l linux-image-$(uname -r) xserver-xorg-core xserver-xorg-video-intel
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=============================-=============================-==========================================================================
ii linux-image-2.6.32-21-generic 2.6.32-21.32 Linux kernel image for version 2.6.32 on x86/x86_64
ii xserver-xorg-core 2:1.7.6-2ubuntu5 Xorg X server - core server
ii xserver-xorg-video-intel 2:2.9.1-3ubuntu4 X.Org X server -- Intel i8xx, i9xx display driver

[Dagfinn Ilmari Mannsåker (ilmari)]

Further information: the machine is a Lenovo Thinkpad x201s with a Core i7 L-620 CPU and integrated graphics. lspci and dmidecode output attached.

[Dagfinn Ilmari Mannsåker (ilmari)]

It just occurred gain, this time with a different backtrace:

[ 4350.545525] INFO: task i915:308 blocked for more than 120 seconds.
[ 4350.545529] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4350.545533] i915 D 00000000ffffffff 0 308 2 0x00000000
[ 4350.545539] ffff88022e105d40 0000000000000046 0000000000015bc0 0000000000015bc0
[ 4350.545545] ffff88022f595f80 ffff88022e105fd8 0000000000015bc0 ffff88022f595bc0
[ 4350.545550] 0000000000015bc0 ffff88022e105fd8 0000000000015bc0 ffff88022f595f80
[ 4350.545555] Call Trace:
[ 4350.545568] [<ffffffff8153f897>] __mutex_lock_slowpath+0xe7/0x170
[ 4350.545576] [<ffffffff81058620>] ? finish_task_switch+0x50/0xe0
[ 4350.545580] [<ffffffff8153f78b>] mutex_lock+0x2b/0x50
[ 4350.545617] [<ffffffffa00c337d>] i915_gem_retire_work_handler+0x3d/0xa0 [i915]
[ 4350.545635] [<ffffffffa00c3340>] ? i915_gem_retire_work_handler+0x0/0xa0 [i915]
[ 4350.545643] [<ffffffff81080777>] run_workqueue+0xc7/0x1a0
[ 4350.545647] [<ffffffff810808f3>] worker_thread+0xa3/0x110
[ 4350.545653] [<ffffffff81085320>] ? autoremove_wake_function+0x0/0x40
[ 4350.545657] [<ffffffff81080850>] ? worker_thread+0x0/0x110
[ 4350.545661] [<ffffffff81084fa6>] kthread+0x96/0xa0
[ 4350.545667] [<ffffffff810141ea>] child_rip+0xa/0x20
[ 4350.545671] [<ffffffff81084f10>] ? kthread+0x0/0xa0
[ 4350.545674] [<ffffffff810141e0>] ? child_rip+0x0/0x20
[ 4350.545694] INFO: task Xorg:1316 blocked for more than 120 seconds.
[ 4350.545696] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4350.545699] Xorg D 0000000000000000 0 1316 1235 0x00400004
[ 4350.545703] ffff88020c4a7cb8 0000000000000086 0000000000015bc0 0000000000015bc0
[ 4350.545708] ffff88020c411ab0 ffff88020c4a7fd8 0000000000015bc0 ffff88020c4116f0
[ 4350.545713] 0000000000015bc0 ffff88020c4a7fd8 0000000000015bc0 ffff88020c411ab0
[ 4350.545717] Call Trace:
[ 4350.545722] [<ffffffff8153f897>] __mutex_lock_slowpath+0xe7/0x170
[ 4350.545726] [<ffffffff8153f78b>] mutex_lock+0x2b/0x50
[ 4350.545742] [<ffffffffa00c2e36>] i915_gem_busy_ioctl+0x46/0xd0 [i915]
[ 4350.545757] [<ffffffffa002de2a>] drm_ioctl+0x27a/0x480 [drm]
[ 4350.545771] [<ffffffffa00c2df0>] ? i915_gem_busy_ioctl+0x0/0xd0 [i915]
[ 4350.545776] [<ffffffff81088432>] ? enqueue_hrtimer+0x82/0xd0
[ 4350.545782] [<ffffffff810893b9>] ? __hrtimer_start_range_ns+0x189/0x400
[ 4350.545788] [<ffffffff81152a92>] vfs_ioctl+0x22/0xa0
[ 4350.545793] [<ffffffff81152d41>] do_vfs_ioctl+0x81/0x380
[ 4350.545797] [<ffffffff811530c1>] sys_ioctl+0x81/0xa0
[ 4350.545802] [<ffffffff810131b2>] system_call_fastpath+0x16/0x1b

Full dmesg attached.

[Dagfinn Ilmari Mannsåker (ilmari)]

Managed to trigger it with a lock debugging kernel, attached is output of blocked tasks and locks held when it happens.

[Tony Kernan (ackernan)]

I have same traces on a Dell Inspiron. When I close th lid on my laptop and reopen it my screen is blank and nothing short of a reboot works. I disabled all screensavers and just have a blank screen. I did a fresh install of Xubuntu 10.04 64-bit, using 2.6.32-22 kernel.

[Mubes (dave-marples)]

I seem to be having this problem on a Lenovo X201 with i5-540, Lucid 64 bit.

I swapped over to Xorg from deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu but that doesn't seem to be helping. As with the original bug report it seems to be frequent with high video activity. Last week I had it continuously while doing a mirrored video arrangement with projector - so much that the machine was unusable. Don't have access to the PJ at the moment but will post an update when I can get it again - if it's quickly and easily reproducible I guess it'll make it easier to find/fix the culprit.

DAVE

[Chris Halse Rogers (raof)]

I'm forwarding this bug from an Ubuntu reporter:
https://bugs.edge.launchpad.net/bugs/568138

[Problem]
Reporter gets occasional X freezes with no obvious trigger. The system remains responsive to SSH. Attempting to restart X fails.

There are no errors recorded in Xorg.0.log when these freezes occur, but dmesg contains hung task backtraces ending in __mutex_lock_slowpath.

Reporter is using libdrm 2.4.18, drm 2.6.33 and xf86-video-intel 2.9.1.
I have also experienced freezes with the same dmesg backtrace using libdrm 2.4.20, drm 2.6.35-rc3 and xf86-video-intel 2.11.0 on a GM45 card.

[lspci]
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)

Xorg.0.log: http://launchpadlibrarian.net/44988804/Xorg.0.log
Example dmesg outputs containing blocked task backtrace:
http://launchpadlibrarian.net/45481306/dmesg
http://launchpadlibrarian.net/44988795/dmesg
Blocked task & held locks output from lock-debugging kernel: http://launchpadlibrarian.net/47665797/locks.txt
intel_gpu_dump output: http://launchpadlibrarian.net/44988870/gpudump

[Original report]
Occasionally X hangs completely, not even SAK will kill it, however SAK followed by ctrl-alt-del successfully switches to the shutdown splash.

When this happens, the following shows up in dmesg:

[ 5169.457964] INFO: task i915:302 blocked for more than 120 seconds.
[ 5169.457970] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5169.457974] i915 D 00000000ffffffff 0 302 2 0x00000000
[ 5169.457981] ffff88022e0d9d20 0000000000000046 0000000000015bc0 0000000000015bc0
[ 5169.457988] ffff88022f791ab0 ffff88022e0d9fd8 0000000000015bc0 ffff88022f7916f0
[ 5169.457994] 0000000000015bc0 ffff88022e0d9fd8 0000000000015bc0 ffff88022f791ab0
[ 5169.458000] Call Trace:
[ 5169.458015] [<ffffffff8153f867>] __mutex_lock_slowpath+0xe7/0x170
[ 5169.458021] [<ffffffff8153f75b>] mutex_lock+0x2b/0x50
[ 5169.458063] [<ffffffffa00d5550>] intel_idle_update+0x60/0x1d0 [i915]
[ 5169.458085] [<ffffffffa00d54f0>] ? intel_idle_update+0x0/0x1d0 [i915]
[ 5169.458095] [<ffffffff81080777>] run_workqueue+0xc7/0x1a0
[ 5169.458101] [<ffffffff810808f3>] worker_thread+0xa3/0x110
[ 5169.458107] [<ffffffff81085320>] ? autoremove_wake_function+0x0/0x40
[ 5169.458113] [<ffffffff81080850>] ? worker_thread+0x0/0x110
[ 5169.458117] [<ffffffff81084fa6>] kthread+0x96/0xa0
[ 5169.458124] [<ffffffff810141ea>] child_rip+0xa/0x20
[ 5169.458129] [<ffffffff81084f10>] ? kthread+0x0/0xa0
[ 5169.458133] [<ffffffff810141e0>] ? child_rip+0x0/0x20
[ 5169.458154] INFO: task Xorg:1364 blocked for more than 120 seconds.
[ 5169.458157] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5169.458160] Xorg D 0000000000000000 0 1364 1263 0x00400004
[ 5169.458166] ffff88020bd13ca8 0000000000000082 0000000000015bc0 0000000000015bc0
[ 5169.458172] ffff880208c74890 ffff88020bd13fd8 0000000000015bc0 ffff880208c744d0
[ 5169.458177] 0000000000015bc0 ffff88020bd13fd8 0000000000015bc0 ffff880208c74890
[ 5169.458183] Call Trace:
[ 5169.458189] [<ffffffff8153f867>] __mutex_lock_slowpath+0xe7/0x170
[ 5169.458195] [<ffffffff8153f75b>] mutex_lock+0x2b/0x50
[ 5169.458214] [<f...

[Chris Halse Rogers (raof)]

I also see this same deadlock infrequently on my GM45 x200s which has a significantly different graphics chip, so might not be the same problem.

I'll forward this upstream.

[Chris Halse Rogers (raof)]

I've forwarded this bug upstream. You should subscribe to https://bugs.freedesktop.org/show_bug.cgi?id=28805 as upstream may wish to get more debugging information.

[Chris Wilson (ickle)]

I believe this is the relevant commit:

commit e552eb7038a36d9b18860f525aa02875e313fe16
Author: Jesse Barnes <email address hidden>
Date: Wed Apr 21 11:39:23 2010 -0700

    drm/i915: use PIPE_CONTROL instruction on Ironlake and Sandy Bridge

    Since 965, the hardware has supported the PIPE_CONTROL command, which
    provides fine grained GPU cache flushing control. On recent chipsets,
    this instruction is required for reliable interrupt and sequence number
    reporting in the driver.

    So add support for this instruction, including workarounds, on Ironlake
    and Sandy Bridge hardware.

    https://bugs.freedesktop.org/show_bug.cgi?id=27108

    Signed-off-by: Jesse Barnes <email address hidden>
    Tested-by: Chris Wilson <email address hidden>
    Signed-off-by: Eric Anholt <email address hidden>

[Daniel J Blueman (danielblueman)]

I have been experiencing this issue on 2.6.35-rc3 when a bunch of kernel debug options are enabled - let me know if you'd like the .config (tuned for an Intel desktop board). It reproduces reliably usually within an hour of activity and we get a similar signature [1] to other reports.

Commit e552eb7038a36d9b18860f525aa02875e313fe16 doesn't seem to address the issue, as this commit was introduced in 2.6.34.

--- [1]

INFO: task i915:774 blocked for more than 120 seconds.

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

i915 D ffff88010f0ba610 6280 774 2 0x00000000

 ffff88010f22dcb0 0000000000000086 ffff88010e742a00 ffff88010f0ba610

 ffff88010f22dfd8 00000000001d4440 ffff88010f22dfd8 ffff88010f0ba610

 00000000001d4440 00000000001d4440 ffff88010f22dfd8 00000000001d4440

Call Trace:

 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220

 [<ffffffff816425fa>] mutex_lock_nested+0x1ea/0x4c0

 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220

 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220

 [<ffffffff81644d03>] ? _raw_spin_unlock_irqrestore+0x53/0xa0

 [<ffffffff813a4170>] ? intel_idle_update+0x0/0x220

 [<ffffffff813a41ba>] intel_idle_update+0x4a/0x220

 [<ffffffff813a4170>] ? intel_idle_update+0x0/0x220

 [<ffffffff81069b20>] worker_thread+0x220/0x390

 [<ffffffff81069ace>] ? worker_thread+0x1ce/0x390

 [<ffffffff8108475d>] ? trace_hardirqs_on+0xd/0x10

 [<ffffffff8106eb70>] ? autoremove_wake_function+0x0/0x40

 [<ffffffff81069900>] ? worker_thread+0x0/0x390

 [<ffffffff8106e65e>] kthread+0xae/0xc0

 [<ffffffff81004024>] kernel_thread_helper+0x4/0x10

 [<ffffffff81645114>] ? restore_args+0x0/0x30

 [<ffffffff8106e5b0>] ? kthread+0x0/0xc0

 [<ffffffff81004020>] ? kernel_thread_helper+0x0/0x10

INFO: lockdep is turned off.

INFO: task Xorg:2004 blocked for more than 120 seconds.

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Xorg D ffffffff8180a360 4608 2004 1936 0x00400004

 ffff8801112d5c58 0000000000000086 ffff8801112d5bd8 ffffffffffffffff

 ffff8801112d5fd8 00000000001d4440 ffff8801112d5fd8 ffff8801078f0000

 00000000001d4440 00000000001d4440 ffff8801112d5fd8 00000000001d4440

Call Trace:

 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90

 [<ffffffff816425fa>] mutex_lock_nested+0x1ea/0x4c0

 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90

 [<ffffffff814f27f5>] ? sock_aio_write+0x125/0x140

 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90

 [<ffffffff813958fb>] i915_gem_throttle_ioctl+0x3b/0x90

 [<ffffffff8137734a>] drm_ioctl+0x33a/0x4c0

 [<ffffffff812d3d9c>] ? debug_object_deactivate+0x5c/0x110

 [<ffffffff812d333c>] ? do_raw_spin_unlock+0x6c/0xc0

 [<ffffffff8108280d>] ? trace_hardirqs_off+0xd/0x10

 [<ffffffff81644d03>] ? _raw_spin_unlock_irqrestore+0x53/0xa0

 [<ffffffff812d3deb>] ? debug_object_deactivate+0xab/0x110

 [<ffffffff81072ffc>] ? lock_hrtimer_base+0x2c/0x60

 [<ffffffff8112eff8>] vfs_ioctl+0x38/0xd0

 [<ffffffff8112f1ca>] do_vfs_ioctl+0x8a/0x5b0

 [<ffffffff81058dbc>] ? do_setitimer+0x1cc/0x1f0

 [<ffffffff810e8d72>] ? might_fault+0x72/0xd0

 [<ffffffff8112f73a>] sys_ioctl+0x4a/0x80

 [<ffffffff812d3d9c>]...

[Daniel J Blueman (danielblueman)]

I have been experiencing this issue on 2.6.35-rc3 when a bunch of kernel debug options are enabled - let me know if you'd like the .config (tuned for an Intel desktop board). It reproduces reliably usually within an hour of activity and we get a similar signature [1] to other reports.

Commit e552eb7038a36d9b18860f525aa02875e313fe16 doesn't seem to address the issue, as this commit was introduced in 2.6.34.

I have updated the fd.o bugzilla entry also.

--- [1]

INFO: task i915:774 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

i915 D ffff88010f0ba610 6280 774 2 0x00000000
 ffff88010f22dcb0 0000000000000086 ffff88010e742a00 ffff88010f0ba610
 ffff88010f22dfd8 00000000001d4440 ffff88010f22dfd8 ffff88010f0ba610
 00000000001d4440 00000000001d4440 ffff88010f22dfd8 00000000001d4440

Call Trace:
 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220
 [<ffffffff816425fa>] mutex_lock_nested+0x1ea/0x4c0
 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220
 [<ffffffff813a41ba>] ? intel_idle_update+0x4a/0x220
 [<ffffffff81644d03>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
 [<ffffffff813a4170>] ? intel_idle_update+0x0/0x220
 [<ffffffff813a41ba>] intel_idle_update+0x4a/0x220
 [<ffffffff813a4170>] ? intel_idle_update+0x0/0x220
 [<ffffffff81069b20>] worker_thread+0x220/0x390
 [<ffffffff81069ace>] ? worker_thread+0x1ce/0x390
 [<ffffffff8108475d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff8106eb70>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81069900>] ? worker_thread+0x0/0x390
 [<ffffffff8106e65e>] kthread+0xae/0xc0
 [<ffffffff81004024>] kernel_thread_helper+0x4/0x10
 [<ffffffff81645114>] ? restore_args+0x0/0x30
 [<ffffffff8106e5b0>] ? kthread+0x0/0xc0
 [<ffffffff81004020>] ? kernel_thread_helper+0x0/0x10

INFO: lockdep is turned off.
INFO: task Xorg:2004 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Xorg D ffffffff8180a360 4608 2004 1936 0x00400004
 ffff8801112d5c58 0000000000000086 ffff8801112d5bd8 ffffffffffffffff
 ffff8801112d5fd8 00000000001d4440 ffff8801112d5fd8 ffff8801078f0000
 00000000001d4440 00000000001d4440 ffff8801112d5fd8 00000000001d4440

Call Trace:
 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90
 [<ffffffff816425fa>] mutex_lock_nested+0x1ea/0x4c0
 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90
 [<ffffffff814f27f5>] ? sock_aio_write+0x125/0x140
 [<ffffffff813958fb>] ? i915_gem_throttle_ioctl+0x3b/0x90
 [<ffffffff813958fb>] i915_gem_throttle_ioctl+0x3b/0x90
 [<ffffffff8137734a>] drm_ioctl+0x33a/0x4c0
 [<ffffffff812d3d9c>] ? debug_object_deactivate+0x5c/0x110
 [<ffffffff812d333c>] ? do_raw_spin_unlock+0x6c/0xc0
 [<ffffffff8108280d>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff81644d03>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
 [<ffffffff812d3deb>] ? debug_object_deactivate+0xab/0x110
 [<ffffffff81072ffc>] ? lock_hrtimer_base+0x2c/0x60
 [<ffffffff8112eff8>] vfs_ioctl+0x38/0xd0
 [<ffffffff8112f1ca>] do_vfs_ioctl+0x8a/0x5b0
 [<ffffffff81058dbc>] ? do_setitimer+0x1cc/0x1f0
 [<ffffffff810e8d72>] ? might_fault+0x72/0xd0
 [<ffffffff8112f73a>] sys_ioctl+0x4a/0x80
 [<ffffffff812d3d9c>]...

[Chris Wilson (ickle)]

Can you confirm that is waiting on a request and not stuck polling registers? i.e. cpu time is 0%.

Can you also get the full stack traces of all processes so we can see which one is holding the mutex.

The contents of /sys/kernel/debug/dri/0/ (in particular the interrupts and requests) will be useful as would an intel_reg_dumper.

[Chris Wilson (ickle)]

The 6 pipe-control flushes [actually repeated dword stores] are what the docs suggest as the work-around for fun hardware. Can you confirm if you are indeed still seeing this on 2.6.35? And if so give me the info I requested. Thanks.

[Chris Wilson (ickle)]

Still not sure what the cause actually is, but 2.6.36-rc3 contains a patch that will break any waits on a missed interrupt.

[Pieter L. (pieterlangendonck)]

Hello,

I think I have exactly the same problem. The logfile is really similar.
At a certain moment my X hangs, I can do a ssh shell and login and reboot my machine.

I think this problem might be caused because the GPU gets to warm.

I have had this problem 3 times now, yesterday I got it after only 10 minutes working with my system or so... So it is really become a serious problem for me!

I'm using Ubuntu 10.04.1 LTS. Kernel: 2.6.32-24-generic.
I have a D945GSEJT board (ATOM N270, 945G intel onboard graphics).
This board does not have a FAN, it is cooled passively.

I have had many troubles with my first board which at a certain moment did not work at all anymore. So I had to send it back and I got a replacement but I think this is a repaired board.
I now have again a problem. This one.

Can this problem be caused because the GPU gets to warm because it is not sufficiently cooled?

One other thing:
It this problem really fixed already?
What do I need to do to get the fix? And is the cause clear? I mean is it fixed as a workaround or was it really a bug...

Please let me know.
I found this page, by googling on the error that I have...

Thanks,
Pieter Langendonck

[Chris Wilson (ickle)]

We are fairly confident that we have this fixed, so I am marking the report fixed. If the new hangcheck fires or if the machine is still freezing on 2.6.36, then please re-open.

Pietr, you have a separate bug; google is mistaken. Unlikely to be overheating since the Atom has such a low TDP that passive cooling should be sufficient, if it was it should be throwing up more errors [MCE] than just hangs.

[Timo Aaltonen (tjaalton)]

this should be fixed in 2.6.36 and later.

[Brent Rickels (brent-k)]

Hello Customer

We found a way out for you - now you can pay for as many watches as a lot of style changes you have.
Now you do not have to choose between your wife is and your wallet is happiness!

********************************************
EXCELLENT TRANSACTION.....Pleasure to do business with....Prompt and courteous. Buy with confidence from this company...Beautiful timepiece!!
Thank you very much
                     Brad Singer
********************************************

Click here ---> http://dodor.ru