Description of Problem: When I try to load the voodoo 3 video module called tdfx it fails. The file exists in the proper place in the module system, but does not work Version-Release number of selected component (if applicable): I don't have the version number because the module will not respond to modinfo -a or -p. How Reproducible: Always bad Steps to Reproduce: 1. modprobe tdfx 2. Responds no such module found 3. Actual Results: No action Expected Results: tdfx module loaded to the kernel Additional Information: This has casued me a whole lot of trouble. If I were a new linux user I would be back on windows now.
The X server loads the DRM kernel modules on its own accord. Never ever should you _ever_ need to "modprobe tdfx". It is totally unnecessary. tdfxfb.o is something completely and totally different than tdfx.o The former is the tdfx framebuffer driver, and the latter is the tdfx DRM module required by the DRI in XFree86 for 3D acceleration. 3Dfx hardware should work correctly with or without DRM modules loaded. If you start the X server, and DRI does not work on 3dfx hardware, then one of the following is likely: 1) X is misconfigured - Voodoo 3, Banshee only support 3D in 16bit depth and at resolutions 1024x768 and lower. or 2) You're using an i386 kernel which doesn't contain DRM support. In this case, our installer is broken for not choosing a DRI capable kernel for your CPU. Please reassign bug to "anaconda" component if this is the case. Those are two possible scenarios. Please attach to the bug report, your X server log file /var/log/XFree86.0.log from after a failure. Also attach your X config file, and /var/log/messages. Use the file attachment link below.
Another note... If you are in fact trying to use tdfx framebuffer support, you need to read the Framebuffer HOWTO, and configure the system properly to work in framebuffer mode. You'll need to reconfigure X to use fbdev also. I recommend not using framebuffer mode, as it is complex for many users to configure, and doesn't really provide any benefits on x86 architecture.
Back to the begining. I'm trying to load RH 7.3 in a partition on a hard drive that has RH 7.2 running fine. 7.3 should load fine but it doesn't. I have it appears the wrong information. It is correct that if I issue #modprobe tdfx on 7.2 it loads. On 7.3 it can't find it. Will gather up and send you what you request.
Created attachment 71904 [details] This is the Xserver log files and XF86Config file
The anaconda software found my video card but not my monitor. This was good enough for a full screen installation. When I turn off the system writes that it can't find some other modules like the sound and one other I can't figure out. Of course that never happens on version 7.2 I found the tdfx driver at /usr/Xr11R6/lib/drivers/ on both versions.
Created attachment 72044 [details] messages file from version 7.3
Well I looked and there is no kernel tree on my version 7.3 load. How do I get that done? Is it a RPM? Assuming that is successful I can be sure that DRM support is provided. Is there a way to find out if DRM support is present?
This has taken too long and my abilities are too limited to get Red Hat Version 7.3 to operate on my computer. There are I'm sure others with a voodo video card that are finding they can't load this either. I'm sorry that you and I can't find a "simple" way to fix the problem. I think there may not be a simple way... So I will use my Cheapbytes cd-rom's with version 7.3 as coasters and await the next version of Red Hat and hope it works for me as well as 7.2 has been doing.
Your above X log/config file attachment is compressed in zip format, which is why I haven't looked at it at all (and wont). Attach files to bugzilla as plain ASCII text file attachments using the bugzilla attachment link. There are 300+ bug reports I have to look at, and if I have to download a zip file on each one of them and uncompress it, and then either keep track of those uncompressed files (on whatever random machine I happen to be working on at the time), or else redownload it every time I look at the bug report, then I'm more inclined to look into / fix other bugs that are easier to deal with.
I'd also like to make clear that bugzilla is NOT a technical support forum. It is _strictly_ for reporting bugs and enhancement requests. If a user requires technical assistance to learn how to configure something, they should use the Red Hat mailing lists, or some other mailing lists.
If DRI can not find the DRM kernel modules, then they do not exist, which means you are either using a non-Red Hat kernel, or you are using the Red Hat i386 kernel - which does not support DRM because DRM does not work on i386 processors. The DRM kernel modules are _ONLY_ available in the i586, i686, and athlon kernels. I _personally_ test Voodoo 3, 4, 5, and Banshee with each release, and ensure that DRI is functional. I can assure you that with the proper i586/i686/athlon kernel installed and booted, and XFree86 configured properly, that DRI 3D acceleration DOES WORK on Voodoo 3 hardware. You MUST USE 16 bit color depth (hardware limitation), and must also use a maximum resolution of 1024x768 (driver limitation). I just personally double tested this with an i686SMP kernel on a dual P-III Xeon, and it works fine. As such I am closing this bug report as WORKSFORME because it works for me, and I believe that you are using a kernel that does not have DRM kernel modules. On a side note... tdfxfb.o has nothing to do with DRI whatsoever
Additionally, the following will show you what kernels are installed, and what architecture they are for. rpm -q --qf '%{name}-%{version}-%{release} %{arch}\n' kernel I have no idea how to usefully determine the arch the running kernel was compiled for, so you'll have to ensure that you're NOT using the i386 kernel somehow on your own.
Created attachment 73024 [details] XF86Config
Created attachment 73025 [details] XFree86.0.log
Created attachment 73026 [details] XFree86.9.log
Your X config file attachment is the XFree86 3.3.6 configuration file, not the 4.x config file. That probably isn't important now though that the log file is attached. From your logfile: [drm] failed to load kernel module "agpgart" [drm] failed to load kernel module "tdfx" (II) TDFX(0): [drm] drmOpen failed (EE) TDFX(0): [dri] DRIScreenInit failed, disabling DRI. This indicates that you do not have kernel DRM modules. This is indicative that you're either using a homebrew kernel compiled by hand which is missing DRM support and/or agpgart support, or else you are using the Red Hat Linux i386 kernel. In both cases, it is not a bug. The i386 kernel does not support agpgart nor DRM. You *MUST* use an i586, i686, or athlon kernel, or you will not get working DRI. That is intentional, and not a bug. The kernels we ship which support agpgart, and DRI work for me. Closing bug again as WORKSFORME. If you need assistance installing/upgrading your kernel to one of the DRM supported kernels, please join valhalla-list Bugzilla isn't a tech support forum.
MHARRIS is convinced I'm using a kernel that I compiled. This is a complete falsehood. The kernel I am using is the one the loader (ananconda) took from the CD-ROM and applied to the system as I loaded version 7.3 onto the hard drive.It may not have DRI support but that's not my fault. The kernel loaded was loaded by anacanda using the full screen loader. I am not sure I understand the method mharris has given me to find out if my kernel has DRI. I will try it first on this 7.2 and see if it works. I just used rpm -q --qf '%{name}-%{version}-%{release} %{arch}\n' kernel on my current system and it said:kernel-2.4.7-10 i386 So in version 7.2 a i386 kernel works fine. I will do the same on version 7.3 when I boot up in the thing. It's very shacky and hard to work with.
so what CPU does your machine have?
>MHARRIS is convinced I'm using a kernel that I compiled. This is >a complete falsehood. The kernel I am using is the one the loader >(ananconda) took from the Um.. NO. That is NOT what I said. Read it again. Read it 5 times if you need to. "This is indicative that you're either using a homebrew kernel compiled by hand which is missing DRM support and/or agpgart support, or else you are using the Red Hat Linux i386 kernel." Precicely WHERE in that statement am I "convinced" that you are using a custom kernel? I presented POSSIBILITIES. One of those is that you're using the RED HAT SUPPLIED i386 kernel. The i386 kernel DOES NOT HAVE DRM. THIS IS NOT A BUG, IT IS INTENTIONAL. If anaconda chose an i386 kernel for a machine which is Pentium or higher, K5, K6, Athlon, Cyrix or similar, then anaconda was wrong. Solution: Install and boot an i586 or i686 kernel. This is _NOT_ an XFree86 or kernel bug.
This is a real linux screwup. I thought Xconfigurator was screwed up but after a week of communication with MHARRIS it seems the problem is that anaconda loaded the wrong kernel. These are Red Hat .rpm packages that don't do things like they used to. I as a user can't change them... I verified using a MHARRIS provided test that indeed I'm using a "i386" kernel which doesn't have the proper modules loaded. Lack of the DRM module is what keeps my X windows from working. I opened another bug 72720 to anaconda and this morning I got my answer. The Red Hat 7.3 cd-rom set does NOT contain a "i586" kernel .jpg. So, assuming that anaconda is working right, it tried to load the proper kernel but it was not there. So it loaded the "i386" kernel and X windows doesn't work if your using a high quality video card. I will try and find and download a proper .jpg of a "i586" kernel, but this sure smells like Microsoft Inc. where they say "if your having a problem contact your administrater".
Please try the following place: ftp://ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i586/ (or use a mirror site close to you)
For all on this list, I downloaded the file I needed kernel-2.4.18-10.i586 which was supposed to be on the version 7.3 cd-rom set but was left off by accident, and loaded it. Now I got the tdfx module loaded! Still had a problem with X windows however. So I looked at the log file from both 7.3 and 7.2 and found I have set up a 1280X1024 window under 7.2 so ran Xconfigurator and set 7.3 for that size and it came right up! Looks stable and nice on this KDS flat screen 17 inch active element monitor called radius. Thanks for your help and while not a bug, it's a kinda major screwup not to have the right kernel loaded...:-)
k5di) I agree with you. I apologize if I've seemed a bit short of patience above, but I get these type of bug reports a _lot_. The i586 kernel was left off intentionally, not accidentally. I believe it was done due to disk space limitations. The bug in the installer that chooses the wrong kernel just adds to it. As a result, even though this is _not_ an XFree86 bug, I get inundated with bug reports, email, people in IRC over the issue, and quite often people are very hostile with me, so I've become quite impatient with people myself over this issue. There really is nothing that we can do to fix the problem since the installer is hard coded on the CDROM itself, we can't really update it. We also can't add missing kernels to the CD that were left off. Sorry this problem also frustrated you too.
Hello mharris and the gang. I have had it. In version 7.3 you have currupted /usr/lib/ so that "legasy" software like gnu-cash can't run on that version. It runs fine on 7.2 and that's where I am now. Too many errors by Redhat in 7.3 and sure you guys know that. It all already runs on 7.2 so here I stay. Better luck on 7.4
Excuse me? Corrupted /usr/lib how exactly? What you're saying makes absolutely no sense, and I also fail to see how it bares any relevance whatsoever to this bug report. Red Hat Linux 7.3 is our most stable release in the 7.x series period, so if it doesn't work well for you, you're the exception. By the way, being hostile in bug reports is not a good way to get people to jump to help you.