new Intel driver freezes system on video play after changing to console

Bug #141063 reported by unggnu
28
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Medium
xserver-xorg-video-intel (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

Thanks to the overlay fix video playing works fine under compiz with new Intel driver but after changin to console every xv player shows only a black or blue screen. The sound is working but there is no image. After some seconds, normally after closing the Video player, the laptop freezes completely that even the hardware mute button doesn't work anymore (led doesn't flash). Both problems happen without compiz too but it seems that it takes a little bit longer or another video start after changing to console to crash the system. If I don't start any video after mode change Laptop doesn't seem to freeze.
The freeze isn't duplicate of the Bug #127101, which often crashes my Laptop too, since desktop is still watchable (no gray rectangles) but maybe they are connected.
I hadn't this problem with i810 at least before trying new Intel driver.
I am using Sony TX2 laptop with i915 graphic card and current Gutsy.

Revision history for this message
In , Raul Sanchez Siles (rasasi78) wrote :

Created an attachment (id=11583)
Xorg log.

Revision history for this message
In , Raul Sanchez Siles (rasasi78) wrote :

Created an attachment (id=11584)
xorg configuration file

Please forget about the ForceEnablePipeA option.

Revision history for this message
In , Willi Mann (foss-ml) wrote :

Are you interested in my gdb logs? I've produced them by switching to VT, not by playing a second video.

Revision history for this message
In , Raul Sanchez Siles (rasasi78) wrote :

Willi,
regarding the backtraces, 2 things could happen:
a) The backtrace matches the one I've posted. In that case it's not necessary you dupe it, unless there's some info I haven't provided.
a) The backtrace is different, meaning that it's not referring to the same problem. Check if the problem is already reported or alternatively file a new bug report.

In general having a backtrace is very useful in order to identify where the problem is and also to check if that's already reported.
Thanks for you interest.

Revision history for this message
unggnu (unggnu) wrote : experimental Intel driver freezes system on video play after suspend

Binary package hint: xserver-xorg-video-intel

Thanks to the overlay fix video playing works fine under compiz with new Intel driver but after suspend, which works fine, every xv player shows only a black or blue screen. The sound is working but there is no image. After some seconds, normally after closing the Video player, the laptop freezes completely that even the hardware mute button doesn't work anymore (led doesn't flash). Both problems happen without compiz too but it seems that it takes a little bit longer or another video start after suspend to crash the system. If I don't start any video after suspend Laptop doesn't seem to freeze (independent of compiz).
The freeze isn't similar to the Bug #127101, which often crashes my Laptop too, since it happens without switching video mode and the desktop is still watchable (no gray rectangles).
I hadn't this problem with i810 at least before trying new Intel driver.
I am using Sony TX2 laptop with i915 graphic card and current Gutsy.

Is there any possibility to get the Intel driver without the Overlay fix to check if they are connected?

Revision history for this message
unggnu (unggnu) wrote :
Revision history for this message
unggnu (unggnu) wrote :
Revision history for this message
unggnu (unggnu) wrote :

Btw. I have forgot to mention that a video have to be played before suspend. Otherwise video playing works fine after suspend. At least for me.

Revision history for this message
unggnu (unggnu) wrote : Re: new Intel driver freezes system on video play after suspend

The easiest way to confirm this issue is to run a video with Totem and then suspend. After resume video window is black and sound stops after some seconds or doesn't appear again. If I now close Totem PC freezes completly. This is independent of compiz and Totem since Vlc usage results in the same.

Revision history for this message
unggnu (unggnu) wrote :

It has something to do with console change not with suspend. So the easiest way confirm the issue is to run a video with Totem (xv) and close it. Then switch to console and back. If you are lucky you got no gray rectangles (Bug # 127101) and come back to desktop. Now start another video with Totem, which should have a black video window, let it run for some seconds and then close it. System should freeze. Maybe you have to wait some seconds longer for video play if nothing happens.

description: updated
Revision history for this message
Sebastian Keller (skeller) wrote :

I can confirm this bug. In gutsy, when i start watching a video in totem, switch to the console using ctrl-alt-f1 and back then the video is black. Then I closed totem and started it again. The video was still black. After some time the laptop froze, not even sysrq worked. I used xv as video output and "intel" as driver.

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Revision history for this message
unggnu (unggnu) wrote :

Another interesting point. After installing patched xserver-xorg-core from bug #127101 system doesn't freeze anymore but XV output is still black or blue after console change. In Most cases X crashes/restarts after such a change and video player exit. Sometimes X/Keyboard freezes but mouse is still moveable and video sound works normally like under bug #138094.

Revision history for this message
unggnu (unggnu) wrote :

Unfortunately the system still freezes most of the time completely.

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

First, I must say that I'm using xserver-xorg-core from <https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101/comments/32>.

To me it's easier to trigger this bug not closing totem. That is:

1. Open some video file in totem.
2. Switch to VT1. At this point I've seen the gray blocks hang from bug #127101, but I think now it only happens when video is being played.
3. Switch back to VT7. Video in totem is black.
4. Keep switching to VT1 and back to VT7 while the video is playing until system hangs.

I'm attaching Xorg log from my last test. There's another log of same hang in a different test at <https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101/comments/35>.

Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

This is probably related to bug #28326, if not a duplicate.

Revision history for this message
unggnu (unggnu) wrote :

Hm, works fine for me with i810 driver so I am not sure.

Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

I'm sorry, you're right, it's probably not a duplicate of bug #28326.

I'm attaching a backtrace.
Looks like upstream bug <https://bugs.freedesktop.org/show_bug.cgi?id=12437>

Changed in xorg-server:
status: Unknown → Confirmed
Changed in xserver-xorg-video-intel:
status: Confirmed → Triaged
Revision history for this message
unggnu (unggnu) wrote :

Another interesting point is that I haven't this problem if I use an external monitor (VGA) and have LFP (LVDS) disabled with xrandr. There is another issue with dark video colors after switching to console and the video overlay is on top but xv still works. The dark video color problem could be fixed through closing video an reopening it with Totem but not the overlay on top issue. This needs an x restart.

Revision history for this message
unggnu (unggnu) wrote :

After removing the overlay fix from bug #111257 the problem disappears.
Video is running normally after switching back from console. Of course only without compiz.

Revision history for this message
In , Raul Sanchez Siles (rasasi78) wrote :

Created an attachment (id=11983)
Xorg log of the crash with more recent git (20071007)

Revision history for this message
In , Raul Sanchez Siles (rasasi78) wrote :

The backtrace I get:
#0 XkbEnableDisableControls (xkbi=0x180, change=542, newValues=512,
    changes=0x0, cause=0xbfae01d4) at ../../xkb/xkbUtils.c:748
#1 0x0818d5f1 in XkbRemoveResourceClient (inDev=0x826f040, id=1096810496)
    at ../../xkb/xkbEvents.c:1014
#2 0x08085542 in CloseDevice (dev=0x826f040) at ../../dix/devices.c:602
#3 0x080857a9 in CloseDownDevices () at ../../dix/devices.c:624
#4 0x081ba4e3 in AbortServer () at ../../os/log.c:405
#5 0x081baa66 in FatalError (
    f=0x81c4f4c "Caught signal %d. Server aborting\n") at ../../os/log.c:552
#6 0x080c64bd in xf86SigHandler (signo=11)
    at ../../../../hw/xfree86/common/xf86Events.c:764
#7 0xffffe420 in ?? ()
#8 0x0000000b in ?? ()
#9 0x00000033 in ?? ()
#10 0xc0100000 in ?? ()
#11 0x0000007b in ?? ()
#12 0x0000007b in ?? ()
#13 0x08218e80 in ?? ()
#14 0x08ecf5f0 in ?? ()
#15 0xbfae0618 in ?? ()
#16 0xbfae0600 in ?? ()
#17 0xb7affeec in ?? () from /usr/lib/xorg/modules/drivers//intel_drv.so
#18 0x00000016 in ?? ()
#19 0xb7e0cff4 in ?? () from /lib/i686/cmov/libc.so.6
#20 0xfff60700 in ?? ()
#21 0x0000000e in ?? ()
#22 0x00000007 in ?? ()
#23 0xb7ad9075 in i830_free_memory (pScrn=0x8217aa0, mem=0x8ecf5f0)
    at ../../src/i830_memory.c:240
#24 0xb7adcdea in I830StopVideo (pScrn=0x8217aa0, data=0x8267924, shutdown=1)
    at ../../src/i830_video.c:1018
#25 0xb7adceeb in i830_crtc_dpms_video (crtc=0x8219fa8, on=0)
    at ../../src/i830_video.c:2846
#26 0xb7ace1e0 in i830_crtc_dpms (crtc=0x8219fa8, mode=3)
    at ../../src/i830_display.c:713
#27 0x080f0f3e in xf86DPMSSet (scrn=0x8217aa0, mode=3, flags=0)
    at ../../../../hw/xfree86/modes/xf86Crtc.c:1961
#28 0x080f162e in xf86SaveScreen (pScreen=0x8225fe8, mode=0)
    at ../../../../hw/xfree86/modes/xf86Crtc.c:1987
#29 0x0807caa3 in SaveScreens (on=2, mode=1) at ../../dix/window.c:3453
#30 0x080c5942 in DPMSSet (level=1)
    at ../../../../hw/xfree86/common/xf86DPMS.c:160
#31 0x081acb69 in ScreenSaverTimeoutExpire (timer=0x86562e0, now=2036720,
    arg=0x0) at ../../os/WaitFor.c:631
#32 0x081ace74 in DoTimer (timer=0x86562e0, now=542, prev=0x180)
    at ../../os/WaitFor.c:459
#33 0x081ad607 in WaitForSomething (pClientsReady=0xbfae0a50)
    at ../../os/WaitFor.c:293
#34 0x0808ce82 in Dispatch () at ../../dix/dispatch.c:425
#35 0x0807461b in main (argc=8, argv=0xbfae0f74, envp=
Cannot access memory at address 0x188
) at ../../dix/main.c:452

Revision history for this message
In , Daniel Stone (daniels) wrote :

This is the relevant part:

(In reply to comment #6)
> #23 0xb7ad9075 in i830_free_memory (pScrn=0x8217aa0, mem=0x8ecf5f0)
> at ../../src/i830_memory.c:240
> #24 0xb7adcdea in I830StopVideo (pScrn=0x8217aa0, data=0x8267924, shutdown=1)
> at ../../src/i830_video.c:1018
> #25 0xb7adceeb in i830_crtc_dpms_video (crtc=0x8219fa8, on=0)
> at ../../src/i830_video.c:2846
> #26 0xb7ace1e0 in i830_crtc_dpms (crtc=0x8219fa8, mode=3)
> at ../../src/i830_display.c:713
> #27 0x080f0f3e in xf86DPMSSet (scrn=0x8217aa0, mode=3, flags=0)
> at ../../../../hw/xfree86/modes/xf86Crtc.c:1961
> #28 0x080f162e in xf86SaveScreen (pScreen=0x8225fe8, mode=0)
> at ../../../../hw/xfree86/modes/xf86Crtc.c:1987
> #29 0x0807caa3 in SaveScreens (on=2, mode=1) at ../../dix/window.c:3453
> #30 0x080c5942 in DPMSSet (level=1)
> at ../../../../hw/xfree86/common/xf86DPMS.c:160
> #31 0x081acb69 in ScreenSaverTimeoutExpire (timer=0x86562e0, now=2036720,
> arg=0x0) at ../../os/WaitFor.c:631

All the stuff above that is just fatal signal handling, which definitely needs to be improved, but it's not the cause of the crash.

Revision history for this message
In , Willi Mann (foss-ml) wrote :

latest git of intel driver fixes this issue for me it doesn t hang when trying to play the second or further videos , but I still can t switch to VT after I ve played video with xv. Segfault as in Bug#12451, similar backtrace

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

This looks like the bug I fixed yesterday, so it should be fixed for both reporters.

Revision history for this message
Peter Clifton (pcjc2) wrote :

I've been playing with this, and found forcing a reset of the Xv registers after a mode-switch seems to help this problem.

The debdiff, sources and a .deb are at:

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/

I'm not an Ubuntu or X.Org developer, so treat these as what they are.. unofficial and only tested by myself.

The package also has a possible fix / workaround for LP #127101, the "grey blocks" crash on VT switch. (I continued from Bryce's fine work debugging that).

Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

So far I haven't been able to reproduce this bug using xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb package.
Looks like the patch works.

Revision history for this message
unggnu (unggnu) wrote :

Seems to work after several testing. Great job.

Revision history for this message
Scott Robinson (scott-ubuntu) wrote :

Peter, have you pushed your patches back to the upstream bugs or to the -intel maintainer?

Revision history for this message
Peter Clifton (pcjc2) wrote :

Not to the upstream bugs, but I've been in contact with a couple of the Intel driver developers trying to work out a complete solution.

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Bryce Harrington (bryce) wrote :

xserver-xorg-video-intel (2:2.1.1-0ubuntu9) gutsy; urgency=low

   [Peter Clifton]
   * 01_fix_compiz_video.diff:
     - Bracket second clause in test for textured video to avoid
       compiler warning and possibly incorrect testing.
   * 04_fix_hw_restore.diff
     - Only restore palette registers for pipes which are enabled, or
       the system may hard-lock. (Initial patch by Bryce Harrington).
       (Closes LP: #127101)
   * 05_fix_xv_reset.diff
     - Playing Xv video after switching modes once the Xv driver is
       initialised causes a lockup, as the overlay regisers need
       re-programming. Ensure such a reset happens after a mode-switch.
       (Closes LP: #141063)

 -- Bryce Harrington <email address hidden> Sat, 13 Oct 2007 12:58:07 -0700

Changed in xserver-xorg-video-intel:
status: Triaged → Fix Released
Revision history for this message
Craig (candrews-integralblue) wrote :

Were these patches applied upstream? I'm experiencing this same problem on a different distribution (gentoo). Thanks!

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.