Show X11:Drivers:Video / nvidia-gfxG04

Hi... I check last osc build -k . openSUSE_Tumbleweed x86_64 nvidia-gfxG04.spec and see that the compilation of the drivers is done over the kernel 4.15.5-1.3 when the last TW kernel to date is the kernel-default-4.15.6-1.4... Is this normal? Other times that I have done it, basically to rule out that there is an error when doing zypper dup and change the kernel, the kernel was always the same one that I was going to install with zypper dup... As I see you have changed the not doing weak-updates, can this be the cause? Thank you

It could be possible if you haven't installed the kernel devel package for this new kernel I would say.

when I run osc build I don't need to install anything, all are installed automatically

I delete /var/tmp/osbuild-packagecache to force download the last kernel but osc continues downloading kernel-default-devel-4.15.5-1.3.x86_64.rpm and kernel-devel-4.15.5-1.3.noarch.rpm

With the last osc up and yours changes, today kernels updates to 4.15.6-1.5

Hi again... I'm sorry but I do not understand what happened. I have updated TW to the last kernel:kernel-default-4.15.6-1 and the /lib/modules/kernel-4.15.6-1-default directory has been re-created weak-updates ... I understood that you had changed and that it was not going to create more for now ...

Well, kernel packages also run weak-updates. Hope the directory is empty.

weak-updates/ dir has updates/ dir with 4 symlink to @nvidia-drm.ko @nvidia-modeset.ko @nvidia-uvm.ko and @nvidia.ko Regards

Where are these symlinks going to? Are the modules working?

goes to /lib/modules/4.15.2-1-default/updates/ and yes, the nvidia modules works, if not, we would not be talking now about symbolic links but because the compilation of them has failed ... Do not you think? Regards

Ok. Maybe the modules in .../4.15.2-1-default/updates/ were still from an older KMP build. But as long as the kABI doesn't change (and weak-updates should detect this and if it breaks no longer create such links) this shouldn't matter then.

OK,thanks you

From: https://devtalk.nvidia.com/default/topic/1030082/linux/kernel-4-16-rc1-breaks-latest-drivers-unknown-symbol-swiotlb_map_sg_attrs-/

Seems need install this path for works with kernel 4.16: --- a/kernel/common/inc/nv-linux.h~ 2018-01-25 06:09:41.000000000 +0100 +++ b/kernel/common/inc/nv-linux.h 2018-03-05 13:58:17.746725638 +0100 @@ -1209,6 +1209,7 @@ static inline NvU32 nv_alloc_init_flags( static inline NvBool nv_dma_maps_swiotlb(struct pci_dev dev) { NvBool swiotlb_in_use = NV_FALSE; +#if 0 #if defined(CONFIG_SWIOTLB) #if defined(NV_DMA_OPS_PRESENT) || defined(NV_GET_DMA_OPS_PRESENT) / @@ -1251,7 +1252,7 @@ static inline NvBool nv_dma_maps_swiotlb swiotlb_in_use = (swiotlb == 1); #endif #endif - +#endif return swiotlb_in_use; }

Could you open a bugreport for this,please? Thanks!

Someone did it before

It seems 396.18 Nvidia beta driver's version is compatible with kernel 4.16

See http://bugzilla.opensuse.org/show_bug.cgi?id=1088651#c5

OK,thanks

Lats osc install show this message: unresolvable: nothing provides kernel-default-devel = 4.16.2-1 needed by kernel-syms I think we must wait for this,isn't it? Regards

I'm sorry, want to say Last and not Lats...

Hmm. "osc build openSUSE_Factory x86_64" works for me. Maybe this was a temporary issue.

I think it could be a problem related to this: https://lists.opensuse.org/opensuse-factory/2018-04/msg00670.html

problem solved with the new update

is 396.24 update coming soon? (its compatible with xorg 1.20 and even runs on kernel 4.17+) https://devtalk.nvidia.com/default/topic/1032986/unix-graphics-announcements-and-news/-linux-solaris-and-freebsd-driver-396-24/

That's from the a short lived branch, which we do not package.

I would understand that logic for LEAP but not tumbleweed or at least provide both, but then again this isn't the first time you guys have these weird "principles"..but the again who I'm to judge I'm just more of a user/gamer ...sigh.

btw. as the xorg 1.20 update is around the corner and with nvidia releasing monthly driver updates (if any at summer time), are you just going to add some ugly patch and hope it works... well "c'est la vie"

Well, we'll see when xorg-server 1.20 will be released, when I'm updating to it in TW and when long lived branch of the NVIDIA driver will support it. I'm not allowed to talk about the NVIDIA driver schedule.

source: https://devtalk.nvidia.com/default/topic/1029484/linux/-various-all-distros-numerous-performance-amp-rendering-issues-on-390-25/post/5255627/#5255627

the X.Org Server 1.20 has now been released https://lists.x.org/archives/xorg-announce/2018-May/002893.html are you going to patch the current driver or wait? (I think beta driver is coming next month then month after that the LTS driver, not 100% sure)

btw. the current 390.25 has many performance and rendering issues (that also causes kde/kwin to crash easily), but it can be fixed by adding to your xorg conf file this: Option "UseNvKmsCompositionPipeline" "false"

can't say if this issue has been fixed in the newer 396.24 driver

Interesting, but are you still using 390.25? I mean 390.48 is the latest driver release ...

I meant .48 (which I'm using), the problem has been in whole 390.xx ...apparently

it seems Nvidia already did release 390.59 (LTS) https://devtalk.nvidia.com/default/topic/1035485/b/t/post/5260307/#5260307 its just too bad that its so broken release in general. It would be nice if users could get to choose from this one repo between long-term and short-term releases (maybe even beta drivers), at least for gamers this is more important

Hi.Last kernel update (4.16.8) create lib/modules/4.16.8-1-default/updates dir with all 4 nvidia modules and also /lib/modules/4.16.8-1-default/weak-updates/updates dir with 4 links to lib/modules/4.16.0-1-default/updates (see the number kernel error). I must changed by hand. Regards

This should not happen.

Wed Feb 28 13:51:59 UTC 2018 - sndirsch@suse.com - do not run weak-updates on TW, since it creates more harm than benefit (boo#1082704)

I don't run weak-updates at all... zypper dup does it as allways, and that's why I do not understand that just with this new kernel this error has appeared, when it has not done it before Regards

So this didn't happen before with previous kernel updates? Maybe I need to remove nvidia modules in weak-updates/ directories for TW in trigger scripts for kernel-default-devel/kernel-pae-devel in nvidia packages in the end ...

New TW update with kernel 4.16.9-1-default make weak-updates dir disappear Thanks

Christophe Giboudeaux (cgiboudeaux) - over 6 years ago

Thanks! Nice to hear this!

Can you document how you create the pci_ids files ? Trying to build a local package for 396.24 locally, it looks like they removed the x86 archive. I also had to change ftp to https in generate-service-file.sh before running the script. Looks like download.nvidia.com only serves http requests.

Torin Woltjer (SesameStreetThug) - over 6 years ago

Whats the status on getting this updated to the 396 driver?

Torin Woltjer (SesameStreetThug) - over 6 years ago

There are no plans to replace the Long Lived Branch version with a Short Lived Branch version.

I'm disappointed to hear this, but thank you for the response regardless.

Jehferson Mello (VileLasagna) - about 6 years ago

Any plans for adding an SLB alternative to live concurrently?

I'm looking into this right now as I'm sort of leading migration to OpenSuSE at work (RIP Ubuntu, you won't be missed) and due to CUDA being as finicky as it is (oh boy) we need 396. We've been installing through nVidia's run package, which works, but is fiddly, especially for the peeps who ain't too comfy in Linux yet. (and it prevents me from packaging CUDA itself properly as I can't depend on the correct drivers)

If there isn't, I'm happy to make use of your work on the LLB one and try and get our own package building. Would also be happy to share back my tweaks if I get it working (which I'm hoping will be more or less trivial with this as a starting point)

There are currently no plans to create RPMs for SLB in addition to the ones for LLB. And, the next LLB will be released very soon. Unfortunately I'm not allowed to tell you more details about the planned schedule for it.

Jehferson Mello (VileLasagna) - about 6 years ago

With next LLB I mean one with a higher version number than 396.xx! ;-)

Thanks for the info, mate. That'd be really good and can't help but think that with 20-series just around the corner there's some new drivers coming. Will see around here if I'm given the opportunity to wait for those as my hand is being forced on my end (already getting some opportunistic "let's just go back to windows" talk over this =( ). Otherwise, still getting to grips with the OBS environment and seeing if I can hack an RPM to keep people happy for the next couple weeks or something =P

In case you don't use Leap 15/Tumbleweed and are interested in RPMs for 396.xx you may want to use packages created and provided by NVIDIA themselves. http://developer.download.nvidia.com/compute/cuda/repos/

Chech this out. https://build.opensuse.org/package/show/X11:Drivers:Video/nvidia-gfxG05 Version 410.57 is still considered Beta, but an UDA release will be available very soon. And shortly after there will be prebuilt RPMs available via the known repository at NVIDIA.

Alexander Ahjolinna (ahjolinna) - about 6 years ago

Nvidia finally released 390.77 (LTS) which should fix these latest major crashing/rendering issues, for example the kwin one https://devtalk.nvidia.com/default/topic/1037553/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-390-77-long-lived-branch-release-/

NVIDIA 390.87(LTS) backports important (vulkan/opengl) performance fix https://www.nvidia.com/download/driverResults.aspx/137276/en-us

Rogério Leiro (RLFontan) - about 6 years ago

Thanks. On my TODO list now.

Hey, what's up?

Please take a look on this post on openSUSE forum:

https://forums.opensuse.org/showthread.php/533061-Official-pack-for-nVidia-396?p=2880390#post2880390

We are talking about the importance of having 396.x NVIDIA drivers on openSUSE. Maybe you could help.

Thanks!

There are currently no plans to create RPMs for short-lived-branch drivers in addition to the ones for long-lived branch versions. And, the next long-lived branch (with a higher version number than 396.xx!) will be released very soon. Unfortunately I'm not allowed to tell you more details about the planned schedule for it.

Rogério Leiro (RLFontan) - about 6 years ago

Thats amazing!!! Ty!

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

Chech this out. https://build.opensuse.org/package/show/X11:Drivers:Video/nvidia-gfxG05 Version 410.57 is still considered Beta, but an UDA release will be available very soon. And shortly after there will be prebuilt RPMs available via the known repository at NVIDIA.

I've built the packages locally, nothing exploded yet \o/ There were a couple harmless warnings because bison and flex are not required at build time. It doesn't have any visible consequence afaics.

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

Thanks! Good to hear this! :-)

The build is disabled for the whole repo, is it expected ?

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

Sure, due to legal reasons the .run files are missing in the repo, so the builds would always fail. Check README file for building the RPMs on your machine locally.

I'll ask differently, after enabling the X11:Drivers/Video repo, the G03 and G04 packages are available with vendor=obs://build.suse.de/Proprietary/X11:Drivers. can the G05 ones be made available there?

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

build.suse.de is an internal repo for SUSE employees. G05 RPMs will be available for everybody shortly after it's no longer Beta. I'm not allowed to talk about the release schedule. So please don't ask when.

ok, found an issue with nvidia-uvm, the module doesn't load and dmesg mentions: nvidia_uvm: Unknown symbol __pcpu_unique_interrupt_thread_context (err 0)

No idea where it's coming from, grep didn't help.

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

Couldn't reproduce this issue. Tried with latest TW kernel 4.18.12-1-default.

Any pointer? __pcpu_unique_interrupt_thread_context isn't in /boot/System.map-4.18.12-1-default

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

I don't. :-(

Thanks. looks like only my desktop computer has this issue. Even if I try to reinstall the G04 package, this symbol exists in nvidia-uvm.ko... but only on my desktop station, the laptop doesn't have it.

Now I'll try installing the G05 packages on both and copy the module file until I find why this symbol appears only in one module.

Christophe Giboudeaux (cgiboudeaux) - about 6 years ago

Alright, found the issue: on the desktop computer, I changed the ld alternative to use gold. If I switch back to ld.bfd, the symbol isn't visible anymore.

Xu Zhao (nuklly) - almost 6 years ago

The installed dkms.conf is problematic. It contains "DKMS_MODULES" and other stuff not understood by the dkms. In the Nvidia blob, the binary nvidia-installer will modify the original dkms.conf by expanding the "DKMS_MODULES" macros and deploy the modified dkms.conf into the system. We should also install the modified dkms.conf instead of the original one into the system.

Xu Zhao (nuklly) - almost 6 years ago

FYI: the patching done in Arch is here https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nvidia

Hans-Peter Jansen (frispete) - almost 6 years ago

Well, dkms.conf is only installed to /usr/src/kernel-modules/nvidia-$version-$flavor - together with all driver "sources". I doubt the system is interested in reading this file, even if you have some dkms package installed. So just a cosmetic issue ...

Hi Stefan,

TW is on kernel 4.20, and systems, that depend on this driver are quite unhappy since a few days...

Just added a patch to this project, which fixes the build against Kernel 4.20 of factory/TW. Will be fixed in NVIDIA's repository with the next update ...

Hi I update to kernel 4.20 now and have an error... The new modules 4.20 want to link with olds 4.19.11 I doesn't have and then I have NO 4.20 nvidia modules.

See the reply to @frispete above ...

Hi I update to kernel 4.20 now and have an error... The new modules 4.20 want to link with olds 4.19.11 I doesn't have and then I have NO 4.20 nvidia modules. If I compile from this build (osc) I have no problem to create the differents rpms files

Yes, I fixed the build in this repository already. ;-)

It runs with the new 4.20.2 but not on previous 4.20.0 Thanks