Bug 26937

It's still happening with xorg-x11-drv-intel-2.10.902.

I get exactly the same behaviour. It's usually (though not always) triggered by something being drawn on the screen when in full screen mode (e.g. a KDE notify popup).

lspci tells me I have a:

945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)

I'm using the 'intel' driver version 2.10.0, xorg 1.7.5.902. and intel-dri version 7.7.

Please let me know if you need any more info.

Thanks.

I have the same problem, albeit at a reduced intensity, with latest drivers 2.11.0
When I put youtube in fullscreen, video is slow and somewhat jerky, like if there was some problem transmitting data into the framebuffer. Sometimes the video catches up missing frames after a short freeze (1/4 to 1/2 s), and sometimes it just freezes forever. In this case, X works normally, the mouse cursor reacts to the applications, but the screen is locked with the latest video frame, or with black.

The versions I am using:
- distrib: OpenSUSE 11.2 with kernel HEAD and recent X11 repositories
- kernel: 2.6.34-rc3-7-desktop
- Xorg: 7.4-54.5
- org-x11-driver-video: 7.5-26.2 (includes 2.11.0)
- mesa: 7.8-9.1

I hope that this helps. By the way, 3D works really bad, but that is for another report.

Oh, I forgot. The version of xorg-x11-server is 7.5_1.8.0-19.2

And I'm running with a x86_64 kernel.

(In reply to comment #3)
> ...
> sometimes it just freezes forever. In this case, X works normally, the mouse
> cursor reacts to the applications, but the screen is locked with the latest
> video frame, or with black.
> 

It's exactly what I'm getting here with the latest 2.11 drivers. Too bad Intel developers haven't cared to drop here even a single comment. It seems like they are forbidden to use youtube at their work :)

OK, 100% reproducible test case:

Install
http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_rc_linux_040510.tar.gz

Open this video in 
http://www.youtube.com/watch?v=kM0ypzvuphg&feature=popt01us0a

Mozilla Firefox 3.6.2, hit 720p, hit full screen -> get an immediate reproducible
freeze.

It happens even in X.org server 1.8 release.

I didn't see this problem in Firefox 3.5.4 (shipped in Fedora 11). But I can reproduce with upgrading Firefox to 3.6.2.

I use the latest driver.

I have a suspicion that Adobe flash uses GL. Anyway, sounds like a GPU hang which should have been reported in dmesg, so can you please upload /sys/kernel/debug/dri/0/i915_error_state?

What kernel options are required for debugging? My /sys/kernel doesn't contain debug directory at all.

(In reply to comment #11)
> What kernel options are required for debugging? My /sys/kernel doesn't contain
> debug directory at all.

http://intellinuxgraphics.org/i915_error_state.html

Created attachment 35055 [details]
intel_gpu_dump

cat /sys/kernel/debug/dri/0/i915_error_state, return "no error state collected". So upload intel_gpu_dump.

My GPU dump is located here: https://bugs.freedesktop.org/attachment.cgi?id=33718

Doesn't appear to be a GPU hang. Jesse is reporting some page-flip issues fixed with:

22:15 < jbarnes> https://patchwork.kernel.org/patch/90683/
22:15 < jbarnes> that's the one that fixed it for me

So can you please give that a whirl and see if this is just another manifestation of the same bug?

The mentioned patch makes no difference, except now I'm able to restart X server after it hung. Earlier you couldn't even do that - i.e. you could successfully kill X server, but the one that started afterwards didn't refresh the display, i.e. the display was left in a semi-broken state.

That's a step forward! Is there any new clue after restarting X? What's the output of dmesg, i915_error_state and Xorg.log?

(In reply to comment #17)
> That's a step forward! Is there any new clue after restarting X? What's the
> output of dmesg, i915_error_state and Xorg.log?

Chris, I may actually let you SSH into my system to look for clues for this problem.

So far I have no errors logged anywhere, Xorg.0.log.old looks absolutely normally,

$ dmesg | egrep  "drm|intel|i915"
[    3.588558] agpgart-intel 0000:00:00.0: Intel Ironlake/D Chipset
[    3.589260] agpgart-intel 0000:00:00.0: detected 131068K stolen memory
[    3.601367] [drm] Initialized drm 1.1.0 20060810
[    3.636935] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
[    3.636962] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    3.636965] i915 0000:00:02.0: setting latency timer to 64
[    3.640302] i915 0000:00:02.0: irq 29 for MSI/MSI-X
[    3.640312] [drm] set up 127M of stolen space
[    3.913826] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[    3.969013] fb0: inteldrmfb frame buffer device
[    3.969029] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

messages.log logs the only meaningful message which is:

Apr 16 12:56:42 localhost kdm[1829]: X server for display :0 terminated unexpectedly

kdm.log doesn't contain references to any problems at all.




Now I should repeat it once again:

X server doesn't fully freezes: I still *can* move the mouse cursor, however the image on the screen is *frozen* and you cannot leave full screen mode, and even if you killed Firefox (by killall -9 firefox-bin) the image on the screen remains as if Firefox kept running.

Created attachment 35085 [details]
Entire /sys/kernel/debug/dri directory tar.bzip'ped

I don't know if it's of any use, but I'm attaching the entire /sys/kernel/debug/dri directory snapshot when X server hung.

I have the same problem, when flash is running full-screen, the image freezes, but everything else works. Restarting X doesn't help. I once even got the same freeze while viewing a PDF in full-screen presentation mode in Okular (4.4.2).

However, I found a workaround to reset the frozen video:
* exit full-screen flash (usually Esc)
* blindly open a terminal (shortcut helps)
* change the resolution using xrandr:
  xrandr --output LVDS1 --mode 1024x768
* video works now, change the resolution back to normal
  xrandr --output LVDS1 --mode 1366x768
* video still works

I can repeat this procedure several times on every freeze.

An interesting observation, if I mirror the screen:
  xrandr --output LVDS1 --reflect x
the video starts to work, but if I change it back:
  xrandr --output LVDS1 --reflect normal
the screen is still frozen (just gray).

I'm on x86_64, kernel 2.6.33 with TuxOnIce patchset, intel drivers 2.11.0, xorg server 1.7.6, mesa 7.8.1
chipset GM45

i915_error_state says no error state, I'll attach intel_gpu_dump

Created attachment 35125 [details]
Output of intel_gpu_dump

Attached the output of intel_gpu_dump both while frozen and after restoring the video using the workaround I just described.

Btw, I don't mind compiling xorg server with debug information, enabling tracing, attaching debugger etc. if needed.

Chris, I see you are making commits to intel driver, can you please look closely into this issue?

(In reply to comment #20)
> I have the same problem, when flash is running full-screen, the image freezes,
> but everything else works. Restarting X doesn't help. I once even got the same
> freeze while viewing a PDF in full-screen presentation mode in Okular (4.4.2).
> 

xrandr fails to work for me when X server hung.

Same exact problem here with Fedora 13 x86_64 (Gnome) on a Fujitsu Amilo Li 3710 with integrated graphics Intel GM45 (or 4500HD).

- Firefox: 3.6.3

- Xorg: X.Org X Server 1.8.0 Release Date: 2010-04-02

- xorg-x11-drv-intel
Architecture  : x86_64
Version       : 2.11.0
Révision      : 4.fc13

- glxinfo
name of display: :0.0
libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100328 2010Q1 
OpenGL version string: 2.1 Mesa 7.8.1
OpenGL shading language version string: 1.20

If someone needs more infos to debug this, just let me know...

I forgot to say that I'm using with Fedora 13 the kernel 2.6.33.4-95.fc13.x86_64, that Compiz is disabled and that using Flash 64 or 32 wrapped brings the same freezes as described by the other users (means mouse + sound still working, but no way to get off fullscreen, unless using telinit or rebooting).

But, on the same laptop / hardware, Flash 64 plugin with LinuxMint 9 x86_64 works perfectly in fullscreen, EVEN with Compiz enabled, with the following:

- Kernel 2.6.32-22-generic-Ubuntu x86_64 

- Firefox: 3.6.3

- X.Org: X Server 1.7.6 Release Date: 2010-03-17

- xserver-xorg-video-intel
Version : 2:2.9.1-3ubuntu5

- glxinfo:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.2
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20091221 2009Q4 
OpenGL version string: 2.1 Mesa 7.7.1
OpenGL shading language version string: 1.20

So I hope it helps...

*** Bug 28473 has been marked as a duplicate of this bug. ***

Just for another data point on this bug:
Youtube fullscreen works fine for me.
I am using kwin compositing, the last x64 beta flash version, xorg-edgers (with gallium), i7-620M.

I just filed bug 28573 for a similar-sounding issue to this, but it's not an actual hang. Fullscreen flash just fails to update the screen. Also, windowed SDL apps don't update (but everything else works fine). The problem happens with compiz, but not metacity.

(In reply to comment #15)
> Doesn't appear to be a GPU hang. Jesse is reporting some page-flip issues fixed
> with:
> 
> 22:15 < jbarnes> https://patchwork.kernel.org/patch/90683/
> 22:15 < jbarnes> that's the one that fixed it for me
> 
> So can you please give that a whirl and see if this is just another
> manifestation of the same bug?

I have just tried this patch on top of 2.6.34: the X server freeze still occurs when maximizing a flash player plugin. As before, no traces in the logs.

Martin

I get the same with an Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07), 64-bit system.

It happens the second time I make a flash-based video fullscreen.  At some point, it will freeze, and then nothing will make it unfreeze, apart from restarting X.  If I "ESC" out of fullscreen mode and/or kill firefox and/or nspluginviewer, the screen stays the same, but the mouse cursor can move and will change as it passes over various window components (eg: resize cursor at the edge of windows).

I didn't manage to try the trick of changing the resolution, because xrandr point-black refuses to change it with some cryptic error message.

Killing xorg and restarting it makes the problem go away.

Oh, and - as with the others - nothing interesting in Xorg.log or debugfs.

With kernel 2.6.35-rc3-1-desktop and intel xorg driver 2.11.0, youtube/flash now seems to work in fullscreen.

It now works for me, with xf86-video-intel master tip (post-2.11.901), mesa 7.8.2, xserver 1.8.1, libdrm 2.4.21, kernel 2.6.34.

Upgraded to xorg-server 1.8.1.902, xf86-video-intel 2.11.0 and kernel 2.6.34.  It now is worse than before: the freeze happens immediately after going to fullscreen, rather than the second time I go to fullscreen mode.

(In reply to comment #34)
> Upgraded to xorg-server 1.8.1.902, xf86-video-intel 2.11.0 and kernel 2.6.34. 
> It now is worse than before: the freeze happens immediately after going to
> fullscreen, rather than the second time I go to fullscreen mode.

alex, can you try the 2.12 release candidate, 2.11.901, rather than vanilla 2.11.0 with its known page-flipping bugs, one of which it sounds like you just hit.

I have just now tried xf86-video-intel 2.11.901. However, the freeze upon maximizing flash player persists. Rest of the system: kernel 2.6.34, Xorg 1.7.7, libdrm-2.4.21.

OK, so, I've tried it with 2.11.901.  The problem is less severe with this version of the driver.

It no longer freezes the first time I make a flash video fullscreen.  So the problem specific to 2.11.0 has gone.

It does freeze the second and subsequent times (and it's now immediate, usually before flash has managed to draw anything other than a black background).  But it's no longer fatal.  I can ESC out of full screen mode, and everything is restored.

A second or so after I've left fullscreen mode, everything freezes again for a few seconds - it seems to be longer if I have KWin's compositing on than if I have it off, but it happens either way.

Also, KWin crashed within the DRI code (one time out of 3-4 times I tried this).

#6  0x00007f5688c77d30 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#7  0x00007f5688c6cf4b in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#8  0x00007f5688c6f09a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#9  0x00007f569f1d38a4 in KWin::SceneOpenGL::paintBackground (this=0xb2c170, region=...) at /home/kde-devel/src/KDE/kdebase/workspace/kwin/scene_opengl.cpp:892

(I realise this backtrace is unhelpful - is there an option I can pass to configure to get debugging info, without potentially slowing down the driver, in case it happens again?)

Oh, and - as before - the freezes are purely visual.  I can still interact with everything, but the only thing on the screen that changes is the mouse cursor.

A few more things:

After restarting, it seems that the freeze happens on the first time I put a flash video into fullscreen as well.

The crash, of course, is in the intel dri module from Mesa.  I managed to get some symbols:

#6  0x00007fc39de9cd30 in intel_region_buffer () from /usr/lib/xorg/modules/dri/i965_dri.so
#7  0x00007fc39de91f4b in intelClearWithBlit () from /usr/lib/xorg/modules/dri/i965_dri.so
#8  0x00007fc39de9409a in intelClear () from /usr/lib/xorg/modules/dri/i965_dri.so
#9  0x00007fc3b43f88a4 in KWin::SceneOpenGL::paintBackground (this=0x2554f60, region=...)
    at /home/kde-devel/src/KDE/kdebase/workspace/kwin/scene_opengl.cpp:892

The crash is a segfault.

With Intel drivers 2.12, Linux kernel 2.6.34 and xorg-x11-server-Xorg-1.8.0-12.fc13.i686 I cannot reproduce this bug any longer.

I will close it if I don't reproduce it in the next few weeks or unless someone comes with a new reproducible testcase.

Artem, were you by any chance running compiz or some other compositing window manager when you experienced the bug before and are you no longer using compiz?

I have found at least two separate bugs similar to this one that occurred under compiz but not metacity: bug 28573 and bug 28766. So it might be worth testing with compiz. Neither of these bugs affected stability, though.

Also, this bug report appears to cover at least two separate issues, the second of which could be bug 28766, and I have a reproducible testcase for that (though not a convenient one as it requires a working MythTV setup).

(In reply to comment #41)
> Artem, were you by any chance running compiz or some other compositing window
> manager when you experienced the bug before and are you no longer using compiz?
> 
> I have found at least two separate bugs similar to this one that occurred under
> compiz but not metacity: bug 28573 and bug 28766. So it might be worth testing
> with compiz. Neither of these bugs affected stability, though.
> 
> Also, this bug report appears to cover at least two separate issues, the second
> of which could be bug 28766, and I have a reproducible testcase for that
> (though not a convenient one as it requires a working MythTV setup).

No, I've never run any compositing window managers, KDE4's KWin performance even on my currently fastest Intel GPU is not sufficient to comfortably run FX effects during day-to-day activity - everything feels a bit slow and laggy.

Can't reproduce any more with intel drivers 2.12, kernel 2.6.34 and xorg-server 1.7.7 (I'm using KDE4 with compositing kwin). Flash even crashed once while being in fullscreen, but alt+tab restored everything.
Thanks a lot!

After all the reports her I thought I'd try something more adventureous, so I upgrade to xf86_video_intel-2.12.0, mesa-7.8.2, pixman-0.18.2, cairo-1.9.10. Before that I had already been on libdrm-2.4.21 and xf86_video_intel-2.11.901. 

What can I say, the flash player still crashes, still without useful log entries. But the worst thing is, I can no longer switch on KDE4 desktop effects, even when reverting the above mentioned "upgrades". Excellent. I've completely buggered up this machine by trying to get something to work that should have been working in the first place. It seems my idea of saving money by sacrificing two cpu cores for an intel GPU core totally backfired. I now whish I had gone down the Nvidia road.

Martin

(In addition to comment #44)

just for the records, I found the culprit: xf86_video_intel-2.12.0 prevents Kwin from offering desktop effects. xf86_video_intel-2.11.901 works fine (in that respect). I have created another ticket for that. 

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

MArtin

(In reply to comment #44)
> After all the reports her I thought I'd try something more adventureous, so I
> upgrade to xf86_video_intel-2.12.0, mesa-7.8.2, pixman-0.18.2, cairo-1.9.10.
> Before that I had already been on libdrm-2.4.21 and xf86_video_intel-2.11.901. 
> 
> What can I say, the flash player still crashes, still without useful log
> entries. But the worst thing is, I can no longer switch on KDE4 desktop
> effects, even when reverting the above mentioned "upgrades". Excellent. I've
> completely buggered up this machine by trying to get something to work that
> should have been working in the first place. It seems my idea of saving money
> by sacrificing two cpu cores for an intel GPU core totally backfired. I now
> whish I had gone down the Nvidia road.
> 
> Martin

How does it crash? What are the exact versions of Firefox and flash player that you are using? What's your distro? What's your architecture?

(In reply to comment #46)
> How does it crash? What are the exact versions of Firefox and flash player that
> you are using? What's your distro? What's your architecture?

In addition to my reply #36: basically the machine is on Slackware64 13.1, but in order to solve the various issues I have tried various updates. During all these, despite other bugs present, I had the flash player issue. I am using firefox 3.6.3 and flash plugin 10.0 r45. 

kernel      xserver  libdrm  xf86_video  mesa   result
                             _intel
------------------------------------------------------------------------
2.6.33.3    1.7.6    2.4.20  2.11.0      7.8.1  bug #28096 & flash issue
2.6.33.4    1.7.6    2.4.20  2.11.0      7.8.1  bug #28096 & flash issue
2.6.34      1.7.6    2.4.20  2.11.0      7.8.1  bug #28096 & flash issue
2.6.34      1.7.7    2.4.20  2.11.0      7.8.1  bug #28096 & flash issue
2.6.35-rc2  1.7.7    2.4.20  2.11.0      7.8.1  bug #28096 & flash issue
2.6.34      1.7.7    2.4.21  2.11.0      7.8.1  flash issue
2.6.34      1.7.7    2.4.21  2.11.901    7.8.1  flash issue
2.6.34      1.7.7    2.4.21  2.12.0      7.8.2  bug #28783 & flash issue
2.6.34      1.7.7    2.4.21  2.12.0      7.8.1  bug #28783 & flash issue

"Flash issue" means, when maximizing the flash video or live stream, the screen freezes, but the mouse pointer moves and the sound continues. Ctrl-Alt-BS recovers, as does killing X via telnet. I seem to remember I had freezes without maximizing and even without a flash player active (but firefox), but the reliable trigger at the moment is maximizing.

It seems to be really fixed in 2.12, thus closing.

Martin wrote:

> Hi Artem,
> 
> I still get a freeze when maximising a flash plugin. Sometimes only the
> second or third time, but I can reliably freeze the display. I shall
> attach the relevant part of a .xsession-errors file.
> 
> Since I am currently on 2.12, do you want me to create a new bug ticket,
> or are you going to re-open 26937? Please advise.
> 
> Thanks,
> 
> cu Martin

Reopening.

Martin, please attach `lspci` (and lspci -vvv) and dmidecode output.

Created attachment 36696 [details]
Output of lspci

Created attachment 36697 [details]
Output of lspci -vvv

Created attachment 36698 [details]
Output of dmidecode

Martin, I still don't get why you can't try X server 1.8.2 - I'm almost sure Intel drivers developers will not bother installing X server 1.7.7 just to figure out what might be wrong with it.

Almost all of us are using X server 1.8.2 or even rc's of 1.9.0, and there's a chance that this issue may take place for you due to bugs in the older X server.

If you are unwilling to install a newer X server in Slackware, you may try e.g. any recent enough LiveCD like Fedora 13.

Hi Artem,

(In reply to comment #53)
> Martin, I still don't get why you can't try X server 1.8.2 

Actually, I have tried building an xserver 1.8.2 package using the existing Slackbuild script (which is made for 1.7.7). Unfortunately it breaks at some point and I am not familiar enough with the xorg build environment to sort it out.

> I'm almost sure
> Intel drivers developers will not bother installing X server 1.7.7 just to
> figure out what might be wrong with it.
> 
> Almost all of us are using X server 1.8.2 or even rc's of 1.9.0, and there's a
> chance that this issue may take place for you due to bugs in the older X
> server.

That is one possibility. If I could be enabled to provide better debugging information, would that help?

> If you are unwilling to install a newer X server in Slackware, you may try e.g.
> any recent enough LiveCD like Fedora 13.

As I said, I am very willing. Only I haven't managed to do it so far.

With regards to a Fedora Live CD: I can sure download it and fire it up. The only question is, what would that help? Assuming the problem did not surface with the Live CD: then we'd know the bug is triggered in some software configuration and not in others. If the problem was present with the Live CD: then you'd know that a software configuration you are familir with (Fedora) triggers the bug on some hardware other than yours. Sp we're back to the same problem: you need better debug information from my side.

In closing, I shall experiment some more with xserver and Live CD. Please let me know if and how I can provide better debug information.

Martin

(In reply to comment #54)
> Actually, I have tried building an xserver 1.8.2 package using the existing
> Slackbuild script (which is made for 1.7.7). Unfortunately it breaks at some
> point and I am not familiar enough with the xorg build environment to sort it
> out.

Scratch that. I have looked at it again and managed to build the xorg server and the drivers I need. (The majority of drivers did not build, btw, but I did not spend the effort of hunting down newer versions from all over the internet.)

NB, for posterity, these are the packages I created & installed:

xorg-server-1.8.2-x86_64-1mr
xorg-server-xephyr-1.8.2-x86_64-1mr
xorg-server-xnest-1.8.2-x86_64-1mr
xorg-server-xvfb-1.8.2-x86_64-1mr
xf86-video-intel-2.12.0-x86_64-1mr
xf86-video-vesa-2.3.0-x86_64-2mr
xf86-input-evdev-2.3.3-x86_64-1mr

I also installed those, although they are not required:

xf86-input-keyboard-1.4.0-x86_64-1mr
xf86-input-mouse-1.5.0-x86_64-1mr

Just to document all othe deviations from a standard Slack 13.1 installation:

libdrm-2.4.21-x86_64-1mr
mesa-7.8.2-x86_64-1mr

I found one problem with the upgrade, namely the xorg-server seems to ignore the settings in /etc/hal/fdi/policy/10-keymap.fdi (which define my keyboard layout and enable Ctrl-Alt-Backspace). However, there is an easy workaround via the system settings that will add a setxkbmap call to the startup procedure.

Results with regards to the flashplayer freeze: the stability has improved dramatically. I could maximize and minimize a youtube video like 20 times, before the dislpay finally froze. During the switch there is a lot of flickering, as if there are a large number of page flips. Also the switch is not always successful, and sometimes flash has difficulties updating its own window. My impression is that the latter issues are related to the flash player rather than the driver. However, the final freeze of the entire display obviously is a system wide effect that should not be allowed to occur.

So, what can I try next? I still think what we really need is more information about the actual error condition at the time it occurs.

Martin

I have just tried kernel 2.6.34.1 which appears to contain some i915 drm patches, but I still got a freeze after maximizing a flash video for the fifth time.

Martin, since you now have a 2.6.34 kernel, can you upload the /sys/kernel/debug/dri/0/i915_error_state following a hang (presuming of course that a GPU hang is being detected by the kernel). That will at least confirm whether it is a GL issue or a DDX bug.

As I've just copied some sanity checks for MI_WAIT_FOR_EVENT over to the video code, they may or may not help in this case:

commit 272d1c14a39c32ade39b5a8b080a891f2b3d6e8e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 9 10:41:19 2010 +0100

    video: apply the crtc box checks from dri.
    
    The dri code is much more careful in ensuring that the scan lines that
    is waits for are valid. Copy this code to video, with a bit of work this
    can be refactored, and perhaps even teach dri how to handle rotated
    front buffers.
    
    References:
    
      Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video
                  in Totem
      https://bugs.freedesktop.org/show_bug.cgi?id=28964

(In reply to comment #57)
> Martin, since you now have a 2.6.34 kernel, can you upload the
> /sys/kernel/debug/dri/0/i915_error_state following a hang (presuming of course
> that a GPU hang is being detected by the kernel). That will at least confirm
> whether it is a GL issue or a DDX bug.

OK, one kernel compilation & reboot later: Before and after a hang, /sys/kernel/debug/dri/0/i915_error_state contains the line "no error state collected".

> commit 272d1c14a39c32ade39b5a8b080a891f2b3d6e8e
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Jul 9 10:41:19 2010 +0100

Chris, could you attach the patch? saves me downloading a complete git repository (and getting my head around it). ;-)

Martin

Chris's patch is a patch to xf86-video-intel and is available here:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/patch/?id=272d1c14a39c32ade39b5a8b080a891f2b3d6e8e

Oh, add this too:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/patch/?id=141e88c8730a099a6ca5eab1350c2e53a680cb0d

(In reply to comment #60)
> Oh, add this too:
> 
> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/patch/?id=141e88c8730a099a6ca5eab1350c2e53a680cb0d

OK, here we go. I couldn't apply the patches to 2.12.0 because the file structure had changed. So I bit the bullet, did a 

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel

and took it from there. The SlackBuild script didn't work at first, but after adding a call to autogen.sh everything built fine.

The result: I could maximize the flash plugin 30 times in a row or so (I didn't really count). As before, the flash plugin shows a lot of flickering, has problems updating the screen and sometimes delays the whole browser which is most likely an issue of flash, not the video driver.

Unfortunately, in the end I got a hanging black screen. Only difference: this time I did not have to kill X because the system crashed back to the kdm greeter (logon screen) after a few seconds of me clicking blindly on the black screen. Still nothing in i915_error_state.

So I'm not sure. The number of possible maximzations seems to have increased before the screen decides to hang...

Martin

Martin, interesting thanks for doing the testing. X crash is not really an improvement though, at least in my book! ;-) X should have left a backtrace in its log file, it would be excellent if you could track it and upload it. As you are not experiencing GPU hangs, then it strongly suggests you are suffering from broken dri2 swapping. Here you will want to be using xserver-1.9, but lets have a look at the backtrace first...

Created attachment 36934 [details]
segfault caught in Xorg.log

I found a backtrace in the log...

Backtrace:
[ 46671.417] 0: /usr/bin/X (xorg_backtrace+0x28) [0x45db98]
[ 46671.417] 1: /usr/bin/X (0x400000+0x5a839) [0x45a839]
[ 46671.417] 2: /lib64/libc.so.6 (0x7f8609090000+0x33620) [0x7f86090c3620]
[ 46671.417] 3: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f8606fff000+0x27b20) [0x7f8607026b20]
[ 46671.417] 4: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f8606fff000+0x1d415) [0x7f860701c415]
[ 46671.417] 5: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f8606fff000+0x1f6fa) [0x7f860701e6fa]
[ 46671.417] 6: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f86085db000+0x31ed3) [0x7f860860ced3]
[ 46671.417] 7: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f86085db000+0x361c0) [0x7f86086111c0]
[ 46671.417] 8: /usr/bin/X (0x400000+0x46da4) [0x446da4]
[ 46671.417] 9: /usr/bin/X (0x400000+0x2242a) [0x42242a]
[ 46671.417] 10: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f86090aeb6d]
[ 46671.417] 11: /usr/bin/X (0x400000+0x21fe9) [0x421fe9]
[ 46671.417] Segmentation fault at address 0x40

Hmm, totally unexpected. Looks reminiscent of:

commit 772f8236d50725f0b330508616b4f2a9a910662a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 30 13:58:05 2010 +0100

    dri: Handle errors during GetBuffers() gracefully.
    
    Unwind the array of Pixmaps already allocated and report failure for the
    old dri GetBuffers() path.

Check you have the "latest and greatest" mesa, attach gdb and get a full backtrace.

(In reply to comment #64)
> Check you have the "latest and greatest" mesa, 

I'm on 7.8.2 which appears to be the latest release.

> attach gdb and get a full backtrace.

just to confirm, what process do you want me to attch to, and what packages do I need to recompile with -g flag beforehand?

(In reply to comment #65)
> 
> > attach gdb and get a full backtrace.
> 
> just to confirm, what process do you want me to attch to, and what packages do
> I need to recompile with -g flag beforehand?

From a remote PC via SSH connection you need to start X or XDM (e.g. kdm, gdm) under gdb, e.g. like this:

ssh my_pc

$ su -
# gdb X
...
run

You absolutely need to build X server itself and intel driver with -g, I'm not sure about any other packages.

In theory every package X server depends on ( ldd `which X` ) is better to be recompiled with -g.

With 2.12.0, I no longer seem to get unrecoverable X-server freezes in full screen mode.

When I switch to full-screen mode on a flash video, it is fine for about half a second, then freezes.  The mouse cursor moves just fine, but nothing else updates.  However, ESC will take me out of full screen mode and returns everything to normal.

Alex, that sounds like bug 28573, and it's partially fixed on the master branch.

just a brief update: After some poking around I have finally managed to compile and install the most relevant packages with -g but when attaching to the X process it came up "debug symbols not found" or so. I also managed to trigger a segfault, but I could not get more information than what is already logged in this ticket.

While trying to trigger a segfault (by repeatedly maximizing and minimizing a flash video) I gained some additional insight: it is not just firefox & flash that start flickering and show update problems, it is every application.

Hitting the full-screen button on Flash videos freezes my system as well. A small number of frames are drawn, and sound goes on for a short while, but then my system freezes completely: even SSH sessions die.

I run most recent git versions of all relevant software: kernel, xorg-server, libdrm, mesa, xf86-video-intel.  I have an Intel 855GM chipset and have applied daniel vetter's kernel patch as described in bug #27187.

It might be an unrelated bug though, because most OpenGL apps show the same behavior.

quick update on 2.6.35: the hang plus eventual segfault can still be triggered.

I'm seeing this bug for quite some time on my Fedora system (2.6.35, rawhide, T61, i965)- and even after several months there is still no solution ?  How can I help to track this down - it's very annoying to accidentally press full screen and lose whole desktop.

xorg-x11-drv-intel-2.12.0-4.fc14.x86_64

firefox-3.6.7-1.fc14.x86_64
flash 10.0 rc45

To add few more details - I've checked also with current git tree for intel driver & libdrm  (compiled for 1.8.99.906, module version = 2.12.0) and having exactly same result  (even with 2.6.36-rc0 fedora kernel)

Doing some more time consuming tests here - it seems the major problem is with usage of the latest available 64bit version of flash plugin before adobe stoped producing - when using nswrapped 32bit version (10.1 r82 in my case) it seem the windows doesn't stay frozen - and get's removed after a while (like 10sec) with messages like:

*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:1927):invoke_NPP_SetWindow: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2537):invoke_NPP_HandleEvent: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2537):invoke_NPP_HandleEvent: assertion failed: (rpc_method_invoke_possible(plugin->connection))


(sometimes it even works as expected and window is properly restored back.
Moreover with Option "DRI" "off" which gets unusable slow fullscreen mode - it seems to return actually quite reliable always - with XV there is probably some race.)

Anyway - with using 32bit plugin on 64bit firefox the problem doesn't look that bad and fullscreen window doesn't obscure desktop screen 'forever'.

So the key point here is usage of 64bit plugin  (10.0 r45 in my case) which triggers some bug and leaves irremovable X-Window on the screen.

So any idea what should you I look for now ?
I've wanted to bisect - but it seems intel driver is somewhat tightly bind to kernel & Xorg version - so I can not go backward easily to find usable version (if there every existed such)
~

I tried the latest git version of xf86-video-intel-2.12.0 with kernel 2.6.35.2. With that, the issue still persists. The stability seems to have gone down compared to my comment #55: it took only a few cycles before the whole window manager was so unusable that I voluntarily killed X from another console.

@Zdenek: I am also using 64 bit flash 10.0 rc45. I could accept a faulty application (flash) but it is not on to take down the whole system. ;-)

The only solution I can think of, is to strace X server and upload this log here.

How it can be done?

1) Run Firefox and open any flash video, do not play it

2) Go to any text console (Ctrl+Alt+F1-F6), login as root, find X server PID (ps ax | grep X), then run strace:

strace -fF -p pid_of_X_server -o /tmp/Xserver.log

3) Go back to X server (Ctrl+Alt+F7), start playing video in full screen

4) as soon as your X server hangs, go back to text console and stop strace (Ctrl + C)

5) Compress this log (bzip2 -9 or xz -9) and upload it somewhere (e.g. mediafire.com) so that developers could see what's going on.

In the meantime it seems like Intel X driver development has stalled (http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/) - Intel can fork out $7 billions to buy McAffee, but they cannot hire a few more devs to solve critical problems (this bug report is just one of them, another problem is a horrible OpenGL performance of the Intel Linux drivers).

Have you tried Chris Wilson's patch on the intel-gfx list:

It is claimed to fix https://bugs.freedesktop.org/show_bug.cgi?id=29584 but I think it fixes my flash hangs. The description is:

Marty Jack reported an issue he found where the page-flipping handler
was being lost on server reset. This results in the swap completion
notification being lost, with the sporadic hang of full screen
applications like Compiz, flash and even glxgears!

Fixes:

  Bug 29584 - Server in compute loop
  https://bugs.freedesktop.org/show_bug.cgi?id=29584

There are also several possibly related bugs with similar symptoms, i.e.
OpenGL applications hanging on missed swap notifications.

(In reply to comment #77)
> Have you tried Chris Wilson's patch on the intel-gfx list:

I noticed the patch is part of the latest git master branch of xf86-video-intel, so I pulled & installed that. The bad news is, I still got flickering and an eventual segfault when repeatedly maximizing/minimizing a flash video.

[426158.738] 0: /usr/bin/X (xorg_backtrace+0x28) [0x45db98]
[426158.738] 1: /usr/bin/X (0x400000+0x5a839) [0x45a839]
[426158.738] 2: /lib64/libc.so.6 (0x7f90d4ecd000+0x33620) [0x7f90d4f00620]
[426158.738] 3: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f90d2e3c000+0x27b20$
[426158.738] 4: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f90d2e3c000+0x1d415$
[426158.738] 5: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f90d2e3c000+0x1f6fa$
[426158.738] 6: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f90d4418000+0x$
[426158.738] 7: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f90d4418000+0x$
[426158.738] 8: /usr/bin/X (0x400000+0x46da4) [0x446da4]
[426158.738] 9: /usr/bin/X (0x400000+0x2242a) [0x42242a]
[426158.738] 10: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f90d4eebb6d]
[426158.738] 11: /usr/bin/X (0x400000+0x21fe9) [0x421fe9]
[426158.738] Segmentation fault at address 0x40
[426158.738] 
Fatal server error:
[426158.738] Caught signal 11 (Segmentation fault). Server aborting

When I find some time this weekend I shall try strace.

(In reply to comment #78)

> When I find some time this weekend I shall try strace.

well, I tried. Strace breaks when maximizing the video for the first time. The stderr output on the screen is:

root@arnold$ strace -f -tt -p 2026 -o /tmp/Xserver.strace.log
Process 2026 attached - interrupt to quit
*** glibc detected *** strace: malloc(): memory corruption (fast): 0x00000000010c1ff0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x76ce6)[0x7f5fd5154ce6]
/lib64/libc.so.6(+0x7afe9)[0x7f5fd5158fe9]
/lib64/libc.so.6(__libc_malloc+0x6e)[0x7f5fd5159c8e]
strace[0x4094c8]
strace[0x40697c]
strace[0x40442e]
strace[0x405434]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f5fd50fcb6d]
strace[0x402cf9]
======= Memory map: ========
00400000-0042c000 r-xp 00000000 08:05 454729                             /usr/bin/strace
0062b000-00648000 rw-p 0002b000 08:05 454729                             /usr/bin/strace
00648000-00657000 rw-p 00000000 00:00 0
010c1000-010e2000 rw-p 00000000 00:00 0                                  [heap]
7f5fd0000000-7f5fd0021000 rw-p 00000000 00:00 0
7f5fd0021000-7f5fd4000000 ---p 00000000 00:00 0
7f5fd4ec8000-7f5fd4ede000 r-xp 00000000 08:05 456824                     /usr/lib64/libgcc_s.so.1
7f5fd4ede000-7f5fd50dd000 ---p 00016000 08:05 456824                     /usr/lib64/libgcc_s.so.1
7f5fd50dd000-7f5fd50de000 rw-p 00015000 08:05 456824                     /usr/lib64/libgcc_s.so.1
7f5fd50de000-7f5fd5249000 r-xp 00000000 08:05 131084                     /lib64/libc-2.11.1.so
7f5fd5249000-7f5fd5449000 ---p 0016b000 08:05 131084                     /lib64/libc-2.11.1.so
7f5fd5449000-7f5fd544d000 r--p 0016b000 08:05 131084                     /lib64/libc-2.11.1.so
7f5fd544d000-7f5fd544e000 rw-p 0016f000 08:05 131084                     /lib64/libc-2.11.1.so
7f5fd544e000-7f5fd5453000 rw-p 00000000 00:00 0
7f5fd5453000-7f5fd5473000 r-xp 00000000 08:05 131198                     /lib64/ld-2.11.1.so
7f5fd5648000-7f5fd564b000 rw-p 00000000 00:00 0
7f5fd5670000-7f5fd5672000 rw-p 00000000 00:00 0
7f5fd5672000-7f5fd5673000 r--p 0001f000 08:05 131198                     /lib64/ld-2.11.1.so
7f5fd5673000-7f5fd5674000 rw-p 00020000 08:05 131198                     /lib64/ld-2.11.1.so
7f5fd5674000-7f5fd5675000 rw-p 00000000 00:00 0
7fff22909000-7fff2292a000 rw-p 00000000 00:00 0                          [stack]
7fff229ff000-7fff22a00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

I uploaded the compressed strace here:
http://www.mediafire.com/file/rsnznmsase4f1k5/Xserver.strace.log.xz

Note: the strace does not include the actual error situation I was trying to capture.

I've tested with some latest git tree for DRM & Intel driver
(drm: b61e81a191d3a5c269c5f7c40199aebc9ebc034c (nouveau: accept both 0.0.16)
 intel:104cd0554bde1d109a54db7a93700d5edfabd914 (Add sandybridge D0 support)
and linux 2.6.36-rc2 (9ee47476d6734c9deb9ae9ab05d963302f6b6150)

and I could still hit bug relatively easily with some flash videos.
(specifiably flash video on  tv.sme.sk seems be quite killer one)

I'll try to add some trace with  drm.debug (if someone has some specific number I should try to use?)

I've also checked some patched in git log history and notices that
some ->busy are set to  -1 - some others to 1 and check is only for -1 -
anyway setting all '1' to '-1' didn't helped either.

I'll attach Xorg strace & Xorg.log though I doubt these would be usefull.

What I've noticed is - when I enable lockdep checking (lockdep.prove_locking=1 lockdep.lock_stat=1) - thus slowing machine somewhat down - it's much much harder to trigger fullscreen deadlock - so it looks like it's some timedepending bug.

Also I've tested with enabled (as you could see in provided attachments)
 Option "DebugFlushCaches" "true"
 Option "DebugFlushBatches" "true"
 Option "DebugWait" "true"
 Option "FallbackDebug" "true"

And it also was no help.

Created attachment 38124 [details]
Xorg log output

Compressed strace output from Xorg process - from moment when  xterm & metacity & firefox was running on the screen with flash video running - switch from VT console to Xorg screen and flipping fullscreen in flash video until it stays olny in fullscreen mode.

Created attachment 38125 [details]
Strace output from Xorg

Ooops sorry - this is real strace.

Attachment from comment 81 is actually Xorg log trace with enabled some debuging option in xorg.conf (and driver is compiled with I830DEBUG define)

Hello, I only want to mention that I and other user have checked that this bug is posterior to 2.9.1 version.
In 2.9.1 version this works well.

(In reply to comment #83)
> Hello, I only want to mention that I and other user have checked that this bug
> is posterior to 2.9.1 version.
> In 2.9.1 version this works well.

Well - maybe for you - but on my T61

with kernel 2bfc96a127bc1cc94d26bfaa40159966064f9c8c  - 2.6.36-rc3
and today's git for intel driver (2b96c18165d713cd6781dbf217ec33e11cc961bc)
and drm library - I'm still able relatively quickly destroy my Xserver session with   64bit flash and firefox. (usually 2-3   fullscreen-window switches on flashes from tv.sme.sk) So the bug is definitelly still there.

I assumed Rafael meant that it only occurred _since_ 2.9.1.  The general consensus for most users seems to be that things started going bad around the 2.10.0 mark - that's certainly true for me.  Although "posterior" is an odd word to use, and I was unsure what he meant by this.

confirming bug still present with 2.6.36-rc4. 

Btw, I noticed a few short periods of black screen during the boot sequence - maybe as a result of all the vblank changes in the kernel code recently. However, these blackouts would be subject of a separate bug report.

I meant, we cannot reproduce this bug with 2.9.1 driver version.
With the latest snapshot I tested, I don't obtain a X freeze, just the player image is gone and I see all playback in black. The sound is still alive as always.

I have upgraded to:

libdrm-2.4.22
mesa-7.9
xf86-video-intel-2.13.0
pixman-0.19.4
cairo-1.10.0

kernel is 2.6.36-rc4, xorg-server is 1.8.2.

unfortunately flash will still freeze the display when repeatedly maximizing and miimizing the flash window.

Other noticeable differences: a couple of blackouts when first logging on (as if the monitor re-syncs) and a lot of kwin crashes when trying to trigger the flash issue.

(In reply to comment #88)
> unfortunately flash will still freeze the display when repeatedly maximizing
> and miimizing the flash window.
> 
> Other noticeable differences: a couple of blackouts when first logging on (as
> if the monitor re-syncs) and a lot of kwin crashes when trying to trigger the
> flash issue.

Purely for 64bit flash users - latest available 10.2 d161 build from Adobe doesn't lock screen in fullscreen mode - on the other hand - this is only invisible cache file from flash video...
(At least that's my current impression - haven't see a lock from flash - even thought with older version it's quite easy to achieve)

(In reply to comment #89)
> Purely for 64bit flash users - latest available 10.2 d161 build from Adobe
> doesn't lock screen in fullscreen mode 

that's great news. do you happen to have a download URL? I cannot find it.

I still think the issue needs fixing, btw, because a user space program should not be allowed to crash the X server.

OK, I have found this:
http://download.macromedia.com/pub/labs/flashplayer10/flashplayer_square_p2_64bit_linux_092710.tar.gz

The FAQ by Adobe Labs might also be interesting:
http://labs.adobe.com/technologies/flashplayer10/

will report back.

(In reply to comment #91)
> will report back.

jury is back.

I find 10.2 is indeed more stable than 10.0. In the sense that where before it took 20 cycles it now takes 50 or 100. However, eventually I got flickering, jerky video playback, oscillating between two frames, a kwin crash and finally a hanging display. I could kill X from a text console and all was starting up again fine.

It all seems visually related to the switching of frame buffers. I had no hard crash of any sort.

(In reply to comment #92)
> (In reply to comment #91)
> > will report back.
> 
> jury is back.
> 
> I find 10.2 is indeed more stable than 10.0. In the sense that where before it
> took 20 cycles it now takes 50 or 100. However, eventually I got flickering,
> jerky video playback, oscillating between two frames, a kwin crash and finally
> a hanging display. I could kill X from a text console and all was starting up
> again fine.

Hmm - never tried so many times - in fact my Xserver gets killed faster because of  suspend/resume hang -  which is now completely broken - as the bug seems to be non-trivial to trigger - but the last reliable kernel for resume was 2.6.35 - current version 2.6.36-rcX have some strange bug inside....

(In reply to comment #93)
> Hmm - never tried so many times - in fact my Xserver gets killed faster because
> of  suspend/resume hang -  which is now completely broken - as the bug seems to
> be non-trivial to trigger - but the last reliable kernel for resume was 2.6.35
> - current version 2.6.36-rcX have some strange bug inside....

funny, on this machine I have no problems with suspend and resume, but on another one I could not resume with 2.6.35, most likely due to the i915 kernel driver. The problem has never been found but was gone with 2.6.36-rc4.

some update: I have upgraded my distro to its "current" branch (due to another issue with intel video). The coponent versions now are:

xorg 1.9.2
xf86-input-evdev 2.5.0
xf86-video-intel 2.13.0
libdrm 2.4.22
mesa 7.9
cairo 1.10.0
kde 4.5.1
kernel 2.6.36

Unfortunately this hasn't solved the flash problem. On the contrary, it has gone worse: it now takes only a few clicks to trigger the bug.

quick update: i have upgraded the kernel to 2.6.37. when maximising a flash video, the screen froze immediately. However, switching between virtual terminals was quite possible, and the X server could be cleanly shut down using Ctrl-Alt-Backspace.

The root cause is:

commit 53fbc9f1760ee481cba1f6dceb9e7c97282a2976
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Dec 30 15:32:40 2010 +0000

    Don't replace the scanout bo through PutImage
    
    As the bo may be pinned for either use by the scanout or through sharing
    with another application, under those circumstances we cannot replace
    the bo itself but must force the blit for PutImage.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31367
    Reported-and-tested-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

After some googling I found out that the patch is for the xf86-video-intel tree. I found it surprising that a patch dated 30th December 2010 could be responsible for a problem almost a year old, and only recently confirmed for 2.13.0.

So I got the latest git version xf86-video-intel, built a new slackware package and ran a test. I had to build and install a package for libdrm-2.4.23 beforehand since that is a dependecy.

Unfortunately the display froze yet again after the second maximization of a flash video. Currently on the latest flash square 64 bit beta plugin, version 10.2 as of 2010-11-17. 

Sorry, I'll have to re-open this ticket.

Well - I've rechecked progress - 
recompiled todays  intel & drm driver - and I'm running 2.6.37 kernel.

Behavior seems to be different now.

I'm using still 'older' version of 64bit flash plugin (for its ability to create readable /tmp/ files).  And for now - I've not 'yet' got any screen 'deadlock' - i.e. switch between fullscreen and window playback seems to work for many different video types.

However now the problem now seems to be different for some videos - after switch back from fullscreen the windowed playback no longer updates its windows.
(i.e. videos from  http://tv.sme.sk)

so the movie is played - sound works - but no new frames are rendered in the window - after switch back to fullscreen everything plays fine - switch back to windows - and nothing is rendered.

Probably windowed version updates picture somewhere - but this buffer is not rendered on the screen.

we should have thrown a party when this bugzilla entry had its one year anniversary...

Anyway, I have tried to maximize a flash video today on my Clarkdale machine. On the first try the user session crashed back to the logon manager. Note this is a different (better!) system reaction than what has been reported in the beginning of this bug report, but still not quite satisfactory.

In the system logs I find:

[202824.024] 
Backtrace:
[202824.030] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a02d8]
[202824.030] 1: /usr/bin/X (0x400000+0x60fc9) [0x460fc9]
[202824.030] 2: /lib64/libc.so.6 (0x7f4524a97000+0x340b0) [0x7f4524acb0b0]
[202824.030] 3: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f452294d000+0x42970) [0x7f452298f970]
[202824.030] 4: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f452294d000+0x36319) [0x7f4522983319]
[202824.030] 5: /usr/lib64/xorg/modules/dri/i965_dri.so (0x7f452294d000+0x3892a) [0x7f452298592a]
[202824.030] 6: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f4523fda000+0x35d23) [0x7f452400fd23]
[202824.030] 7: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f4523fda000+0x38463) [0x7f4524012463]
[202824.030] 8: /usr/bin/X (0x400000+0x2def1) [0x42def1]
[202824.030] 9: /usr/bin/X (0x400000+0x21ffe) [0x421ffe]
[202824.030] 10: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f4524ab5e5d]
[202824.030] 11: /usr/bin/X (0x400000+0x21bb9) [0x421bb9]
[202824.030] Segmentation fault at address 0x40
[202824.030] 
Fatal server error:
[202824.030] Caught signal 11 (Segmentation fault). Server aborting

The release levels currently installed:

kernel 2.6.38.6 with CK patch (including BFS v0.401)
libdrm-2.4.25-x86_64-1
xf86-video-intel-2.15.0-x86_64-1
xorg-server-1.9.5-x86_64-1
mesa-7.10.2-x86_64-1
flash-player-plugin-10.2.111710-x86_64-1mr
mozilla-firefox-4.0.1-x86_64-1

In the lastes Ubuntu 11.04 I can reproduce this issue in KDE, but not in GNOME, nor in KXDE. In previous distributions I used to reproduce this also in GNOME.
Does it might be mesa related issue?

It's definitely not DE related, but different DE's have different compositing managers (or you can run them without compositing at all) - so that can cause a difference.

*** Bug 35126 has been marked as a duplicate of this bug. ***

Created attachment 46866 [details]
Xorg backtrace

I can reproduce with this setup
System environment:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03)
-- system architecture: i686
-- xf86-video-intel: git-9d6e02a135efdea1d169d1938359ab2b553e941c
-- xserver version: git-0e7f61d72c4a929319e57c9b5b777e9413c23051
-- mesa version: git-355944087365a963d01deb5fcd6727dfd5360470
--libdrm version: git-61be94018ae9c403517d53f69357719224fa6ff3
-- kernel version: git-c1d10d18c542278b7fbc413c289d3cb6219da6b3
-- Linux distribution: Gentoo Linux
-- Machine or mobo model: Toshiba Satellite A105-S4094
-- Display connector: LVDS1 connected 1280x800+0+0 (normal left inverted right
x axis y axis) 289mm x 2100mm

I'm seeing this bug on my Lenovo T420 with the integrated intel HD Graphics 3000.

The problem also occurs on programs like VLC and Xine.

Have the developers of the driver been able to reproduce the problem, would any more information be useful?

*** Bug 32766 has been marked as a duplicate of this bug. ***

Considering that all the remaining reports have focused on mesa (with multiple generations), have you confirmed that the bug is still present in recent mesa?

Assuming fixed, if not can you please open a report per mesa driver.