xorg deadlocked after screen fades to black

I don't think this is a dupe of #390917 because the "sudo xset dpms force off" method does not reproduce this bug for me.

> Please don't set this to incomplete on the basis of a missing /etc/motd ... as I said apport-cli hangs.

Setting to incomplete since we really want the output of `lscpi -vvnn` (to get the numerical PCI IDs), but once we have that we can set it to Confirmed ;-)

Attached.

Why are you changing all my tags from "GM965" to "965GM"? Intel has never made a part called the 965GM.

http://www.intel.com/products/notebook/chipsets/gm965/gm965-overview.htm

On Sun, Jul 5, 2009 at 6:37 PM, Jeffrey Baker wrote:
> Why are you changing all my tags from "GM965" to "965GM"?  Intel has
> never made a part called the 965GM.

The main reason is consistency. Tags are useful because bug reports
with a similar property gets the same tag. In this case, there are
several other bug reports with the 965gm tag and none with gm965, and
it is nice to click on the 965gm tag and get a list of currently open
bugs reported on 965GM. The idea would be to see which tags are used,
and use them instaed of inventing new and similar ones [1].

But I agree that it is a bit confusing which tag to use for a given
chipset. I "standardized" on 965gm more than half a year ago when
there were a few bug reports with each (and similar for other
chipsets). The main reason for using 965gm is that this is what the
chipset is called in the intel driver. In Xorg.0.log you will see the
line
(--) intel(0): Chipset: "965GM"
and when I was cleaning up the tag structure half a year ago I found
that it was most consistent to use this line as a tag name where
possible (some of those are too long or have invalid tag characters).
The list of what can end up on this line can be found in the source
code: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/i830_driver.c
. The currently used tags for X are listed at
https://wiki.ubuntu.com/X/Tagging . Grepping for GM965 in the source
code gives no hits. I have no idea why it is this way, but I think it
is easier to use what the log files say than what it says on the
package.

[1]: When I started to standardize the tags, the list of bugs would
show all tags used for a package along with the number of bug reports
with that tag. While this was problematic since the list would be a
mile long when the list was for all ubuntu bugs, it was very useful as
a suggestion for what tags to put on a bug report.

Hi Jeffrey, upstream believes this bug is solved upstream but needs your confirmation against their upstream code. We provide a PPA called xorg-edgers which includes packages of their code, to make it easier for you to test. Would you mind installing the -intel driver from xorg-edgers and confirming that it does indeed fix it? If you can confirm that, then I can backport the specific fixes to Karmic.

https://edge.launchpad.net/~xorg-edgers/+archive/ppa

Will definitely check it out, but it might take me a few days to get to it. Thanks for the notice.

My fade-to-black issues was fixed by these improvements, thanks.

But I have a similar problem without the black. Screen frozen and no response from any keyboard or mouse activity. ssh still active and the tasks that were not tied to screen activity are still chugging along fine.

/var/log/syslog has:

Nov 17 15:35:46 user-desktop kernel: [27120.768086] INFO: task i915/0:260 blocked for more than 120 seconds.
Nov 17 15:35:46 user-desktop kernel: [27120.768094] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 17 15:35:46 user-desktop kernel: [27120.768099] i915/0 D c08145c0 0 260 2 0x00000000
Nov 17 15:35:46 user-desktop kernel: [27120.768109] efb1ff04 00000046 e64fa000 c08145c0 efabe718 c08145c0 2d77d24b 00001782
Nov 17 15:35:46 user-desktop kernel: [27120.768122] c08145c0 c08145c0 efabe718 c08145c0 00000000 00001782 c08145c0 e8732400
Nov 17 15:35:46 user-desktop kernel: [27120.768134] efabe480 ef893814 ef893818 ffffffff efb1ff30 c056f776 c0748e80 ef89381c
Nov 17 15:35:46 user-desktop kernel: [27120.768147] Call Trace:
Nov 17 15:35:46 user-desktop kernel: [27120.768163] [<c056f776>] __mutex_lock_slowpath+0xc6/0x130
Nov 17 15:35:46 user-desktop kernel: [27120.768169] [<c056f690>] mutex_lock+0x20/0x40
Nov 17 15:35:46 user-desktop kernel: [27120.768207] [<f8257c0a>] i915_gem_retire_work_handler+0x2a/0x70 [i915]
Nov 17 15:35:46 user-desktop kernel: [27120.768219] [<c0157a7e>] run_workqueue+0x6e/0x140
Nov 17 15:35:46 user-desktop kernel: [27120.768236] [<f8257be0>] ? i915_gem_retire_work_handler+0x0/0x70 [i915]
Nov 17 15:35:46 user-desktop kernel: [27120.768243] [<c0157bd8>] worker_thread+0x88/0xe0
Nov 17 15:35:46 user-desktop kernel: [27120.768251] [<c015c280>] ? autoremove_wake_function+0x0/0x40
Nov 17 15:35:46 user-desktop kernel: [27120.768257] [<c0157b50>] ? worker_thread+0x0/0xe0
Nov 17 15:35:46 user-desktop kernel: [27120.768263] [<c015bf8c>] kthread+0x7c/0x90
Nov 17 15:35:46 user-desktop kernel: [27120.768269] [<c015bf10>] ? kthread+0x0/0x90
Nov 17 15:35:46 user-desktop kernel: [27120.768276] [<c0104007>] kernel_thread_helper+0x7/0x10

May I provide other diagnostic information to help resolve this issue?