hello,

I have the same problem on my debian SID. I made many tests for one week. And I
found the problem caused by the radeon driver and not by xorg. The 6.9 version
is also affected. When you add the Option "noaccel" "true" in your xorg.conf,
that runs well.
With 20060113 snapshot, it works.
With 20060327 snapshot, it doesn't work.

So, the problem comes from a patch or a change commited between this two dates.

Are you absolutely sure about the 20060113 snapshot? I ask because I have run
the 20050528 version for a very long time and this one definately has the
problem, too.

Furthermore, in my case it can be that a freeze only occurs after one or two
weeks, in between which everything works perfectly.

So, if you´re right, then the bug was fixed in 20060113 and reintroduced with
20060327 ?

Or, your problem is rather one of the many other "radeon freeze problems"
described in this bugtracker. There are many with reproduceble freezes, so quite
different with this irregular freeze that happens without any commonality
(except running openGL programs at the time of a freeze).

Maybe I try the snapshot. I just have some problems with the install script. It
doesn´t recognize the correct directories on my system. How have you done it,
using also a debian SID?

Michael

Yes, 20060113 snapshot works. But I can't test your 20050528 snapshot, the
radeon module doesn't build with my 2.6.16 kernel.

In order to test the 20060113 snapshot, I build x.org 6.9 from source and apply
the snapshot. With x.org 7.0 and this snapshot, I have the same problem as you.

I found a tip to know if the driver freezes. I notice that my computer always
freezes in some conditions. For instance, I want to insert a "big picture" (300
dpi) into an abiword document, if I move the scroll bar, it freezes. Basicly, I
notice the display of big pictures in some applications (abiword, firefox ...)
freeze my computer.

Can you try this test in order to know if it freeze also your computer ?

Well, I use xorg 7.0, so according to your proposition the dri driver of 060113
shouldn´t work either.

I just opened a 300 dpi scanned picture in firefox with no problem. But I do
have dri turned off at the moment, for once because I need to work and don´t
like any freezes at the moment ( ;-) ). And secondly there is another bug (or
feature) in the dri driver which prevents the CPU from entering power saving
state C3 (https://bugs.freedesktop.org/show_bug.cgi?id=7119), and I need a long
battery life for the moment.

I might try later to see if this is somehow related. However, my experiences
were a bit different. I cannot remember having had any freezes in applications
that don´t use openGL, irrespectable of whether they opened big pictures or not.
On the other hand, nearly all crashes happen within openGL programs (even within
those using only small textures such as chromium).

It will be interesting to hear the opinion of an experienced developer (if
someone is interested at all, this is...).

Best regards,

Michael

BTW.: Yesterday I tried using a different xorg.conf that utilizes MergedFB
(http://mg.pov.lt/xorg.conf). It should give a very nice setup, as you can use
different resolutions on the LCD and the external CRT. You can even have a
Xinerama like setup.

Unfortunately, when switching between the metamodes, the system froze with more
than 50% probability. That was with dri enabled as well as disabled. So it seems
to be another unrelated freeze bug. If there is a good response here on this bug
tracker I will file a bug report for this, too. If nobody cares, well, then I
won´t...

One addition: I decided to try to use EXA instead of XAA. (Don´t know if it
makes any difference at all to openGL or not. But in lack of any founded
suggestions...)

The system still freezes with EXA as well as with XAA. So, no real difference
(except that EXA is way slower and produces drawing artefacts in normal use ->
still very alpha, I guess).

This time I also tried the SysRQ magic keys in the hope to save some more
information to disk, but to no avail. Kernel is completely frozen (and twice I
had data loss on the hd again :( I guess, I don´t feel any longer for testing
any of my own ideas, if not a developer asks for such a test...)

So, now, until someone comes with a good idea, I turn off DRI and at least enjoy
a stable and power saving desktop. ( I just fear that it won´t be easy to make
xgl a working reality on a radeon r100 machine... )

Regards,

Michael

ping...

Anyone interested? Any more data needed? Anything I can do?

I'm running without dri now. Haven't had a freeze since then... (But no Google
Earth, no games, and in the future no xgl :( )

You could try to mount the filesystem where your logfiles are with the sync
option to maybe get some hint in a log file, though it's not certain this will help.
Such irregular freezing bugs are incredibly hard to track down, even more so if
they seem to be restricted to specific hardware (sometimes differences in
graphic card bios can trigger if lockups will happen or not).

Hmm, yes, I see. Especially the unregular lockups are awful to identify. :-(

Two ideas that I'd like to discuss:

1.) insert error debug messages into the dri driver, e.g. writing some status
information to syslog, so that one might be able to find out at least in what
function the freeze happens?

2.) Don't write the syslog messages to the disk, but broadcast them on the
network and log them on a second computer?

But maybe it is simpler to start with a more regular freeze such as bug #7154.
This one is easily reproducible and I guess the developers might be able to make
some educated guesses in what function such a freeze might happen. Then with the
above approach we might be able to identify the function, which may be a start
to find the error...

Unfortunately this bug here is the most problematic at the moment as it occurs
when any OpenGL app is running (last freeze was with Google Earth). Without
finding it, xgl won't be usable. :(

Stéphane Marchesin suggested on IRC that this might be related to GART
texturing. Does setting the environment variable
RADEON_GARTTEXTURING_FORCE_DISABLE=1 make a difference?

If not, does an older version of the 2D driver make a difference, per bug 7154?

(In reply to comment #9)
> Stéphane Marchesin suggested on IRC that this might be related to GART
> texturing. Does setting the environment variable
> RADEON_GARTTEXTURING_FORCE_DISABLE=1 make a difference?
> 

Am I right, that this should be used like:

RADEON_GARTTEXTURING_FORCE_DISABLE=1 googleearth

?

> If not, does an older version of the 2D driver make a difference, per bug 7154?

I will try 6.5.7.3-3, however it has severe distortions on OpenGL apps (not sure
if this is only with MergedFB, however. Will turn off MergedFB to check.)

I will try both suggestions, but with this bug, it may take some time until the
next freeze happens (sometimes just a few minutes, sometimes several hours ...)

(In reply to comment #10)
> 
> Am I right, that this should be used like:
> 
> RADEON_GARTTEXTURING_FORCE_DISABLE=1 googleearth

Yes, or just

export RADEON_GARTTEXTURING_FORCE_DISABLE=1

on the command line or in a shell startup script to make it always used.

First results:

No, 6.5.7.3-3 also freezes with OpenGL (Using GoogleEarth is a good test, it
seems. First freeze within 1 minute :-) )

Without MergedFb the distortions in OpenGL are gone.

Now trying the encvironmen variable (with 6.5.7.3-3).

uuufs, this time it took nearly an hour (and I already thought: That's it!), but
then again: FREEZE.

So, the environment variable did not help, either. (Pity...)


btw. is there a place where I can ask a question about xorg.conf? (no bug, just
a configuration question.)

0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility 
M6 LY
xorg-x11-server-1.1.0
xorg-x11-drv-ati-6.6.1

With 20060707 snapshot, it works.
With 20060717 snapshot, it doesn't work.

xorg.conf
...
Section "Module"
        Load    "dbe"
        Load    "glx"
       Load    "dri"
        SubSection      "extmod"
                Option "omit xfree86-dga"
        EndSubSection
        Load    "type1"
        Load    "freetype"
EndSection
...
Section "Device"
        Identifier      "Radeon 7000"
        VendorName      "ATI"
        BusID           "PCI:1:0:0"
        BoardName       "Radeon Mobility M6 LY"
        Driver          "ati"
        Option          "AGPMode"       "4"
        Option          "AGPFastWrite"  "false"
        Option          "AccelMethod"   "XAA"
EndSection

For what it's worth, I have the exact same problem. Occasional complete system
freeze when using an OpenGL app. I have an ATI X800XT with 8.27 drivers from
ATI. I'm running Mandriva 2006. I know just saying "Me too!!" doesn't help much,
but if you want me to upload some logs for comparison, LMK But, like yours, they
don't show anything about the crash. I gave up on linux for awhile because of
this a year ago. I came back thinking new drivers should have fixed it by now. 
Oh well...

problem in DRM. with patch https://bugs.freedesktop.org/attachment.cgi?id=5904 
all well

Created attachment 6744 [details]
xorg configuration file (PCI-BusType)

My working xorg.conf file.

Comment on attachment 6744 [details]
xorg configuration file (PCI-BusType)

Short summary: r300 is stable when forced into PCI mode via "BusType" option,
otherwise completely and randomly freezes the system when "glx" module is
loaded, but not when "dri" module is enabled.
--

Same thing here. Using an older r300 driver (downloaded from cvs in July) in
AGP mode, it just happened when the GLX module was loaded. 2D acceleration
worked (XAA, EXA) and the system didn't freeze (dri and drm modules were
enabled in xorg.conf).

After the latest driver update (from git), DRI doesn't work (disabled) when the
driver uses AGP mode. However, when I force the driver into PCI mode via the
"BusType" "PCI" option, DRI and GLX work (though slow, I only get 1000 fps in
glxgears instead of >=2000 fps). This is on a radeon 9500 Pro (4E44, it says
ATI Radeon 9700 Pro ND AGP) 128MB.

The various AGP options for the driver (and I've tried everything) won't make
any difference. X won't even start with AGPFastWrite option enabled (reboot
required).

Although PCI mode is not fast, at least I have a working system with 3D
acceleration and transparency fx etc.

Btw: Two glxgears work, but a third will cause a "Ran out of GART memory!
Please consider adjusting GARTSize option." How can I do that? And xscreensaver
sometimes has display errors (I guess memory is not enough, I'm using MergedFB)
but doesn't crash.

The r300 driver also seems to do something strange to my TFT screen: Gamma? is
too high, so that background pictures with very light grey actually are
completely white. On the second monitor (CRT), everything's ok. Changing gamma
with xgamma doesn't help though, I can't see the light grey colours. I guess
there's something wrong with the signal processing? Maybe I should file an
extra bug report about this? It would be nice anyway if different gamma
settings could be chosen for the other monitor.

The radeon works fine in windows xp (although the display gets corrupted after
resuming from standby or hibernation) with catalyst drivers. I can play games
for hours, there are no stability problems, and I've even overclocked the gpu
and video memory and tested for artifacts. RAM is ok, too => the system is rock
stable.

Dark your bug isn't related t to this one. M6 card are not r300 card.
Anyway what is your ddx radeon driver version ? A fix about r300
lockup went in few weeks ago. Even if it was mostly for 9800 card it
might help for other r300.

Other advise don't enable agpfastwrite and try with lower agp speed.
If nothings help please open a new bug. I added your mail to this
one so you can see my reply quickly.

xorg-server snapshot 2006-08-28 not problems.

Is this still a problem?

Yes it is still a problem.

I have actually managed to trace the DRI issue on my laptop down to the interaction between the xorg radeon driver and the Synaptics touchpad.

Laptop: Acer 1681 with ATI Radeon Mobility 9600 and Synaptics touchpad.

OSes used to test: Slackware 12.0, 12.1, 12.2, Ubuntu 8.04, 8.10

Apparently, the driver works if I have a USB mouse plugged in to my box (touchpad still enabled as a PS2 mouse using the 'mouse' xorg driver).

If I instead only have the touchpad enabled (no USB mouse connected), then the screen freezes within a minute.

By using:

Option "DRI" "False"

The system does not freeze even if only the touchpad is enabled (no usb mouse connected).

I will attach proper output from lspci and X error log soon.

*** This bug has been marked as a duplicate of bug 12934 ***