SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,095
Original Poster
Rep:
Quote:
Originally Posted by enorbet
Does this mean it won't work with a MultiLib install... installing 32bit compatibility libraries? By this I am referring to launching the NVIDIA*.run file from Runlevel 3.
Good point.
Quote:
Originally Posted by akimmet
32bit compatibility libraries are still included with 64bit nVidia drivers.
What he said ^
Thanks, akimmet, for the clarification.
Last edited by cwizardone; 10-21-2018 at 06:50 PM.
Thanks guys. I've had some difficulties installing the 410.66 driver. It fails to build on my custom 4.15.0 kernel with that nebulous message about gcc (hasn't changed) and about 4 other possibilities (nouveau? blacklisted... modeset? disabled in lilo, etc) none of which seem appropriate. I'm still running 396.54.09 which builds just fine but I'm expecting my 1070Ti and Vulkan are new enough that 410 might offer even better performance so I'll keep at it from time to time..
Out of curiosity, why are you running such an old and unprotected kernel? I never tend to sit on the 4.x.0 releases very long since the initial releases tend to spur a lot of bug fixes once issues are found...
Out of curiosity, why are you running such an old and unprotected kernel? I never tend to sit on the 4.x.0 releases very long since the initial releases tend to spur a lot of bug fixes once issues are found...
As usual, bassmadrigal, you're right and I've just been satisfied way too long partly out of habit and partly from aversion to spending the time to build a new one. I'll fix this by the morning and I'm quite sure, be glad I did. Thanks once again for sage advice of the most gentlemanly kind.
For the next SBo release, I'm pulling the plug on 32-bit support. nvidia-390.87 will be the last that supports both arch. Multilib will still be on option for those x86_64 users that need it.
Update - I built and installed kernel v4.16.18 and soon after 4.10.66 nvidia went in w/o a hitch. Thanks again. It's working great.
Re: 32 bit. I'm a little sad to see 32bit go as it was just simpler (and more obvious) than running MultiLib but OTOH I knew the day would come and hopefully this is a sign that very soon MultiLib transition will no longer be needed. It does make me consider how OS/2, a fully 32bit system, was able to run 16 and even 8bit apps natively with no hoops to jump through. I suppose that's still possible just more work than anyone wants to engage in. It also makes me giggle at Hollywood in films like the box office smash "Independence Day" when Jeff Goldblum's hacker character manages to hack into a computer system developed by an alien race capable of interstellar travel when if even by some astronomical odds it was based on Binary and the hacker thought in Machine Language, the feat was literally a completely insurmountable task. Almost every year it gets more ridiculous trying to imagine such a gap
enorbet,
SLAMD64, the short lived x86_64 port of Slackware, was pretty transparent in the 32/64 mix. I remember that Alien Bob had a post on why he set up multilib the way it now is somehere on either LQ or his blog. I'll try to find it. Almost can't fathom that Slackware64-13.0 and multilib dates to 2009! Where does the time go?
I posted sometime back that the 410.xx series would not work on my system, but the 390.xx would. Well, the occasion arose that I had to reinstall Slackware from scratch (mostly due to my impatience in waiting for Eric to post an update to icu4c and related applications), and thought I'd use the newly released driver to see if something in my old install was causing 410.xx to fail, and it turned out it was. To this day, I don't know what misconfiguration in my old install was responsible for 410.xx not working, but glad it's working now!
Added support for the following GPUs:
Quadro RTX 6000
Quadro RTX 5000
Added a USB-C display connector type identifier, such that a display connected using Turing's USB-C connector will be named, e.g., "USB-C-0" rather than "DP-5". Scripts and configuration files that use the DP identifier for this connector will be affected.
Fixed a bug that caused vkGetPhysicalDeviceDisplayPropertiesKHR() to occasionally return incorrect values for physicalResolution.
Added the synchronization state for PRIME Displays to nvidia-settings.
Edit in: The 410.73 driver has been running perfectly for several hours with -current, the 4.19.0 kernel and xorg-1.20.3.
Last edited by cwizardone; 10-25-2018 at 08:08 PM.
Added a new hook script, "pre-unload", to the nvidia-installer hook script system. This script, if present, will be executed before nvidia-installer attempts to unload existing NVIDIA kernel modules.
Fixed a bug that caused vkGetPhysicalDeviceDisplayPropertiesKHR() to occasionally return incorrect values for physicalResolution.
Added the synchronization state for PRIME Displays to nvidia-settings.
Improved error reporting in eglSwapBuffers() by generating codes for some missing error types, and adding additional detail to the already existing ones.
Improved the appearance and functionality of the nvidia-settings control panel when it is resized to small sizes.
Updated the nvidia-settings control panel to prevent some icons from being displayed incorrectly while using some GTK+ themes.
Fixed a bug that could cause WINE to crash on recent OS releases.
Fixed a bug that could cause an X server crash when exiting Vulkan applications running on X servers with UBB enabled.
Fixed an X driver bug that caused the "NoEdidModes" token of the "ModeValidation" X configuration option to reject non-EDID modes whose timings matched EDID modes.
Changed the NvEncCreateBitstreamBuffer API call in the NvEncodeAPI library to return NV_ENC_ERR_UNIMPLEMENTED instead of NV_ENC_SUCCESS when the encoder instance is configured to run in motion estimation-only mode. As an indirect consequence of this change, users running the AppEncME sample application from the Video Codec SDK prior to SDK version 8.2.16 will observe a segmentation fault due to bugs in the NvEncoder class. It is recommended that users download the latest version of the SDK, where these bugs have been fixed, from https://developer.nvidia.com/nvidia-video-codec-sdk.
Fixed an OpenGL driver bug that caused the upper bounds of floating-point viewports, specified through the ARB_viewport_array extension, to be clipped incorrectly.
Added a new X configuration option "HardDPMS" which is disabled by default, but can be enabled to put displays to sleep with modesets rather than VESA DPMS. This may fix some displays that fail to sleep when DPMS becomes active. "HardDPMS" will be enabled by default in a future release.
Raised the minimum supported X.Org xserver version to 1.5 (video driver ABI version 4).
Enabled the NVreg_EnableBacklightHandler kernel module option by default.
Removed the LinuxThreads version of the /usr/lib/libnvidia-tls.so library and replaced it with the NPTL one that was previously installed in /usr/lib/tls/. This fixes crashes on Debian systems when the /etc/ld.so.nohwcap file is present.
Updated nvidia-installer to allow the --no-cc-version-check option to disable the compiler version check when installing with DKMS.
Changed the minimum required Linux kernel version from 2.6.9 to 2.6.32.
Fixed an OpenGL bug where conditional rendering (NV_conditional_render) was incorrectly affecting mipmap generation.
Fixed a bug that could cause the X server to hang on systems booted in legacy VGA mode when using a DisplayPort Multi-Stream link.
Edit in: Installed and running well.
Last edited by cwizardone; 11-09-2018 at 11:44 AM.
Added support for the following GPUs:
Quadro RTX 4000
Fixed a bug that could cause the X server to hang on systems booted in legacy VGA mode when using a DisplayPort Multi-Stream link.
Fixed a bug that caused mode switches to fail when an SDI output board was connected.
Fixed a bug that could cause rendering corruption in Vulkan programs.
Added a new hook script, "pre-unload", to the nvidia-installer hook script system. This script, if present, will be executed before nvidia-installer attempts to unload existing NVIDIA kernel modules.
Last edited by cwizardone; 11-15-2018 at 07:07 PM.
I wish they would update the 390 series, I have a card no longer supported in the 410 series. Installation fails on building (4.19.x kernel) the nvidia-drm module, suggesting that I use the --no-drm option. LOL
Last edited by chrisretusn; 11-16-2018 at 04:10 AM.
Reason: Spelling issues.
I wish they would update the 390 series, I have a card no longer supported in the 410 series. Installation fails on building (4.19.x kernel) the nvidia-drm module, suggesting that I use the --no-drm option. LOL
maybe you missed it, but there's is a patch for it in the unofficial repository for current
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
