Bug 39148
|
Description
Jim Hayward
2001-05-04 22:23:24 UTC
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. 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 autodetected. 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
/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.
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, 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 mharris. 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: 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. To mharris. 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 mharris 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 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. To mharris. 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 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 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. 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 (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... 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 fix (anyone?). 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 it). |