kernel-huge-5.4.0_rc6-x86_64-1.txz:

enorbet · 11-06-2019, 11:43 AM

Quote:

Originally Posted by rogan

They've had maybe 25 years to join the train, or at least release info, to get their
chips supported natively. One of the last dinosaurs in the business.

I wan't offended being well aware and even understanding of Linus's position and frustration. I'm also a big fan of OSS but realize the GPL was crafted exactly as it is to allow companies, even proprietary ones, to profit from Linux support. I'm not a kernel developer so I don't share Linus's frustration as a simple User. I doubt his 2012 rant did much to change nVidia's stance but it is possible that AMD/Ati's efforts in OSS might. I have spent thousands of dollars on nothing but nVidia graphics since 1995 but I am beginning to consider AMD and I very much doubt I am alone in this. Every time I bought a new card I wrote nVidia to tell them I'd bought yet another exactly because of their Linux support. If I switch to AMD I will write both of them to tell them why.

In the meantime I am just incredibly grateful to nVidia for being THE early supporter of almost every so-called "alternative" OpSys ever made with quality drivers. Had they not, it is unlikely that AMD/Ati ever would have. If we consider the value and importance of ANY accelerated 3D drivers to the viability and success of Linux, it seems to me Linus may have been just "flexing" AFTER Linux already had grown partly, maybe largely, because of nVidia's expense and efforts to support anything but MS.

cwizardone · 11-06-2019, 12:12 PM

@enorbet,
Well said!

rogan · 11-06-2019, 02:15 PM

enorbet: I mostly agree with you stance on this, but I still consider theirs an outdated and in the long run impossible attitude. They are BIG contributors to the kernel project, yet they won't release a single spec on any of their graphics products so someone can write an open driver for it... Why ?

Their attitude towards this project is to contribute when there is a clear and immediate gain for them in doing so, as with ARM, and to contribute absolutely nothing otherwise. I'm not saying that they should be obliged to do so, but I for one don't particularly trust binary only drivers and the hassle that follows, so I avoid using them if there's a way.

Lockywolf · 11-07-2019, 12:03 AM

The nvidia-legacy390-kernel doesn't build with the following error:

Code:

CC [M]  /tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.o
In file included from /tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c:13:
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/common/inc/nv-linux.h:1799:6: error: "NV_BUILD_MODULE_INSTANCES" is not defined, evaluates to 0 [-Werror=undef]
 1799 | #if (NV_BUILD_MODULE_INSTANCES != 0)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c:39:6: error: "NV_BUILD_MODULE_INSTANCES" is not defined, evaluates to 0 [-Werror=undef]
   39 | #if (NV_BUILD_MODULE_INSTANCES != 0)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c: In function ‘nv_init_module’:
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c:349:6: error: "NV_BUILD_MODULE_INSTANCES" is not defined, evaluates to 0 [-Werror=undef]
  349 | #if (NV_BUILD_MODULE_INSTANCES != 0)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c: In function ‘nv_exit_module’:
/tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.c:364:6: error: "NV_BUILD_MODULE_INSTANCES" is not defined, evaluates to 0 [-Werror=undef]
  364 | #if (NV_BUILD_MODULE_INSTANCES != 0)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:266: /tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel/nvidia/nv-frontend.o] Error 1
make[1]: *** [Makefile:1649: /tmp/SBo/NVIDIA-Linux-x86_64-390.129/kernel] Error 2
make[1]: Leaving directory '/usr/src/linux-5.4-rc6'
make: *** [Makefile:81: modules] Error 2

Where exactly this NV_BUILD_MODULE_INSTANCES has to be defined I am not sure. The Makefile suggests that some versions of Kbuild read the Kbuild file, and some read the Makefile, so the patch should be trivial, but I am not that familiar with Kbuild.

TurboBlaze · 11-07-2019, 02:43 AM

How about these patchs https://git.archlinux.org/svntogit/p...s/nvidia-390xx for nvidia-390xx?

ponce · 11-07-2019, 05:12 AM

Quote:

Originally Posted by TurboBlaze

How about these patchs https://git.archlinux.org/svntogit/p...s/nvidia-390xx for nvidia-390xx?

the only one of them that's actually applied in the PKGBUILD is for kernels < 4.16.
AFAIK there are no patches available that let 390.129 build on kernels 5.4.x (for previous versions they still build) yet (hope someone can provide them soon)...

Lysander666 · 11-07-2019, 07:47 AM

First issue running this kernel - 24 hours or so after install. I was working away doing nothing in particular [browsing, Telegram] - laptop screen goes black, couldn't get to a terminal, nothing would bring it back. Had to REISUB.

Back to 4.19.76 for now.

Quote:

Originally Posted by AlleyTrotter

nearly 700 views and 17 reply and not one person thought this was a useful post
SHEESE!

I found out about it in the main kernel thread, others may have seen the changelog. People are more likely to first read a thread they have already subscribed to since they get notifications.

enorbet · 11-08-2019, 10:50 AM

Quote:

Originally Posted by rogan

enorbet: I mostly agree with you stance on this, but I still consider theirs an outdated and in the long run impossible attitude. They are BIG contributors to the kernel project, yet they won't release a single spec on any of their graphics products so someone can write an open driver for it... Why ?

We could ask IBM if reverse engineering a la Compaq affected their revenue and their market position. Please note that there used to be a dozen graphics systems/chips companies with foundries. Now there are essentially three. It is a highly competitive market area. If secrecy wasn't an important tool to security and longevity, there would never have been laws regarding encryption and some government officials wouldn't be all but demanding back doors in encryption. Are you going to allow backdoors into your PCs? When you park your car in town do you leave the keys in it?

Quote:

Originally Posted by rogan

Their attitude towards this project is to contribute when there is a clear and immediate gain for them in doing so, as with ARM, and to contribute absolutely nothing otherwise. I'm not saying that they should be obliged to do so, but I for one don't particularly trust binary only drivers and the hassle that follows, so I avoid using them if there's a way.

As I mentioned I've spent thousands of dollars since 1995 and all of them with nVidia and since 1999 all of those have run Linux. Prior to that I ran IBM's OS/2 which nVidia also supported with a binary driver. Since 1995 I can count on one hand the number of problems I've had with these drivers. Appropriate to this thread, my install of -Current is now successfully running 5.4-rc6 (compiled from source) with the NVIDIA-linux-X86_64.run blob installer. No issues once nVidia quickly addressed the "Module.symvers" change.

FWIW I am attracted to the ease provided by current development of OSS kernel support of AMD/Ati and will be watching that carefully even if it will likely be 3-5 years before I seek an upgrade for my Main's GTX-1070 Ti. I suspect this will be pressure where it counts for nVidia (and for we Linux users), not so much just from me, but as a trend.

allend · 11-09-2019, 12:48 AM

Anybody else having trouble booting the generic 5.4.0-rc6-smp kernel from /testing in Slackware-current? I am getting a kernel panic (see attached screenshots)
I have no problems with the 4.19.82 kernel on this 32-bit hardware.
Also no problems with the generic 5.4.0-rc6 kernel on 64-bit hardware.

Lockywolf · 11-09-2019, 01:10 AM

Did you try booting without a microcode update?

TurboBlaze · 11-09-2019, 02:09 AM

Quote:

Originally Posted by ponce

AFAIK there are no patches available that let 390.129 build on kernels 5.4.x

NVIDIA 390.132 Linux Driver Released For Legacy Fermi Support

allend · 11-09-2019, 03:22 AM

@Lockywolf - I have not attempted to put a microcode update on this PC.

kgha · 11-09-2019, 04:32 AM

Quote:

Originally Posted by allend

Anybody else having trouble booting the generic 5.4.0-rc6-smp kernel from /testing in Slackware-current? I am getting a kernel panic (see attached screenshots)
I have no problems with the 4.19.82 kernel on this 32-bit hardware.
Also no problems with the generic 5.4.0-rc6 kernel on 64-bit hardware.

Yup, same thing happened to me when testing 5.4.0-rc6-huge-smp on an old 32-bit netbook. The huge non-smp kernel boots OK, though.

ttk · 11-09-2019, 02:03 PM

Just noticed this thread, and making a note to post later about my adventures getting this kernel working on a Lenovo P73 with D620 GPU and hybrid graphics management.

I'd posted a bit on the "Latest Kernel Release" thread but was wary of polluting it with marginally off-topic content. This thread seems like a better fit.

kingbeowulf · 11-09-2019, 04:40 PM

I'm definitely excited about 5.4 possibility as LTS, and landing in 15.0. If only I had a miniITX mobo for this ITX case so I can test (HINT! HINT!). It might be time to dual boot my main box by putting current on the spare NVME drive.

Although I agree with enorbet as I too have run Nvidia GPU for a long time (TNT2, GeforceDDR 256 upgrades from Paradise Bahamas S3 Trio64 and 3DFX Voodoo), I am still excited about the possibility to switch to AMD Navi GPU in my next build. Nvidia's support has been excellent (after all, I maintain the scripts on SBo). Without that, AMD would never be a contender. Still, my gaming addiction, desire to move to 4K, and Nvidia's price are in conflict. If AMD GPU works OOTB for my game titles on Slackware with no additional drivers...heck, I'll switch. AMD just has currently a better bang for my limited buck.