I'm sorry, I don't know which version of the radeon driver is in debian's xserver-xorg-video-ati packages, I hope you can help me out here. Anyway, here's the problem: On xserver-xorg-video-ati versions greater than 1:6.6.3 (like in Debian Lenny or Ubuntu Feisty) the X server freezes when using Compiz or other 3D applications like tuxracer. With Compiz on Gutsy (xserver-xorg-video-ati 1:6.7.195) or Hardy (1:6.7.0) it takes about 20 minutes until it freezes, sometimes less. X freezes immediately when trying to run a 3D game. This is not the case on a current install of Debian testing (Lenny) or Ubuntu Feisty. I started a bugreport on Launchpad with additional information: https://bugs.launchpad.net/bugs/195051 And here's another report for that issue: https://bugs.launchpad.net/bugs/108527 I couldn't find any information if the problem is already known around here. Please let me know if you need any further informations.
I have exactly the same problem with Gutsy + 6.8.0 I'm using the ppa packages: http://ppa.launchpad.net/tormodvolden/ubuntu/ Thank you for the driver. Good luck. N.
I can confirm this with Ubuntu Hardy (current as of 2008/03/21) on two systems, both using the xserver-xorg-video-ati driver. One is a ThinkPad T40 with the ATI Mobility 9000 (ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000]), and the other is a workstation with an ATI X600 (ATI Technologies Inc RV380 [Radeon X600 (PCIE)]). Both exhibit the freezing behaviour described above, usually leaving only the mouse cursor active. The system is unresponsive to mouse clicks or keyboard events other than Alt+SysRq which can be used to "safely" restart the system. I haven't been able to reproduce this bug with any reliability. It seems to happen randomly when using Compiz.
This is also in Ubuntu bug https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/195051 , which has some backtraces and additional information on the bug.
I talked with Alex at XDC2008 yesterday about this. He felt it was due to wrongly guessed registered back before the AMD documentation releases, that can now be fixed up by redoing those mappings; this is work he plans to undertake within the next 3-6 months. Backtrace (while running Bubble3D screensaver): http://launchpadlibrarian.net/12894430/backtrace-bubble3d Backtrace (while running Extreme Tuxracer game): http://launchpadlibrarian.net/12895009/backtrace-etracer The music continues playing, but the X screens are frozen Backtraces (without full symbols): * http://launchpadlibrarian.net/12863959/backtrace2 * http://launchpadlibrarian.net/12177917/Xorg-lockup.txt * http://launchpadlibrarian.net/12172793/gdb Sample Xorg.0.log's: * http://launchpadlibrarian.net/12433344/Xorg.0.log * http://launchpadlibrarian.net/12172839/Xorg.0.log Workarounds (not widely verified): * Option "AGPMode" "1" - but hinders performance
Frustrated by the freeze in Ubuntu Hardy (current), I decided to try Fedora 8 to see if there was any difference. In three weeks of running Fedora 8 with Compiz enabled, I have yet to see the freeze. The Fedora version of the driver is also 6.8.0-1, although I have no idea if they've modified it in any way. Has this bug been confirmed on any distributions other than Ubuntu 7.10 and 8.04?
I'm also having this same problem on my hardy heron installation. It's upto date at time of writing and uses an ATI Radeon 9800pro and the opensource ATI driver. It will seemingly randomly lockup everything is unresponsive apart from the mouse cursor, i have accessed the computer in this state as SSH seems to still work and running the top command shows compiz.real using up all available cpu and using sudo kill -9 i'm able to regain use of that pc again (just loosing the window decorations). If there is anything needed to further aid the resolution of this bug please ask and i can try to help (but with the freezes being quite random and my time limited i might not be able to check this report to regularly). PS: I'm currently only assuming this issue is related to the driver, it could be compiz itself but reading this bug description and the related launchpad.net bug it seems more likely my problem is the same as described here.
(In reply to comment #5) > Has this bug been confirmed on any distributions other than Ubuntu 7.10 and > 8.04? > I was able to reproduce this bug on Debian sid (xserver-xorg-video-ati 1:6.8.0) and Arch Linux (xf86-video-ati 6.8.0).
Has anyone tested with xf86-video-ati from git master and the drm from git master? There are several commits to both that may help. Relevant commits: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=0a96173cc38e506728d4c3f2dd383ba56e856578 http://cgit.freedesktop.org/mesa/drm/commit/?id=1674d2817929fe4ee4e1c4762e89600119dbdc50 http://cgit.freedesktop.org/mesa/drm/commit/?id=753a4bdf1b554490f7b288c0203050b5114433c3
I try this morning and the problem is still there. Freeze after some time of using compiz.
Do either of the following options help? Option "BusType" "PCI" Option "AGPMode" "1"
I flipped on EXA last night, and it seems to have solved the issue (that or some Ubuntu bug pushes). Anyway, here's my relevant information: Ubuntu Hardy Heron 8.04 (fully updated) uname -r: 2.6.24-16-generic dpkg -l | grep xserver-xorg-video-ati: ii xserver-xorg-video-ati 1:6.8.0-1 X.Org X server -- ATI display driver Xserver version: 1.4.0.90 I'm running an ATI FireGL v3200 (M24 GL 3154 PCIE) on a Thinkpad T43p. The relevant part of my xorg.conf is: Section "Device" Identifier "ATI Technologies Inc M24GL [Mobility FireGL V3200]" Driver "radeon" VendorName "IBM ThinkPad" Option "DynamicClocks" "on" Option "XAANoOffscreenPixmaps" "true" Option "AddARGBGLXVisuals" "true" Option "AccelMethod" "EXA" Option "RenderAccel" "true" Option "EnablePageFlip" "true" Option "ColorTiling" "on" BusID "PCI:1:0:0" EndSection The only thing I've changed myself is that I added AccelMethod EXA yesterday, and its hte first time I've gone more than 24 hours without Compiz causing a hardlock. Hope that helps...
(In reply to comment #10) > Do either of the following options help? > > Option "BusType" "PCI" > Option "AGPMode" "1" > Both seem to work around the freeze. At least after a quick tuxracer test. "BusType" "PCI" is painfully slow, though. "AGPMode" "1" results in a somewhat playable tuxracer (but then again, the radeon driver never worked for me satisfactorily when it comes to 3D games) -- I don't have anything to compare, though, because without the option, it (still) freezes instantly.
I just did another test, where I replaced Option "AGPMode" "1" with Option "DynamicClocks" "on" Option "XAANoOffscreenPixmaps" "true" Option "AddARGBGLXVisuals" "true" Option "AccelMethod" "EXA" Option "RenderAccel" "true" Option "EnablePageFlip" "true" Option "ColorTiling" "on" and tuxracer immediately froze again. Maybe I shouldn't have copied *all* of Matt's options but frankly I'm not in the mood for any more trial and error. But Alex, if you need me to do any further testing, just ask. I will stick to "AGPMode" "1" for now and report back if I stumble across any issues.
Sorry for the multiple posts but I just did another test where I only used Option "AccelMethod" "EXA" because it was recommended in my report over at Launchpad. The result was a much more fluent tuxracer that was actually playable. The downside however, is a much slower 2D rendering. For example when moving a window over an area of the desktop with icons, the background flickers. Also moving a window from one viewport to another on Compiz will result in a pretty rough transition. It would be great if we could have the best of both worlds. Adding both options unfortunately doesn't do the trick.
(In reply to comment #14) > Sorry for the multiple posts but I just did another test where I only used > > Option "AccelMethod" "EXA" > > because it was recommended in my report over at Launchpad. > > The result was a much more fluent tuxracer that was actually playable. > The downside however, is a much slower 2D rendering. For example when moving a > window over an area of the desktop with icons, the background flickers. > Also moving a window from one viewport to another on Compiz will result in a > pretty rough transition. > > It would be great if we could have the best of both worlds. > Adding both options unfortunately doesn't do the trick. > EXA preforms pretty well with the latest ati driver from git a recent X server. The root of this problem in your case is that AGP sucks. There are just too many combinations of agp cards and chipsets that only work at specific settings (some only work at 1x, others only work at 4x or 8x, etc.). We've tried both defaults in the driver, but someone's combination always breaks.
I am on the beta of Ubuntu 9.10 (Karmic) and I'm glad to tell you this issue seems to be gone for good. I did not need to create a xorg.conf and set something manually this time. Compiz works out of the box and does not cause X to freeze. I even tried running "Extreme Tuxracer" and while the game runs horribly slow, it does not freeze. According to my Xorg.0.log, I am using the radeon driver so I consider this fixed. Thank you.
Sorry, I obviously spoke too soon. After a couple of days without a problem, X froze just now using Openoffice (and Compiz enabled). reopening...
Is this still an issue with kms or a newer version of the driver?
(In reply to comment #18) > Is this still an issue with kms or a newer version of the driver? I still experience hard systen freezes with latest drivers. Only workaround is to disable AGP completely (radeon.agpmode=-1). Starting KDE4 with OpenGL compositing enabled freezes the system every time; with firefox it takes a while. This started happening with xf86-video-ati git releases around mid-april 2008, with and without KMS. (Mobility 9700, intel 855PM).
This may be a duplicate of bug 28402
I also experienced random freezes after a 3d application ran, but only with kernels newer than 2.6.33. The solution was to change preemption model from preemptible kernel to voluntary kernel preemption. Might this be related?
I can confirm that this has been happening on Ubuntu 12.04 as of 12/17/2012. This usually occurs using compiz when the monitors go into ACPI power save mode. This occurs using both the open source ATI driver, and fglrx.
(In reply to comment #22) > This usually occurs using compiz when the monitors go into ACPI power save > mode. If it only happens at DPMS power save, it's probably not this bug but bug 49761.
Nope, don't think so
(In reply to comment #24) > Nope, don't think so Why not? Have you tried the fix for that?
As I said earlier, it happens identically with both fglrx and xorg-video-ati. If a patch to xorg-video-ati fixes a bug while using fglrx, that would be surprising indeed.
(In reply to comment #26) > As I said earlier, it happens identically with both fglrx and > xorg-video-ati. If a patch to xorg-video-ati fixes a bug while using fglrx, > that would be surprising indeed. Does the patch for xf86-video-ati fix xf86-video-ati?
(In reply to comment #26) > If a patch to xorg-video-ati fixes a bug while using fglrx, that would be > surprising indeed. The component field of this report says Radeon. It's unlikely for fglrx and radeon to be affected by one and the same bug. It's possible that fglrx has a similar bug though.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/3.
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.