Bug 88767 - [r128] frequent corruption/artifacts
Summary: [r128] frequent corruption/artifacts
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/rage128 (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 91420 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-24 06:49 UTC by Christopher Chavez
Modified: 2018-08-10 20:50 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (30.14 KB, text/plain)
2015-01-24 06:49 UTC, Christopher Chavez
no flags Details
Screenshot 1 (136.19 KB, image/png)
2015-01-24 06:58 UTC, Christopher Chavez
no flags Details
Screenshot 2 (152.82 KB, image/png)
2015-01-24 07:04 UTC, Christopher Chavez
no flags Details
Screenshot 3 (134.00 KB, image/png)
2015-01-24 07:20 UTC, Christopher Chavez
no flags Details
Screenshot 4 (130.89 KB, image/png)
2015-01-24 07:28 UTC, Christopher Chavez
no flags Details
Screenshot 5 (104.98 KB, image/png)
2015-01-24 07:34 UTC, Christopher Chavez
no flags Details
screenshot of font corruption in KDE3 from openSUSE Tumbleweed with 18.0 server and r128 driver 6.10.1 (122.01 KB, image/jpeg)
2016-02-05 05:35 UTC, Felix Miata
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Chavez 2015-01-24 06:49:14 UTC
Created attachment 112761 [details]
Xorg.0.log

Using LXDE on Debian 8 PowerPC (iMac G3 w/ G4 upgrade), xf86-video-r128 package xorg-xserver-video-r128 6.9.2-1. I can upload several screenshots of corruption, artifacts, etc., most of which occur frequently but I can't yet reliably reproduce.

I might be able to run xts5 and see if that gives anything more specific; is there another utility preferred for testing 2D rendering to help with identifying/investigating these kinds of issues?
Comment 1 Christopher Chavez 2015-01-24 06:58:44 UTC
Created attachment 112762 [details]
Screenshot 1

This untouched screenshot shows artifacts in an LXTerminal window:
-the left-hand edge of the the window, which incrementally disappears as text is output to the terminal (after running ls and scrot in this case).
-the lower right-hand corner shows text from an Iceweasel window
The artifacts persisted after moving the window to the position it now appears.
Comment 2 Christopher Chavez 2015-01-24 07:04:36 UTC
Created attachment 112763 [details]
Screenshot 2

This untouched screenshot was taken after waking up the display from standby (the computer itself did not suspend):
-the title bar and border of the LXTerminal window is partially missing/corrupted.
Comment 3 Christopher Chavez 2015-01-24 07:20:56 UTC
Created attachment 112764 [details]
Screenshot 3

This untouched screenshot shows
-corruption in the Iceweasel address bar (which was present in the other screenshots to a lesser degree) and
-an artifact on the webpage displayed--"Configuring the" appearing in whitespace after scrolling down the page (smooth scrolling is disabled)
Comment 4 Christopher Chavez 2015-01-24 07:28:50 UTC
Created attachment 112765 [details]
Screenshot 4

Similar to as in Screenshot 3, there is an artifact after scrolling--"Seeing Printers on Other Subnets" as well as missing text in LXTerminal (the prompt is missing on the current line and the previous line has a box at the prompt where it should say "scrot" for the sixth time.
Comment 5 Christopher Chavez 2015-01-24 07:34:56 UTC
Created attachment 112766 [details]
Screenshot 5

This screenshot shows more substantial artifacts appearing in the LXTerminal window resembling information (scaled 50% vertically) from the PCManFM window.
Comment 6 Connor Behan 2015-03-04 06:39:14 UTC
Yes, a certain percentage of EXA render ops cause corruption, at least until you move the mouse to that area forcing a redraw. The bad news is that I never managed to fix this. The good news is that by selectively disabling features, you can probably get back to a normal screen.

One thing is that these are mostly text composite operations. So you can add

Option "ExaNoComposite" "true"

to the "Driver" section. Another possibility is that the XComposite extension itself is causing a conflict. For this try an xorg.conf with

Section "Extensions"
  Option "Composite" "false"
EndSection

and combinations of the two. Hope that helps.
Comment 7 Christopher Chavez 2015-03-07 08:52:47 UTC
(In reply to Connor Behan from comment #6)
> Yes, a certain percentage of EXA render ops cause corruption, at least until
> you move the mouse to that area forcing a redraw.

In my case a redraw is not forced simply by moving the mouse; the cursor itself flickers as well (using the DMZ cursor theme; this might be a separate issue). Doing something in the window might cause it to redraw affected components only. I don't remember how else to trigger an entire redraw short of minimizing a window.

I have yet to test the workarounds; for reference, the current xorg.conf should be the same as the "imac 400,450" entry here: http://oswaldkelso.blogspot.com/2009/11/imac-xorgconf-ppc-all-versions.html (when I installed Debian 7, it did not work out of the box--apparently a known issue).
Comment 8 Connor Behan 2015-03-08 18:20:26 UTC
(In reply to Christopher Chavez from comment #7)
> (In reply to Connor Behan from comment #6)
> > Yes, a certain percentage of EXA render ops cause corruption, at least until
> > you move the mouse to that area forcing a redraw.
> 
> In my case a redraw is not forced simply by moving the mouse; the cursor
> itself flickers as well (using the DMZ cursor theme; this might be a
> separate issue).

It might be useful to try Option "SWcursor" "true" if you haven't already.
Comment 9 Connor Behan 2016-02-05 04:59:02 UTC
*** Bug 91420 has been marked as a duplicate of this bug. ***
Comment 10 Felix Miata 2016-02-05 05:35:15 UTC
Created attachment 121534 [details]
screenshot of font corruption in KDE3 from openSUSE Tumbleweed with 18.0 server and r128 driver 6.10.1

This is with the following configuration:
Section "Extensions"
        Option          "ExaNoComposite" "true"
        Option          "Composite" "Disable"
EndSection

Normally I only use disable composite, but tried other per comment 6 without any apparent effect. Same unpleasant effect using only ExaNoComposite.

gfxcard pic:
https://bugs.freedesktop.org/attachment.cgi?id=117165

cpuinfo:
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 6
model name	: AMD Athlon(tm) XP 2000+
stepping	: 2
cpu MHz		: 1666.415...
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow vmmcall
Comment 11 Connor Behan 2016-02-05 05:51:58 UTC
(In reply to Felix Miata from comment #10)
> Created attachment 121534 [details]
> screenshot of font corruption in KDE3 from openSUSE Tumbleweed with 18.0
> server and r128 driver 6.10.1
> 
> This is with the following configuration:
> Section "Extensions"
>         Option          "ExaNoComposite" "true"

That one goes in "Driver".
Comment 12 Felix Miata 2016-02-05 06:06:09 UTC
(In reply to Connor Behan from comment #11)
> (In reply to Felix Miata from comment #10)
> > Section "Extensions"
> >         Option          "ExaNoComposite" "true"
> That one goes in "Driver".

Please elaborate. String "river" is not present in any of sections Monitor, Screen, Device, DRI, Extensions, Module, Modes or anywhere else I can find in any of the many xorg.conf files I've accumulated, while the xorg.conf man page is heavily loaded with same string.
Comment 13 Christopher Chavez 2016-02-05 06:30:57 UTC
(In reply to Felix Miata from comment #12)
> (In reply to Connor Behan from comment #11)
> > (In reply to Felix Miata from comment #10)
> > > Section "Extensions"
> > >         Option          "ExaNoComposite" "true"
> > That one goes in "Driver".
> 
> Please elaborate. String "river" is not present in any of sections Monitor,
> Screen, Device, DRI, Extensions, Module, Modes or anywhere else I can find
> in any of the many xorg.conf files I've accumulated, while the xorg.conf man
> page is heavily loaded with same string.

In many (if not all) of the xorg.conf files I came across for the iMac G3, indeed there was not a Driver "r128" entry under the "Device" section (which according to man xorg.conf is mandatory, though I'm guessing the xf86-video-ati wrapper figures out what to do if it's not present). So the "ExaNoComposite" option entry is implied to go after the Driver "r128" entry in the "Device" section:

Section "Device"
    Identifier "Configured Video Device"
    Driver "r128"
    Option "ExaNoComposite" "true"
    ...
EndSection
Comment 14 Christopher Chavez 2016-02-05 06:36:44 UTC
(In reply to Connor Behan from comment #6)
> One thing is that these are mostly text composite operations. So you can add
> 
> Option "ExaNoComposite" "true"
> 
> to the "Driver" section. Another possibility is that the XComposite
> extension itself is causing a conflict. For this try an xorg.conf with
> 
> Section "Extensions"
>   Option "Composite" "false"
> EndSection
> 
> and combinations of the two. Hope that helps.

My preliminary, unscientific results are that the corruption in my case wasn't totally eliminated by any combination of toggling ExaNoComposite or the Xcomposite extension (confirmed each in the Xorg.0.log), though some combinations seemed to be worse off than others.
Comment 15 Felix Miata 2016-02-05 09:35:00 UTC
Option "ExaNoComposite" "true" is a sufficient solution here with or without my usual Option "Composite" "false" set.
Comment 16 Connor Behan 2016-02-05 13:52:46 UTC
I'm an idiot. I indeed meant "Device" :).
Comment 17 Connor Behan 2016-04-18 16:53:36 UTC
*** Bug 94913 has been marked as a duplicate of this bug. ***
Comment 18 Ben Crocker 2018-01-29 23:09:37 UTC
I note that:
1) the X server was built in December 2014;
2) you're running a fairly old (3.2) kernel, also;
3) there seems to be an acceptable workaround (setting
Option "ExaNoComposite" "true"
in the "Device" section).

Could you try this with a newer X server and kernel?

I note that you're using really old graphics hardware;
while I realize that this is not a Mesa problem, please
note that Mesa dropped support for R128 in 2012 with version 8.0.
Comment 19 Christopher Chavez 2018-01-30 01:54:41 UTC
(In reply to Ben Crocker from comment #18)
> I note that:
> 1) the X server was built in December 2014;
> 2) you're running a fairly old (3.2) kernel, also;
Actually, I was running 3.16 at the time I reported this (3.2 was used by whichever  machine debian used at the time to compile the 3.16 kernel for me). I did eventually use 4.x kernels but do not recall there ever being any noticeable improvement.

> 3) there seems to be an acceptable workaround (setting
> Option "ExaNoComposite" "true"
> in the "Device" section).
>
> Could you try this with a newer X server and kernel?
As I mentioned in bug 91739, I no longer possess any r128-equipped machines, and am unlikely to acquire any in the near future. If Felix Miata is still happy with the workaround (cf. comment #15), then I guess this can be closed as WORKSFORME/WONTFIX until someone wishes to reopen it.
Comment 20 Felix Miata 2018-01-30 04:00:29 UTC
The PC motherboard my r128 was installed in died shortly after I last commented here, and the last time I booted a G3 was long before then, so there is no need to keep this open on my account.
Comment 21 GitLab Migration User 2018-08-10 20:50:25 UTC
-- 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-r128/issues/4.


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.