Xorg freezes randomly when using dri with radeon 7000 cards and the ati or radeon driver. Uncommenting dri in Xorg.conf stops this. Please, tell me which further information you need to fix this bug. Downstream bugreport: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/16873
This bug has been fixed in the release cylce of Ubuntu Dapper Drake, I assume that this has been fixed in DRI, too.
ok, happened again.
Also getting the same hang with the ff. configuration: Video Chipset: "ATI Radeon VE/7000 QY(AGP/PCI)" (ChipID=0x5159) Motherboard Chipset: SiS735 Kernel version: 2.6.13 Slackware 10.2 Running a simple program like gears will cause hangs within a minute. Not using a framebuffer console, dropping down to 1024x768x16-bit instad of higher resolutions at 24-bit don't make a difference.
Hello, I think it may also be relate to EXA versus XAA as AccelMethod. Same issue happens on this box: - Gentoo i686, kernel vanilla 2.6.16.5 - ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (ChipID = 0x5159), on AGP 4x bus - X Window System Version 7.0.0, with only xorg's ATI driver (version 6.5.8) radeon driver compiled - dri and glx enabled in xorg.conf The freeze is highly reproducible and happens after 2-5 seconds of dragging around a glxgears window ALWAYS and ONLY when Option "AccelMethod" is set to "exa" in xorg.conf AND gnome has a background image set. When AccelMethod is not set so that it reverts back to xaa OR gnome has a solid color background (no image), everything works perfect and fast. That said, I don'use exa and I'm totally happy with performance and stability. Hope it helps, ilGino
Is everybody here running on x86_64? Can you try whether the DRM from DRI CVS makes a difference?
I am not running x86_64, I am running x86. I'll try the drm from the cvs.
I want to add that I've been encountering theses random freezes, whether or not DRI was enabled or disabled, though I haven't figured out precisely which activity causes it (seems completely random, at this point). My machine is an x86, latest ubuntu dapper, radeon 7000.
I can confirm similar behavior when enabling dri with the 'ati' xorg driver. The system just freezes randomly at any point in time. I also tried the commercial ati driver with dri and the same thing happens. I am running ubuntu dapper drake on the latest updates as of 5/28/06. This problem is resolved when dri is disabled in the xorg.conf. If there is any more info I can provide, please let me know! Thanks.
My config is a Thinkpad T30 with Radeon 7500 Mobility and it freezes with and without dri. I am running Dapper with all latest updates. Switched to using "vesa" driver and so far has been stable. This bug started with Breezy and continues to Dapper. Not on Hoary.
I suggest , to try disable Accel Option "NoAccel" "boolean" Enables or disables all hardware acceleration. The default is to enable hardware acceleration. I think in Fedora 5, they workaround with disable accel
Created attachment 5781 [details] logfile of freezed Xorg
It's been reported that this doesn't happen in depth 16 instead of 24, can you confirm that?
I can confirm that it still freezes in 16 bit or 24 bit. The only thing that stops it from freezing is disabling DRI. This system is Dual P4 800 MHZ, running Ubuntu Dapper, 2.6.22-34 kernel, 768 MB ram, Radeon 7000 VE w/ 32 mb onboard mem. Jeff
let me also add this to my previous comment. This machine is also dual boot w/ Win XP, and this problem is non-existent in Windowx XP, so I am pretty sure that there is nothing wrong w/ the card. Also, I have a Radeon 7500 QV in a different machine that works flawlessly under both win and linux, as well as DRI. This only happens on the 7000 under linux. Jeff
Hello, just upgraded this gentoo box: - xorg X Window System from 7.0.0 to 7.1.0 - xorg's ATI driver from 6.5.8 to 6.6.0 - mesa from 6.4.2 to 6.5 and the freeze seems not to happen any more, neither with XAA nor with EXA (which in turn feels less responsive than XAA). Some other minor packages were upgraded which I didn't take note of, so I'm not sure if this improvement is related only to the three packages I mentioned before. DRI is enabled and working as before. This machine is not AMD nor x86_64, it'a a plain old Pentium 4 with intel 815/845 chipset and ATI Radeon RV100 QY [Radeon 7000/VE] (ChipID = 0x5159) on AGP 4x bus (configured in xorg.conf and confirmed in Xorg.log). Hope this helps, ilGino
Hello, one more upgrade a few days ago: - xorg's ATI driver from 6.6.0 to 6.6.1 and everything still seems to work fine either with XAA or with EXA (which in turn feels less responsive than XAA). One warning I noticed in Xorg.log: (WW) RADEON(0): [dri] limiting video memory to one aperture of 65536K (WW) RADEON(0): [dri] detected radeon kernel module version 1.22 but 1.23 or newer is required for full memory mapping. So, after I checked that radeon module in kernel source 2.6.17 has upgraded from 1.22 to 1.24 in radeon_drv.h, I switched from kernel 2.6.16.20 to 2.6.17. With the new kernel I have to report no visibile issues for now: DRI is working, XAA and EXA are working, no hangs, I will tell you in case of problems. BTW this is the diff between 2.6.16.20 and 2.6.17 Xorg.log: 6c6 < Current Operating System: Linux mybox 2.6.16.20 #1 Sun Jun 11 09:45:33 CEST 2006 i686 --- > Current Operating System: Linux mybox 2.6.17 #1 Sun Jun 25 09:30:10 CEST 2006 i686 14c14 < (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jun 25 08:00:59 2006 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jun 25 09:34:50 2006 438c438 < (II) RADEON(0): [dri] Found DRI library version 1.2.0 and kernel module version 1.22.0 --- > (II) RADEON(0): [dri] Found DRI library version 1.2.0 and kernel module version 1.24.0 449,450d448 < (WW) RADEON(0): [dri] limiting video memory to one aperture of 65536K < (WW) RADEON(0): [dri] detected radeon kernel module version 1.22 but 1.23 or newer is required for full memory mapping. 659c657 < (II) RADEON(0): [drm] mapped SAREA 0xd08a3000 to 0xb7b36000 --- > (II) RADEON(0): [drm] mapped SAREA 0xd08a3000 to 0xb7bf6000 665c663 < (II) RADEON(0): [agp] Ring mapped at 0xb393e000 --- > (II) RADEON(0): [agp] Ring mapped at 0xb39fe000 667c665 < (II) RADEON(0): [agp] Ring read ptr mapped at 0xb393d000 --- > (II) RADEON(0): [agp] Ring read ptr mapped at 0xb39fd000 669c667 < (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0xb373d000 --- > (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0xb37fd000 671c669 < (II) RADEON(0): [agp] GART Texture map mapped at 0xb325d000 --- > (II) RADEON(0): [agp] GART Texture map mapped at 0xb331d000 673a672 > (**) RADEON(0): DRI New memory map param 723c722 < (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xf47ff400 --- > (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xec7fec00 Ciao, ilGino
If you're still experiencing this, please try current xf86-video-ati git. There's been a DRI stability fix specifically for RV100 and R300 derivatives.
I am also experiencing this bug. It is extremely easy to freeze my machine by opening certain applications and dragging their window frames. I am on FC5 and have a Radeon x300 running at 1600x1200. I believe this should be a high priority bug. Turning off acceleration (via "NoAccel") _does_ fix this bug, but at 1600x1200 it is hard to use X without acceleration! As a result, my FC5 box is essentially unusable; I've had no better than ten minutes of uptime when logged in directly. I am fully yum updated and the bug does not appear to be fixed. Please let me know what I can do to help pin down this problem. If you need me to do some code spelunking or use specific development/debug tools, let me know.
(In reply to comment #18) > I believe this should be a high priority bug. Turning off acceleration > (via "NoAccel") _does_ fix this bug, but at 1600x1200 it is hard to use X > without acceleration! Just disable DRI then.
Did Michaels suggestion help?
In my case, the issue was due to a Red Hat patch (backported from upstream) to stabilize hardware rendering on Radeon 7xxx hardware. See this link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180150 and in particular comments #5 and #14 where I had reported that a certain vendor specific patch was the culprit. There was a later update upstream by M. Dänzer documented at: https://bugs.freedesktop.org/show_bug.cgi?id=4324 which fixed the issue for me (dropping the patch as a whole also worked).
Ok closing this one too, seems we have a bunch of duplicated bug see #5111, #5104. Reopen if you still experience this bug with recent xorg/dri/drm.
Oups wrong button :)
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.