Summary: | x11-drivers/nvidia-drivers-440.82-r3 with kernel 5.7.0 - .../work/kernel/nvidia/nv-vm.c:66:13: error: implicit declaration of function ‘set_memory_array_uc’; did you mean ‘set_pages_array_uc’? [-Werror=implicit-function-declaration] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Julien Delquié <julien.dlq> |
Component: | Current packages | Assignee: | Jeroen Roovers (RETIRED) <jer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alamahant, b.buschinski, hjckr, ivan, jasmin+gentoo, kajanos, krinpaus, m.debruijne, pacho, sean.poynter, skobkin-ru, wdiazux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Compatibility patch to compile nvidia drivers 390 series from 5.6 to 5.7 kernel
patch for 5.7 kernel |
Description
Julien Delquié
2020-06-01 18:21:02 UTC
Created attachment 643096 [details, diff]
Compatibility patch to compile nvidia drivers 390 series from 5.6 to 5.7 kernel
That is the patch I`m using to get x11-drivers/nvidia-drivers-390.132-r2 to compile against kernel 5.7
May or may not works for 440 drivers series. If coding structure is the same as the legacy driver, should be easy to port to the latest drivers.
Created attachment 643102 [details, diff]
patch for 5.7 kernel
works with 440.82-r3 on my system
Thanks Harris Landgarten mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-440.82-r3 wget https://726688.bugs.gentoo.org/attachment.cgi\?id\=643102 -O /etc/portage/patches/x11-drivers/nvidia-drivers-440.82-r3/patch.diff is working for me too gcc - 10.1.0 kernel - 5.7.0 nvidia-drivers - nvidia-drivers-440.82-r3 *** Bug 726942 has been marked as a duplicate of this bug. *** *** Bug 726942 has been marked as a duplicate of this bug. *** (In reply to Harris Landgarten from comment #2) > Created attachment 643102 [details, diff] [details, diff] > patch for 5.7 kernel > > works with 440.82-r3 on my system Confirm this patch worked on my system. Thank you. Confirm - please add those patch to tree. (In reply to Michal Jakubowski from comment #7) > Confirm - please add those patch to tree. No. So we'll have to wait for Nvidia then, again: https://forums.developer.nvidia.com/t/nvidia-440-82-kernel-5-7-patch/125815 it is always better to leave non-buildable ebuild in the tree than include a patch :-) I do not why, though. Confirming – proposed patch is working against 5.7 kernel. (In reply to Jeroen Roovers from comment #8) > (In reply to Michal Jakubowski from comment #7) > > Confirm - please add those patch to tree. > > No. Just to understand the reasoning behind this no, can you share the motivation (I'm fine with the posted patches, so no problems with my system, but I'm honestly curious). Thanks (In reply to Fabio Coatti from comment #11) > (In reply to Jeroen Roovers from comment #8) > > (In reply to Michal Jakubowski from comment #7) > > > Confirm - please add those patch to tree. > > > > No. > > Just to understand the reasoning behind this no, can you share the > motivation (I'm fine with the posted patches, so no problems with my system, > but I'm honestly curious). It's the same reasoning every time and it was codified in the ebuilds more than a decade ago, even before I started maintaining the ebuilds. The code was recently moved to nvidia-driver.eclass: nvidia-driver_check_kernel() { if kernel_is ge $(ver_cut 1 ${NV_KV_MAX_PLUS}) $(ver_cut 2 ${NV_KV_MAX_PLUS}); then ewarn "Gentoo supports kernels which are supported by NVIDIA" ewarn "which are limited to the following kernels:" ewarn "<sys-kernel/gentoo-sources-${NV_KV_MAX_PLUS}" ewarn "<sys-kernel/vanilla-sources-${NV_KV_MAX_PLUS}" ewarn "" ewarn "You are free to utilize eapply_user to provide whatever" ewarn "support you feel is appropriate, but will not receive" ewarn "support as a result of those changes." ewarn "" ewarn "Do not file a bug report about this." ewarn "" fi check_extra_config } All of you should already have seen these messages. (And yet people file bug reports about it, which I kind of support as that way there is an easy to find place where people can post the patches that they are using and sharing regardless of safety and security concerns.) And… why not just make another thing: - block installation of kernel X not compatible with nvidia-driver Y, using I don't know, package.mask, rules in ebuild? I'm not an expert. - if people want to try the thing, even if it is not secure, they unmask, and do the thing knowing what could happen. Fwiw, I agree with Beelzebubbie, I don't understand why you must left something broken in tree, instead of doing something less dirty. Also, I agree with Fabio Coatti, I hate when people just say « no. » without explanation. Sorry, but it's just rude, it's argumentum ad potentiam. Even if it's always the same question, even if it's always the same problem, you WILL have some kind of noob like me that just want to learn peacefully. And sorry, but this… is not. (In reply to Julien Delquié from comment #13) > And… why not just make another thing: > - block installation of kernel X not compatible with nvidia-driver Y, using > I don't know, package.mask, rules in ebuild? I'm not an expert. That would make it _harder_ to test whether nvidia-drivers-X works with gentoo-sources-Y. On some major kernel versions, no changes are necessary, and on some minor kernel version changes, stable kernel maintainers can break nvidia-drivers. Supporting all possible different combinations is very difficult, which is why we have a "stable branch" in Gentoo Linux, which tends to ensure that _stable_ nvidia-drivers-X works with _stable_ gentoo-sources-Y (and even then might break with _stable_ gentoo-sources-Y.Z. > - if people want to try the thing, even if it is not secure, they unmask, > and do the thing knowing what could happen. This is why the ebuilds *warn* and not block and is also why they point out that you could probably patch the driver but not receive support for it. > Fwiw, I agree with Beelzebubbie, I don't understand why you must left > something broken in tree, instead of doing something less dirty. Because the stable branch is not broken. > Also, I agree with Fabio Coatti, I hate when people just say « no. » without > explanation. Sorry, but it's just rude, it's argumentum ad potentiam. Perhaps that was rude and perhaps you shouldn't say sorry for pointing that out. Because over the years, nvidia-drivers maintainers have been required to point this out again and again and again (argumentum ad nauseam). I could probably spend an hour or two referencing previous bug reports with the same questions and the same answers here. When I said "[a]ll of you should already have seen these messages", I hoped that would save me from referencing a couple dozen bug reports all the way back to the early days of these incompatibilities. > Even if it's always the same question, even if it's always the same problem, > you WILL have some kind of noob like me that just want to learn peacefully. That is why it was codified in the ebuilds when an incompatible kernel was targeted, which no one seems to want to read or acknowledge. Maybe something is wrong with the way it is written? Suggestions for improvement of the text (or its visibility) are very much welcome. So… it is better to just report issue to upstream (NVIDIA) and just wait, correct? And stick with what is written in wiki : « When a new, incompatible kernel version is released, it is probably best to stick with the newest supported kernel for a while. NVIDIA usually takes a few weeks to prepare a new proprietary release they think is fit for general use. Just be patient. If absolutely necessary, then it is possible to use the epatch_user command with the nvidia-drivers ebuilds: this allows the user to patch nvidia-drivers to somehow fit in with the latest, unsupported kernel release. Do note that neither the nvidia-drivers maintainers nor NVIDIA will support this situation. The hardware warranty will most likely be void, Gentoo's maintainers cannot begin to fix the issues since it's a proprietary driver that only NVIDIA can properly debug, and the kernel maintainers (both Gentoo's and upstream) will certainly not support proprietary drivers, or indeed any "tainted" system that happens to run into trouble. » https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers Note that the current patch seems to be the one that will be included by NVIDIA itself, so safe, but not sure until it is released, actually. Sadly, this experience will just make me scared about report something to Gentoo. Not knowing if it will help, or just piss Gentoo developpers off. When a major kernel revision hits I normally check the latest nvidia ebuild to see what the supported version is. That used to be easier looking for the paragraph that's in the nvidia eclass now. Now the NV_KV_MAX_PLUS variable in the ebuild seems to have the first NOT supported version number (right now it says 5.7), so then I mask the 5.7 kernel and check in every few days to see if anything's improved. I'd rather do that than compile and install a kernel for nothing. Not the nicest solution but it works. What would be really nice is if the kernel update gave a warning before installation, but I doubt that's easy to implement. Welcome to Gentoo Julien! is working for me too gcc - 10.1.0 kernel - 5.7.2 nvidia-drivers - nvidia-drivers-440.82-r3 (In reply to Julien Delquié from comment #15) > So… it is better to just report issue to upstream (NVIDIA) and just wait, > correct? Yes, I think yes, and it is already done, see https://forums.developer.nvidia.com/t/nvidia-440-82-kernel-5-7-patch/125815/5 :) Thanks for the patch, also worked fine here. Kernel 5.7.2. Works fine. Thanks! > That is why it was codified in the ebuilds when an incompatible kernel was > targeted, which no one seems to want to read or acknowledge. Maybe something > is wrong with the way it is written? Suggestions for improvement of the text > (or its visibility) are very much welcome. I always use `emerge -v`, so when a build error happens, rarely the warning is still visible and most of the time it is even out of the scroll buffer of my terminal. Perhaps others also do that and perhaps that can explain why so many ppl misses that.. I can say for myself that I only saw this warning message after I saw you mentioning it on this bug report, and I found this bug report only after I went googling for the build error message that was visible to me. I couldn't see the warning on my terminal, so to satisfy my curiosity I went looking for the whole build log file on the portage temp work dir and it was indeed there ;) Also, I rarely update individual packages, it's usually in the middle of some world update that's been running for hours and it suddenly breaks. I then tend to look the last visible error msgs only and fix that. Is there any facility in the ebuild that would allow you to print the message also *after* a break? > (...) Maybe something > is wrong with the way it is written? Suggestions for improvement of the text > (or its visibility) are very much welcome. My log for reference: * Package: x11-drivers/nvidia-drivers-440.82-r3 * Repository: gentoo * Maintainer: jer@gentoo.org * USE: X abi_x86_32 abi_x86_64 amd64 driver elibc_glibc gtk3 kernel_linux libglvnd multilib tools userland_GNU uvm * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 5.7.4-gentoo * Gentoo supports kernels which are supported by NVIDIA * which are limited to the following kernels: * <sys-kernel/gentoo-sources-5.7 * <sys-kernel/vanilla-sources-5.7 * * You are free to utilize eapply_user to provide whatever * support you feel is appropriate, but will not receive * support as a result of those changes. * * Do not file a bug report about this. * * Checking for suitable kernel configuration options... [ ok ] * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking NVIDIA-Linux-x86_64-440.82.run to /var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work >>> Unpacking nvidia-settings-440.82.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work >>> Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work >>> Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work ... * Applying nvidia-settings-fno-common.patch ... [ ok ] * Applying nvidia-settings-linker.patch ... [ ok ] * Applying nvidia-drivers-440.26-locale.patch ... [ ok ] >>> Source prepared. About the text itself, on a first glance of the warning, my eyes tend to look to the end of line where the versions are: .......... kernels which are supported by NVIDIA ................ following kernels: ....gentoo-sources-5.7 ....vanilla-sources-5.7 And the I guess the brain does a quick pattern-match for 5.7 and I see: * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 5.7.4-gentoo-f1 Everything seems fine. I shouldn't break, I think... But since I saw this bug report and tried to understand why you are saying it is not supported by nvidia yet when the warning says otherwise, I then notice the "<" on the beginning of the line. "Ohh, I see, so the last supported kernel for <5.7 is actually 5.6" Perhaps using "<= 5.6" would make it clearer? Thanks for this patch: confirmed that works with Kernel 5.7.3. (In reply to Jeroen Roovers from comment #14) > (In reply to Julien Delquié from comment #13) > > And… why not just make another thing: > > - block installation of kernel X not compatible with nvidia-driver Y, using > > I don't know, package.mask, rules in ebuild? I'm not an expert. > > That would make it _harder_ to test whether nvidia-drivers-X works with > gentoo-sources-Y. On some major kernel versions, no changes are necessary, > and on some minor kernel version changes, stable kernel maintainers can > break nvidia-drivers. Supporting all possible different combinations is very > difficult, which is why we have a "stable branch" in Gentoo Linux, which > tends to ensure that _stable_ nvidia-drivers-X works with _stable_ > gentoo-sources-Y (and even then might break with _stable_ gentoo-sources-Y.Z. > > > - if people want to try the thing, even if it is not secure, they unmask, > > and do the thing knowing what could happen. > > This is why the ebuilds *warn* and not block and is also why they point out > that you could probably patch the driver but not receive support for it. > > > Fwiw, I agree with Beelzebubbie, I don't understand why you must left > > something broken in tree, instead of doing something less dirty. > > Because the stable branch is not broken. > > > Also, I agree with Fabio Coatti, I hate when people just say « no. » without > > explanation. Sorry, but it's just rude, it's argumentum ad potentiam. > > Perhaps that was rude and perhaps you shouldn't say sorry for pointing that > out. > > Because over the years, nvidia-drivers maintainers have been required to > point this out again and again and again (argumentum ad nauseam). I could > probably spend an hour or two referencing previous bug reports with the same > questions and the same answers here. When I said "[a]ll of you should > already have seen these messages", I hoped that would save me from > referencing a couple dozen bug reports all the way back to the early days of > these incompatibilities. > > > Even if it's always the same question, even if it's always the same problem, > > you WILL have some kind of noob like me that just want to learn peacefully. > > That is why it was codified in the ebuilds when an incompatible kernel was > targeted, which no one seems to want to read or acknowledge. Maybe something > is wrong with the way it is written? Suggestions for improvement of the text > (or its visibility) are very much welcome. Hi this argument was interesting to me, I just wanted to suggest maybe you can make that eclass kernel check block the installation unless some ENV variables are set. Like $I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS for gcc. That way people will probably notice warnings better. I didn't notice that until I saw your comment. It's not in the nvidia's changelog but tried the two new beta drivers released today (440.100 and the more experimental 450.51 which is likely the reason this took some time) against 5.7.5 and seems to build without a patch. Not that I tested all USE flags and other considerations. Quick side notes for maintainer while at it: 1. fno-common patch is failing on both, I tried to build with -fno-common without patch and went fine 2. 450.51 will fail on dolib libnvidia-fatbinaryloader.so.450.51, library seems gone so I removed it from NV_GLX_LIBRARIES to build. Still there for 440.100. (In reply to Ionen Wolkens from comment #24) > the two new beta drivers meant to say two new drivers, only 450.51 is beta And one last off-topic note, didn't experiment with it but there's also a new 390.138. I do hope it fixes libglvnd support (bug #713546) but I'm not too hopeful. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b7642553d22fc824f27c755153cfa0b82edd043 commit 5b7642553d22fc824f27c755153cfa0b82edd043 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-06-25 07:41:42 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-06-25 07:42:57 +0000 x11-drivers/nvidia-drivers: Version 440.100 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Closes: https://bugs.gentoo.org/show_bug.cgi?id=726688 Signed-off-by: Jeroen Roovers <jer@gentoo.org> x11-drivers/nvidia-drivers/Manifest | 3 + .../nvidia-drivers/nvidia-drivers-440.100.ebuild | 585 +++++++++++++++++++++ 2 files changed, 588 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9aaec89357ebed0b1dbc9e64e4044f66313b98b3 commit 9aaec89357ebed0b1dbc9e64e4044f66313b98b3 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-06-25 06:43:35 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-06-25 07:42:57 +0000 x11-drivers/nvidia-drivers: Version 390.138 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Bug: https://bugs.gentoo.org/show_bug.cgi?id=726688 Signed-off-by: Jeroen Roovers <jer@gentoo.org> x11-drivers/nvidia-drivers/Manifest | 6 + .../nvidia-drivers/nvidia-drivers-390.138.ebuild | 578 +++++++++++++++++++++ 2 files changed, 584 insertions(+) |