Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 726688 - 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]
Summary: x11-drivers/nvidia-drivers-440.82-r3 with kernel 5.7.0 - .../work/kernel/nvid...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Jeroen Roovers (RETIRED)
URL:
Whiteboard:
Keywords:
: 726942 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-06-01 18:21 UTC by Julien Delquié
Modified: 2020-06-25 07:43 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Compatibility patch to compile nvidia drivers 390 series from 5.6 to 5.7 kernel (xf86-video-nvidia-0002-fix-for-kernel-5.7.patch,2.08 KB, patch)
2020-06-02 01:30 UTC, Francois Chenier
Details | Diff
patch for 5.7 kernel (nvidia-kernel-5.7.patch,777 bytes, patch)
2020-06-02 03:26 UTC, Harris Landgarten
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Delquié 2020-06-01 18:21:02 UTC
Here is the error when trying to build nvidia-drivers with kernel 5.7.0:

/var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work/kernel/nvidia/nv-vm.c: In function ‘nv_set_memory_array_type’:
/var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/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]
   66 |             set_memory_array_uc(pages, num_pages);
      |             ^~~~~~~~~~~~~~~~~~~
      |             set_pages_array_uc
/var/tmp/portage/x11-drivers/nvidia-drivers-440.82-r3/work/kernel/nvidia/nv-vm.c:69:13: error: implicit declaration of function ‘set_memory_array_wb’; did you mean ‘set_pages_array_wb’? [-Werror=implicit-function-declaration]
   69 |             set_memory_array_wb(pages, num_pages);
      |             ^~~~~~~~~~~~~~~~~~~
      |             set_pages_array_wb
cc1: some warnings being treated as errors


Reproducible: Always

Steps to Reproduce:
1. build gentoo-sources-5.7.0
2. build @module-rebuild (nvidia-driver)
3. get the error at compile time
Actual Results:  
nvidia-driver build is ko.

Expected Results:  
nvidia-driver build is ok.
Comment 1 Francois Chenier 2020-06-02 01:30: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.
Comment 2 Harris Landgarten 2020-06-02 03:26:09 UTC
Created attachment 643102 [details, diff]
patch for 5.7 kernel

works with 440.82-r3 on my system
Comment 3 Sergey Galkin 2020-06-02 06:07:31 UTC
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
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2020-06-03 14:26:05 UTC
*** Bug 726942 has been marked as a duplicate of this bug. ***
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2020-06-03 17:35:33 UTC
*** Bug 726942 has been marked as a duplicate of this bug. ***
Comment 6 Steve Williams 2020-06-04 08:32:37 UTC
(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.
Comment 7 Michal Jakubowski 2020-06-05 10:30:13 UTC
Confirm - please add those patch to tree.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2020-06-05 12:34:56 UTC
(In reply to Michal Jakubowski from comment #7)
> Confirm - please add those patch to tree.

No.
Comment 9 Julien Delquié 2020-06-05 13:00:52 UTC
So we'll have to wait for Nvidia then, again: https://forums.developer.nvidia.com/t/nvidia-440-82-kernel-5-7-patch/125815
Comment 10 Beelzebubbie 2020-06-07 13:38:04 UTC
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.
Comment 11 Fabio Coatti 2020-06-08 06:32:39 UTC
(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
Comment 12 Jeroen Roovers (RETIRED) gentoo-dev 2020-06-10 06:08:09 UTC
(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.)
Comment 13 Julien Delquié 2020-06-10 06:32:31 UTC
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.
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2020-06-10 06:51:55 UTC
(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.
Comment 15 Julien Delquié 2020-06-10 07:04:25 UTC
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.
Comment 16 Nick Reale 2020-06-10 19:29:56 UTC
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!
Comment 17 Markus Giese 2020-06-11 20:46:55 UTC
is working for me too
gcc - 10.1.0
kernel - 5.7.2
nvidia-drivers - nvidia-drivers-440.82-r3
Comment 18 josef.95 2020-06-13 11:46:38 UTC
(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 :)
Comment 19 Nikolay Kichukov 2020-06-15 12:06:26 UTC
Thanks for the patch, also worked fine here.
Comment 20 Artem Siryk 2020-06-16 00:49:22 UTC
Kernel 5.7.2. Works fine. Thanks!
Comment 21 Fabiano 2020-06-19 18:04:15 UTC
> 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?
Comment 22 Shiru 2020-06-21 14:40:26 UTC
Thanks for this patch: confirmed that works with Kernel 5.7.3.
Comment 23 Alireza 2020-06-21 23:27:36 UTC
(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.
Comment 24 Ionen Wolkens gentoo-dev 2020-06-24 17:29:24 UTC
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.
Comment 25 Ionen Wolkens gentoo-dev 2020-06-24 18:25:34 UTC
(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.
Comment 26 Larry the Git Cow gentoo-dev 2020-06-25 07:43:01 UTC
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(+)