* Patrick Shanahan [02-13-23 18:22]:

* Peter Maffter [02-13-23 15:52]:

...

Hello,

after the update the screen only shows a '-'. All the usual other tty screens that you get with e.g. STRG-ALT-F1 are also gone.

I can connect to the PC via ssh from my Ubuntu Laptop and check what is going on.

I am using an old GTX 570 on that PC.

Previously when the G06 stuff was installed instead of updating the needed G04 stuff, I was able to install NVIDIA-Linux-x86_64-390.157.run manually and the login and XFCE worked.

But now even that fails. :-(

Any pointers? Is that the beginning of the things that are named in Subject "Nvidia 390x driver users - glibc 2.37 will bring bad news" ?

had similar problem with G04 drivers

reverted to glibc 2.36-4.4 and have graphics display again.

If you are unable to find glibc < 2.37, I can give you access to mine.

glibc glibc-devel glibc-extra glibc-locale glibc-locale-base nscd

need to be changed and after I can run most of the avaiilable nvidia G04 versions available.

tks Matthew for the solution see https://bugzilla.opensuse.org/show_bug.cgi?id=1208204 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

* Andrei Borzenkov [02-13-23 23:15]:

On 14.02.2023 02:24, Patrick Shanahan wrote:

...

* Patrick Shanahan [02-13-23 18:22]:

...

* Peter Maffter [02-13-23 15:52]:

...

Hello,

after the update the screen only shows a '-'. All the usual other tty screens that you get with e.g. STRG-ALT-F1 are also gone.

I can connect to the PC via ssh from my Ubuntu Laptop and check what is going on.

I am using an old GTX 570 on that PC.

Previously when the G06 stuff was installed instead of updating the needed G04 stuff, I was able to install NVIDIA-Linux-x86_64-390.157.run manually and the login and XFCE worked.

But now even that fails. :-(

Any pointers? Is that the beginning of the things that are named in Subject "Nvidia 390x driver users - glibc 2.37 will bring bad news" ?

had similar problem with G04 drivers

reverted to glibc 2.36-4.4 and have graphics display again.

If you are unable to find glibc < 2.37, I can give you access to mine.

glibc glibc-devel glibc-extra glibc-locale glibc-locale-base nscd need to be changed and after I can run most of the avaiilable nvidia G04 versions available.

tks Matthew for the solution see https://bugzilla.opensuse.org/show_bug.cgi?id=1208204

There is no comment from anyone named Matthew in this bug.

it was in email on opensuse-support list. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 2023-02-14 18:06, Andrei Borzenkov wrote:

On 14.02.2023 19:37, Patrick Shanahan wrote:

...

...

...

tks Matthew for the solution see https://bugzilla.opensuse.org/show_bug.cgi?id=1208204

There is no comment from anyone named Matthew in this bug.

it was in email on opensuse-support list.

Excellent. So what about posting actual link to solution instead of posting link to something that does not have a solution?

Must be this one: https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/... Basically he downgraded glibc. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

Hello, In the Message; Subject : Re: No Login, no Graphics after update to Tumbleweed 20230211-0 Message-ID : <20230213232227.GF5508@wahoo.no-ip.org> Date & Time: Mon, 13 Feb 2023 18:22:27 -0500 [PS] == Patrick Shanahan has written: [...] PS> > But now even that fails. PS> > :-( PS> > PS> > Any pointers? PS> > Is that the beginning of the things that are named in Subject "Nvidia 390x PS> > driver users - glibc 2.37 will bring bad news" ? PS> > PS> had similar problem with G04 drivers PS> reverted to glibc 2.36-4.4 PS> and have graphics display again. PS> If you are unable to find glibc < 2.37, I can give you access to mine. PS> glibc PS> glibc-devel PS> glibc-extra PS> glibc-locale PS> glibc-locale-base PS> nscd PS> need to be changed PS> and after I can run most of the avaiilable nvidia G04 versions available. Isn't this the solution in glibc 2.37? In the Message; Subject : [Workaround/Solution]Re: Nvidia 390x driver users - glibc 2.37 will bring bad news Message-ID : <53c383f5-2d5e-2dcc-97c8-2af170014881@suddenlinkmail.com> Date & Time: Thu, 9 Feb 2023 01:01:03 -0600 [DCR] == "David C. Rankin" has written: [...] DCR> All is not lost!! DCR> Key is to make the nvidia driver use to current /usr/lib/tls (from glibc 2.37) DCR> so the magiccookie/authcookie are interpreted the same. This prevents the DCR> "Connection Refused" on xinit. DCR> See both: DCR> https://bbs.archlinux.org/viewtopic.php?pid=2083569 DCR> (complete install stage solution) DCR> https://aur.archlinux.org/pkgbase/nvidia-390xx-utils DCR> (quickfix with ldconfig) DCR> The nvidia-390xx driver can continue to function! Regards. --- ┏━━┓彡 野宮 賢 mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ "The question of who holds the platform and whether the person or organisation holding it is trustworthy has serious and profound implications in these volatile times. Once trust is broken, it is extremely difficult to restore. It is necessary to diversify in advance." -- Financial Times --

On 14.02.2023 04:54, David C. Rankin wrote:

On 2/13/23 14:49, Peter Maffter wrote:

...

Is that the beginning of the things that are named in Subject "Nvidia 390x driver users - glibc 2.37 will bring bad news" ?

The glibc 2.37 TLS change is the culprit

See: https://bbs.archlinux.org/viewtopic.php?pid=2083569

The problem discussed there was that Arch package did not install library in the "normal" dynamic linker search path. openSUSE package does $ rpm -qlp nvidia-glG04-390.157-17.5.x86_64.rpm ... /usr/lib64/libnvidia-tls.so.390.157 /usr/lib64/tls /usr/lib64/tls/libnvidia-tls.so.390.157

For history and solution. The last 390XX driver is compiled with glibc 2.36 and the TLS handling of xauth tokens is not the same in 2.37.

The solution is to make the nvidia driver use the tls lib from 2.37. Simplest fix is to create /etc/ld.so.conf.d/nvidia and include /usr/lib/tls so the glibc 2.37 driver has precedence (works fine here with the G04 driver on Arch)

And did it fix the problem on *openSUSE*?

On 14.02.2023 07:17, Andrei Borzenkov wrote:

On 14.02.2023 04:54, David C. Rankin wrote:

...

On 2/13/23 14:49, Peter Maffter wrote:

...

Is that the beginning of the things that are named in Subject "Nvidia 390x driver users - glibc 2.37 will bring bad news" ?

The glibc 2.37 TLS change is the culprit

See: https://bbs.archlinux.org/viewtopic.php?pid=2083569

The problem discussed there was that Arch package did not install library in the "normal" dynamic linker search path. openSUSE package does

$ rpm -qlp nvidia-glG04-390.157-17.5.x86_64.rpm ... /usr/lib64/libnvidia-tls.so.390.157 /usr/lib64/tls /usr/lib64/tls/libnvidia-tls.so.390.157

OK, apparently these two libraries are different which explains the failure. I wonder if /usr/lib(64)/libnvidia-tls.so.x.y was ever used at all. If yes, replacing it with (incompatible) library will simply introduce similar bug, but in another direction.

Hello, In the Message; Subject : Re: No Login, no Graphics after update to Tumbleweed 20230211-0 Message-ID : <87wn4jcjw6.wl-nomiya@galaxy.dti.ne.jp> Date & Time: Wed, 15 Feb 2023 19:17:45 +0900 [MN] == Masaru Nomiya has written: [...] MN> The nvidia-glG04-390.157-17.5.x86_64.rpm has been modified and I don't MN> know what you showed, but looking at the source MN> NVIDIA-Linux-x86_64-390.157.run, it is indeed libnvidia-tls.so.390.157 MN> and tls /libnvidia-tls.so.390.157 is different from MN> libnvidia-tls.so.390.157. MN> 13080 Oct 12 18:14 libnvidia-tls.so.390.157 MN> 14480 Oct 12 18:14 tls/libnvidia-tls.so.390.157 MN> And now, looking at the fixes in the MN> 14480 Oct 12 18:14 libnvidia-tls.so.390.157 MN> That is, MN> 13080 Oct 12 18:14 libnvidia-tls.so.390.157 was being used, MN> which caused the problem. MN> So, David decided to change the /etc/ld.so.conf.d to look at MN> tls/libnvidia-tls.so.390.157. The problem was tentatively solved. In MN> the fixed version, libnvidia-tls.so.390.157 has been replaced by the MN> correct libnvidia-tls.so.390.157, which means that the problem is MN> fundamentally solved, as Bernd reported. This means that MN> glG04-390.157-17.5.x86_64.rpm had a source-derived bug. I checked and found that it is not a bug, but a duplicate structure, which would be the correct term. In nvidia-glG04-390.157-lp154.17.1.x86_64.rpm, the ollowing is the results; 13080 Oct 12 18:14 libnvidia-tls.so.390.157 14480 Oct 12 18:14 tls/libnvidia-tls.so.390.157 In short, the 13080 Oct 12 18:14 libnvidia-tls.so.390.157 is for the glibc 2.36 environment, and 14480 Oct 12 18:14 tls/libnvidia-tls.so.390.157 is probably for glibc 2.37. However, it is structured for people who know how to use /etc/ld.so.cpnf.d, and in this sense, I think it is unfriendly. Since this is a good opportunity, Andrei、could you please show us the results of the following? $ ldd /usr/lib64/*.so* | grep "not found" Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "She continues to deeply divide opinion, nearly a decade after her death in 2013, due to her policies of privatisation, breaking the power of trade unions, and selling off public housing." -- World Is One News --

Am 14/02/2023 um 21:02 schrieb Bernd Ritter:

Hi,

same here, had to boot to recovery mode. But thankfully an update to TW 20230213 fixed it!

I can also confirm that todays update openSUSE Tumbleweed 20230212-0 -> 20230214-0 with: nvidia-gfxG04-kmp-default-390.157_k6.1.10_1-19.1.x86_64 (NVIDIA) nvidia-gfxG04-kmp-default-390.157_k6.1.10_1-19.1.x86_64.rpm nvidia-glG04-390.157-19.1.x86_64 (NVIDIA) nvidia-glG04-390.157-19.1.x86_64.rpm nvidia-glG04-32bit-390.157-19.1.x86_64 (NVIDIA) nvidia-glG04-32bit-390.157-19.1.x86_64.rpm nvidia-computeG04-390.157-19.1.x86_64 (NVIDIA) nvidia-computeG04-390.157-19.1.x86_64.rpm nvidia-computeG04-32bit-390.157-19.1.x86_64 (NVIDIA) nvidia-computeG04-32bit-390.157-19.1.x86_64.rpm x11-video-nvidiaG04-390.157-19.1.x86_64 (NVIDIA) x11-video-nvidiaG04-390.157-19.1.x86_64.rpm x11-video-nvidiaG04-32bit-390.157-19.1.x86_64 (NVIDIA) x11-video-nvidiaG04-32bit-390.157-19.1.x86_64.rpm corrected the bug. X11, xfce are working again. glxinfo | grep renderer OpenGL renderer string: GeForce GTX 570/PCIe/SSE2 is also ok. Thanks for that quick fix! BR Pete

Am 16/02/2023 um 00:47 schrieb Patrick Shanahan: [...]

I believe the final part of the puzzle was filled by kernel-firmware-nvidia-20230210-1.1.noarc

as the quoted drivers did not solve for me until I installed the updated firmware.

but all is good. first hickup that lasted more than an hour for me in quite a few (maybe > 10) years.

Just for fun (all is good): my 9527 Feb 13 21:45 /var/log/Xorg.0.log.old from the installed run-File says: grep "nv" /var/log/Xorg.0.log.old [ 6.425] (II) LoadModule: "nvidia" [ 6.425] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so [ 6.439] (II) Module nvidia: vendor="NVIDIA Corporation" [ 7.141] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select" [ 7.142] (II) NVIDIA(0): "DFP-4:nvidia-auto-select" [ 7.167] (II) NVIDIA(0): Setting mode "DFP-4:nvidia-auto-select" [ 7.245] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia Your (EE) Failed to load module "nv" (loader failed, 0) which you reported in https://bugzilla.opensuse.org/show_bug.cgi?id=1208204 (thx for this report!) is not there. It looks like there was no error reported in Xorg.0.log, when this error happened on Feb 13th. Pete

* Patrick Shanahan [03-05-23 18:57]:

* Peter Maffter [03-05-23 17:33]:

...

System was working till todays zypper dup.

Now again: no graphic system with kernel-default-6.2.1-1.1 .

zypper update nvidia-gfxG04-kmp of course does not help.

This time at least the old system with 6.1.12-1-default is working so that I can write this email and on the 20230304-0 system I could try to compile the NVIDIA-Linux-x86_64-390.157.run But I do remember that this does not help.

I read: "create /etc/ld.so.conf.d/nvidia and include /usr/lib/tls" Was this the solution to this problem?

off-list

you might try (I have not yet but they have worked for me in the past), https://download.opensuse.org/repositories/home:/wkazubski:/G03/openSUSE_Tum...

changelog states: * Thu Mar 02 2023 Stefan Dirsch - and now apply the patch 'kernel-6.2.patch' for real

published today nvidia-computeG04-32bit 390.157-19.1 -> 390.157-22.1 nvidia-gfxG04-kmp-default 390.157_k6.1.10_1-19.1 -> 390.157_k6.2.1_1-22.1 nvidia-glG04 390.157-19.1 -> 390.157-22.1 nvidia-glG04-32bit 390.157-19.1 -> 390.157-22.1 x11-video-nvidiaG04 390.157-19.1 -> 390.157-22.1 x11-video-nvidiaG04-32bit 390.157-19.1 -> 390.157-22.1 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 3/5/23 17:57, Patrick Shanahan wrote:

* Peter Maffter [03-05-23 17:33]:

...

System was working till todays zypper dup.

Now again: no graphic system with kernel-default-6.2.1-1.1 .

zypper update nvidia-gfxG04-kmp of course does not help.

This time at least the old system with 6.1.12-1-default is working so that I can write this email and on the 20230304-0 system I could try to compile the NVIDIA-Linux-x86_64-390.157.run But I do remember that this does not help.

I read: "create /etc/ld.so.conf.d/nvidia and include /usr/lib/tls" Was this the solution to this problem?

off-list

you might try (I have not yet but they have worked for me in the past), https://download.opensuse.org/repositories/home:/wkazubski:/G03/openSUSE_Tum...

changelog states: * Thu Mar 02 2023 Stefan Dirsch - and now apply the patch 'kernel-6.2.patch' for real

Nvidia packages, all The 6.2 kernel brings a couple of build failures in the nvidia-390xx module (openSUSE's G04 driver). The AUR package has a patch that addresses the issue. May save somebody a bit of time chasing it down: https://aur.archlinux.org/cgit/aur.git/commit/?h=nvidia-390xx-utils&id=36ce5f92aa82e7b7eb9bfff03ae2c2526305d04b -- David C. Rankin, J.D.,P.E.

On 11/16/23 10:20, Peter Maffter via openSUSE Users wrote:

Here we go again.

openSUSE Tumbleweed  20231108-0 -> 20231114-0 Compilation of the nVidia modules fails with

  CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-encoder.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.c:708:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)   708 |     .prime_handle_to_fd     = drm_gem_prime_handle_to_fd,       |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~ make[4]: *** [/usr/src/linux-6.6.1-1/scripts/Makefile.build:244: /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.o] Error 1

No X11 with 20231114-0, only cmd. Had to go back to 6.5.9-1-default (20231108)

Maybe I am too early again.

BR

See patch: https://aur.archlinux.org/packages/nvidia-390xx-utils works fine. Same as: https://paste.opensuse.org/pastes/d0b21ec8d3d4

Am 07/03/2023 um 09:23 schrieb David C. Rankin:

...

On 3/5/23 17:57, Patrick Shanahan wrote:

...

* Peter Maffter [03-05-23 17:33]:

...

System was working till todays zypper dup.

Now again: no graphic system with kernel-default-6.2.1-1.1 .

zypper update nvidia-gfxG04-kmp of course does not help.

This time at least the old system with 6.1.12-1-default is working so that I can write this email and on the 20230304-0 system I could try to compile the NVIDIA-Linux-x86_64-390.157.run But I do remember that this does not help.

I read: "create /etc/ld.so.conf.d/nvidia and include /usr/lib/tls" Was this the solution to this problem?

off-list

you might try (I have not yet but they have worked for me in the past),

https://download.opensuse.org/repositories/home:/wkazubski:/G03/openSUSE_Tum...

changelog states:     * Thu Mar 02 2023 Stefan Dirsch     - and now apply the patch 'kernel-6.2.patch' for real

Nvidia packages, all

    The 6.2 kernel brings a couple of build failures in the nvidia-390xx module (openSUSE's G04 driver). The AUR package has a patch that addresses the issue. May save somebody a bit of time chasing it down:

https://aur.archlinux.org/cgit/aur.git/commit/?h=nvidia-390xx-utils&id=36ce5f92aa82e7b7eb9bfff03ae2c2526305d04b

-- David C. Rankin, J.D.,P.E.

Does this mean, I have to patch every time I do an update of Tumbleweed x.y to x.(y+1) or (x+1).0 ? :-( Is there a step by step guidance for Tumbleweed, I never did this for nVidia (I had to patch other sources a long time ago so I understand the principle, but kicking of a complete build of /usr/src/kernel-modules/nvidia-390.157-default is new to me). Also "PACKAGE NEEDS LONG TERM MAINTAINER" at https://aur.archlinux.org/packages/nvidia-390xx-utils does not sound good. Do I have to exchange hardware (graphic card) on my old machine because nobody is using this stuff and testing it? Thx in advance BR Am 17/11/2023 um 06:02 schrieb David C. Rankin via openSUSE Users:

On 11/16/23 20:52, David C. Rankin via openSUSE Users wrote:

...

On 11/16/23 10:20, Peter Maffter via openSUSE Users wrote:

...

Here we go again.

openSUSE Tumbleweed  20231108-0 -> 20231114-0 Compilation of the nVidia modules fails with

   CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-encoder.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.c:708:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)    708 |     .prime_handle_to_fd     = drm_gem_prime_handle_to_fd,        |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~ make[4]: *** [/usr/src/linux-6.6.1-1/scripts/Makefile.build:244: /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.o] Error 1

No X11 with 20231114-0, only cmd. Had to go back to 6.5.9-1-default (20231108)

Maybe I am too early again.

BR

See patch:

https://aur.archlinux.org/packages/nvidia-390xx-utils

  works fine. Same as:

https://paste.opensuse.org/pastes/d0b21ec8d3d4

I installed 6.6.1 on Arch on the 11th after patching nvidia-390xx-utils and the nvidia modules build fine with dkms, e.g.

[2023-11-08T23:11:43-0600] [ALPM-SCRIPTLET] ==> dkms install --no-depmod nvidia/390.157 -k 6.6.1-arch1-1 [2023-11-08T23:12:46-0600] [ALPM-SCRIPTLET] ==> dkms install --no-depmod vboxhost/6.1.48_non_OSE -k 6.6.1-arch1-1 [2023-11-08T23:13:02-0600] [ALPM-SCRIPTLET] ==> depmod 6.6.1-arch1-1 [2023-11-08T23:13:24-0600] [ALPM-SCRIPTLET] ==> Starting build: '6.6.1-arch1-1'

The 6.5 -> 6.6 patch was minor compared to the 6.4 -> 6.5 patch. Let's hope 6.6 -> 6.7 is minor as well :)

On 11/20/23 04:55, Peter Maffter via openSUSE Users wrote:

Does this mean, I have to patch every time I do an update of Tumbleweed x.y to x.(y+1) or (x+1).0 ? :-(

Is there a step by step guidance for Tumbleweed, I never did this for nVidia (I had to patch other sources a long time ago so I understand the principle, but kicking of a complete build of /usr/src/kernel-modules/nvidia-390.157-default is new to me).

Generally with openSUSE, there will be an updated Nvidia driver released. But you have run into one of the drawbacks of a rolling-release when the kernel version changes. The Nvidia-390xx driver will break on just about every kernel version update (e.g. 6.3->6.4, 6.4->6.5, and 6.5->6.6, etc...) It takes time to test and put out an updated version of the driver package. The downside to the 390xx driver is it is no longer actively developed (only maintained). So it is up to the distribution to patch the kernel module files to accommodate whatever changes affect it when a new kernel is released. If you can get ahold of the source file for the nvidia-390xx-utils package that does the dkms setup for build of the nvidia kernel modules, then it is simple to edit the .spec file and include the patch I linked to. With Arch, the 390xx driver is user-maintained, so I know to get a patch ready when a new kernel is imminent. A little effort up-front makes for a seamless kernel update and successful build of new drivers when the new kernel appears. I don't use tumbleweed yet (one rolling-release at a time has been enough...), but you are in the same boat with the 390xx driver. The nvidia-utils package will need to be patched to build the new driver (or there was a manual build of the driver you can use, others will have to chime in there, I don't use it, I think Patrick has the link .. if I recall correctly..., should be a simple search to find it) Whether you want to try patching yourself, or wait for openSUSE to provide an update, this is where rolling-releases have a chicken-or-the-egg issue. Ideally, there would be someone to looks into this and have an updated package for Tumbleweed ready when then new kernel update hits the tumbleweed repos -- but there is limited manpower to put toward non-distro proprietary driver support (even though we all know there will be many people caught by surprise if that work isn't done) At least with openSUSE, there will be an update coming -- it's just a matter of when. -- David C. Rankin, J.D.,P.E.

* Peter Maffter via openSUSE Users [11-20-23 18:20]:

If there would be a step by step guidance how to compile the kernel module(s?) of nVidia for 390.xx for Tumbleweed, that would be enough for me.

I have the sources on my machine ( /usr/src/kernel-modules/nvidia-390.157-default ), I understand, what the patch does ( https://paste.opensuse.org/pastes/d0b21ec8d3d4 in /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.c ), it is just that my last kernel compilation was somewhere around 1999 afair and I do guess, that this process changed a lot since then for Tumbleweed.

With a little guidance I can help myself (at least I think so ;-) ).

BR

Am 20/11/2023 um 20:34 schrieb David C. Rankin via openSUSE Users:

...

On 11/20/23 04:55, Peter Maffter via openSUSE Users wrote:

...

Does this mean, I have to patch every time I do an update of Tumbleweed x.y to x.(y+1) or (x+1).0 ? :-(

Is there a step by step guidance for Tumbleweed, I never did this for nVidia (I had to patch other sources a long time ago so I understand the principle, but kicking of a complete build of /usr/src/kernel-modules/nvidia-390.157-default is new to me).

Generally with openSUSE, there will be an updated Nvidia driver released. But you have run into one of the drawbacks of a rolling-release when the kernel version changes. The Nvidia-390xx driver will break on just about every kernel version update (e.g. 6.3->6.4, 6.4->6.5, and 6.5->6.6, etc...) It takes time to test and put out an updated version of the driver package.

The downside to the 390xx driver is it is no longer actively developed (only maintained). So it is up to the distribution to patch the kernel module files to accommodate whatever changes affect it when a new kernel is released.

If you can get ahold of the source file for the nvidia-390xx-utils package that does the dkms setup for build of the nvidia kernel modules, then it is simple to edit the .spec file and include the patch I linked to.

With Arch, the 390xx driver is user-maintained, so I know to get a patch ready when a new kernel is imminent. A little effort up-front makes for a seamless kernel update and successful build of new drivers when the new kernel appears.

I don't use tumbleweed yet (one rolling-release at a time has been enough...), but you are in the same boat with the 390xx driver. The nvidia-utils package will need to be patched to build the new driver (or there was a manual build of the driver you can use, others will have to chime in there, I don't use it, I think Patrick has the link .. if I recall correctly..., should be a simple search to find it)

Whether you want to try patching yourself, or wait for openSUSE to provide an update, this is where rolling-releases have a chicken-or-the-egg issue. Ideally, there would be someone to looks into this and have an updated package for Tumbleweed ready when then new kernel update hits the tumbleweed repos -- but there is limited manpower to put toward non-distro proprietary driver support (even though we all know there will be many people caught by surprise if that work isn't done)

At least with openSUSE, there will be an update coming -- it's just a matter of when.

just patch the NV*.run files and install it. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 11/20/23 20:44, Masaru Nomiya via openSUSE Users wrote:

How about this?

1. cd ~

2. $ wgethttps://download.nvidia.com/XFree86/Linux-x86_64/390.157/NVIDIA-Linux-x86_64...

3. $ wgethttps://paste.opensuse.org/pastes/d0b21ec8d3d4

4. edit the file d0b21ec8d3d4 as follows;

--- a/nvidia-drm/nvidia-drm-drv.c +++ b/nvidia-drm/nvidia-drm-drv.c | V --- kernel/nvidia-drm/nvidia-drm-drv.c +++ kernel/nvidia-drm/nvidia-drm-drv.c

5. $ sh ./NVIDIA-Linux-x86_64-390.157.run --apply-patch d0b21ec8d3d4

then you will get the patched driver;

NVIDIA-Linux-x86_64-390.157-custom.run

See, I know you and Patrick would have the directions down pat. I recall it being discussed a few times before... Thanks Good luck Peter -- this is the Cliff's Notes version that should get you by. -- David C. Rankin, J.D.,P.E.

On Tue, Nov 21, 2023 at 1:38 PM Bjoern Voigt via openSUSE Users wrote:

I think, it's not a good idea to use the driver from https://download.nvidia.com/ if you usually use the RPM Nvidia driver. At least in the past some additional steps were necessary to switch back to the RPM Nvidia driver later.

If I have a problem with the Nvidia sources, I use the following steps (I use version 545.29.02 here, but 390.157 should work similar):

1. cd /usr/src/kernel-modules/nvidia-545.29.02-default 2. Apply the patches 3. Compile the driver (here for Kernel version 6.6.1-1-default): vers=6.6.1-1-default; make clean modules KERNEL_UNAME=$vers; make modules_install KERNEL_UNAME=$vers; make clean KERNEL_UNAME=$vers; depmod $vers

This will not work if Secure Boot is enabled. NVIDIA package will additionally generate key, sign modules and enroll the corresponding certificate in MOK.

If the kernel is updated, the recompilation is done automatically. If

Yes, by virtue of the trigger script in the openSUSE NVIDIA package.

the Nvidia RPM is updated, you have to check, if the new Nvidia RPM driver needs patches too.

Björn

On 21.11.23 11:55, Masaru Nomiya via openSUSE Users wrote:

Do you even know what you're talking about?

There is no such thing as /usr/src/kernel-modules/nvidia-545.29.02-default.

Masaru, read more carefully. I wrote about the Nvidia RPM packages and added "I use version 545.29.02 here, but 390.157 should work similar". The directory is from nvidia-driver-G06-kmp-default-545.29.02_k6.6.1_1-18.2.x86_64 (nvidia-tumbleweed repository).

Kind Regards & Good Night. In Europe it's currently noon.

Kind Regards, Björn

Hello, Since last September, openSUSE has been having frequent network problems. I have reported it but it is not fixed.... I posted this email yesterday, but it was not delivered, so I checked the mailing list archives to see what was going on. To my suprise, there are too many emails that are not included in the archive..... Anyway. Sorr for vary late reply. I'd go a cold. In the Message; Subject : Re: nVidia: build error with kernel 6.6.1 Message-ID : <16385560-8fea-4cd4-a3c3-8c9ae4d4f440@arcor.de> Date & Time: Tue, 21 Nov 2023 12:27:10 +0100 [BV] == Bjoern Voigt via openSUSE Users has written: BV> On 21.11.23 11:55, Masaru Nomiya via openSUSE Users wrote: MN> > Do you even know what you're talking about? MN> > There is no such thing as /usr/src/kernel-modules/nvidia-545.29.02-default. BV> Masaru, read more carefully. I wrote about the Nvidia RPM BV> packages and added "I use version 545.29.02 here, but 390.157 BV> should work similar". The directory is from BV> nvidia-driver-G06-kmp-default-545.29.02_k6.6.1_1-18.2.x86_64 BV> (nvidia-tumbleweed repository). I mistakenly thought it was a work area you created. With my proprietary driver, it's /usr/src/nvidia-545.29.06. Then why are you doing this? In the Message; Subject : Re: nVidia: build error with kernel 6.6.1 Message-ID : <42ee4c61-c016-411e-8e1e-fad2e1a1fcc0@arcor.de> Date & Time: Tue, 21 Nov 2023 11:37:52 +0100 [BV] == Bjoern Voigt via openSUSE Users has written: [...] BV> 3. Compile the driver (here for Kernel version 6.6.1-1-default): BV> vers=6.6.1-1-default; make clean modules KERNEL_UNAME=$vers; make BV> modules_install KERNEL_UNAME=$vers; make clean KERNEL_UNAME=$vers; BV> depmod $vers [...] I mean, if you look at the Makefile, you should be able to see that installing kernel modules is just # make modules -j$(nproc) && make modules_install -j$(nproc), right? That said, I have a question... How do you install the kernel modules you built? I'm very curious about this point. By the way, when there is a keinel update, I use the following script to install NVIDIA driver, #! /bin/sh nvidia-uninstall && cd /usr/local/tmp && tar -zxf /home/masaru/temp/nvidia/open-gpu-kernel-modules-545.29.06.tar.gz && cd ../ && rm -rf open-* && make modules -j$(nproc) && make modules_install -j$(nproc) && sh /home/masaru/temp/nvidia/NVIDIA-Linux-x86_64-545.29.06.run --no-kernel-modules -aq && dracut --force $(uname -r) && update-bootloader && vmware-setup.sh && shutdown -r now where, about open-gpu-kernel-modules, please have a look; https://github.com/NVIDIA/open-gpu-kernel-modules MN> Kind Regards & Good Night. BV> In Europe it's currently noon. I am participating in this ML from Japan, far away from Germany. But your name makes me think you are a Scandinavian.... Best Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that must be fed at all costs―even if it isn’t always clear what exactly that data is needed for or what those future AI systems might end up doing." -- Generative AI Is Making Companies Even More Thirsty for Your Data --

On 11/21/23 05:28, Andrei Borzenkov wrote:

On Tue, Nov 21, 2023 at 1:56 PM Masaru Nomiya via openSUSE Users wrote:

...

There is no such thing as /usr/src/kernel-modules/nvidia-545.29.02-default.

andrei@tumbleweed:~> ll /usr/src/kernel-modules/ total 4 drwxr-xr-x 8 root root 4096 Nov 21 14:27 nvidia-545.29.02-default andrei@tumbleweed:~>

Yes, Last few replies have been regarding the nvidia-545 driver which IS still maintained by Nvidia and it irrelevant to the issue Peter has needing an updated nvidia-390 driver (which isn't actively maintained by Nvidia anymore -- thus the need for user-intervention to manually patch and build for the new 6.6 kernel until openSUSE puts out a new G04 driver package) -- David C. Rankin, J.D.,P.E.

Same procedure as every year. Was updating to 20240321-0 today with kernel-default-6.8.1-1.1 ( 6.7.9-1-default before that had a working NVIDIA-Linux-x86_64-390.157 ) Compilation of nVidia modules fails. /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-drv.c:661:23: error: ‘DRM_UNLOCKED’ undeclared here (not in a function); did you mean ‘VM_LOCKED’? 661 | DRM_UNLOCKED), | ^~~~~~~~~~~~ /usr/src/linux-6.8.1-1/include/drm/drm_ioctl.h:155:26: note: in definition of macro ‘DRM_IOCTL_DEF_DRV’ No graphics after reboot. :-( Was able to reboot to 6.7.9-1-default with nVidia driver working. nvidia-drm-drv.c : line 661: static const struct drm_ioctl_desc nv_drm_ioctls[] = { #if defined(NV_DRM_ATOMIC_MODESET_AVAILABLE) DRM_IOCTL_DEF_DRV(NVIDIA_GEM_IMPORT_NVKMS_MEMORY, nv_drm_gem_import_nvkms_memory_ioctl, DRM_UNLOCKED), <------------------------------! #endif /* NV_DRM_ATOMIC_MODESET_AVAILABLE */ Someone has dropped DRM_UNLOCKED from drm_ioctl.h : diff /usr/src/linux-6.8.1-1/include/drm/drm_ioctl.h /usr/src/linux-6.7.9-1/include/drm/drm_ioctl.h 112a113,123

* @DRM_UNLOCKED: * * Whether &drm_ioctl_desc.func should be called with the DRM BKL held * or not. Enforced as the default for all modern drivers, hence there * should never be a need to set this flag. * * Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the * only legacy IOCTL which needs this. */ DRM_UNLOCKED = BIT(4), /**

So obviously nobody tested this before releasing 20240321-0 . Why was DRM_UNLOCKED dropped? Is it possible to ad DRM_UNLOCKED to /usr/src/linux-6.8.1-1/include/drm/drm_ioctl.h ? Any known side effects? How can I compile the nVidia driver (I did compile other software but never the nVidia kernel drivers)? Thanks in advance BR Pete Am 05/03/2023 um 23:32 schrieb Peter Maffter:

System was working till todays zypper dup.

Now again: no graphic system with kernel-default-6.2.1-1.1 .

zypper update nvidia-gfxG04-kmp of course does not help.

This time at least the old system with 6.1.12-1-default is working so that I can write this email and on the 20230304-0 system I could try to compile the NVIDIA-Linux-x86_64-390.157.run But I do remember that this does not help.

I read: "create /etc/ld.so.conf.d/nvidia and include /usr/lib/tls" Was this the solution to this problem?

I am quite a nope here: does "include" mean write something to /etc/ld.so.conf.d/nvidia ?

Currently on 20230227-0 there is: find /usr -name "libnvidia-tls.so.390.157" -ls [...]14480 Feb 14 12:29 /usr/lib64/libnvidia-tls.so.390.157 [...]13752 Feb 14 12:29 /usr/lib/libnvidia-tls.so.390.157 which seems to be the old one from here: https://download.nvidia.com/opensuse/tumbleweed/x86_64/

Thx in advance Pete

Am 13/02/2023 um 21:49 schrieb Peter Maffter:

...

Hello,

after the update the screen only shows a '-'. All the usual other tty screens that you get with e.g. STRG-ALT-F1 are also gone.

I can connect to the PC via ssh from my Ubuntu Laptop and check what is going on.

I am using an old GTX 570 on that PC.

Previously when the G06 stuff was installed instead of updating the needed G04 stuff, I was able to install NVIDIA-Linux-x86_64-390.157.run manually and the login and XFCE worked.

But now even that fails. :-(

Any pointers? Is that the beginning of the things that are named in Subject "Nvidia 390x driver users - glibc 2.37 will bring bad news" ?

I do have strange output about signature and verification: 2023-02-13T00:08:13.628957+01:00 machine4 kernel: [    3.411047][ T527] nvidia: loading out-of-tree module taints kernel. 2023-02-13T00:08:13.628957+01:00 machine4 kernel: [    3.411690][ T527] nvidia: module license 'NVIDIA' taints kernel. 2023-02-13T00:08:13.628958+01:00 machine4 kernel: [    3.412304][ T527] Disabling lock debugging due to kernel taint 2023-02-13T00:08:13.628958+01:00 machine4 kernel: [    3.418769][ T527] nvidia: module verification failed: signature and/or required key missing - tainting kernel 2023-02-13T00:08:13.628963+01:00 machine4 kernel: [    3.426827][ T538] tg3 0000:0d:00.0 eth0: Tigon3 [partno(BCM57781) rev 57785100] (PCI Express) MAC address 00:25:22:e6:5d:d3 2023-02-13T00:08:13.628964+01:00 machine4 kernel: [    3.427483][ T538] tg3 0000:0d:00.0 eth0: attached PHY is 57765 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) 2023-02-13T00:08:13.628964+01:00 machine4 kernel: [    3.428122][ T538] tg3 0000:0d:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] 2023-02-13T00:08:13.628965+01:00 machine4 kernel: [    3.428740][ T538] tg3 0000:0d:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit] 2023-02-13T00:08:13.628965+01:00 machine4 kernel: [    3.482616][ T527] nvidia-nvlink: Nvlink Core is being initialized, major device number 241 2023-02-13T00:08:13.628966+01:00 machine4 kernel: [    3.488784][ T527] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem 2023-02-13T00:08:13.628971+01:00 machine4 kernel: [    3.489637][ T527] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  390.157  Wed Oct 12 09:19:07 UTC 2022 (using threaded interrupts) 2023-02-13T00:08:13.628972+01:00 machine4 kernel: [    3.499362][ T527] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  390.157  Wed Oct 12 09:15:25 UTC 2022 2023-02-13T00:08:13.628972+01:00 machine4 kernel: [    3.505733][ T527] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver 2023-02-13T00:08:13.628973+01:00 machine4 kernel: [    3.506428][ T527] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 1

Update  openSUSE Tumbleweed  20230211-0 -> 20230212-0 did not help either. Boot to the recover modes of 6.1.10-1 or 6.1.8-1 does not help .

6.1.8-1 recovery at least says that "Failed to start X Display Manager" and gives the F1,F2,...ttys. but when I install NVIDIA-Linux-x86_64-390.157.run the F1,F2, ttys are also gone.

Please help.

Thanks in advance BR Pete

I expected that someone can explain to me, why they simply dropped out DRM_UNLOCKED if I can reenter it and how I can compile nVidia drivers again. I guess, that is completely within the intention of Tumbleweed. And yes: there is no solution to this issue on Google, if the solution was banned from Google I do not know. BR Am 23/03/2024 um 07:45 schrieb Andrei Borzenkov:

On 23.03.2024 03:16, Peter Maffter via openSUSE Users wrote:

...

Same procedure as every year.

So what is the point to complain again? ...

...

How can I compile the nVidia driver (I did compile other software but never the nVidia kernel drivers)?

Fix NVIDIA driver to build with new kernel.

NVIDIA driver fails to compile every second kernel version at least. Complaining about it is the same as complaining that it rains. If you are not ready or willing to handle it, then do not use Tumbleweed.

As you are apparently banned by Google, you may try patch from this issue

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/594

Am 23/03/2024 um 17:42 schrieb Andrei Borzenkov:

On 23.03.2024 19:07, Peter Maffter wrote:

...

I expected that someone can explain to me, why they simply dropped out DRM_UNLOCKED

You can read linux kernel commit log why this particular change happened. It may have been discussed on the corresponding development mailing lists (which you can find in MAINTAINERS file in Linux kernel sources) and/or LKML and found in archives. This list is the last place suitable for this question.

Internal kernel API is changing constantly. There is nothing new.

...

if I can reenter it and how I can compile nVidia drivers again.

You need to adapt NVIDIA driver to the new kernel API. You may look for changes in 550 series which is compatible with kernel 6.8. It may be enough as long as no modification of closed source part on NVIDIA driver is required.

Sorry Andrei for addressing you directly in my last email. This is quite an old system from Dec 2011. So no secure boot or similar. ll /sys/firmware/ total 0 drwxr-xr-x 5 root root 0 Mar 23 19:54 acpi drwxr-xr-x 4 root root 0 Mar 23 19:54 dmi drwxr-xr-x 20 root root 0 Mar 23 20:06 memmap ;-) I used the nVidia compile command from From: Bjoern Voigt via openSUSE Users Date: Tue, 21 Nov 2023 11:37:52 +0100 Subject: Re: nVidia: build error with kernel 6.6.1 after editing nvidia-drm-drv.c and replacing DRM_UNLOCKED with 0 according to https://github.com/CachyOS/kernel-patches/blob/master/6.8/misc/nvidia/0001-n... It compiles now without error but there seems to be a problem with depmod and vmlinux not known: ... CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-gem-user-memory.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.o ld -r -o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-frontend.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-instance.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-gpu-numa.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-acpi.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-chrdev.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-cray.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-dma.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-gvi.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-i2c.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-mempool.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-mmap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-p2p.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-pat.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-procfs.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-usermap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-vm.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-vtophys.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-mlock.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-pci.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-registry.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-usermap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-modeset-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-pci-table.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-kthread-q.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-kthread-q-selftest.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-memdbg.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-ibmnpu.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-report-err.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv_uvm_interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nvlink_linux.o ld -r -o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset/nv-modeset-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset/nvidia-modeset-linux.o MODPOST /usr/src/kernel-modules/nvidia-390.157-default/Module.symvers CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko due to unavailability of vmlinux make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-uvm.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-modeset.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-drm.ko DEPMOD /usr/lib/modules/6.8.1-1-default Warning: modules_install: missing 'System.map' file. Skipping depmod. make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' rm -f -r conftest make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' CLEAN /usr/src/kernel-modules/nvidia-390.157-default CLEAN /usr/src/kernel-modules/nvidia-390.157-default/Module.symvers make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' But I can boot to 6.8.1-1 without graphic system and only command line. I am missing here another point obviously and googling for the 2 errors does not give a sufficient solution for the nVidia case, but a lot of stuff for other drivers. I do guess it is a simple root cause for "Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default /nvidia-modeset.ko due to unavailability of vmlinux" and "Warning: modules_install: missing 'System.map' file. Skipping depmod." BR

On 23.03.2024 22:28, Peter Maffter via openSUSE Users wrote:

I used the nVidia compile command from From: Bjoern Voigt via openSUSE Users Date: Tue, 21 Nov 2023 11:37:52 +0100 Subject: Re: nVidia: build error with kernel 6.6.1

I have no idea what it means. Show the full command and the complete output. ...

make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-uvm.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-modeset.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-drm.ko DEPMOD /usr/lib/modules/6.8.1-1-default Warning: modules_install: missing 'System.map' file. Skipping depmod.

bor@tw:~> ll /usr/lib/modules/6.8.1-1-default/System.map -rw-r--r-- 1 root root 7603403 Mar 19 10:32 /usr/lib/modules/6.8.1-1-default/System.map bor@tw:~>

Hello, In the Message; Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : Date & Time: Sat, 23 Mar 2024 21:00:02 +0100 [PM] == Peter Maffter via openSUSE Users has written: [...] PM> /usr/src/kernel-modules/nvidia-390.157-default # PM> vers=6.8.1-1-default;make clean modules KERNEL_UNAME=$vers;make PM> modules_install KERNEL_UNAME=$vers; make clean PM> KERNEL_UNAME=$vers;depmod $vers [...] How about this? depmod $ver ---> depmod -A $ver Kind Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "As Google fights for positioning in a new AI boom and an era where some consumers are turning to TikTok or ChatGPT instead of Google Search, some employees now worry product development could become dangerously hasty. The restructuring of RESIN has increased those concerns, the sources say." -- Google Splits Up a Key AI Ethics Watchdog --

On 24.03.2024 18:44, Peter Maffter via openSUSE Users wrote:

Warning: modules_install: missing 'System.map' file. Skipping depmod.

1. There is no indication this message is actually a problem. Did you check if you can load compiled module(s)? 2. Did you check whether System.map file exists?

make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1'

So there is still something important missing for compilation of the nVidia driver. Did not find anything in Google for this.

BR

Am 24/03/2024 um 17:23 schrieb Peter Maffter via openSUSE Users:

Am 24/03/2024 um 17:17 schrieb Andrei Borzenkov:

...

On 24.03.2024 18:44, Peter Maffter via openSUSE Users wrote:

...

Warning: modules_install: missing 'System.map' file. Skipping depmod.

1. There is no indication this message is actually a problem. Did you check if you can load compiled module(s)?

"Skipping depmod" ?

...

2. Did you check whether System.map file exists?

ll /usr/lib/modules/6.8.1-1-default/System.map -rw-r--r-- 1 root root 7603403 Mar 19 08:32 /usr/lib/modules/6.8.1-1-default/System.map

The article at https://patchwork.kernel.org/project/linux-kbuild/patch/dde798fd-9fef-6ac0-a... says, that before Sept. 2018 this was exiting without any message. "if ! test -r System.map ; then + echo "Warning: modules_install: missing 'System.map' file. Skipping depmod." >&2 exit 0 fi" test -r System.map in my case simply results in nothing although: ll /usr/lib/modules/6.8.1-1-default/System.map -rw-r--r-- 1 root root 7603403 Mar 19 08:32 /usr/lib/modules/6.8.1-1-default/System.map So there seems to be something wrong in /usr/src/kernel-modules/nvidia-390.157-default/Makefile But I do not know, what is missing in the Makefile.

Am 24/03/2024 um 18:26 schrieb Peter Maffter via openSUSE Users:

Am 24/03/2024 um 18:02 schrieb Peter Maffter via openSUSE Users:

...

Am 24/03/2024 um 17:23 schrieb Peter Maffter via openSUSE Users:

...

Am 24/03/2024 um 17:17 schrieb Andrei Borzenkov:

...

On 24.03.2024 18:44, Peter Maffter via openSUSE Users wrote:

...

Warning: modules_install: missing 'System.map' file. Skipping depmod.

1. There is no indication this message is actually a problem. Did you check if you can load compiled module(s)?

"Skipping depmod" ?

...

2. Did you check whether System.map file exists?

ll /usr/lib/modules/6.8.1-1-default/System.map -rw-r--r-- 1 root root 7603403 Mar 19 08:32 /usr/lib/modules/6.8.1-1-default/System.map

The article at https://patchwork.kernel.org/project/linux-kbuild/patch/dde798fd-9fef-6ac0-a...

says, that before Sept. 2018 this was exiting without any message.

"if ! test -r System.map ; then + echo "Warning: modules_install: missing 'System.map' file. Skipping depmod." >&2 exit 0 fi"

test -r System.map in my case simply results in nothing although:

ll /usr/lib/modules/6.8.1-1-default/System.map -rw-r--r-- 1 root root 7603403 Mar 19 08:32 /usr/lib/modules/6.8.1-1-default/System.map

So there seems to be something wrong in /usr/src/kernel-modules/nvidia-390.157-default/Makefile

But I do not know, what is missing in the Makefile.

https://www.linuxquestions.org/questions/ubuntu-63/system-map-no-such-file-o... has a pointer: "If it says "not found" it means you don't have that file in that directory. Either you need to find where System.map or you need to install a separate package that includes System.map. If the file DOES exist on your system but is in a another directory you can create a symbolic link in /lib/modules/2.6.32-25-generic/build to where it really exists OR you could modify the makefile to point to the correct path."

ls -l /lib/modules/6.8.1-1-default/build/System.map is not there.

Shall I make a symbolic link from /usr/lib/modules/6.8.1-1-default/System.map to /lib/modules/6.8.1-1-default/build/System.map ?

As I said: I did compile kernel modules a long time ago and since this changed a lot I am a bit lost here.

I simply tried: ln -s /usr/lib/modules/6.8.1-1-default/System.map /lib/modules/6.8.1-1-default/build/System.map ll /lib/modules/6.8.1-1-default/build/ total 2296 drwxr-xr-x 3 root root 4096 Mar 23 00:15 arch -rw-r--r-- 1 root root 279824 Mar 19 08:32 .config -rw-r--r-- 1 root root 39 Mar 19 08:32 .gitignore drwxr-xr-x 4 root root 4096 Mar 23 00:15 include -rw-r--r-- 1 root root 40 Mar 19 08:32 Makefile -rw-r--r-- 1 root root 128426 Mar 19 08:32 Module.supported -rw-r--r-- 1 root root 1910418 Mar 19 08:32 Module.symvers drwxr-xr-x 7 root root 4096 Mar 23 00:15 scripts lrwxrwxrwx 1 root root 43 Mar 25 22:57 System.map -> /usr/lib/modules/6.8.1-1-default/System.map drwxr-xr-x 3 root root 4096 Mar 23 00:15 tools As I wrote previously I replaced in nvidia-drm-drv.c DRM_UNLOCKED with 0 according to https://github.com/CachyOS/kernel-patches/blob/master/6.8/misc/nvidia/0001-n... /usr/src/kernel-modules/nvidia-390.157-default # vers=6.8.1-1-default;make clean modules KERNEL_UNAME=$vers;make modules_install KERNEL_UNAME=$vers; depmod $vers rm -f -r conftest make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' CLEAN /usr/src/kernel-modules/nvidia-390.157-default CLEAN /usr/src/kernel-modules/nvidia-390.157-default/Module.symvers make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] You are using: cc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] CONFTEST: INIT_WORK CONFTEST: remap_pfn_range CONFTEST: hash__remap_4k_pfn CONFTEST: follow_pfn CONFTEST: vmap CONFTEST: set_pages_uc CONFTEST: list_is_first CONFTEST: set_memory_uc CONFTEST: set_memory_array_uc CONFTEST: change_page_attr CONFTEST: pci_get_class CONFTEST: pci_choose_state [...] CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-linux.o CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-helper.o CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nv-pci-table.o CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-gem-nvkms-memory.o CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm/nvidia-drm-gem-user-memory.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.o ld -r -o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-frontend.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-instance.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-gpu-numa.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-acpi.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-chrdev.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-cray.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-dma.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-gvi.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-i2c.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-mempool.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-mmap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-p2p.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-pat.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-procfs.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-usermap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-vm.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-vtophys.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-mlock.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-pci.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-registry.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/os-usermap.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-modeset-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-pci-table.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-kthread-q.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-kthread-q-selftest.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-memdbg.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-ibmnpu.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv-report-err.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nv_uvm_interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia/nvlink_linux.o ld -r -o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset/nv-modeset-interface.o /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset/nvidia-modeset-linux.o MODPOST /usr/src/kernel-modules/nvidia-390.157-default/Module.symvers CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-uvm.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-modeset.ko due to unavailability of vmlinux CC [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.mod.o LD [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko due to unavailability of vmlinux make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' make[1]: Entering directory '/usr/src/linux-6.8.1-1' make[2]: Entering directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-uvm.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-modeset.ko INSTALL /usr/lib/modules/6.8.1-1-default/kernel/drivers/video/nvidia-drm.ko DEPMOD /usr/lib/modules/6.8.1-1-default make[2]: Leaving directory '/usr/src/linux-6.8.1-1-obj/x86_64/default' make[1]: Leaving directory '/usr/src/linux-6.8.1-1' So depmod is working now, but there is still BTF [M] /usr/src/kernel-modules/nvidia-390.157-default/nvidia-drm.ko Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default After compilation I rebooted from 6.7.9-1-default to 6.8.1-1-default Success: graphics is there. All seems to be working. Short test with a testfilm big_buck_bunny_1080p_h264.mov also shows no strange video things. So just the "Skipping BTF generation for /usr/src/kernel-modules/nvidia-390.157-default" problem remains. BR

Hello, In the Message; Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : <87sf0ftcxh.wl-nomiya@lake.dti.ne.jp> Date & Time: Mon, 25 Mar 2024 08:42:02 +0900 [MN] == Masaru Nomiya has written: MN> Hello, MN> In the Message; MN> Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia MN> Message-ID : MN> Date & Time: Sat, 23 Mar 2024 21:00:02 +0100 MN> [PM] == Peter Maffter via openSUSE Users has written: MN> [...] PM> /usr/src/kernel-modules/nvidia-390.157-default # PM> # vers=6.8.1-1-default;make clean modules KERNEL_UNAME=$vers;make PM> modules_install KERNEL_UNAME=$vers; make clean PM> KERNEL_UNAME=$vers;depmod $vers MN> [...] MN> Isn't this? MN> # vers=6.8.1-1-default;make clean modules KERNEL_UNAME=$vers;make MN> modules_install KERNEL_UNAME=$vers; depmod -A; make clean MN> KERNEL_UNAME=$vers MN> In other words, shouldn't depmod be run before make clean, i.e., MN> immediately after make install? This had nothing to do with. On nvidia 550.67, your method worked fine. If the System.map is not created, it means that 'make vmlinux' is not running, so the patch you used must have a problem? Best Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "As Google fights for positioning in a new AI boom and an era where some consumers are turning to TikTok or ChatGPT instead of Google Search, some employees now worry product development could become dangerously hasty. The restructuring of RESIN has increased those concerns, the sources say." -- Google Splits Up a Key AI Ethics Watchdog --

* Masaru Nomiya [03-25-24 00:46]:

Hello,

In the Message;

Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : <987fc246-4e3f-456e-b01f-f5128fcc8985@yahoo.de> Date & Time: Sat, 23 Mar 2024 20:28:12 +0100

[PM] == Peter Maffter via openSUSE Users has written:

[...] PM> after editing nvidia-drm-drv.c and replacing DRM_UNLOCKED with 0 according to PM> https://github.com/CachyOS/kernel-patches/blob/master/6.8/misc/nvidia/0001-n... [...]

I don't think 'replacing DRM_UNLOCKED with 0' is correct. So, looking at 550.67, replacing 'DRM_RENDER_ALLOW|0' seems correct.

I've created a patch along these lines, so please give it a try.

The patched driver is created as follows;

$ sh ./NVIDIA-Linux-x86_64-390.157.run --apply-patch 390.patch

on my nvidia modules I see: static const enum drm_ioctl_flags DRM_UNLOCKED = 0; -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

Hello, In the Message; Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : <20240325125734.GV28899@wahoo.no-ip.org> Date & Time: Mon, 25 Mar 2024 08:57:34 -0400 [PS] == Patrick Shanahan has written: PS> * Masaru Nomiya [03-25-24 00:46]: [...] MN> > I don't think 'replacing DRM_UNLOCKED with 0' is correct. MN> > So, looking at 550.67, replacing 'DRM_RENDER_ALLOW|0' seems correct. [...] PS> on my nvidia modules I see: PS> static const enum drm_ioctl_flags DRM_UNLOCKED = 0; ? I am talking about this part of driver 550.67? [...] #if defined(NV_DRM_ATOMIC_MODESET_AVAILABLE) DRM_IOCTL_DEF_DRV(NVIDIA_GEM_IMPORT_NVKMS_MEMORY, nv_drm_gem_import_nvkms_memory_ioctl, DRM_RENDER_ALLOW|DRM_UNLOCKED), #endif /* NV_DRM_ATOMIC_MODESET_AVAILABLE */ [...] In the Message; Subject : AW: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : Date & Time: Mon, 25 Mar 2024 13:24:44 +0000 [RK] == Rainer Klier has written: [...] RK> maybe this page helps: RK> https://gist.github.com/joanbm What it says here is driver 470. I think Andrei's advice that driver 390 cannot be used with the current Tumbleweed may be correct? Cf. https://nvidia.custhelp.com/app/answers/detail/a_id/3142 The Linux 390.* legacy driver series is the last to support GF1xx ("Fermi") GPUs. Support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 390.* legacy releases through the end of 2022. Best Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that must be fed at all costs―even if it isn’t always clear what exactly that data is needed for or what those future AI systems might end up doing." -- Generative AI Is Making Companies Even More Thirsty for Your Data --

* Masaru Nomiya [03-25-24 00:46]:

Hello,

In the Message;

Subject : Re: Again: error with kernel 6.8.1-1 when compiling nVidia Message-ID : <987fc246-4e3f-456e-b01f-f5128fcc8985@yahoo.de> Date & Time: Sat, 23 Mar 2024 20:28:12 +0100

[PM] == Peter Maffter via openSUSE Users has written:

[...] PM> after editing nvidia-drm-drv.c and replacing DRM_UNLOCKED with 0 according to PM> https://github.com/CachyOS/kernel-patches/blob/master/6.8/misc/nvidia/0001-n... [...]

I don't think 'replacing DRM_UNLOCKED with 0' is correct. So, looking at 550.67, replacing 'DRM_RENDER_ALLOW|0' seems correct.

I've created a patch along these lines, so please give it a try.

The patched driver is created as follows;

$ sh ./NVIDIA-Linux-x86_64-390.157.run --apply-patch 390.patch

on my nvidia modules I see: static const enum drm_ioctl_flags DRM_UNLOCKED = 0; -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On 23.03.2024 19:07, Peter Maffter wrote:

I expected that someone can explain to me, why they simply dropped out DRM_UNLOCKED

Author: Thomas Zimmermann Date: Wed Nov 22 13:09:40 2023 +0100 drm: Remove locking for legacy ioctls and DRM_UNLOCKED Modern DRM drivers acquire ioctl locks by themselves. Legacy ioctls for user-space mode setting used to acquire drm_global_mutex. After removing the ioctl entry points, also remove the locking code. The only legacy ioctl without global locking was VBLANK_WAIT, which has been removed as well. Hence remove the related DRM_UNLOCKED flag. Signed-off-by: Thomas Zimmermann Reviewed-by: David Airlie Reviewed-by: Daniel Vetter Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-12-tzimme...