Xorg hangs in drm_helper_connector_dpms

could you try running 'apport-collect 1097315' to attach debug logs here, something went wrong the first time.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

If I boot into the quantal kernel, I do not see this issue. So thats what I'm doing as a work around for now.
Each time I forget, and reboot into raring, I hang usually within 15 minutes of usage.

It seems that this is likely triggered by desktop switching but thats not really scientific, just feeling.

seen most recently with 3.8.0-0-generic
$ dpkg -S /boot/vmlinuz-$(uname -r)
linux-image-3.8.0-0-generic: /boot/vmlinuz-3.8.0-0-generic

That's an ancient kernel by raring standards :) There's -2 now, try that out.

meaning dist-upgrade, your -intel driver is just as "obsolete"

Strike the above comment about quantal kernels not showing this. I just saw it with 3.7.0-7-generic:

[ 3000.776154] INFO: task Xorg:1758 blocked for more than 120 seconds.
[ 3000.776163] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3000.776168] Xorg D ffff88013bc93e40 0 1758 1679 0x00400000
[ 3000.776178] ffff880132a23ac0 0000000000000002 ffff880130545c00 ffff880132a23fd8
[ 3000.776187] ffff880132a23fd8 ffff880132a23fd8 ffff880135b35c00 ffff880130545c00
[ 3000.776195] ffff88012fe7c000 ffff88013037ee68 ffff88012fe7a800 0000000000000001
[ 3000.776203] Call Trace:
[ 3000.776219] [<ffffffff816a4ee9>] schedule+0x29/0x70
[ 3000.776296] [<ffffffffa00cefe5>] intel_crtc_wait_for_pending_flips+0x75/0xd0 [i915]
[ 3000.776307] [<ffffffff8107c6c0>] ? finish_wait+0x80/0x80
[ 3000.776348] [<ffffffffa00d1647>] i9xx_crtc_disable+0x87/0x180 [i915]
[ 3000.776390] [<ffffffffa00d5ae0>] intel_crtc_disable+0x30/0x120 [i915]
[ 3000.776433] [<ffffffffa00d84cf>] intel_set_mode+0x24f/0x960 [i915]
[ 3000.776450] [<ffffffff8117739d>] ? __kmalloc+0x13d/0x170
[ 3000.776491] [<ffffffffa00d8d31>] ? intel_crtc_set_config+0x151/0x970 [i915]
[ 3000.776533] [<ffffffffa00d9306>] intel_crtc_set_config+0x726/0x970 [i915]
[ 3000.776576] [<ffffffffa004f119>] drm_mode_setcrtc+0x119/0x5a0 [drm]
[ 3000.776585] [<ffffffff816a379d>] ? mutex_lock+0x1d/0x50
[ 3000.776620] [<ffffffffa004b996>] ? drm_mode_object_find+0x66/0x90 [drm]
[ 3000.776652] [<ffffffffa003f553>] drm_ioctl+0x4d3/0x580 [drm]
[ 3000.776689] [<ffffffffa004f000>] ? drm_mode_setplane+0x370/0x370 [drm]
[ 3000.776699] [<ffffffff8119d0c9>] do_vfs_ioctl+0x99/0x590
[ 3000.776706] [<ffffffff8119d651>] sys_ioctl+0x91/0xb0
[ 3000.776714] [<ffffffff816ae75d>] system_call_fastpath+0x1a/0x1f
[ 3120.776190] INFO: task Xorg:1758 blocked for more than 120 seconds.
[ 3120.776199] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3120.776204] Xorg D ffff88013bc93e40 0 1758 1679 0x00400000
[ 3120.776214] ffff880132a23ac0 0000000000000002 ffff880130545c00 ffff880132a23fd8
[ 3120.776223] ffff880132a23fd8 ffff880132a23fd8 ffff880135b35c00 ffff880130545c00
[ 3120.776231] ffff88012fe7c000 ffff88013037ee68 ffff88012fe7a800 0000000000000001
[ 3120.776238] Call Trace:
[ 3120.776255] [<ffffffff816a4ee9>] schedule+0x29/0x70
[ 3120.776333] [<ffffffffa00cefe5>] intel_crtc_wait_for_pending_flips+0x75/0xd0 [i915]
[ 3120.776343] [<ffffffff8107c6c0>] ? finish_wait+0x80/0x80
[ 3120.776385] [<ffffffffa00d1647>] i9xx_crtc_disable+0x87/0x180 [i915]
[ 3120.776427] [<ffffffffa00d5ae0>] intel_crtc_disable+0x30/0x120 [i915]
[ 3120.776470] [<ffffffffa00d84cf>] intel_set_mode+0x24f/0x960 [i915]
[ 3120.776487] [<ffffffff8117739d>] ? __kmalloc+0x13d/0x170
[ 3120.776528] [<ffffffffa00d8d31>] ? intel_crtc_set_config+0x151/0x970 [i915]
[ 3120.776570] [<ffffffffa00d9306>] intel_crtc_set_config+0x726/0x970 [i915]
[ 3120.776612] [<ffffffffa004f119>] drm_mode_setcrtc+0x119/0x5a0 [drm]
[ 3120.776621] [<ffffffff816a379d>] ? mutex_lock+0x1d/0x50
[ 3120.776657] [<ffffffffa004b996>] ? drm_mode_object_find+0x66/0x90 [drm]
[ 3120.776688] [<ffffffffa003f5...

Immediately after it hangs:
 * $ sudo cat /sys/kernel/debug/dri/0/i915_error_state
    no error state collected
 * 'DISPLAY=:0.0 xrandr' seems to work.
   'DISPLAY=:0.0 xrandr --output LVDS1 --auto --output HDMI2 --off' turned off the monitor, but then never returned.
 * 'DISPLAY=:0.0 gnome-terminal' just hangs
 * when screen dims due to idle (which i've set to 2 minutes), keyboard input will brighten the screen again.

then I tried 'sudo stop lightdm', and slept 120 seconds.
Still, no error state in 'i915_error_state'

Then, i tried 'chvt 1', and gave it 120 seconds to return.
at this point 'dmesg' shows the trace, but /i915_error_state still says "no error state collected"

reproduced on drm-intel-nightly kernel at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-01-28-raring/.

$ dpkg -S /boot/vmlinuz-$(uname -r)
linux-image-3.8.0-994-generic: /boot/vmlinuz-3.8.0-994-generic

$ sudo cat /sys/kernel/debug/dri/0/i915_error_state
no error state collected

$ dmesg > dmesg-drm-intel-nightly.txt

Could you try the actual quantal kernel, which is 3.5.0-NN.. Sounds like a regression in 3.7 and up.

You're right. Thank you for noticing the error in my report yesterday. to my knowledge, I've never seen this issue with the quantal kernel. I've only had the problem with 3.5.X. Yesterday when I rebooted, and saw a 3.8.0 and a 3.7.X I didn't think hard and assumed that 3.7 was quantal, forgetting that raring had a 3.7.

Per Timo's request, I've,
 * installed drm-intel-nightly kernel 2013-01-29
 * installed intel-gpu-tools
 * run kms_flip

I'll attach the output, but no kernel traces found.

This change was made by a bot.

I think this is the likely solution here....

The attachment "Wait for pending flips to complete before disabling encoders." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

This bug was fixed in the package linux - 3.8.0-6.13

---------------
linux (3.8.0-6.13) raring; urgency=low

  [Tim Gardner]

  * Release Tracking Bug
    - LP: #1125364
  * Add ahci modules to d-i
    - LP: #1124415

  [ Chris Wilson ]

  * SAUCE: drm/i915: Wait for pending flips to complete before tearing down
    the encoders
    - LP: #1097315
 -- Tim Gardner <email address hidden> Wed, 13 Feb 2013 12:16:48 -0700

Unfortunately I am still able to trigger freezes after having installed linux 3.8.0-6.13. (I come from bug 1048230 which was marked as a duplicate of this one.)

Darn. And not just gen4 affected. Back to the drawing board for ideas.

I saw this bug again using:
$ dpkg-query --show linux-image-3.8.0-6-generic
linux-image-3.8.0-6-generic 3.8.0-6.13
$ dpkg-query --show xserver-xorg-video-intel
xserver-xorg-video-intel 2:2.21.2-0ubuntu1

I'm in a much worse state now, though, as booting into the 3.5.0-21-generic kernel that used to allow me to actually use my system now
 * wont boot (caps lock key flashes) by default
 * boots, but doesn't see second monitor if I use 'nomodeset' kernel cmdlinle parameter, and X has issues (doesn't re-pait under where the autohided panel is).

I'm sure there are now some other bugs here. This is quite possibly the first time I've rebooted and/or restated X since 2012-02-11 when I apt's log says: xserver-xorg-video-intel:amd64 (2.21.0-0ubuntu1, 2.21.2-0ubuntu1).

To remedy the above (comment 42), I did:
 * install the 2.21.0-0ubuntu1 xserver-xorg-video-intel from [1]
 * update-initramfs -u -k 3.5.0-21-generic
 * reboot
 * I dont need 'nomodeset', laptop LCD and external LCD function fine... generally functional X.

--
[1] https://launchpad.net/ubuntu/raring/+source/xserver-xorg-video-intel/2:2.21.0-0ubuntu1

There's a hint that this is resolved in drm-intel-nightly (drm-intel-experimental), which would suggest that some of the pageflip race fixes help.

Just some information. Yesterday I saw that
xserver-xorg-video-intel at 2:2.21.3-0ubuntu1
was available, so I got it, and rebooted. I figured I'd try with latest kernel and X.

This morning in about 2 hours of general use, while scrolling (in ccsm), I hit this bug again while running kernel:
linux-image-3.8.0-7-generic: /boot/vmlinuz-3.8.0-7-generic

Attached is dmesg.

Hmm, I think we got that pending_flip issue fixed in drm-intel-nightly (look in ppa:mainline).

Running since friday with kernel from drm-intel-nightly ppa:mainline
linux-image-extra-3.9.0-994-generic 3.9.0-994.201303140438 amd64

My screen hasn't frozen all day (usually stops updating within an hour, only mouse is updated and everything just works (except for having screen updates).

[ 14.751] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1b1 (Martin Pitt <email address hidden>)
[ 14.752] (WW) Falling back to old probe method for vesa
[ 14.752] (WW) Falling back to old probe method for modesetting
[ 14.752] (WW) Falling back to old probe method for fbdev
[ 14.752] (II) Loading sub module "fbdevhw"
[ 14.752] (II) LoadModule: "fbdevhw"
[ 14.757] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 14.757] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 14.757] compiled for 1.13.3, module version = 0.0.2
[ 14.757] ABI class: X.Org Video Driver, version 13.1
[ 14.758] (II) intel(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[ 14.758] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[ 14.758] (==) intel(0): RGB weight 888
[ 14.758] (==) intel(0): Default visual is TrueColor
[ 14.758] (--) intel(0): Integrated Graphics Chipset: Intel(R) Q45/Q43
[ 14.758] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3
[ 14.758] (**) intel(0): Framebuffer tiled
[ 14.758] (**) intel(0): Pixmaps tiled
[ 14.758] (**) intel(0): "Tear free" disabled
[ 14.758] (**) intel(0): Forcing per-crtc-pixmaps? no

Seems that maybe this bug isn't solved.

I think the most likely candidate was added to the recent kernel update - Justin, if you can test the latest raring kernel that would be useful.

I must have missed that kernel in my testing, because I've been working with linux-image-3.8.0-13-generic=3.8.0-13.23 for about 2 days now without any problems (3.8.0-12 still had problems for me according to my notes).
So it appears to have been fixed (though the fix was a different upload than the one for which it was resolved).

Thanks for the good work!

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.