R128 DRI lockup on PPC

The only way to get round this is to use the frame buffer, using DRI causes very high latency when working.

When I tried to use the draper ppc live CD and the Xserver failed to load due to the problem with DRI.

This is on an iMac G3 400 MHZ slot loading with an ATI Rage im not sure whether its a 128 or a pro

I have Problems with a ATI RAge 128 pro on a PC (i386) with Dapper.

glxinfo says:
direct rendering: Yes

But glxgears is as slow as without acceleration.
knoppix works and debian with xorg worked, too.

Maybe since the modularized xorg packages?

sorry for jumping on the gun here..

I can also report this bug on my ppc.

Using some old cds, I have found that my old hoary cds work (with agp, too), while breezy and later don't.
Apparently, there has been some sort of regression?

Hi,
Same thing on edgy.

I've read something about patching the driver to get it work

https://launchpad.net/distros/ubuntu/+source/mesa/+bug/24810

I haven't try that yet.

That patch didn't work for me a while ago when i tried it. It doesn't seem to be the same problem, either, if you look at it closely.

This looks like just the thing:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236187

Never mind, that patch makes the CCE reset less, which actually makes it even slower.
If i do the exact opposite (make it reset more), I get way more error messages, but more resets means that the lock isn't as bad....
i is assigned a smaller value in this case:
instead, CCE idle took i = 33
probably just because of more resets

Looking at it on my system, (Note that I've been messing around and am using a lot of the stuff from hoary, without sucess sof ar), every other time that R128CCEWaitForIdle is called, ret=0 and everything is fine. When not 0, ret=-16 and engine is reset.

So, I've installed debian stable with working dri and am now working my way up to see what breaks
it. So far, I've installed the latest xorg (including xserver-xorg-video-ati, Mesa, core xserver ,etc.)
and things are still working like a charm. So, it's probably not the direct fault of either of these...
Which makes drm look suspicious. I'll try that out and report my results

Further testing has proved some of my earlier statements incorrect. I apologize for my stupidity, but here is more correct information:

On older kernels, no ForcePCIMode option is needed to prevent CCE restart.
Still, when running without this option, GL apps do crash after a while, though not nearly as soon. Interestingly, using up more CPU power by playing music at the same time, etc. seems to make it crash sooner.

With ForcePCIMode, the same problems occur (though the older stuff almost seemed to work, it still crashed, though with more effort.)

None of the patches previously listed seem to help.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Closing as expired due to no response in 3 months.