Bug 15824 - Radeon lockup when another window is moved over Xv [TexturedVideo] window
Summary: Radeon lockup when another window is moved over Xv [TexturedVideo] window
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-04 22:35 UTC by David Korth
Modified: 2008-06-26 22:07 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.log from current session (159.44 KB, patch)
2008-05-06 06:03 UTC, David Korth
no flags Details | Splinter Review

Description David Korth 2008-05-04 22:35:31 UTC
When moving a window over an Xv window (such as mplayer), occasionally the system freezes. I've been able to reproduce this consistently.

Test setup: ThinkPad T60p (FireGL V5200), 1600x1200 LCD with 1600x1200 CRT on the left of the LCD.

1. Start mplayer, fullscreen on the CRT.
2. Start OpenOffice or another program with a large window.
3. Drag the window on top of mplayer, and then drag it off of mplayer.

Sound will continue playing, but everything else will be unresponsive. The mouse pointer may continue moving, but it's slow and jerky.

Using radeon git: 24b60c8965f6a0b3f0c2bb1e7236b4d6642c5918
Using xorg-server: 1.4.0.90-r3 (Gentoo)
Comment 1 David Korth 2008-05-04 22:36:06 UTC
I'm using Xv with TexturedVideo because overlay mode is not supported on R500 via the radeon driver.
Comment 2 Alex Deucher 2008-05-06 03:16:49 UTC
Do you have the drm loaded? You need to.  Use of the 3D engine via the MMIO path has issues at the moment.  Also, can you attach your xorg log?
Comment 3 David Korth 2008-05-06 06:03:44 UTC
Created attachment 16385 [details] [review]
Xorg.log from current session

I'm using the latest DRM from the r345-cleanup branch. (X crashes after kdesktop loads if DRM isn't loaded, but that's a whole different thing.)

Here's my current Xorg.log. I can try getting an Xorg.log from a crashed session if you need it. (I think ssh is still working when X locks up.)
Comment 4 Alex Deucher 2008-05-06 06:21:31 UTC
(In reply to comment #3)
> Created an attachment (id=16385) [details]
> Xorg.log from current session
> 
> I'm using the latest DRM from the r345-cleanup branch. (X crashes after

Does drm git master work ok or does it have the same issue?

> kdesktop loads if DRM isn't loaded, but that's a whole different thing.)
> 

That's probably the MMIO issue I mentioned above.

Comment 5 David Korth 2008-05-06 06:26:48 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=16385) [details] [details]
> > Xorg.log from current session
> > 
> > I'm using the latest DRM from the r345-cleanup branch. (X crashes after
> 
> Does drm git master work ok or does it have the same issue?
> 
drm git master has the same problem. I tried out r345-cleanup to see if that fixed it, but it didn't.
Comment 6 David Korth 2008-06-03 21:15:03 UTC
Just noticed that this line appears at the end of xorg.log every time this crash happens:

exaCopyDirty: Pending damage region empty!

I'll try reproducing this with EXA disabled and see if that helps.
Comment 7 Michel Dänzer 2008-06-04 01:42:05 UTC
(In reply to comment #6)
> exaCopyDirty: Pending damage region empty!

That's a harmless line you'll see pretty much always - the damage layer doesn't filter out 'empty' operations.
Comment 8 Andy Furniss 2008-06-04 07:30:47 UTC
I wonder if setting Option "GARTSize" "32" in your device section will help some of your problems.

I run that on r5xx and can't reproduce most of them.

I have, however found one reproduceable mplayer/xv lock up (SysRq able).

Pressing f to get fullscreen when playing always locks up - tried with twm,metacity and compiz.

However getting fullscreen with mplayer -fs always works OK, as does sizing/maximising windows.
Comment 9 Michel Dänzer 2008-06-04 08:53:08 UTC
(In reply to comment #8)
> I wonder if setting Option "GARTSize" "32" in your device section will help
> some of your problems.

GARTSize only matters with OpenGL apps.
Comment 10 Andy Furniss 2008-06-04 11:37:57 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I wonder if setting Option "GARTSize" "32" in your device section will help
> > some of your problems.
> 
> GARTSize only matters with OpenGL apps.
> 

Ahh Ok, I thought that because r500 only uses textured video and needs drm it would be relevant.

FWIW I just found a workaround for my mplayer crash - not much use for compiz but

Option "Composite" "false" in Extensions fixes it.

Comment 11 Andy Furniss 2008-06-15 15:25:26 UTC
(In reply to comment #8)

> I have, however found one reproduceable mplayer/xv lock up (SysRq able).
> 
> Pressing f to get fullscreen when playing always locks up - tried with
> twm,metacity and compiz.
> 
> However getting fullscreen with mplayer -fs always works OK, as does
> sizing/maximising windows.
> 

This is now fixed by the DRM lockup commits.
Comment 12 David Korth 2008-06-26 20:38:17 UTC
The original lockup problem appears to be fixed now. I can drag windows on top of Xv/TexturedVideo windows without the system locking up.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.