Created attachment 68230 [details] cpuinfo, free, lspci Hardware: G3 Apple iBook, second gen. fedora 18 version of the radeon driver. Downstream version is xorg-x11-drv-ati-7.0.0-0.6.20120910git7c7f27756.fc18.ppc. X starts up as normal first, but there is color distortions on gtk or xlib based widgets. Light Qt apps seem to work all right if the system is not pushed too hard. Example, Qterminal may stay for a few hours, but starting a web browser makes X crash in a few seconds. After a crash, xdm restarts X, but now, the colors all have strange extra yellow tint. Attachements: dmesg from boot till Xorg starts misbehaving. Some system info, and Xorg.0.log. Ingvar
Created attachment 68231 [details] dmesg from boot til X starts misbehave
Created attachment 68232 [details] X log
> X starts up as normal first, but there is color distortions on gtk or xlib > based widgets. Light Qt apps seem to work all right if the system is not > pushed too hard. Example, Qterminal may stay for a few hours, but starting a > web browser makes X crash in a few seconds. Does booting with radeon.agpmode=1 or radeon.agpmode=-1 on the kernel command line help? BTW, it looks like the attached Xorg.0.log is from after xdm restarted X? Can you also attach the log file from the first X server? It should be there as Xorg.0.log.old after xdm restarted X.
Booted with radeon.agpmode=1. Worked as before until I tried to start a few apps. Xorg.0.log with stacktrace, and new kernel messages attached. Ingvar
Created attachment 68301 [details] Kernel messages when radeon driver crashes
Created attachment 68302 [details] Xorg.0.log with stacktrace when radeon crashes
More or less same results with radeon.agpmode=-1
(In reply to comment #7) > More or less same results with radeon.agpmode=-1 Please attach the dmesg output from booting with that.
Created attachment 68355 [details] dmesg with radeon.agpmode=-1
Updated to xorg-x11-drv-ati-7.0.0-0.6.20120910git7c7f27756.fc18.ppc on kernel-3.6.6-3.fc18.ppc. Same results as before. Might add that except for the radeon driver, the iBook is stable. Running X apps, even gtk and qt apps, works fine via X-forwarding over ssh, and in a VNC session. Ingvar
Recompiled xorg-x11-drv-ati-6.14.4-6.20120602git930760942.fc17, reenabling ums (the fedora package has a patch that disables ums), and booted with nomodeset. With this, the display seems stable again, and the color distortion is gone. So, does this mean that the problem is in the kernel or in the driver? There are still problems with GTK widgets, but X widgets and Qt widgets are fine. Ingvar
(In reply to comment #11) > So, does this mean that the problem is in the kernel or in the driver? There are several problems. The main one (probably in the kernel) is that acceleration is not stable with KMS. Usually radeon.agpmode=-1 works around that, but for some reason it doesn't seem to on your machine. The second problem (probably in the X driver) is the wrong colours when running on KMS without acceleration. I looked into this briefly a while ago but couldn't figure out what's wrong.
I appear to have the same problem (inverted colours) on an early 2005 G5 iBook running Gentoo with anything more recent than linxu-3.7.0 with UMS. KMS definitely seems to be linked to the problem. FVWM, xterm and ImageMagick's display seem affected; maybe Geeqie too. Firefox and Gnome Terminal get their colours right, though. Everything seems usable otherwise. Linux gloduk 3.10.7-gentoo #9 PREEMPT Fri Sep 6 21:31:50 EST 2013 ppc 7447A, altivec supported PowerBook6,5 GNU/Linux x11-drivers/xf86-video-ati-6.14.6-r1
The color problems with KMS without acceleration should be fixed in this patch: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8927d33f76ee12bc618fecfc59fc7ff1fcedcd5e
and this patch should fix the accelerated case: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c16c59f8f9b6aa7a4a6a6465582ad98f02a3606a
That patch fixes the color issue, at least on kernel 3.10.9 (fedora kernel 3.10.9-200.fc19.ppc). But it is not stable. After a few minutes, the display crashes. See kernel and X logs attached.
Created attachment 85375 [details] output of dmesg (3.10.9-200.fc19.ppc)
Created attachment 85376 [details] Xorg.0.log
(In reply to comment #16) > That patch fixes the color issue, at least on kernel 3.10.9 (fedora kernel > 3.10.9-200.fc19.ppc). But it is not stable. After a few minutes, the display > crashes. See kernel and X logs attached. You're getting a GPU hang. Does radeon.agpmode=-1 help on the newer kernel?
> You're getting a GPU hang. Does radeon.agpmode=-1 help on the newer kernel? Actually, yes, it does. With radeon.agpmode=-1 the display is stable and works quite well with GTK and QT apps. X widgets have distorted colors, though. Ingvar
(In reply to comment #20) > > You're getting a GPU hang. Does radeon.agpmode=-1 help on the newer kernel? > > Actually, yes, it does. With radeon.agpmode=-1 the display is stable and > works quite well with GTK and QT apps. X widgets have distorted colors, > though. > > Ingvar At least, it worked for a few minutes lenger before locking up. When pushed a bit harder (firefox rendering a page while switching windows back and forth), it froze again like this: [ 1642.075416] radeon 0000:00:10.0: GPU lockup CP stall for more than 10000msec [ 1642.075450] radeon 0000:00:10.0: GPU lockup (waiting for 0x00000000000028b7 last fence id 0x00000000000028b6) [ 1642.077303] radeon 0000:00:10.0: Saved 27 dwords of commands on ring 0. [ 1642.077325] radeon 0000:00:10.0: GPU reset succeeded, trying to resume [ 1642.086747] [drm] PCI GART of 512M enabled (table at 0x0000000006180000). [ 1642.086831] radeon 0000:00:10.0: WB disabled [ 1642.086852] radeon 0000:00:10.0: fence driver on ring 0 use gpu addr 0x0000000078000000 and cpu addr 0xc6177000 [ 1642.086957] [drm] radeon: ring at 0x0000000078001000 [ 1642.240286] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 1642.240311] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 1642.240324] radeon 0000:00:10.0: failed initializing CP (-22).
You could disable acceleration: Option "NoAccel" "True" in the decice section of your xorg.conf
(In reply to comment #21) > (In reply to comment #20) > > > You're getting a GPU hang. Does radeon.agpmode=-1 help on the newer kernel? > > > > Actually, yes, it does. With radeon.agpmode=-1 the display is stable and > > works quite well with GTK and QT apps. X widgets have distorted colors, > > though. > At least, it worked for a few minutes lenger before locking up. When pushed > a bit harder (firefox rendering a page while switching windows back and > forth), it froze again like this: Ignore that, that was with the 6.x driver. I'm now running the patches mentioned in comment 14 and comment 15. With agpmode=-1, and it's stable (2x glxgears, firefox, switching and flicking windows, no sweat), and all the colors distortions are fixed, even on pure X widgets. Has been running stable for 20 minutes now. Hooray!
Ah! I just created version of the x11-drivers/xf86-video-ati-7.0.0 Gentoo package in an overlay of mine [0] including the two patches mentioned in comments 14 and 15. I built it, and it seems to work! The colours are no longer inverted, and acceleration seems to be there (RADEON(0): Acceleration enabled). I haven't run it for long enough to know for sure about stability, but from past experience, this setup already has passed the bumpy spot. [0] https://scm.narf.ssji.net/svn/gentoo-portage/browser/x11-drivers/xf86-video-ati
Hum, sometimes, the X server becomes unstable, still. I've also seen messages saying 'failed to map pixmap: -35' which I don't recall seeing before.
Created attachment 85664 [details] Xorg.0.log while crashing
Fairly stable, but I've provoked a crash at least once, see attachement.
(In reply to comment #27) > Fairly stable, but I've provoked a crash at least once, see attachement. Well, the userspace accel drivers may be suffering from some bit-rot at this point. I'd expect you may see similar issues even on x86 in certain cases.
Created attachment 85713 [details] A more complete Xorg.log (3.10.7/KMS; iBook G4 early 2005, PowerBook6,5) The relevant part is probably starting around 300s with [ 305.735] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [some bakctraces] [ 340.052] failed to map pixmap: -35 [ 340.060] [mi] Increasing EQ size to 512 to prevent dropped events. [ 340.065] [mi] EQ processing has resumed after 197 dropped events. [ 340.066] [mi] This may be caused my a misbehaving driver monopolizing the server's resources.
(In reply to comment #29) > Created attachment 85713 [details] > A more complete Xorg.log (3.10.7/KMS; iBook G4 early 2005, PowerBook6,5) > > The relevant part is probably starting around 300s with > [ 305.735] [mi] EQ overflowing. Additional events will be discarded > until existing events are processed. > [some bakctraces] > [ 340.052] failed to map pixmap: -35 > [ 340.060] [mi] Increasing EQ size to 512 to prevent dropped events. > [ 340.065] [mi] EQ processing has resumed after 197 dropped events. > [ 340.066] [mi] This may be caused my a misbehaving driver monopolizing > the server's resources. If you check your dmesg output you'll probably see a GPU lockup reported. If you aren't already using radeon.agpmode=-1, try that, otherwise, see comment 28.
Ok, radeon.agpmode=-1 seem to do the trick.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/44.
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.