Has any one else been able to update the nvidia driver (default repo) 12.3 _64
I reported the issue in the OS ML weeks ago and zero feedback.
I get this error
#### YaST2 conflicts list - generated 2013-05-22 05:13:48 ####
nothing provides ksym(desktop:init_timer_key) = fb0e29f needed by nvidia-gfxG03-kmp-desktop-319.17_k3.4.6_2.10-12.1.x86_64
] do not install nvidia-gfxG03-kmp-desktop-319.17_k3.4.6_2.10-12.1.x86_64
] break nvidia-gfxG03-kmp-desktop-319.17_k3.4.6_2.10-12.1.x86_64 by ignoring some of its dependencies
nothing provides ksym(default:init_timer_key) = fb0e29f needed by nvidia-gfxG03-kmp-default-319.17_k3.4.6_2.10-12.1.x86_64
] do not install x11-video-nvidiaG03-319.17-12.1.x86_64
] break nvidia-gfxG03-kmp-default-319.17_k3.4.6_2.10-12.1.x86_64 by ignoring some of its dependencies
#### YaST2 conflicts list END ###
I always install my proprietary nvidia drivers the hardway. The last successful driver I was able to install was the 310.44. Newer versions gave me difficulty and failed. Some lines from inxi on my PC setup:
I updated the driver yesterday and had zero problems.
I get this error
#### YaST2 conflicts list - generated 2013-05-22 05:13:48 ####
nothing provides ksym(desktop:init_timer_key) = fb0e29f needed by nvidia-gfxG03-kmp-desktop-319.17_k3.4.6_2.10-12.1.x86_64
…snip…
You’re trying to install the kernel module for the 3.4.6 kernel.
You seem to still have the repo for 12.2 configured. Please change that to 12.3 and it should work.
>
> I always install my proprietary nvidia drivers the hardway. The last
> successful driver I was able to install was the 310.44. Newer versions
> gave me difficulty and failed. Some lines from inxi on my PC setup:
>
> Code:
> --------------------
>
> System: Host: corei7-920.darmstadt Kernel: 3.7.10-1.4-desktop
> x86_64 (64 bit) Desktop KDE 4.10.2 Distro: openSUSE 12.3 (x86_64)
> VERSION = 12.3 CODENAME = Dartmouth …
> Graphics: Card: NVIDIA GT200 [GeForce GTX 260]
> X.Org: 1.13.2 drivers: nvidia (unloaded: fbdev,nv,vesa,nouveau)
> Resolution: 1920x1200@60.0hz GLX Renderer: GeForce GTX 260/PCIe/SSE2
> GLX Version: 3.3.0 NVIDIA 310.44
>
> --------------------
>
I’ve got 319.17 running on older system than yours. I think I installed
it from repo.
Fixed a regression that caused multiple BUG messages to be printed in the kernel log on SMP systems.
Fixed a bug that could cause the X server to crash when repeatedly enabling and disabling displays.
Updated nvidia-settings to preserve the relative positioning of displays when changing from a layout where multiple displays are on the same X screen to one where the same displays span multiple X screens.
Fixed nvidia-settings to dlopen(3) “libvdpau.so.1”, rather than “libvdpau.so”.
Added nvidia-persistenced, a daemon utility, to the driver package. nvidia-persistenced can be installed to run on system startup or manually run to allow the NVIDIA kernel module to keep persistent driver state allocated when no other user-space NVIDIA driver components are running.This can improve startup time for other user-space NVIDIA driver components.
Fixed CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow in “NoScanout” Mode. This buffer overflow, which occurred when an X client installed a large ARGB cursor on an X server running in NoScanout mode, could cause a denial of service (e.g., an X server segmentation fault), or could be exploited to achieve arbitrary code execution.
Added initial support for restoration of efifb consoles on UEFI systems where the primary display is driven over VGA or TMDS (e.g. DVI, HDMI, or LVDS).
Added support for the xorg.conf Monitor section options “Ignore”, “Enable”, “Primary”, and “Rotate”.For example, to rotate a monitor identified by a specific EDID hash, one could add the following to /etc/X11/xorg.conf or a file in /etc/X11/xorg.conf.d:
See the README and the xorg.conf(5) man page for more information.
Added an Underscan feature in the nvidia-settings X Server Display Configuration page which allows the configuration of an underscan border around the ViewPortOut.This feature was formerly known as Overscan Compensation.
Added support for application profiles to the NVIDIA client-side GLX implementation. See the “Application Profiles” chapter of the README for more information.
Added support to nvidia-installer for crytographically signing the NVIDIA kernel module. See the “Installing the NVIDIA Driver” chapter of the README for more information.
Added the “PanningTrackingArea” and “PanningBorder” MetaMode attributes.
Added support for RandR 1.3 panning.
Improved performance when the Accel option is disabled.
Added initial support for RandR 1.4 Provider objects with the Source Output capability, which can be used to render the desktop on an NVIDIA GPU and display it on an output connected to a provider with the Sink Output capability, such as an Intel integrated graphics device or a DisplayLink USB-to-VGA adapter.See the README for details.
Added nvidia-modprobe, a setuid root utility, to the driver package. nvidia-modprobe can be used by user-space NVIDIA driver components to make sure the NVIDIA kernel module is loaded and that the NVIDIA character device files are present.When possible, it is recommended to use Linux distribution native mechanisms for managing kernel module loading and device file creation. This utility is provided as a fallback to work out-of-the-box in a distribution-independent way.
Updated the nvidia-settings command line interface to accept display device names, as well as optional target qualifiers, e.g.
Updated the nvidia-settings command line interface to no longer assume the “X screen 0” target, when no target is specified in query and assign operations.Instead, all valid targets of the attribute are processed.
Fixed a memory leak that occurred when destroying a GLX window but not its associated X window.
Fixed a bug that could cause nvidia-installer to fail to delete directories created as part of a previous installation.
Updated nvidia-installer to report failures to remove installed files or restore backed up files with a single warning message, instead of a separate message for each individual failure.
Improved the performance of modesets in cases where the mode timings remained the same, but other parameters of the mode configuration, such as the ViewPort or panning domain, changed.
Fixed an issue with RENDER convolution filters.The driver will no longer normalize filter kernels before accelerating them.
Improved debuggability of the NVIDIA OpenGL libraries by including proper stack unwinding information on all supported architectures.
Updated the dkms.conf file and the makefile for the NVIDIA Linux kernel module to allow DKMS installations on systems with separate source and output directories.
Fixed a bug that caused RENDER Pictures to be sampled incorrectly when using nearest filtering in some cases.
Added support for the RandR “Border” and “BorderDimensions” Output properties, which can be used to configure the ViewPortOut of an RandR output.This is functionally equivalent to the “ViewPortOut” MetaMode token.
Fixed a bug where RRGetCrtcInfo could report incorrect size information when an RandR output has a custom ViewPortIn.
Further improve performance of some versions of HyperMesh with Quadro GPUs.
Added a VDPAU page to the nvidia-settings control panel, to display information about the decoding capabilities of VDPAU-capable GPUs.
Added support for dynamic mode management through RandR, e.g. via the --newmode, --rmmode, and --delmode options in xrandr(1).
Increased the number of pages that are shareable across multiple processes in the x86 build of libnvidia-glcore.so, by reducing its R_386_PC32 relocation count.
Fixed a bug that caused XVideo applications to receive BadAlloc errors after VT switches and mode switches that occurred while a composite manager was running.
Removed the X driver’s support for “CursorShadow”.
Updated nvidia-installer to attempt unprelinking files whose checksums do not match the checksums recorded at installation time.
Switched .run package compression from gzip to xz.This provides a higher level of compression.
According to the README it should work on your hardware.
And you never said what didn’t work, not even in the other thread.
But if you’re satisfied with your older version, there’s no need to upgrade, I would say…
I confess I was both lazy and pressed for time in the other thread, the older version worked, and I did not want to spend the time debugging. While I install the ‘manual’ way, I’ve done this so many times over the years it is incredibly quick. Hence for me to roll back to the 310.44 was no effort.
But also, given it is so incredibly quick, after reading your post just now, I downloaded the 319.17 one more time to try again (and record the errors this time to show).
I started out with the proprietary driver from the NVIDIA-Linux-x86_64-310.44.run installed and running well. I downloaded the NVIDIA-Linux-x86_64-319.17.run, rebooted (with ‘nomodeset 3’ in legacy grub menu) and built/installed the 319.17 driver. Then rebooted and the PC booted to the nouveau driver instead. But this time instead of simply going back to the 310.44 I poked around a bit. I noted this in the inxi -F :
so I looked inside /var/log/Xorg.0.log and noted this:
19.576] (II) LoadModule: "nvidia"
19.576] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
20.032] (II) Module nvidia: vendor="NVIDIA Corporation"
20.032] compiled for 4.0.2, module version = 1.0.0
20.032] Module class: X.Org Video Driver
** 22.228] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please check your
23.040] (EE) NVIDIA: system's kernel log for additional error messages.**
23.040] (II) UnloadModule: "nvidia"
23.040] (II) Unloading nvidia
23.040] (EE) Failed to load module "nvidia" (module-specific error, 0)
after which the nouveau driver could be seen loading in the /var/log/Xorg.0.log.
So I followed the advice from the Xorg.0.log and looked in the dmesg and noted this :
11.076216] nvidia: module license 'NVIDIA' taints kernel.
11.076221] Disabling lock debugging due to kernel taint
** 11.085046] NVRM: The NVIDIA probe routine was not called for 1 device(s).
11.085049] NVRM: This can occur when a driver such as nouveau, rivafb,
11.085049] NVRM: nvidiafb, or rivatv was loaded and obtained ownership of
11.085049] NVRM: the NVIDIA device(s).**
** 11.085051] NVRM: Try unloading the conflicting kernel module (and/or
11.085051] NVRM: reconfigure your kernel without the conflicting
11.085051] NVRM: driver(s)), then try loading the NVIDIA kernel module**
11.085051] NVRM: again.
11.085053] NVRM: No NVIDIA graphics adapter probed!
which prompted me to look even earlier in the dmesg and I noted this:
9.288039] nouveau DEVICE][0000:02:00.0] BOOT0 : 0x0a0100b1
9.288043] nouveau DEVICE][0000:02:00.0] Chipset: G200 (NVA0)
9.288046] nouveau DEVICE][0000:02:00.0] Family : NV50
9.290072] nouveau VBIOS][0000:02:00.0] checking PRAMIN for image...
9.362840] nouveau VBIOS][0000:02:00.0] ... appears to be valid
9.362842] nouveau VBIOS][0000:02:00.0] using image from PRAMIN
9.362940] nouveau VBIOS][0000:02:00.0] BIT signature found
9.362942] nouveau VBIOS][0000:02:00.0] version 62.00.3d.00
9.383091] nouveau MXM][0000:02:00.0] no VBIOS data, nothing to do
9.383107] nouveau PFB][0000:02:00.0] RAM type: GDDR3
9.383108] nouveau PFB][0000:02:00.0] RAM size: 896 MiB
plus many other nouveau driver entries PRIOR to the nVidia proprietary loading event.
That suggested that the blacklisting of the nouveau driver by the 319.17 was not working. Note there was NO entry in my PC’s /etc/modprobe.d/50-blacklist.conf to blacklist the nouveau driver as that was not needed with the proprietary nvidia 310.44 driver. … So now, noting you succeeded with the 319.17 I decided to blacklist the nouveau and I added ‘blacklist nouveau’ to the end of the /etc/modprobe.d/50-blacklist.conf, … I then rebooted, and the PC came up properly this time with the 319.17 nvidia driver.
So the 319.17 DOES work for my graphics if I blacklist nouveau in the 50-blacklist.conf file. Interesting thou, that the 310.44 did not need such blacklisting.
Correct … the available (unless blacklisted) DRM/KMS nouveau driver gets loaded for the console framebuffer, prior to initiation of X. Once X comes up, the nvidia driver fails to load because nouveaufb has control of the device, but, as you noted, the nouveau (DDX part of the stack) loads.
See ‘KernelModeSetting’ (KernelModeSetting) for further info/explanation/background
was there not a /etc/modprobe.d/nvidia-desktop.conf containing such blacklisting of the nouveau? I can’t see how it (the booting process and desired loading of the nvidia X driver) would have gotten around the problem otherwise (save for use of a nomodeset boot parm or exilement of the nouveau from the system )
There is no nvidia-desktop.conf file now with the 319.17 installed. Possibly there was such a file when the 310-44 was installed, and possibly the 319.17.run executable deleted such a nvidia-desktop.conf file. I don’t know. I don’t nominally poke around in the /etc/modprobe.d/ directory unless I am specifically looking for something.
Perhaps if I rolled back to the 310.44 I could find out, but I’m not ‘that’ curious. … Maybe someone else who may still has the 310-44 installed could chime in.
Well, I can’t say for sure what was in place previously (when you were running the v310.44 driver) to allow the nvidia driver to load up, but I have a good idea why there is absence of such a module directive from your manual install of the v319.17:
Yes but there were problem with it installed. basically lose of functionality ie some 3d graphics were broken. Not sure since I did not look but I think nouveau was being run rather the NVIDIA. This on a 6800+ card. The origianl attempt to add NVIDIA did not work at all since the system chose GO3 it turned out GO2 was the driver that worked. but only fully after removing the nouveau package.
Right, I believe that. But nouveau is only used (or, in your case rather fbdev, since the nvidia rpms should have blacklisted nouveau) if nvidia fails to load. No need to uninstall the nouveau X driver. That’s my point.
This on a 6800+ card. The origianl attempt to add NVIDIA did not work at all since the system chose GO3 it turned out GO2 was the driver that worked. but only fully after removing the nouveau package.
Yes, the G03 driver doesn’t support 68xx cards anymore. Only series 8 and upwards. And the one-click install doesn’t check that, that’s why there’s more than one on the openSUSE NVIDIA page. You have to click on the right one for your card.
But I doubt that your problems were related to nouveau…
Interesting. So that suggests by my booting to run level 3 (with nomodeset entered as a boot code option) the nvidia .run installer was not able to detect the nouveau driver loaded, and so it did not black list the nouveau driver. That does explain 319.17 hiccup … I’m still puzzling thou over 310.44 as to why it had no problem. Possibly the technique to identify the risk of the nouveau driver loading changed between the 310.44 installer and the 319.17 installer.
Right. With the nomodeset boot parm, kernel mode setting is disabled, and, consequently, the drm/kms nouveaufb doesn’t get loaded, and, hence, the nvidia installer detects nothing nouveau, and so [my assumption is] no blacklist is generated.*
When KMS is active, the boot sequence initially results in the vesafb driver running the console, but this is then handed over to the drm/kms nouveaufb driver. Whereas, with a nomodeset, the vesafb driver would remain in control of the console, or hands over to another suitable user mode setting (UMS) framebuffer driver (if you have specified such in the kernel boot options). You may just for an FYI/knowledge sake (or perhaps maybe not), wish to test this out (by passing the appropriate boot parms) and observe the associated results incurred (as shown in dmesg) … (i.e. dmesg | less )
I’m really not certain why they’d use such logic, as the (in general) existence of the nouveau driver should almost necessitate that a blacklisting is done by default. I’m likely over looking something. shrugs
… I’m still puzzling thou over 310.44 as to why it had no problem. Possibly the technique to identify the risk of the nouveau driver loading changed between the 310.44 installer and the 319.17 installer.
I don’t know. But given the mechanism of the driver loading, some sort of provision had to be in place (initrd, grub/kernel boot parm, /etc/modprobe.d/file). But now that you are (presumably) happily utilizing the newer release, (http://www.youtube.com/watch?v=386JprXXU90)
Interesting thou, that the 310.44 did not need such blacklisting.