From a conversation with Christian Zandler (@ www.minion.de) over why the September 5th Nvidia 1.0-3123 patch for Linux 2.6 wasn't working with Makefile.nvidia: "I'll take a look, but the NVIDIA Makefile will likely disappear fairly soon; the reason for this is that it doesn't interact well with the Linux 2.6 module mechanisms, when module versioning, ..., is enabled." Some sort of mid-term fix is required, since many of the 2.5/2.6 savvy NVidia-kernel ebuild varients rely on Makefile.nvidia to not break the sandbox. Reproducible: Always Steps to Reproduce: 1. Download Nvidia-kernel 1.0-3123. 2. Apply patch from http://www.minion.de/files/NVIDIA_kernel-1.0-3123-2.6.diff . 3. Copy Makefile.kbuild to Makefile; "nvidia.ko" kernel module builds/works succesfully. 4. Make clean; Copy Makefile.nvidia to Makefile; "NVdriver" kernel module made, but attempting to insert it results in a response of "invalid module format", and depmod will not inventory it. 5. Experimental ebuilds that attempt to apply the 2.6/3123 patch given case #3 seem not to work well even unsandboxed (might just be me), and ones that attempt to do #4 obviously do not work. At some point in time, NVidia ideally will update their own build scripts for Linux 2.6, and tihs point may become mute.
Locally, I am trying out Linux 2.6.0-test4.
See also related: bug # 27412 bug # 28061 {this note is not for the Gentoo developers, since you're already assigned to all these. I just intend it to help some of the other people interested in this issue.}
Ok, so what exactly do you want ?
Or let me put it less harsh (if it did sound that way): Why did you add this bug ? Besides the fact that I do not support 3123 with 2.6, The first 4496 did not really have the .nvidia Makefile, but I did patch that. Meaning, as long as I am using it with 2.6 (and the kernel guys do not fix kbuild to not have to write to src dir), or some other capable guy, we will do our own Makefile.nvidia.
This bug is kind of two things: 1. This bug is advisory since the "Official" Makefile.nvidia for the 2.4 to 2.6 patches may be on its way out. As quoted, this Makefile does not take into account certain Linux 2.6 features. It may be possible to modify said Makefile to take into account these issues, but it would require someone much more familiar with the new build system than me. Obviously, this point becomes mute (at least for the newest drivers) when Nvidia releases a newer makefile. (However, sandbox issues may still exist if it uses the kbuild system.) 2. Issue #1 may be affecting my ability to run the 1.0-3123 Nvidia kernel driver. I was looking to update the existing 1.0-3123 ebuild (which has some 2.5 support) to work with the 2.6.0-test series, with little luck on my part. There is a 3123 patch for 2.6; and I have no trouble using Makefile.kbuild and manually building the module for my own use. Makefile.nvidia just builds an invalid module on my system, and neither makefile works for me when placed in an ebuild. I am in 100% agreement that you cannot maintain the older ebuilds forever. However, the number of nvidia bugs in Bugzilla, the fact that many cards like mine seem picky about which driver they use, and the fact that older ebuilds (back to 1.0-2xxx) exist imply some level of support. The fact the 1.0-3123 ebuild was previously modified to support 2.5.x kind of implied to me that 2.6 support was guaranteed. If this is not going to be the case, I would like to see the unsupported ebuilds start spitting out errors/warnings when attempting to be built on a newer kernel than designed.
> This bug is kind of two things: > > 1. This bug is advisory since the "Official" Makefile.nvidia for the 2.4 > to 2.6 patches may be on its way out. As quoted, this Makefile does not > take into account certain Linux 2.6 features. It may be possible to > modify said Makefile to take into account these issues, but it would > require someone much more familiar with the new build system than me. > This is now for 1.0-3123 I assume. > Obviously, this point becomes mute (at least for the newest drivers) > when Nvidia releases a newer makefile. (However, sandbox issues may > still exist if it uses the kbuild system.) > If it is for the later builds, I will keep a custom one, or patch whatever they give to fill our needs. There was however changes that should fix the kbuild system for 2.6 at least. > 2. Issue #1 may be affecting my ability to run the 1.0-3123 Nvidia > kernel driver. I was looking to update the existing 1.0-3123 ebuild > (which has some 2.5 support) to work with the 2.6.0-test series, with > little luck on my part. There is a 3123 patch for 2.6; and I have no > trouble using Makefile.kbuild and manually building the module for my > own use. Makefile.nvidia just builds an invalid module on my system, > and neither makefile works for me when placed in an ebuild. > > I am in 100% agreement that you cannot maintain the older ebuilds > forever. However, the number of nvidia bugs in Bugzilla, the fact > that many cards like mine seem picky about which driver they use, and > the fact that older ebuilds (back to 1.0-2xxx) exist imply some level > of support. > Ebuild side there will be support. On the other hand, if the drivers do not work, then it should be taken up with Nvidia to fix it for that chipset card ? > The fact the 1.0-3123 ebuild was previously modified to support 2.5.x > kind of implied to me that 2.6 support was guaranteed. If this is not > going to be the case, I would like to see the unsupported ebuilds start > spitting out errors/warnings when attempting to be built on a newer > kernel than designed. > Yes, just not for 2.6. I will be happy to apply patches though, but I really do not have the time to hack 2.6 support for 5-6 different versions. Get a working patch, and I will apply it. Otherwise I will add the error on kernel 2.6.
If you have updated patches for older versions, please just add them in new bugs.
For the record, I managed to find my problem with the 4xxx driver series; I suspect others may have it as well. The answer is hiding in Nvidia's Linux documentation if you look hard enough. If someone gets a really really long hang (in my case potentially 10 minutes long) before XFree86 starts up, their video card BIOS may be reporting that a TV port, DVI digital output, etc. may be enabled, when it really is not. Alternatively, the card might also be providing improper I2C information needed by Nvidia's display detection routine. The solution is to add a line like: Option "IgnoreDisplayDevices" "DFP, TV" To the "nvidia" device section covering their (analog) monitor. This is discussed in the FAQ section of Nvidia's linux driver documentation, about 28 entries into it under the question "X takes a long time to start (possibly several minutes). What can I do?"
