Bug 6429

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 :)