Summary: | Radeon lockup when another window is moved over Xv [TexturedVideo] window | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | David Korth <gerbilsoft> | ||||
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
Severity: | normal | ||||||
Priority: | medium | CC: | adf.lists | ||||
Version: | 7.3 (2007.09) | ||||||
Hardware: | x86 (IA32) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
David Korth
2008-05-04 22:35:31 UTC
I'm using Xv with TexturedVideo because overlay mode is not supported on R500 via the radeon driver. 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? 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.) (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. (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. 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. (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. 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. (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. (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. (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. 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.