12.04 PPC G3 R128 AGP Mesa DRI and Modelines

[str8bs]

Howdy. My first post here.
Just began exploring Linux a few months ago, so I am definitely in the newbie category. I am exploring a charity idea using old PPC/X86_64 PC's to engage youngsters in technology and the "hacker spirit."

Sidenote:
@rsavage (if you read this) - I've googled my way to many a useful post/wiki with your moniker on it. Just wanted to say THANKS for your contributions.

Moving on to topic:

Hardware: 2 G3's
iMac G3 600mhz RAM=384MB with ATI Rage 128 Ultra 2X AGP 16MB
iMac G3 500mhz RAM=1GB with ATI Rage 128 Ultra 2X AGP 16MB

Installation:
12.04 PPC 32 via mini iso cli install followed by tasksel Xubuntu desktop. Managed to get display and then mesa HW rendering with FPS @ 300+.

Two issues I am stumped on and requesting help with. (please)
AGP
I can not enable DRI unless I force PCI mode. Does this option literally force it down to 133/33 AND prevent reading textures directly from system ram? (I am speculating yes based on what I am seeing.)
If so, is there a way to get it working in AGP mode? Even 1X should yield a significant performance increase.

Modelines
I was able to eliminate a slight pixel shift in 1024x768 with a tweak of the modeline found from Xorg.0.log. I managed to get 800x600 and 640x480 working in a useable state, but they do not fill or center the screen. Does anyone know how to find the correct clock for these modes on these iMacs? I think I could work back from that and create the correct modes? Note the difference in clock from CVT command and the modeline from Xorg.0.log in attached xorg.conf comments. (If you are wondering why- some games/children's apps work better or require lower res. e.g. Ri-li and SuperTux)
This post is the short story. I'll follow up later with a detailed post including logs and various options tried. (UseFBDev and NoINT had no effect on AGP issue.)

I tried to make this xorg.conf self explanatory.


###Str8bs July 1, 2012
###Works on iMac G3's 500/600mhz ATI Rage 128 Ultra AGP 2X 16mb
###Ubuntu 12.04 3.2.0-25 and 3.2.0-26
###To enable hardware acceleration, install old mesa 7.11 per wiki http://wiki.ubuntu.com/PowerPCKnownIssues

Section "Monitor"
Identifier "iMacG3CRT"
HorizSync 58-62
VertRefresh 74-118
UseModes "str8bsTWEAKED"
EndSection

Section "Device"
Identifier "Rage128"
Driver "ATI"
Option "ForcePCIMode" "true" ###Without this, I have to disable DRI.
Option "PreferredMode" "1024x768"
EndSection

Section "Screen"
Identifier "TheOnlyOneIHave"
Monitor "iMacG3CRT"
DefaultDepth 24 ###Change to 16 or 8 for lower color depth.
SubSection "Display"
Depth 24
Modes "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Section "Module"
# Disable "dri"
EndSection

Section "Modes"
Identifier "str8bsTWEAKED"

###!!!!!! INCORRECT MODES CAN DAMAGE CRT SCREENS !!!!!!
####Please research and understand before using. These work on my two G3 iMacs.
####800x600 and 640x480 still don't fill screen. Searching solution. pclk?

Modeline "1024x768" 78.75 1024 1048 1144 1312 768 769 772 799 +hsync +vsync
ModeLine "800x600" 63.75 800 840 920 1064 600 603 607 628 +hsync +vsync
Modeline "640x480" 51.00 640 680 744 856 480 483 487 507 +hsync +vsync

###Tweaked from these CVT outputs and xorg log
####FromXorgLog
#Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync
### 1024x768 74.90 Hz (CVT 0.79M3) hsync: 60.29 kHz; pclk: 82.00 MHz
###CVT output
###cvt 1024 768 75
### 1024x768 74.90 Hz (CVT 0.79M3) hsync: 60.29 kHz; pclk: 82.00 MHz
#Modeline "1024x768_75.00" 82.00 1024 1088 1192 1360 768 771 775 805 -hsync +vsync
### cvt 800 600 95
### 800x600 94.77 Hz (CVT) hsync: 60.37 kHz; pclk: 63.75 MHz
#ModeLine "800x600_95" 63.75 800 848 928 1056 600 603 607 637 -hsync +vsync
###cvt 640 480 117
### 640x480 116.33 Hz (CVT) hsync: 60.14 kHz; pclk: 51.00 MHz
#Modeline "640x480_117.00" 51.00 640 680 744 848 480 483 487 517 -hsync +vsync
EndSection


Thanks

[rsavage]

Sidenote:
@rsavage (if you read this) - I've googled my way to many a useful post/wiki with your moniker on it. Just wanted to say THANKS for your contributions.


Thanks for the thanks! It's getting embarrassing when I search and continually find my own posts.....I must cut this forum out - it's time for somebody to take over!



I can not enable DRI unless I force PCI mode. Does this option literally force it down to 133/33 AND prevent reading textures directly from system ram? (I am speculating yes based on what I am seeing.)
If so, is there a way to get it working in AGP mode? Even 1X should yield a significant performance increase.
I don't have an r128 so I can't help you much. To set AGP mode use the
Option "AGPMode" # <i>

option. I speculated in the FAQ that turning off AIGLX would solve system freezes with r128. I don't know if anybody has tried it. I've tried it with 12.04 and downgrading the mesa drivers, but glxgears doesn't work for me with my radeon card (it did work in 11.04). The downgrading mesa seems to be the problem. You could try it in 10.04?

Tormod Volden is working on a better solution than downgrading all of mesa. You should try and compile his package https://launchpad.net/~xorg-edgers/+archive/mesa-legacy/+packages (https://launchpad.net/%7Exorg-edgers/+archive/mesa-legacy/+packages) so that you can use mesa 8.x. He has an interest in r128 and will probably be able to help you further.

Can you update the known issues page or Faq with any progress you make please?

[str8bs]

I speculated in the FAQ that turning off AIGLX would solve system freezes with r128. I don't know if anybody has tried it.
Not for me. Unless I either disable DRI OR force pci mode(not both.) I have the issue. The issue? I wonder if what people are calling freezes are really freezes? On mine, it could easily be mistaken for a freeze but it isn't. It is just incredibly slow. The gui eventually loads. Mouse cursor moves on screen minutes after you actually move it. In xorg log I find a bunch of:

[ 265.172] (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025
[ 265.172] (EE) R128(0): Idle timed out, resetting engine...
[ 282.882] (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025
[ 282.882] (EE) R128(0): Idle timed out, resetting engine...
[ 298.704] (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025
[ 298.705] (EE) R128(0): Idle timed out, resetting engine...Once I force PCI mode, Option AGPMode gets ignored. I have to force PCI to enable DRI which is required for MESA.


Tormod Volden is working on a better solution than downgrading all of mesa. Great news! These machines are old but I am all for making what hardware they have work for a living. Will try the package. I should clarify that my AGP issue exists before downgrading Mesa. After forcing PCI mode, downgrading to old Mesa currently works with HW rendering.


Can you update the known issues page or Faq with any progress you make please? Sure but I hesitate. I am too new to Linux to be confident I am not spreading bad information. I am working on a detailed walk through of install on these from blank screen all the way to mesa. It seems a lot has changed recently, even from 3.2.0.23 to now. (no longer have to
video=offb:off and add aty128fb to modules for example)

Thanks again.

[rsavage]

(EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025


This I believe is an old problem. See https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/87530 .

I think people added Option "CCEusecTimeout" "100000" to overcome it (looking at old xorg.conf files), but reading the bug report it doesn't sound very promising.

The other interesting thing is



One can get Ati Rage 128 DRI working only with this kernel config:
CONFIG_DRM=y
CONFIG_DRM_R128=y
It gives ~ 460 fps in glxgears then.

So possibly compiling a kernel would solve it? Somebody left a cryptic message on askubuntu.com hinting that a kernel needed to be compiled to get the best performance. I thought they probably were just referring to aty128fb, but this maybe it.



Once I force PCI mode, Option AGPMode gets ignored. I have to force PCI to enable DRI which is required for MESA.

Because of these problems is dri automatically truned off with AGP? You'd have to look at the xorg.0.log.



I should clarify that my AGP issue exists before downgrading Mesa.

I don't understand. You won't have hardware accelerated mesa with 8.x.



It seems a lot has changed recently, even from 3.2.0.23 to now. (no longer have to
video=offb:off and add aty128fb to modules for example)

That was me harassing the kernel people that got that changed. If the solution really is kernel related then you could also push for another change.

[str8bs]

I think people added Option "CCEusecTimeout" "100000" to overcome it ... Tried that too and no change.


So possibly compiling a kernel would solve it?
I was wondering if it was similar to KMS with Radeon AGP as noted in theArchWiki (http://wiki.archlinux.org/index.php/ATI)

For AGP support, it is necessary to add intel_agp (or ali_agp, ati_agp, amd_agp, amd64_agp etc.) before the radeon module.


Because of these problems is dri automatically truned off with AGP? Not if I am interpreting logs correctly. I saved a first boot log (right after tasksel Xubuntu with no xorg.conf) and one with PCI mode forced in xorg.conf. Attached.


I don't understand. You won't have hardware accelerated mesa with 8.x. Sorry, my attempt at clarification just confused things. What I mean is the DRI/AGP issue exists before I downgrade Mesa so that has no effect. I have to have option "ForcePCIMode" "true" unless I disable DRI. With DRI enabled and PCIMode forced, I can then downgrade MESA and HW works.

I think what I really am trying to solve for is this?

dmesg | grep AGP
[ 0.585628] Linux agpgart interface v0.103
[ 29.655997] agpgart-uninorth 0000:00:0b.0: Apple UniNorth/Pangea chipset
[ 29.658518] agpgart-uninorth 0000:00:0b.0: configuring for size idx: 64
[ 29.736441] agpgart-uninorth 0000:00:0b.0: AGP aperture is 256M @ 0x0
[ 43.502188] agpgart: Couldn't find an AGP VGA controller.
[ 43.502261] agpgart-uninorth 0000:00:0b.0: putting AGP V2 device into 0x mode
dmesg | grep 128
[ 0.051065] NetLabel: domain hash size = 128
[ 0.510244] aty128fb 0000:00:10.0: enabling device (0086 -> 0087)
[ 0.511251] aty128fb 0000:00:10.0: Invalid ROM contents
[ 0.511280] aty128fb: Invalid ROM signature 8181 should be 0xaa55
[ 0.511307] aty128fb: BIOS not located, guessing timings.
[ 0.511342] aty128fb: Rage128 TR Ultra AGP [chip rev 0x4] 16M 128-bit SDR SGRAM (1:1)
[ 0.528219] Console: switching to colour frame buffer device 128x48
[ 0.543908] fb0: ATY Rage128 frame buffer device on Rage128 TR Ultra AGP
[ 42.894184] aty128fb 0000:00:10.0: Invalid ROM contents
[ 43.488491] [drm] Initialized r128 2.5.0 20030725 for 0000:00:10.0 on minor 0
[ 43.502284] aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode

I also tried installing non-free firmware with no change.


That was me harassing the kernel people that got that changed. And another THANKS again! :)

[rsavage]

And another THANKS again! :)

Well I'm a bit concerned I may have made things worse for you. I don't understand why you get


[ 43.502188] agpgart: Couldn't find an AGP VGA controller.The agpgart and uninorth_agp modules are started before drm as the various instructions say to do. The only thing is aty128fb is started now so early because it is built in. Maybe this has an effect? At the moment the only way I can think of to get around this is to install the 3.2.0-23 kernel (the linux-image-3.2.0-23-powerpc-smp package). You can then specify the order in which the modules are loaded.

I assume you have tried debian wheezy (via mintppc 11) already? That has a different kernel setup with uninorth_agp built in too.

I don't understand why building in the drm modules should help, but since the bug report says it helps you should probably try it. If you work out that a kernel change is needed then I think you can still get the 12.04 kernel setup changed.

It looks like

(EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025is not related to 3d hardware acceleration then.

If this was a common bug surely it should of been squished by now? It makes you think that there is something about PowerPC that triggers it more. Maybe the usefbdev option?

I think your best bet is to try and get hold of Tormod and see if he can help. He tried to help r128 users before, but as far as I know nobody took him up on his offer http://ubuntuforums.org/showthread.php?p=11816354 .

[str8bs]

At the moment the only way I can think of to get around this is to install the 3.2.0-23 kernel
Based on my unreliable memory, I had the same issue with -23 when I had aty128fb in /etc/modules and /etc/initramfs-tools/modules. I'm not really up to speed on how these effect load order. Do you mean try the same using kernel 3.2.0-23 and line uninorth_agp before aty128fb?


I assume you have tried debian wheezy (via mintppc 11) already? About a month ago and IIRC I disabled DRI. Will re-test. I started looking at Qimo-Session which wasn't in the default repositories with that install. Xubuntu seemed the best choice since Qimo loads XFCE anyway and we have the education bundles.
I will try kernel compile. Will take some learning on my part. (Never compiled before.)


If this was a common bug surely it should of been squished by now? I was thinking the same. Most xorg.conf's I find on the net have DRI disabled. I wonder if most people are content with that so it doesn't come up?


...Tormod... and see if he can help. He tried to help r128 users before, but as far as I know nobody took him up... Shame. I saw that and misinterpreted it as "never mind" since aty128fb was put back. Other than my goal of getting AGP mode, the only out of the box issues these two have are the HorizSync/VertRefresh monitor section and Disable DRI or ForcePCIMode to get working 1024x768(Still searching better modelines for the lower resolutions.) I have another iMac 333 with the Rage128 Pro 6M next on the list.

[rsavage]

Did you get kernel 23 with the mini iso? I thought you'd get the latest kernel. If that is the case the known issues page needs rewording.

I think you've got what I meant. Add the lines

uninorth_agp
aty128fb

in that order to the files you gave so that the agp module gets started before the framebuffer. See if you still get "agpgart: Couldn't find an AGP VGA controller".

You presuambly looked up the Horiz/vert/modeline values used in the previous xorg.conf files? Have you tried resetting pram. Sometimes causes a shift in screen position from what I gather.

[str8bs]

Did you get kernel 23 with the mini iso?
No. kernel 23 was with alternate CD. If I later dist-upgraded that, I could remove aty128fb from the two modules files and it matches the discussion in this thread.

Unless otherwise stated, the logs and posts in this thread are kernel 25 or later installed via USB boot of the mini iso.

Since I am slow at getting my documentation together, I should try and clarify a few things:
Unless stated, I am booting with no kernel parameters appended.
Without DRI disabled or PCI Mode forced, what I see when X starts, is a "garbled" framebuffer display that looks like a high resolution on the top half of the screen and lower resolution on the bottom half. This could easily be mistaken for a freeze, but if I leave it long enough, the login screen comes up. (I can actually log in if I want to wait another half hour.) timeout messages in Xorg Log as posted earlier.
If "quiet splash" is appended at boot, I have a blank screen after the splash screen for the same time period until the login screen finally loads.

Regarding modelines for lower resolution.
Did not try resetting pram. Will do. It is really close right now. Suspect finding the dot clock would get me there. Most xorg.conf's I find on the net show 8x6 and 6x4 at 60hz which definitely won't work on these.

I am traveling this week so it may be mid next week before I can pick it up again. Thanks again for your help.

[rsavage]

Okay here is my considered opinion.....I'm studied the logs you've provided more closely....

By disabling dri you don't have any drm messages. It is drm that sets the AGP mode as far as I am aware (guessing by the log messages I have). The software rasterizer is loaded with this option.

By forcing PCI mode you get drm/dri. The log you gave loaded the swrast, but if you had downgraded mesa you would have had hardware acceleration.

I can't see huge differences between the 'no xorg conf' log and the above. Sure you have the agp prefix instead of pci, but the majority of messages are the same. The one that is missing with forcepci is



[drm] loaded kernel module for "r128" driver.
I don't understand if that is significant or if the code for pci/agp just logs things differently. With PCI mode is the r128 half of drm not loaded? Doesn't make much sense.

I still think the significant error is



aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode
It points to a problem with the uninorth_agp module if you ask me. This is why it seems to be mostly a powerpc problem.

My theory with compiling drm modules in [=y] as a solution is that I suspect that forces PCI mode. I may be wrong, but it would be interesting if you could achieve ~460fps with PCI. Maybe drop to 16 bit colour or enable hyperz?

I have found an example where agp r128 powerpc appears to be working http://lists.debian.org/debian-x/2010/09/msg00479.html . Only agp mode 1 though. I've looked at the kernel configs from that time and I can't see anything that sticks out.

I'm concluding that is just works for some machines and some it doesn't. A bit like radeon KMS (which is another uninorth_AGP problem).

I maybe completely wrong though! I usually am!

EDIT:

you could try booting with the drm.debug=1 boot parameter to see if you get more information.

lots of xorg.conf files here http://mac.linux.be/content/g3-imac-tray-loader-slotloader-all-versions-xorgconf

[str8bs]

Thanks for taking a look.

Regarding PRAM and Modelines:
You were right. I did not reset PRAM, but confirmed that changing geometry settings in OSX changed my display in Linux. Since I'm dual booting OSX 10.4, I will adjust there first and then "tweak" modelines until I get there. Sidenote: stumbled on "apt-get install videogen" and find it a lot more useful than cvt for this purpose.

Regarding AGP vs. PCIMode:
A major cocern for me is the ability to use system RAM, and I may have confirmed AGPSize gets ignored when ForcePCIMode is used. My thinking that RAM is relatively cheap and easy for these machines. VideoRAM - not gonna happen. Could be really useful on the ones with 4 or 6 MB of VRAM.

If I add Option "AGPSize" "32" to the xorg.conf in the first post, this is the major difference I was hoping to fix more so than just FPS.

This is from 3.2.0-23 (Lubuntu) but is the same as 3.2.0-26

PCIMode
[ 930.139] (II) R128(0): Using 8 MB AGP aperture
[ 930.140] (II) R128(0): Using 1 MB for the ring buffer
[ 930.140] (II) R128(0): Using 2 MB for vertex/indirect buffers
[ 930.140] (II) R128(0): Using 1 MB for AGP textures
AGP Mode (and unusable due to CCEtimeouts)
[ 34.422] (II) R128(0): Using 32 MB AGP aperture
[ 34.422] (II) R128(0): Using 1 MB for the ring buffer
[ 34.422] (II) R128(0): Using 2 MB for vertex/indirect buffers
[ 34.422] (II) R128(0): Using 29 MB for AGP textures
Putting uninorth_agp in modules didn't change things. drm.debug didn't yield anything obvious to me.


I still think the significant error is
aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode Agreed, and I don't understand this either:
dmesg | grep -i vga
[ 0.047384] vgaarb: loaded
[ 32.545041] vgaarb: this pci device is not a vga device
[ 33.354151] vgaarb: this pci device is not a vga device
[ 33.964274] agpgart: Couldn't find an AGP VGA controller.
I still will try the kernel compile to see if it yields more performance. But, if it does force PCI mode, then we still lose use of system RAM. (I think.)

I realize DRI for R128 is no longer officially supported, but would a bug report be warranted? Even if a user isn't downgrading mesa, the initial install appears as "hung" system since DRI is enabled by default.

The attached has detailed logs with and without PCIMode in 3.2.0-23 if anyone wants to take a closer look.
Thanks

[tormod]

aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode

I have actually seen this other places (savage/x86). I think this is a bug in the kernel agp driver or in the agp bridge. It tries to set a value (the default value, 1?) that the card does not say it can use, and it ends up with "0". This is not the same 0 as in agpmode=0 which is meant to disable AGP. I proposed a kernel patch (http://lists.freedesktop.org/archives/dri-devel/2011-November/016101.html), but no developer wants to touch this old agp stuff even with a long stick.


Agreed, and I don't understand this either:
dmesg | grep -i vga
[ 0.047384] vgaarb: loaded
[ 32.545041] vgaarb: this pci device is not a vga device
[ 33.354151] vgaarb: this pci device is not a vga device
[ 33.964274] agpgart: Couldn't find an AGP VGA controller.
I still will try the kernel compile to see if it yields more performance. But, if it does force PCI mode, then we still lose use of system RAM. (I think.)

I realize DRI for R128 is no longer officially supported, but would a bug report be warranted? Even if a user isn't downgrading mesa, the initial install appears as "hung" system since DRI is enabled by default.

Yes, you can always file a bug. Probably no developers will have time to fix it properly, but at least DRI should default to off if it causes hangs.

Oh and by the way, you can check if that AGP mode "0" bug is the same by trying out other AGP speeds (1,2,4). If you hit the right speed, the message should change from 0x to your value.

[str8bs]

Tormod,
Thank you for taking a look. It appears you attempted to solve my problem last year. :)
I was not able to get the "0x" to change using other agpmode=. May be expected, but odd that XorgLog reports "8" as "illegal" but not 4 even though this card is only 2X?

I went ahead and opened bug report. https://bugs.launchpad.net/ubuntu/+bug/1023975 (https://bugs.launchpad.net/ubuntu/+bug/1023975)

I keep googling myself to confusion regarding GIT. Is there a way I could test your patch? What search terms would lead me to the equivalent of "GIT for Dummies?"

[bipa]

Sorry for waking up this old thread. I hope I'm not violating forum rules here but this thread seemed relevant to the problem I have.

I'm currently trying to revive an old G3 iMac DV+ (450 MHz G3 CPU) with Ubuntu 12.04 (this is actually for the local Kindergarten so children can learn playing with gcompris and stuff like that).

This model has an ATI Rage 128 Pro AGP 2x with 8 MB of VRAM.

Following the "PowerPC FAQ" and "PowerPC known issues" instructions (thanks to the people who took the time to write these), I managed to install everything pretty well, but I still believe the video performance is rather poor so I wanted to try to enable all possible accelerations.

Thank to str8bs's instructions and sample xorg.conf bits (found on several forums), I tried to activate DRI, but it looks like I have a special behaviour :

- I installed kernel-firmware-nonfree
- I downgraded the 4 libgl-mesa* deb packages to version 7
- I have AIGLX and Composite disabled
- I added the "ForcePCIMode" to xorg.conf
- I have the "CCEusecTimeout" parameter set to 100000

When I try at 1024x768 @ 24 bpp, I get an error message saying that I need at least 9 MB of VRAM, so DRI is disabled. Not sure whether AGP mode would lift this memory requirement? The system is fairly useable, noticeably faster than with framebuffer driver, but GLX is completely unavailable.

So I tried at 800x600 @ 24 bpp and 1024x768 @ 16 bpp, but everytime I get a corrupt screen and no explicit error (according to the logs, everything is fine and DRI is enabled). Also the dmesg looks ok (with drm startup messages), although I do see the aforementioned messages about agpgart not finding any VGA adapter. But despite the absence of severe error messages, the screen stays garbled : in single-user mode I can still Ctrl-Alt-Backspace out of it, but in normal mode I have to hard-reset the machine.

At some point (not after all attempts), I noticed the following message in Xorg.0.log:

(EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025

(despite the CCEusecTimeout option being set in xorg.conf)

So maybe this is the same kind of issue str8bs was referring to (the X server not being completely crashed but rather extremely slow, but I didn't have the patience to wait until a non-garbled login screen shows up).

I can add a word about the actual "garbage" I see on screen :

- in 16 bpp mode, it's like the screen is subdivided in two halves vertically : the upper half has some remnants of text from the console and the bottom half is filled with a dithered green/grey-ish color

- in 24 bpp mode 800x600, the top half is black and the bottom half has some orange-ish pixel garbage spread horizontally

Anybody (especially str8bs) can tell me if they already observed a similar behaviour and if there is a known fix? Thanks in advance.

PS: BTW I also compiled Tormod's mesa-legacy package, which compiled and installed fine on my iMac G3, but didn't solve the problem either. I can provide the binary powerpc deb packages in case anybody is interested.

[str8bs]

@ Mods - Sorry for bumping an old one. Been away and just noticed the previous post requesting help.

@BIPA - I never tested on one with less than 16mb VRAM. Maybe you can confirm, but I speculate "forcePCImode" bug/issue may only apply to the Rage 128 Ultra 16M which is AGP 2X with a chipset that allowed greater than 2X speeds.

I can say the "half and half" garbled screen behavior is what I would see in the "extremely slow" failure without "forcePCImode."
I don't think the VGA arbitration (vgagarb) error is relevant to this issue. You should only need "forcePCIMode" if you see the one with "putting AGP ... 0x mode." If you don't see that, or see something other than 2X, I would try forcing 2x in the xorg.conf.

You should not need to disable AIGLX or composite. Firmware non-free did nothing to help mine either.

DRI will automatically be disabled with VRAM less than 9M at higher res and depth. One of the things I was curious about with your hardware is if you get CAN get DRI enabled in AGP mode, you might be able play with GART size to increase shared memory available. (Keep in mind the 100Mhz bus speed on these things. Any trip across that bus will be slow. It is 66Mhz on the 333 cpu and older.)

I would start trying something that won't auto disable DRI like 16 bit 800x600 or 640x480. (You will have to add mode lines to support those.)
If you get that working, experiment with GART size and check your logs to see if it gives you the RAM.(See my July 11 post this thread.) If so, try upping the res and depth again and add "enabled" in the DRI section. (I think will force it on.)