Kernel 4.4.172 on Slack64 and Nvidia

phenixia2003 · 02-14-2019, 08:45 AM

Hello,

Quote:

Originally Posted by FlinchX

I don't understand what's going on

https://download.nvidia.com/XFree86/...rtedchips.html

lists GT 730 as supported, just as camorri said above.

I guess that list refers to the GT730 based on Kepler GPU (GK208) while your G730 is based on Fermi GPU (GF108) for which support has been retired from nvidia driver:

https://www.phoronix.com/scan.php?pa...Fermi-Mainline
https://nvidia.custhelp.com/app/answ...tail/a_id/4654
https://nvidia.custhelp.com/app/answ...QnclMjElMjE%3D

--
SeB

enorbet · 02-14-2019, 09:17 AM

If you don't do 3D Gaming and insist on keeping a lower level, 5-6 year old card it is probably wise to use nouveau. This may depend on which of 3 chipsets it has, the newer Maxwell, the older Fermi, and the even older Kepler designs, but it will work.

However if for whatever reason you have installed the proprietary driver and enjoyed some improved function why not just stick with a kernel that worked with it? If the card is embedded then all the other chipsets are equally old and shouldn't be hard pressed for a kernel upgrade.

If it is simply a removable device why not accept a $70-$100 fee every 6 years or so as "the cost of doing business" since this is exactly how nVidia manages to afford to provide us with great drivers for no cost. Is less than 1 dollar a month too much to ask, especially when there is a free alternative?

BTW assuming nVidia is hostile to Linux is IMHO patently absurd since they simply wouldn't make serious drivers for it at all, let alone for almost 20 years. Not only do they make great drivers but have you ever done "NVIDIA-foo.run --extract-only" and looked at the documentation? There is not only zero evidence of actual hostility, they look pretty damned proud, concerned and responsible to me.

Considering I can play the exact same game even somewhat crippled by running it on an NTFS partition (so Windows can see it too) and get virtually identical performance and further considering that Windows users comprise at least 100 TIMES more revenue than Linux where is there any evidence for hostility? They just have a different point of view and business plan than Linus does.

Specific to this thread since documentation says the GT730 is supported by nvidia with a specific driver and apparently some even have got it working on lower models like the 710, it would appear the kernel is the issue. The only choice is to spend either money or time to find a combination that works for you. TANSTAAFL, right?

FlinchX · 02-14-2019, 10:03 AM

@enorbet I make a difference between spending time and wasting time. Spending time to learn about this issue by reading this forum, the SBo mailing list, the nvidia forum is fair to me. Wasting more than one hour to wait for a live chat session just to hear that they don't support Linux in live chat is very unfair and I feel cheated for not being able to read that explicitly on their live chat page. You see, I actually stared at the counter on the chat page that kept resetting every 5 minutes and saying sorry, just because I didn't want to waste the time of some poor dude doing that support.

As for their forum, well, there's the thread that I've linked in a previous post in this thread. A forum moderator there answered about the 418.30 version and that answer is marked as accepted by the original poster. Yet there's the question about the backport for legacy versions and more reports below about the same problem. Yet zero feedback to them, for two weeks. And I'm worried that if the thread is marked as solved, there might be no answers. I'd go and just create another thread there to ask for an explicit yes or no to the question about a backport for the legacy versions, but I don't want to trash their forum with dupes.

Don't get me wrong, I'm not trying to use this forum as a place to spread hate against nvidia just because "Linus did it so it's cool", and I really hope it isn't seen like this. But as an end user I believe that so far I did my "homework", in the boundaries of my limited knowledge, by reading the available resources and trying to make things work. I had a working system, I updated software and now I'm suspended in the air, not knowing what to do next for reasons mentioned above.

enorbet · 02-14-2019, 12:12 PM

To be clear FlinchX I think it totally sux that it took an hour of waiting only to be told "We don't do Linux support". I agree that this should be made absolutely clear since I don't think nVidia needs to be a fancy dancer on that subject as they are perfectly justified. I just don't see that as evidence of hostility... maybe too much input from the Sales Department but not hostile.

FlinchX · 02-14-2019, 12:13 PM

Quote:

Originally Posted by kingbeowulf

If nouveau has suffient support for your GPU, I recommend nouveau instead of nvidia for the older cards (< GTX 600).

Been using nouveau for a few hours as a fallback and it's getting really annoying because of GPU fan being extremely loud. It wasn't like that with the blob. It's not even about performance, but I'm becoming confident I won't be able to use it on a daily basis, I'll get headache from this noise.

Richard Cranium · 02-14-2019, 05:43 PM

You might be able to control that via the hwmon interface.

See https://www.kernel.org/doc/Documenta...ouveau_thermal

You can find the /sys/class/hwmon subdirectory via...

Code:

cd /sys/class/hwmon; for n in *; do echo -n "${n} "; cat $n/name; done

On my machine, that gives...

Code:

cd /sys/class/hwmon; for n in *; do echo -n "${n} "; cat $n/name; done
hwmon0 atk0110
hwmon1 k10temp
hwmon2 nouveau

...and when I look inside /sys/class/hwmon/hwmon2, there's several things that I can tweak...

Code:

 /sys/class/hwmon/hwmon2 $ ls -lart
total 0
lrwxrwxrwx 1 root root    0 Feb 13 20:52 subsystem -> ../../../../../../../../class/hwmon/
-r--r--r-- 1 root root 4096 Feb 14 17:36 update_rate
-rw-r--r-- 1 root root 4096 Feb 14 17:36 uevent
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_max_hyst
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_max
-r--r--r-- 1 root root 4096 Feb 14 17:36 temp1_input
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_emergency_hyst
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_emergency
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_crit_hyst
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_crit
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_auto_point1_temp_hyst
-rw-r--r-- 1 root root 4096 Feb 14 17:36 temp1_auto_point1_temp
-r--r--r-- 1 root root 4096 Feb 14 17:36 temp1_auto_point1_pwm
-rw-r--r-- 1 root root 4096 Feb 14 17:36 pwm1_min
-rw-r--r-- 1 root root 4096 Feb 14 17:36 pwm1_max
-rw-r--r-- 1 root root 4096 Feb 14 17:36 pwm1_enable
-rw-r--r-- 1 root root 4096 Feb 14 17:36 pwm1
drwxr-xr-x 2 root root    0 Feb 14 17:36 power/
-r--r--r-- 1 root root 4096 Feb 14 17:36 name
-r--r--r-- 1 root root 4096 Feb 14 17:36 fan1_input
lrwxrwxrwx 1 root root    0 Feb 14 17:36 device -> ../../../0000:04:00.0/
drwxr-xr-x 3 root root    0 Feb 14 17:36 ../
drwxr-xr-x 3 root root    0 Feb 14 17:36 ./

FlinchX · 02-14-2019, 10:25 PM

Quote:

Originally Posted by Richard Cranium

You might be able to control that via the hwmon interface.

See https://www.kernel.org/doc/Documenta...ouveau_thermal

Problem is, the average temperature of the GPU stays the same - around 38-40C - with my regular workflow without additional apps putting heavy load, for both the blob and the nouveau driver. I know because I monitor that for both and temperature info goes into the dzen2 "cockpit". But the fan with nouveau is super noisy, and it starts right since the module is loaded by the kernel at system startup. I've seen the Arch wiki and a few other resources, they all have warnings in red about fiddling with these low level settings at my own risk. I am really hesitant to modify them.

Richard Cranium · 02-14-2019, 11:25 PM

Mine's sitting at ~42C with a fan speed of 900-930 with no 3d work going on. OTOH, I don't see a way to stress it since FreeCAD and Blender appear to use the CPU more than the graphics card.

ljb643 · 02-17-2019, 04:32 PM

Anyone else still using the older 304-series nVidia driver? That's the last series that works with my GeForce 7300GT card. The latest release 304.173 of that driver does not build with the new Slackware-14.2 kernel-4.4.172. The build fails with an error about get_user_pages(). Maybe nVidia will release an update to this legacy series, maybe not. Here's a patch to fix it right now. I only tested it with 32-bit Slackware and this specific kernel update.

After upgrading the kernel to 4.4.172 and installing the kernel-source package, unpack the NVIDIA driver:

Code:

# sh NVIDIA-Linux-x86-304.137.run --extract-only

Change into the NVIDIA-Linux-x86-304.137 directory.

You can apply the attached patch, using 'patch -p0 < nv-patch-k4.4.172.txt', or do it manually. To do it manually, edit kernel/nv-linux.h as follows. Delete from the line #if defined(NV_GET_USER_PAGES_REMOTE_PRESENT) through the corresponding #endif (60 lines deleted) and replace them with this:

Code:

#define NV_GET_USER_PAGES(start, nr_pages, write, force, pages, vmas) \
    get_user_pages(current, current->mm, start, nr_pages, \
       ((write ?  FOLL_WRITE : 0) | (force ? FOLL_FORCE : 0)), pages, vmas)

Now install the nVidia driver with

Code:

# ./nvidia-installer

FlinchX · 02-18-2019, 01:50 AM

Quote:

Originally Posted by ljb643

Here's a patch to fix it right now.

Oh yes, thank you for making my day, kind sir!

The 390.x driver had the same problem and your HOWTO fixes its build as well! The only difference is that the problem code is in another file: kernel/common/inc/nv-mm.h

Hopefully kingbeowulf notices this soon and us mere mortals can get a working buildscript for nvidia-legacy390-kernel as part of some future weekly routine SBo update.

I am confirming that 390.x kernel module builds fine with this change to the source code, loads fine and works fine so far on vanilla Slackware64-14.2 without multilib. I ran glxgears and a fullscreen game that wouldn't run with nouveau for a very quick test before posting this. The patch that is very similar to the one for 304.x is attached.

ehartman · 02-18-2019, 02:12 AM

Quote:

Originally Posted by ljb643

Anyone else still using the older 304-series nVidia driver? That's the last series that works with my GeForce 7300GT card.

I'm using a Quadro FX1500 card and 304.173 is the last nVidia package for that adapter too.
I'm not using the 4.4.173 kernel yet, but thanks in advance for the patch so that when I would upgrade I at least know my video driver will work again too.

ljb643 · 02-18-2019, 06:22 PM

Quote:

Originally Posted by FlinchX

... I am confirming that 390.x kernel module builds fine with this change to the source code, loads fine and works fine so far on vanilla Slackware64-14.2 without multilib...

I'm a little puzzled and uncomfortable with the patch you attached. You are adding code to define NV_GET_USER_PAGES but you are not removing or replacing another definition of NV_GET_USER_PAGES. That's different from what I did for the 304 driver. Why would this work?

FlinchX · 02-19-2019, 12:54 AM

Quote:

Originally Posted by ljb643

I'm a little puzzled and uncomfortable with the patch you attached. You are adding code to define NV_GET_USER_PAGES but you are not removing or replacing another definition of NV_GET_USER_PAGES. That's different from what I did for the 304 driver. Why would this work?

All I did was to follow the suggestion:

1.

Quote:

Delete from the line #if defined(NV_GET_USER_PAGES_REMOTE_PRESENT) through the corresponding #endif

2.

Quote:

replace them with this:

Code:

#define NV_GET_USER_PAGES(start, nr_pages, write, force, pages, vmas) \
    get_user_pages(current, current->mm, start, nr_pages, \
       ((write ?  FOLL_WRITE : 0) | (force ? FOLL_FORCE : 0)), pages, vmas)

It was a purely "monkey see - monkey do" approach that was rather text oriented, because I don't know more C than hello world. I did it because I was impatient to wait for a SBo update. Did I end with a formal successful compilation by doing some incorrect change? I am surely willing to learn more if this thread is the appropriate place for it, so you're very welcome to post a little more detailed and newbie-centric feedback. Did I just do something wrong or the change I ended with is also harmful and I should edit the post to hide it? The last thing I'd want to happen is some other user to end having troubles because of my incompetence.

rugujr · 02-19-2019, 06:04 AM

Quote:

Originally Posted by FlinchX

It was a purely "monkey see - monkey do" approach that was rather text oriented, because I don't know more C than hello world. I did it because I was impatient to wait for a SBo update. Did I end with a formal successful compilation by doing some incorrect change? I am surely willing to learn more if this thread is the appropriate place for it, so you're very welcome to post a little more detailed and newbie-centric feedback. Did I just do something wrong or the change I ended with is also harmful and I should edit the post to hide it? The last thing I'd want to happen is some other user to end having troubles because of my incompetence.

I tested the patch on a 14.2 x64 4.4.172 kernel and got no problems at all. Thanks for the patch.

ljb643 · 02-19-2019, 06:42 PM

Hey, if it works, it works, and you were successful.

For the 304 series: I saw that there is a script called conftest.sh that is supposed to figure out how to adapt various functions the nVidia driver needs to different kernel API changes. The section of interest defined two macros NV_GET_USER_PAGES and NV_GET_USER_PAGES_REMOTE. I then determined that (1) the macro NV_GET_USER_PAGES_REMOTE was never used; (2) NV_GET_USER_PAGES was used only once, and (3) conftest.sh was too complex and tricky for me to figure out how to fix it for the newer kernel. So I took the easy way out and just made a definition of NV_GET_USER_PAGES that works with the newer kernel only.

I have not seen the nVidia driver 390 series at all. But as I said, if your fix works, then it works.