Kernel 4.4.172 on Slack64 and Nvidia

camorri · 01-31-2019, 02:03 PM

I started to update my 14.2 installs today. I started on my back-up system.

The 4.4.172 packages install without problems. I have an Nvidia card, a GeForce GT 710 in my system. I had this driver installed on 4.4.157 without any problems.

On this system I have 4 disks, I have current, two 14.2/64 installs and a 14.2/32 bit install. Each is on a separate disk.

After installing 4.4.172 on my backup system, I tried to build NVIDIA-Linux-x86_64-410.93.run . This failed to build.

I looked at /var/log/nvidia-installer.log and saw the same failure as in this post: https://www.linuxquestions.org/quest...es-4175646130/

It took some effort, I downloaded NVIDIA-Linux-x86_64-418.30.run and ran the file. It built the Nvidia driver, and I'm using it now. The driver is Beta. I have not see another problem with it so far.

This is more of a warning to anyone using the 410.93 driver on an Nvidia card. I downloaded the beta driver from this link https://devtalk.nvidia.com/default/topic/1046879.

I have several other installs to update. So, proceed with caution.

Jeebizz · 01-31-2019, 07:47 PM

I found a different solution - but it is rather dumb and I do not recommend it. I just said fsck it and installed the kernel from -current - NVIDIA complained about gcc being an older version but I ignored it and forced it to compile, and well it worked.

bender647 · 01-31-2019, 08:02 PM

My wife uses the nvidia driver, so after trying 410.78 and 410.93, I eventually came to the 418.30 beta version too. Built it with the slackbuilds.org scripts by setting VERSION=418.30. It seems to work, but I was unable to use the COMPAT32=yes flag or the script would throw an error so we'll do without the 32-bit libraries for now.

Code:

install: cannot stat '32/tls/libnvidia-tls.so.418.30': No such file or directory

Drakeo · 02-01-2019, 10:32 AM

Yes Obviusly Pat has no use for nvida. Oh well send him some money. Thanks for the broken kernel on stable.

willysr · 02-01-2019, 11:32 AM

It's not Pat's fault. It's upstream who decided to merge that changes in LTS release.

Richard Cranium · 02-01-2019, 12:56 PM

Quote:

Originally Posted by Drakeo

Yes Obviusly Pat has no use for nvida. Oh well send him some money. Thanks for the broken kernel on stable.

The nvidia driver that comes with the kernel works just fine.

volkerdi · 02-01-2019, 02:41 PM

Quote:

Originally Posted by Drakeo

Thanks for the broken kernel on stable.

The kernel isn't broken just because closed-source blobs haven't caught up with a changed API. That's to be expected, actually.

While I don't agree with changing APIs on a supposedly stable kernel series, we still have a difference of opinion about where the breakage lies.

dugan · 02-01-2019, 04:46 PM

It's NVidia's responsibility to keep up.

Don't worry; they will.

Lenard Spencer · 02-01-2019, 07:39 PM

Quote:

Originally Posted by bender647

My wife uses the nvidia driver, so after trying 410.78 and 410.93, I eventually came to the 418.30 beta version too. Built it with the slackbuilds.org scripts by setting VERSION=418.30. It seems to work, but I was unable to use the COMPAT32=yes flag or the script would throw an error so we'll do without the 32-bit libraries for now.

Code:

install: cannot stat '32/tls/libnvidia-tls.so.418.30': No such file or directory

What I did here was to comment out lines 181-189 in nvidia-driver.SlackBuild (also necessary for the 415 driver) and multilib built and installed with no problem.

bender647 · 02-01-2019, 07:39 PM

I had more time tonight, so saw it was an easy fix to get the slackbuilds.org 410.78 script to work with the 418.30 beta drivers and COMPAT32=yes.

Here's the patch.

Code:

--- nvidia-driver.SlackBuild.410.78	2019-02-01 20:28:28.699342182 -0500
+++ nvidia-driver.SlackBuild	2019-02-01 20:26:34.426244301 -0500
@@ -25,7 +25,7 @@
 # see changelog.txt
 
 PRGNAM=nvidia-driver
-VERSION=${VERSION:-410.78}
+VERSION=${VERSION:-418.30}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}
 
@@ -164,7 +164,7 @@
 rm -rf /var/lib/nvidia
 # which 32-bit tls? why? why?
 if [ "$ARCH" = "x86_64" -a "${COMPAT32}" = "yes" ]; then
-      install -m 755 32/tls/libnvidia-tls.so.$VERSION $PKG/usr/lib/tls/libnvidia-tls.so.$VERSION
+      install -m 755 32/libnvidia-tls.so.$VERSION $PKG/usr/lib/tls/libnvidia-tls.so.$VERSION
       cd $PKG/usr/lib
           ln -sf tls/libnvidia-tls.so.$VERSION libnvidia-tls.so.$VERSION
       cd -

Of course, change the version numbers in all the download links to get the source.

FlinchX · 02-02-2019, 04:38 AM

Quote:

Originally Posted by volkerdi

I don't agree with changing APIs on a supposedly stable kernel series

I have to say I was as well at least confused about this happening, especially that I recall Linus saying once that kernel changes should never break userland, albeit I don't remember the context.

I am not following kernel development at all, but as an end user this change simply forces me to delay updating the kernel packages in Slackware 14.2 (and I'm really not happy about it) until there will be virtualbox and nvidia blob releases that will work out of the box without me having to adapt my update workflow (I am using the virtualbox binary installer from oracle, but I do install the nvidia blobs using the SBo scripts). I have seen willysr's blog post about virtualbox workaround and the suggested approaches to fix it for nvidia drivers in this forum, but I rather prefer to wait for a little longer. Also, since I have to use r8168 from SBo, because my network cards don't work properly with the stock kernel, this gives me another reason to wonder if I might end with broken networking after the update as well. Haven't seen any forum thread about r8168 issues yet, but I suppose it's because virtualbox/nvidia blobs are just widely used unlike this one.

Could anybody provide a reference link to the relevant lkml threads where the necessity of changing the API in the stable kernel version was discussed? I have attempted to look for it on my own but with no luck so far. This is unusual enough to trigger my curiosity even if I probably won't understand any technical details. While this feels inconvenient and disturbs my weekly Slackware stable update workflow, I'm trying to not be quick in picking sides by blaming either party involved, but I'm definitely interested to learn more why it happened rather than what exactly (from a technical standpoint) happened.

Petri Kaukasoina · 02-02-2019, 05:13 AM

Quote:

Originally Posted by FlinchX

I recall Linus saying once that kernel changes should never break userland,

Nvidia kernel modules are not userland.

kjhambrick · 02-02-2019, 05:46 AM

FlinchX --

Yes, I feel the same way.

I am still on 4.4.167.kjh because I can't build VMWare Workstation 12.1 against 4.4.168+

I am even more concerned looking at the 4.4.168 changelog https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.168

There were 'a zillion' API changes that seem to related to get_user_pages() ( commit 8e50b8b07f462ab4b91bc1491b1c91bd75e4ad40 )

Look thru the changelog for Author: Lorenzo Stoakes <redacted@example.com>

I wonder what else is broken that we may not find as a compiler error but instead as a kernel oops ?

I did not find any discussion about the implications of changing the API for get_user_pages() but I gave up pdq.

Here is a lwn article: https://lwn.net/Articles/753027/

And willysr wrote a blog post about 4.9 and current in May 2017: https://slackblogs.blogspot.com/2017...-on-linux.html

I believe I could apply willysr's patch to make VMWare Workstation 12.1 compile against 4.4.168+ but I am going to try VMWare Workstation 15 instead and then I will only resort to willysr's patch 'if I have to' ( another day )

Yes, I am a tad miffed but not at Pat / Slackware.

I don't think the kernel devs thought much about userspace when they applied all of Lorenzo's commits to 4.4.168.

And then the planets aligned in such a way that I skipped 4.4.168 because I was so busy at work so I missed my opportunity to pipe up back when 4.4.168 was released.

Anyhow ... it is what it is ... no one ( at least not me ) will remember this bump in the road in a year-or-two ...

-- kjh

EDIT: I saw Petri Kaukasoina's post while I was going thru my bookmarks to write my 'me too rant'.

Interesting point !

Third Party Apps that link to the Kernel -and-or- provide Kernel Modules are not userland Apps.

I had never looked at it that way but I DO see your point

Thank You !

Richard Cranium · 02-02-2019, 12:10 PM

https://www.nvidia.com/download/driv...x/142166/en-us is a better link to the beta driver.

jmccue · 02-02-2019, 02:46 PM

Will I knew this day was coming for me, the nvidia version I need is 304 and there is no hope for that ever being fixed. I was expecting it to occur on the next release of Slackware, but a bit early.

I ended up ordering a non-nvidia card (I am on a desktop) and from what I see that should be fine (I am not a 3d gamer).

Anyway all this does is confirm my current conviction, never buy anything associated with nvidia