Bug 39148 - Voodoo Banshee screen corruption
Voodoo Banshee screen corruption
Status: CLOSED DUPLICATE of bug 18810
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
: 44299 47706 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-04 18:23 EDT by Jim Hayward
Modified: 2007-04-18 12:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-17 10:10:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from lspci -vn, lspci -n, XFree log (40.00 KB, text/plain)
2001-05-05 00:59 EDT, Jim Hayward
no flags Details
Mike, first attachment didn't post right, this is better (28.21 KB, text/plain)
2001-05-05 01:23 EDT, Jim Hayward
no flags Details
Voodoo Banshee tdfx driver object file from recompile of XFree86-4.0.3-5.i386.src.rpm with Patch319 commented out (54.68 KB, application/octet-stream)
2001-05-13 23:18 EDT, Roger Mason
no flags Details
Replacement for attachment ID 18250 (replacement XFree86 tdfx_drv.o) (54.68 KB, application/octet-stream)
2001-05-14 08:01 EDT, Roger Mason
no flags Details
my XFree86 log file (X 4.0.3-15) (21.59 KB, text/plain)
2001-06-12 11:14 EDT, James Pattie
no flags Details
lspci -vn and lspci -n in one file. (1.80 KB, text/plain)
2001-06-12 11:16 EDT, James Pattie
no flags Details
Attachment explained in my last comment (16.83 KB, text/plain)
2001-06-13 04:27 EDT, romano
no flags Details

  None (edit)
Description Jim Hayward 2001-05-04 18:23:24 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
is reboot.

How reproducible:
Always

Steps to Reproduce:
1.boot the system, login, startx
2.
3.
	

Additional info:

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
properly? Thanks
Comment 1 Mike A. Harris 2001-05-04 23:46:58 EDT
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
hardware somehow.
Comment 2 Jim Hayward 2001-05-05 00:59:30 EDT
Created attachment 17426 [details]
Output from lspci -vn, lspci -n, XFree log
Comment 3 Jim Hayward 2001-05-05 01:03:51 EDT
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 :-).
Comment 4 Jim Hayward 2001-05-05 01:23:08 EDT
Created attachment 17427 [details]
Mike, first attachment didn't post right, this is better
Comment 5 Jim Hayward 2001-05-05 11:28:37 EDT
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
Comment 6 Need Real Name 2001-05-05 16:00:40 EDT
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
Comment 7 Jim Hayward 2001-05-06 14:28:27 EDT
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.
Comment 8 Mike A. Harris 2001-05-07 02:36:50 EDT
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
autodetected.

I'm also going to bring it up on the DRI lists, and post back what I find.
Comment 9 Need Real Name 2001-05-09 12:33:47 EDT
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! :)
Comment 10 Need Real Name 2001-05-11 17:52:54 EDT
The only file affected by that bad patch319 is
    /usr/X11R6/lib/modules/drivers/tdfx_drv.o.
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.
Comment 11 Mike A. Harris 2001-05-11 19:16:20 EDT
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 cyoung@linuxnetworker.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.
Comment 12 Need Real Name 2001-05-13 16:52:39 EDT
To mharris@redhat.com.  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
Comment 13 Mike A. Harris 2001-05-13 17:31:49 EDT
Sorry...  My test releases of XFree86 are located at:

ftp://people.redhat.com/mharris/testing

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.
Comment 14 Need Real Name 2001-05-13 19:08:16 EDT
To mharris@redhat.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

Comment 15 Need Real Name 2001-05-13 19:57:07 EDT
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 mharris@redhat.com 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...

Jason Fitzgerald
Comment 16 Mike A. Harris 2001-05-13 20:24:42 EDT
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
instead.
Comment 17 Need Real Name 2001-05-13 22:45:11 EDT
To mharris@redhat.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.  
  
- Jason
Comment 18 Roger Mason 2001-05-13 23:18:30 EDT
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
Comment 19 Roger Mason 2001-05-13 23:29:40 EDT
  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...
Comment 20 Roger Mason 2001-05-14 08:01:20 EDT
Created attachment 18272 [details]
Replacement for attachment ID 18250 (replacement XFree86 tdfx_drv.o)
Comment 21 William L. Thomson Jr. 2001-05-14 17:24:13 EDT
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.
Comment 22 James Pattie 2001-06-04 14:48:53 EDT
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.
Comment 23 romano 2001-06-12 08:20:03 EDT
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?
Comment 24 Mike A. Harris 2001-06-12 09:00:46 EDT
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.
Comment 25 Mike A. Harris 2001-06-12 10:47:18 EDT
*** Bug 44299 has been marked as a duplicate of this bug. ***
Comment 26 Mike A. Harris 2001-06-12 10:49:15 EDT
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.
Comment 27 romano 2001-06-12 10:58:42 EDT
Well, note that for me the problem begun with th upgrade to RH7.1. XFree86-4.0.x
shipped with 
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. 
Comment 28 James Pattie 2001-06-12 11:14:31 EDT
Created attachment 20862 [details]
my XFree86 log file (X 4.0.3-15)
Comment 29 James Pattie 2001-06-12 11:16:15 EDT
Created attachment 20863 [details]
lspci -vn and lspci -n in one file.
Comment 30 romano 2001-06-13 04:26:39 EDT
I have made some tests on my machine; data is attached in the report.txt file
(merged togheter). 
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
setting wrong.

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
worked. 

Hope this helps...
Comment 31 romano 2001-06-13 04:27:43 EDT
Created attachment 20944 [details]
Attachment explained in my last comment
Comment 32 Mike A. Harris 2001-06-19 00:32:22 EDT
Deferring until a way of autodetecting the various Banshee cards,
or another suitable workaround can be determined.
Comment 33 Phil 2001-07-10 09:50:45 EDT
*** Bug 47706 has been marked as a duplicate of this bug. ***
Comment 34 Mike A. Harris 2001-07-17 10:09:25 EDT
Fixed in rawhide 4.1.0-0.9.0 release.  Can you please test this and confirm the
fix (anyone?).
Comment 35 Mike A. Harris 2001-07-17 10:21:01 EDT
Please update dupe bug with results.

*** This bug has been marked as a duplicate of 18810 ***
Comment 36 James Pattie 2001-08-06 15:33:24 EDT
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.
Comment 37 Need Real Name 2001-09-24 11:47:15 EDT
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
it).

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