Red Hat Bugzilla – Bug 39148
Voodoo Banshee screen corruption
Last modified: 2007-04-18 12:33:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.4 i586)
Description of problem:
PCI Monster Fusion (Voodoo Banshee chipset)
Version 4.0.3-5 is unusable with this card, the screen is completely
corrupted and unreadable. I downloaded 4.0.3-10 from rawhide with the same
results. I was using 4.0.2-6 (last rawhide version I downloaded) on 7.0
with no problems. I have never had ANY problems with ANY RedHat Linux
release (been using RH since 5.2) with this card prior to this. I tried
downloading 4.0.2-12.1 (The lastest 4.0.2.x on rawhide) to see if it was a
4.0.3.x problem, but it also had the corruption problem. Also switching to
another console after starting x, in order to shutdown X, the console
screen is corrupted now also. The only way to restore the screen to normal
Steps to Reproduce:
1.boot the system, login, startx
I checked the XFree86 log it doesn't show any errors. Added thought the
Glide3 packages are separate in 4.0.2-6, but in 4.0.2-12.1 and the 4.0.3.x
I've tried they are integrated, related? Maybe something not integrated
There is a patch applied to the tdfx for banshee cards. It is possible that
it fixes a problem on some cards and creates a problem on others. If the
PCI ID's are identical, there is no easy way to fix it without being joe
3dfx superguru. <grin> Try my latest 4.0.3-13 on people.redhat.com and
see if that changes anything. There is a bunch of 3dfx stuff just went in.
I'm also working on some ther 3dfx stuff too, but it is VERY slow considering
I do not have any 3dfx hardware to work with. ;o(
Send me the output of "lspci -vn", "lspci -v", your XFree86 log, and config all
as file attachments using the attachment link below. This will add data points
to corelate with other bug reports.
If you are really brave, download the src.rpm of 4.0.3-13 and comment out the
line in the spec file:
%patch319 blah blah
Then change the release number from -13 to -13jh at the top of the spec and
rebuild XFree86 with rpm -ba XFree86.spec
If you do the above and it works for you, let me know, and I will forward
the info to the DRI guys to try and make it autodetect the different banshee
Created attachment 17426 [details]
Output from lspci -vn, lspci -n, XFree log
Mike, you mean you aren't "joe 3dfx guru", damm I'm disappointed. <grin>
I should have known to provide the output from lspci, forgive me ;-). The XFree
log is from 4.0.3-5. I'm downloading the src for 4.0.3-13 now, will let you know
what happens. I'm always brave :-).
Created attachment 17427 [details]
Mike, first attachment didn't post right, this is better
Mike, I compiled 4.0.3-13 without patch 319 (banshee timing patch), and it works
perfect now. I will try recompiling it with the patch and see if it screws up
again. I suspect it will. Will let you know. Thanks
I was glad to find this information, since I too had the same problem. This
card was also the Diamond Monster Fusion, Banshee. Same exact problem. I had
used 7.0, as well as the 7.1 Beta version called Feston, without problem.
Although I have experimented with RH, since 5.2, I am not versed enough to
recompile source code. I reloaded 7.0, in the interim, and will try to keep an
eye on this, if a new patched RPM is released in the future. Thanks - Dave
Mike, patch 319 is definitely causing the problem with 4.0.3.x I am having. I
recompiled 4.0.3-13 with patch 319 this time and the screen corruption problem
is back. I works great compiled without patch 319.
Ok, glad that you got it working. I am going to try and obtain a banshee,
and the specs for it, and see if I can figure out a way of having this stuff
I'm also going to bring it up on the DRI lists, and post back what I find.
Just as a note, I have this exact problem on a 3DFx Voodoo 3 AGP card. It
takes about 10 minutes of use for the corruption to present itself. I will
also be trying to steps referenced above and will report the results. Having
bug tracking openly available is a wonderful thing! :)
The only file affected by that bad patch319 is
It's only 56 kbytes. One of you who has rebuilt it without the patch
please attach it to this bug so people who find their way here don't
have to rebuild the whole XFree86 package. Thanks.
For anyone who hasn't done so already, please upgrade to XFree86-4.0.3-14.
This is the current release, and will be an errata unless other things
get fixed as well, in which case -15 or something later will be an errata.
Actually, there will most likely be a -15 RSN.
To email@example.com, there are many problems fixed in the above
mentioned release on all tdfx cards. Plese open a new bug report for any
Voodoo 3 bugs, but make sure someone else hasn't already reported it. Thanks
for your data as well.
For those who want to ride the cutting edge... 4.0.99.x test release will
be unleashed into rawhide within a week or two. Just a heads up.
To firstname.lastname@example.org. Can you point us in the direction of the said files we
need? XFree86-4.0.3-14. All I could find on Redhat's FTP is XFree86-4.0.3-
11. I'm most likely just looking in the wrong place, but don't really know
where else to search. I scoured a bit in RedHat's FTP, but was unsuccessful in
finding those files.
For what it's worth I'm a Creative Labs Blaster Banshee PCI Card user having
the above problems. Thanks for all your help...
Cheers. Jason Fitzgerald
Sorry... My test releases of XFree86 are located at:
Any other software I maintain here, may also have test releases located
at the above location at any given point in time as well. Usually just
XFree86 and Mesa though.
To email@example.com. Thanks for the prompt reply. I've just d/led the
updates from your ftp site and plan on now applying them. I'll keep you
updated if I run into any problems.
I'm a happy RedHat Camper to have this bug reporting system.
Ciao - Jason Fitzgerald
System: ASUS Motherboard (i815EP Chipset), 128 Megs of RAM, Creative Labs
Blaster Banshee 16 Meg PCI Video Card, Proview 19" 986 Series Monitor.
What I did: Clean install of Redhat v7.1 with above mentioned video problems
as every one else is having. When I saw to update to XFree86-4.0.3-14, I
couldn't find it at Redhat's Site, but did notice there was XFree86-4.0.3-11,
so I d/led and did a RPM -Uvh of all those files. Next I came back here and
found out where to find XFree86-4.0.3-14 files, so I then d/led them and did a
RPM -Uvh of both the newer version of Mesa and XFree from mharris' site. I
then used Xconfigurator, hoping to see clean video when all configured, but I'm
stuck at the same position as when I did the initial install of Red Hat v7.1.
The video is garbled and unusuable.
To firstname.lastname@example.org or anyone else who might know. What should I do to get
working X in RedHat v7.1? Should I do a clean install of RedHat v7.1, then
RPM -Uvh Mesa and XFree86 from mharris' ftp? Do you guys think I made a
mistake by installing build 11, then upgrading to build 14? Should I have gone
from build 5 directly to build 14?
Thanks in Advance...
Unlike what you may be used to in other operating systems (non-Linux), you
should pretty much _never_ need to reinstall the whole OS. Reinstallation
usually ends up either being drastic overkill or resulting in a duplication
of the problem that needed solving.
To answer your question about upgrading XFree86, you did not do anything wrong.
It is perfectly fine to upgrade from -5 to -anything later. The banshee code
as shipped in -5 is the same ever since for the memory timing problem. The
patch that changes the memory timing for the banshee makes it work on more
cards than without the patch, so that is the way it stays until someone who
knows about the banshee stuff can make it autodetect a certain card feature
and special case the two memory timing values. I am trying to gather info
to do this right now, but it may take some time. If our XFree86 doesn't
work for you, you can rebuild it after commenting out the %patch319 line in
the spec file. You'll need 1Gb of disk space to build it, and about 9
hours on a 300Mhz CPU, or much less on a faster CPU. The result should be
a working driver. If I can't find a fix soon, I might consider adding a
new configuration option for it so it can be changed in the config file
To email@example.com. Thanks for the valuable information. I'm not real new
to computers however my knowledge of them isn't quite what you would expect for
someone who has used them as long as I have. Basically, due in fact to that
I've really just used computers and not really delved into developing software,
nor hardware. This mind you, is just to give you an idea of where I'm coming
from on the subject of Computers and Linux. However, what you are saying is
making sense. For right now I'll do as you said for the patch and look forward
to reading much more on this at a later date. Thanks for taking the time to
converse about this subject. I look forward to news in the future. For now,
the recompilation will do.
Created attachment 18250 [details]
Voodoo Banshee tdfx driver object file from recompile of XFree86-4.0.3-5.i386.src.rpm with Patch319 commented out
I just added an attachment to this bug. It is the tdfx_drv.o object file that corrects the memory timing problem with some Voodoo Banshee cards
(like mine). I recompiled XFree86-4.0.3-5.i386.src.rpm after commenting out Patch319 in the spec file. Substitution of this file for the driver
of the same name in /usr/X11R6/lib/modules/drivers has corrected all screen corruption problems on my RH 7.1 system. I'm using a Diamond
Monster Fusion video card. Your results may vary...
Created attachment 18272 [details]
Replacement for attachment ID 18250 (replacement XFree86 tdfx_drv.o)
Thanks, I ran into the same problem with my Diamond Monster Fusion. I just
downloaded the replacement driver, thanks for compiling that. If I have
problems I will let you know. Otherwise thanks.
Is there any know issues or problems with ATI rage video cards? I have been
wanting to upgrade a couple machines, but because of the problems with the
Diamond cards, I have been a little reluctant.
I have the Monster Fusion AGP Voodoo Banshee and have tried all versions of X
4.0.3 and 4.0.99 that I could find on rawhide with the video corruption problem
still existing. X 4.0.3-15 works fine with my Voodoo3 AGP card.
I am trying to download the XFree86-4.0.3-15 rpm package, but I was not able to
find it in people.redhat.com/mharris/testing. Am I doing sthing strange?
If your banshee (anyone's) doesn't work with our official build, then it
is unlikely it will work with a future build as I won't be getting rid
of patch 319 as all that does is switches who the driver works for, leaving
the problem still there.
Until I have time to experiment a little with the driver, people will have
to rebuild X from my src.rpm after commenting out patch319 from the specfile.
Anyone having problems with our 4.0.3 rpm packages *please* supply me
with your "lspci -vn" output either in email or preferably in the bug report,
and state specifically that your card does not work with 4.0.3-x but tell me
what values of x do not work (probably all). I will special case these
cards in an attempt to try and get rid of the problem.
*** Bug 44299 has been marked as a duplicate of this bug. ***
Note to everyone - this problem is in ALL XFree86 releases, not just 4.0.3.
It includes the recently released 4.1.0. The XFree86 team knows of no way
to fix this.
Well, note that for me the problem begun with th upgrade to RH7.1. XFree86-4.0.x
RH7.0 (and yes, I am sure I was running a XFree86-4) worked ok for me. I will
try to collect some more info at home. Note again: I have a voodoo3 3000 PCI,
not a Banshee.
If anything fails, I think a option that dinamically disable the patch is the
only way to go.
Created attachment 20862 [details]
my XFree86 log file (X 4.0.3-15)
Created attachment 20863 [details]
lspci -vn and lspci -n in one file.
I have made some tests on my machine; data is attached in the report.txt file
First of all, I re-state that I _do_ see corruption without changing resolution
with the stock server.
I changed my tdfx_drv.o with the one I downloaded from this bugzilla page, and
now all is working.
Looking around, I noticed (but I think it's unrelated) that my PC have the MTRR
In the attached file, you have:
the output of lspci -v, lspci -vn, lspci -vvvv
the dmesg of the boot of my machine
the result of cat /proc/mtrr
the diff -u between the output of startx when it did not work and when it
Hope this helps...
Created attachment 20944 [details]
Attachment explained in my last comment
Deferring until a way of autodetecting the various Banshee cards,
or another suitable workaround can be determined.
*** Bug 47706 has been marked as a duplicate of this bug. ***
Fixed in rawhide 4.1.0-0.9.0 release. Can you please test this and confirm the
Please update dupe bug with results.
*** This bug has been marked as a duplicate of 18810 ***
I'm running X 4.1.0-0.9.1 and X now works perfectly with my Diamond Monster
Fusion Banshee card. I've noticed that when you log out of your window manager
(I'm using KDE on a RH 7.1 box) that DRI is now disabled. But if you switch to
a console and kill X, when it comes back, DRI is now enabled. If needed, I can
attach the output of the log file that shows when DRI becomes disabled.
Also, going fullscreen appears to work in most cases now but some programs
(notably ShogoDemo) crash X and restart it and then all my consoles have a
picture of the X desktop and I can no longer see anything on them. X restarts
ok, just on the next available vt.
I downloaded the SRPM of the 4.0.3-24 and checked out the spec file. I am not
seeing patch 319 in the spec. Was it removed or just commented (and I'm missing