Bug 38529 - Rage 128 RF flickers black
Summary: Rage 128 RF flickers black
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-01 03:52 UTC by ezolt
Modified: 2007-04-18 16:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-01 11:57:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My lspci (2.69 KB, text/plain)
2001-05-01 03:53 UTC, ezolt
no flags Details
dmesg for the system (12.30 KB, text/plain)
2001-05-01 03:55 UTC, ezolt
no flags Details
XFree86 log file (26.82 KB, text/plain)
2001-05-01 03:57 UTC, ezolt
no flags Details
snapshot of the black strangeness.. (145.52 KB, image/png)
2001-05-01 04:01 UTC, ezolt
no flags Details
XClearWindow flicker testcase (5.49 KB, text/plain)
2001-05-07 11:27 UTC, ezolt
no flags Details
X11perf header file.. Required for above test case. (15.21 KB, text/plain)
2001-05-07 11:29 UTC, ezolt
no flags Details
XFree86.9.log log file (3.75 KB, text/plain)
2001-06-25 23:15 UTC, matthew jull
no flags Details
output of nm .... (1.84 KB, text/plain)
2001-06-26 13:44 UTC, matthew jull
no flags Details
log file for working, but flickering XFree86.4.0.3-5 (25.40 KB, text/plain)
2001-06-26 13:45 UTC, matthew jull
no flags Details
output of objdump...on 4.1.0-0.5.9 (8.33 KB, text/plain)
2001-06-26 14:54 UTC, matthew jull
no flags Details

Description ezolt 2001-05-01 03:52:24 UTC
When running Redhat 7.1, I've noticed the following strange behavior on my RAGE
128 RF.  I believe that it is all related:

1) Scrolling in KWrite (QT), Emacs (xt) and Abiword (GTK), all ficker black when the text 
is scrolled quickly. 

2) When logging out of KDE2, instead of the normal shaded stipple, the entire screen
turns black, with the exception of the dialogue box in the middle. 

3)  As menus are flipped through, they leave black underneath them.  They are
eventually repainted, but it is very distracting.

There are only certain types of surfaces that turn black when passed over.  Whitespace in 
Konqueror turns black (empty space on the webpage), but text fields (such as the one I 
am typing in...) remain a sane color. (in this case, white)

This is VERY annoying, and makes the otherwise polished desktop look flakey.  

It is almost as if the surface underneath were intiallized to black, instead of the proper 

This problem disappears if:
1) I disable DRI. 
2) I use Option     "UseCCEfor2D"

Neither of these are acceptable. (I need 3d, and I can't handle the slowness of the CCE)

If you need more experients or something for me to try, just drop me a line.

I've attached my lspci, dmesg, & a picture of the blackness. The screen shot was taken 
with ksnapshot.  Note, on the original screen, there is a window where the blackness in 
the snapshot is.


Comment 1 ezolt 2001-05-01 03:53:24 UTC
Created attachment 16946 [details]
My lspci

Comment 2 ezolt 2001-05-01 03:55:46 UTC
Created attachment 16947 [details]
dmesg for the system

Comment 3 ezolt 2001-05-01 03:57:24 UTC
Created attachment 16948 [details]
XFree86 log file

Comment 4 ezolt 2001-05-01 04:01:09 UTC
Created attachment 16949 [details]
snapshot of the black strangeness..

Comment 5 Alexei Podtelezhnikov 2001-05-01 18:27:55 UTC
Cool! I see some of it too on Rage 128 _PF_. My blackness, however, manages to
recover extremely quickly. I just see some flickering in certain areas. For
example, KDE's time set tool flickers in the area of clock. 

I also see this in your dmesg:
[drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed!
This is still unresolved, see bug 26999. Maybe it's time to update r128 driver
from 20001215 to something newer?

I suggest that you use 16 bpp color depth instead of 24/32. It might cure a lot
of problems, you won't see a difference, you'll enjoy much faster
3d-acceleration, and you'll see the above messages much less often.

Comment 6 ezolt 2001-05-02 14:26:34 UTC
I've flipped to using 16-bit color, and things are faster, but the problem still remains.

Comment 7 Mike A. Harris 2001-05-06 06:41:48 UTC
Bug was misfiled against XFree86-Servers-3.3.6, reassigning to XFree86-4.0.3.

Comment 8 Mike A. Harris 2001-05-06 06:44:49 UTC
I have reproduced this problem on an ATI AIW r128p 32M (AIW 128 Pro) AGP.
That is the black splotches as well as the fifo errors.

The fifo errors are kernel bugs in DRM, not XFree86, and may or may not
have to do with the black splotches.

Comment 9 ezolt 2001-05-07 11:20:50 UTC
I've traced things down a little further, and I think I've found another clue to the puzzle. 
It appears that the "XClearWindow(xparms.d, xparms.w);"  call causes a significant amount of 

XClearWindows is supposed to clear that window to the background color. 

I don't know all that much about X, but I would imagine that most of the widgets/windows use 
this when they are redrawing themselves.

I've attached a very hacked version of x11perf which shows the problem clearly. 

This program should simply open a window and clear it white 1000 times. 

It is easy to see a band of black as this tries to clear the screen white.  I'm not quite sure where 
the "XClearWindow" call is handled in the Xserver, or I would investigate more. 

Comment 10 ezolt 2001-05-07 11:27:06 UTC
Created attachment 17546 [details]
XClearWindow flicker testcase

Comment 11 ezolt 2001-05-07 11:29:02 UTC
Created attachment 17547 [details]
X11perf header file.. Required for above test case.

Comment 12 Mike A. Harris 2001-05-16 13:41:08 UTC
The do_wait_for_fifo and do_wait_for_idle errors reported on r128 cards when
doing DRI are fixed in our latest Rawhide kernel on rawhide.redhat.com.

This fix has been tested and confirmed.  Please give it a shot and let me
know if it fixes at least that problem for you.  It works for me.

Comment 13 Mike A. Harris 2001-05-16 13:41:42 UTC
The do_wait_for_fifo and do_wait_for_idle errors reported on r128 cards when
doing DRI are fixed in our latest Rawhide kernel on rawhide.redhat.com.

This fix has been tested and confirmed.  Please give it a shot and let me
know if it fixes at least that problem for you.  It works for me.

Comment 14 ezolt 2001-05-18 03:43:24 UTC
I will be out of town next week.  I am going to try the new kernel before that..
If I can't, I try a week from now. 


Comment 15 ezolt 2001-05-18 10:45:34 UTC
I've check it out... The 2.4.3-5 kernel on rawhide does NOT fix the problem.

Comment 16 matthew jull 2001-06-25 12:37:05 UTC
I have the same problems: screen flicker with black bands... it wasn't there
for redhat 7.0 and i ahve installed all updates to the os (including kernel,
etc.). nice little demo by ezolt@perf.zko.dec.com - shows the problem

i hope this gets sorted out soon, becuase it is driving me crazy and i
am wishing i hadn't upgraded!


Comment 17 matthew jull 2001-06-25 12:39:19 UTC
oh, and furthermore, my machine (laptop) is using the
ATI|Rage Mobility M3 AGP 2x graphics card.


Comment 18 Need Real Name 2001-06-25 13:47:36 UTC
This bug is fixed for me by the XFree86 4.1 rpms in rawhide.

Comment 19 matthew jull 2001-06-25 23:15:49 UTC
Created attachment 21806 [details]
XFree86.9.log log file

Comment 20 matthew jull 2001-06-25 23:16:35 UTC
XFree86 4.1 rpms installed from rawhide on RH7.1 (with all updates)
on a machine with a ATI|Rage Mobility M3 AGP 2x, does not work
at all - i.e. will not allow the X server to start (see attached log file
above ).  any ideas?  had to switch back to XFree86-4.0.3-5 rpms.


Comment 21 Need Real Name 2001-06-26 11:48:51 UTC
Hmm, looks like the XFree86 rpm has been broken since I installed it; my 
libbitmap.a doesn't have those undefined symbols.  The one that works for me is 
XFree86-4.1.0-0.0.1.  Just to verify, do the undefined symbols also show up 

  nm -u /usr/X11R6/lib/modules/fonts/libbitmap.a

?  I also have an M3 laptop (the Dell C600); thus my interest.  But I'm on the 
compiler team, not OS, so I can't really do anything about the problem for 
you.  I expect the undefined symbols will be fixed in the next rawhide release, 

Comment 22 matthew jull 2001-06-26 13:43:00 UTC
know where i can get the XFree86-4.1.0-0.0.1 rpms? tried nm -u
/usr/X11R6/lib/modules/fonts/libbitmap.a, but no symbols listed
as per the errors in the above XF86 log file. This is regardless of the XFree86
version (the one that works, and the one that doesn't). i attached
the output of the above command (the same for both versions)
in libbitmap.a.4.1.0-0.5.9.txt
have noticed that /usr/X11R6/lib/modules/fonts/libbitmap.a lives
in the XFree86-xfs-4.0.3-5.i386.rpm for 4.0.3-5, but in the 
XFree86-4.1.0-0.5.9.i386.rpm for 4.1.0-0.5.9 

any further help appreciated...

i also attach a XF86.4.0.3-5.log that works, but gives the black flickering
stuff mentioned above.

Comment 23 matthew jull 2001-06-26 13:44:13 UTC
Created attachment 21848 [details]
output of nm ....

Comment 24 matthew jull 2001-06-26 13:45:41 UTC
Created attachment 21849 [details]
log file for working, but flickering XFree86.4.0.3-5

Comment 25 Need Real Name 2001-06-26 14:40:09 UTC
Does objdump -h show any of the .rodata.* sections mentioned in the bad log?

Comment 26 matthew jull 2001-06-26 14:53:27 UTC
yes, they're there. don't know what to make of this though.

Comment 27 matthew jull 2001-06-26 14:54:21 UTC
Created attachment 21851 [details]
output of objdump...on 4.1.0-0.5.9

Comment 28 Need Real Name 2001-06-26 16:04:40 UTC
Well, that's almost certainly the problem, then.  Sounds like whoever built the 
RPM was passing -fdata-sections to gcc, and the XFree86 module loader can't 
deal.  The solution is to not use that flag.

Mike, care to push out a new rpm?  In the meantime, I notice that rpmfind.net 
still has the 0.0.1 rpms that I've been using with no problems.

Comment 29 matthew jull 2001-06-27 14:19:35 UTC
thanks - 0.0.1 rpms work fine.... and solve the problem for the moment.


Comment 30 Mike A. Harris 2001-11-01 11:57:12 UTC
ezolt: Do you still see this problem with XFree86 4.1.0-3 as released with
Red Hat Linux 7.2?  If you could test it, and update the report, I'd
appreciate it.  If the problem still exists, I can then dig deeper into it,
otherwise if it is solved, I'd like to close the report now.


Comment 31 Mike A. Harris 2002-02-09 10:46:06 UTC
This problem seems long since fixed in 4.1.0, the current release of X
for both 7.1 and 7.2 is 4.1.0-15.

Note You need to log in before you can comment on or make changes to this bug.