No, Aaron insists this define should be get_num_physpages(), i.e. with round brackets. I haven’t checked the assembly (I feel like they are the same) so he may be right.
Daniel posted an official set of patches for this, which will be included in the next release: num_physpages and support for 3.11 and later kernels - Announcements and News - NVIDIA Developer Forums
They are not the same. get_num_physpages is a function pointer. get_num_physpages() calls the function.
sLipKn07, the installer’s supposed to combine the uvm/dkms.conf.fragment and dkms.conf for you, when the Unified Memory module is installed. Did that not happen in your case?
siddly, were you experiencing a similar problem (dkms.conf.fragment couldn’t be appended), or was the Unified Memory kernel module failing to install for a different reason?
sLipKn07 and siddly, can you both please provide nvidia-bug-report.log files from failed installation attempts?
in my case, i use --extract-only, no installation, no output any log, only extract files. (is for a make package for my distibution (own package, no official)
greeings
Oh, okay. Yes; in that case, feel free to package a pre-combined dkms.conf. The reason it’s split up across two files in the .run package is just a hacky way to allow people to include or exclude the Unified Memory module when using DKMS.
Another possibility is to write a separate dkms.conf file for the Unified Memory module; this can be a bit tricky because the nvidia-uvm.ko build depends on the nvidia.ko build. (It needs nvidia.ko’s Module.symvers file.) An example separate dkms.conf file is:
RM_PACKAGE_NAME="nvidia"
PACKAGE_NAME="${RM_PACKAGE_NAME}-uvm"
PACKAGE_VERSION="331.17"
RM_OUT_DIR=${dkms_tree}/${RM_PACKAGE_NAME}/${PACKAGE_VERSION}/build
BUILT_MODULE_NAME[0]="nvidia-uvm"
DEST_MODULE_NAME[0]=${PACKAGE_NAME}
DEST_MODULE_LOCATION[0]="/kernel/drivers/char/drm"
CLEAN="make -C ${RM_OUT_DIR} clean; make clean RM_OUT_DIR=${RM_OUT_DIR}"
MAKE[0]="make module KERNEL_UNAME=${kernelver} KBUILD_EXTMOD=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_
VERSION}/build RM_OUT_DIR=${RM_OUT_DIR}"
AUTOINSTALL="yes"
By setting RM_OUT_DIR, the nvidia-uvm.ko build will look for Module.symvers there, and if it’s absent, it will trigger a build of nvidia.ko first. Note that this will result in a redundant build of nvidia.ko, since DKMS cleans the build tree after it’s done, so you’ll never get Module.symvers as a leftover artifact of a previous DKMS build. In some ways, it’s not as nice as the already sort of weird combined dkms.conf for both modules, but it does allow you to provide the Unified Memory module in its own separate package, if you want to do that.
nvidia-uvm.ko is an optional part of the driver stack, but future versions of CUDA won’t be able to function without it, so if you anticipate that users of your distro will need CUDA functionality, you’ll want to include it in your package.
oks, thanks for the info!
greetings
Nvidia sucks. I remember a couple of years ago that every new driver was compatible not only with the current stable kernel series, but even with the rc series of the next stable. Now, 3.12 is a few days away from release and 331.17 beta does not officially support either 3.11 or 3.12. That’s simply awful. When will they release a newer version that supports the current kernels? Come on people, 3.11 was released exactly 2 two months ago and still no compatible drivers. What’s wrong with you?
I can’t blame Linus giving Nvidia the finger…
Now who broke kernel API in 3.11?
It still doesn’t support Google Earth. Satellite photos are not displayed.
Older driver supported Google Earth.
maverick6664,
Please, attach your nvidia-bug-report, distro, its bitness and version.
birdie,
My distro is Gentoo with official generic kernel 3.10.17, 32bit mode.
I attached nvidia-bug-report.log.gz, but I’m not sure it succeeded… :(
nvidia-bug-report.log.gz (57.5 KB)