Coder Social home page Coder Social logo

open-gpu-kernel-modules's Issues

User Linter and CI

It would be a good practice to enforce linter to detect/avoid things like pointed out in #24

G-Sync shown as not supported with opensource driver.

NVIDIA Driver Version
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 515.43.04 Release Build (@)

GPU
RTX 3050

Describe the bug
G-SYNC reported as unsupported while it is supported.

To Reproduce
Open Nvidia Control Panel -> OpenGL (There should be checkbox for G-SYNC) but it's missing

Expected behavior
It should have G-SYNC checkbox like on proprietary version

Check screenshots below with open and proprietary version.

https://i.imgur.com/Cwqcovr.png -> opensource
https://i.imgur.com/jFFC2oV.png -> proprietary
https://i.imgur.com/LFJiz1M.png -> opensource
https://i.imgur.com/o9ff7lW.png -> proprietary

https://i.ibb.co/RQ278qH/2022-05-12-15-13-38.jpg -> lenovo g27q-20

Regards,
Rosen Aleksandrov

Also support T234 in the same driver

NVIDIA Driver Version
34.1 and 515.43.04
GPU
AGX Orin and RTX 2080 Ti

Describe the bug
AGX Orin already ships with an open-source NVIDIA kernel driver for the display. This means that when we install this driver, we lose the display output tied to the display controller already present on the SoC.

To Reproduce

On an AGX Orin:

$ modinfo 5.10.65-tegra/extra/opensrc-disp/nvidia.ko
filename: /lib/modules/5.10.65-tegra/extra/opensrc-disp/nvidia.ko
firmware: nvidia/34.1.0/gsp.bin
alias: char-major-195-*
version: 34.1.0
supported: external
license: Dual MIT/GPL
srcversion: 92576267C511B79A495FD51
alias: pci:v000010DEd*sv*sd*bc06sc80i00*
alias: pci:v000010DEd*sv*sd*bc03sc02i00*
alias: pci:v000010DEd*sv*sd*bc03sc00i00*
alias: of:N*T*Cnvidia,tegra234-displayC*
alias: of:N*T*Cnvidia,tegra234-display

This conflicts with this driver, which doesn't have T234D support included. (and the driver in L4T doesn't have dGPU support included!)

Expected behavior

This driver should support T234D too (nvidia,tegra234-display). Having two incompatible open-source drivers this early is quite unusual.

Even better change (if possible)

Supporting T234, instead of just the display block-only variant (T234D) in this driver, (and T194 if possible) outright in this driver so that the GPU too would be driven by this instead of nvgpu. That'd help in support for 3rd-party OS distributions on that hardware.

NVIDIA I2C driver issues

Copy/paste from an email I sent to [email protected], I haven't verified this against this new open driver, but it has been an issue for a while with the proprietary kernel driver.

I am the lead developer of OpenRGB, an open source RGB lighting control application for Windows and Linux. Our goal is to create a universal RGB control app, talking directly to as many RGB lighting devices as possible. As RGB control is often only supported by official software in Windows, Linux users get left out. That's where we come in.

As you are probably aware, a lot of graphics cards have built-in RGB lighting that features software control. Most cards implement RGB control using the GPU's I2C interface. We're facing an issue controlling certain RGB devices over the NVIDIA GPU's I2C interface in Linux with the proprietary NVIDIA driver. The same code is working fine using NvAPI on Windows and using the Nouveau I2C implementation on Linux, so we believe this to be an issue specific to NVIDIA's proprietary Linux driver.

The cards we've been focused on lately are the ASUS 3xxx series cards, which all use a similar I2C RGB chip that is also found on some ASUS motherboards and various manufacturers' RGB DRAM modules. The chip comes from ENE. The I2C protocol used by this chip is a 16-bit address scheme where you first write a 16-bit address to the 0x00 register of the ENE chip, then perform either a read or write operation to a fixed chip register. This chip appears to be an SMBus chip, so we're using the SMBus functions in the Linux kernel as shown in these two accessor functions:

(ene_dev_id is the 8-bit I2C address of the ENE chip, ene_register is the 16-bit address in the chip that we are reading or writing)

unsigned char ENESMBusInterface_i2c_smbus::ENERegisterRead(ene_dev_id dev, ene_register reg)
{
    //Write ENE register
    bus->i2c_smbus_write_word_data(dev, 0x00, ((reg << 8) & 0xFF00) | ((reg >> 8) & 0x00FF));

    //Read ENE value
    return(bus->i2c_smbus_read_byte_data(dev, 0x81));
}

void ENESMBusInterface_i2c_smbus::ENERegisterWrite(ene_dev_id dev, ene_register reg, unsigned char val)
{
    //Write ENE register
    bus->i2c_smbus_write_word_data(dev, 0x00, ((reg << 8) & 0xFF00) | ((reg >> 8) & 0x00FF));

    //Write ENE value
    bus->i2c_smbus_write_byte_data(dev, 0x01, val);
}

The issue here appears to be with regards to i2c_smbus_write_word_data. To detect and verify that the chip exists on the bus, we do a series of i2c_smbus_read_byte_data calls and these all work fine on the NVIDIA proprietary Linux driver. However, after detecting the chip we then write a 16-bit address and attempt to read from it. Specifically, we try to read a region of the ENE chip's memory known to contain a version string. The expectation is that the word data write puts the 16-bit address of the byte we want to read into the chip, and the following byte data read from 0x81 returns one byte from the 16-bit address.

With other SMBus host controllers (Intel and AMD chipsets) as well as the NVIDIA GPU I2C on both Windows (NvAPI) and Linux (Nouveau), this works fine and we successfully retrieve the ENE RGB controller's version string. With the NVIDIA proprietary Linux driver, we read garbage. Since we know the i2c_smbus_read_byte_data function works with other manufacturers' NVIDIA GPU boards and for detecting the chip, I can only assume the issue is that the i2c_smbus_write_word_data function isn't working correctly. Note that i2c_smbus_write_byte_data does appear to work on several other manufacturers' GPU RGB chips so I have to assume it's specific to word data.

We have also observed issues with SMBus block operations, though doing the same block operations using I2C_RDWR ioctl (thus avoiding the SMBus layer) seem to work on the NVIDIA proprietary driver.

DKMS Infrastructure

As far as i know, most users consume the old proprietary driver as a DKMS package for their distro to permit building against upstream/binary kernels which they are not compiling from source every time they update the kernel or driver pacakge. If the relevant DKMS build files and structure are in this repository, it's less likely to end up with the "per-distro-implementation" schism normally left up to the downstream packagers.

Mention OpenRmEnableUnsupportedGpus in README

The error from this line references info about OpenRmEnableUnsupportedGpus being in the README, but it isn't mentioned anywhere.

For reference, to load the module on non-datacenter cards the OpenRmEnableUnsupportedGpus setting in NVReg must be set to 1. This can be done with module parameters, e.g. a file in /etc/modprobe.d reading options nvidia NVreg_OpenRmEnableUnsupportedGpus=1 seems to do the trick.

I'm writing this from Xorg running on a consumer 2080 Ti with the open source module loaded, so it seems to be not entirely broken, would be nice to have this mentioned somewhere then :)

Finally!!

Where've you been all these years?

Now to add KMS, DRM and Mesa support!

Windows On Arm64, support?

NVIDIA Driver Version
Please write the version of the NVIDIA driver you are using.

GPU
Please write the particular model of NVIDIA GPU you are using.

Describe the bug
Please write a clear and concise description of what the bug is.

To Reproduce
Please write the steps to reproduce the behavior.

Expected behavior
Please write a clear and concise description of what you expected to happen.

Please reproduce the problem, run nvidia-bug-report.sh, and attach the resulting nvidia-bug-report.log.gz.

Copy paste bug inside `dp_connectorimpl.cpp`

NVIDIA Driver Version
Git version

if (dev->dscCaps.dscBitsPerPixelIncrement == BITS_PER_PIXEL_PRECISION_1_16)
{
dscInfo->sinkCaps.bitsPerPixelPrecision |= DSC_BITS_PER_PIXEL_PRECISION_1_16;
}
if (dev->dscCaps.dscBitsPerPixelIncrement == BITS_PER_PIXEL_PRECISION_1_16)
{
dscInfo->sinkCaps.bitsPerPixelPrecision = DSC_BITS_PER_PIXEL_PRECISION_1_16;
}

Value of dscInfo->sinkCaps.bitsPerPixelPrecision is overriden in next line

License?

Thanks for the effort to open source this. To clarify the intent and future use here, can we get an official LICENCE.md file here as well?

BSD or MIT would be excellent.

Hard freezes with opensource driver

NVIDIA Driver Version
515.43.04.

GPU
RTX 3050

Describe the bug
Not work at all

To Reproduce
Build the driver regarding the documentation, and using it for X.Org

Expected behavior
To work by design

Please reproduce the problem, run nvidia-bug-report.sh, and attach the resulting nvidia-bug-report.log.gz.
nvidia-bug-report.log.gz

Xorg.0.log

Null pointer dereference in nv-acpi.c

NVIDIA Driver Version
Git

void NV_API_CALL nv_acpi_methods_uninit(void)
{
struct acpi_device *device = NULL;

#if defined(NV_ACPI_BUS_GET_DEVICE_PRESENT)
acpi_bus_get_device(nvif_parent_gpu_handle, &device);
nv_uninstall_notifier(device->driver_data, nv_acpi_event);
#endif
device->driver_data = NULL;
nvif_parent_gpu_handle = NULL;
return;
There isn't any validation on the return value from acpi_bus_get_device unlike other places where acpi_bus_get_device is being used.
device might be null when dereferencing.

(suggestions) use a linter in your internal dev environment

I'm seeing dozens of tickets that could be avoided if Nvidia used a linter in their own internal dev environment. GitHub Actions could also be implemented to autocheck code for compliance, security issues, quality, etc. At my work we use cppcheck for static code analysis and it's been amazing so far. SonarQube/Lint is also an option as well as being open source/free.

Depends on proprietary firmware binaries

Please may you also release the firmware source code under a free software license?
(Those at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia)
The driver requires them to work, and without them core features like reclocking will not function, which hindered Nouveau for years.
It's also (virtually) impossible to replace them by reverse-engineering because they are signed and the GPU will refuse to load firmware which is not signed by nVidia.

OS distributions such as Parabola GNU+Linux-libre use Linux-libre, a version of Linux without blobs, and does not distribute blobs.
In essence, without the firmware also being free software, this awesome free software driver release is crippled in the free world, as it relies on proprietary binaries.

error: implicit declaration of function 'sys_close' [-Werror=implicit-function-declaration]

NVIDIA Driver Version
Latest version of 'main' as of today.

GPU
3090

Describe the bug
Trying to compile the code and getting the following error.

make[1]: Entering directory '/tmp/open-gpu-kernel-modules/kernel-open'
make[2]: Entering directory '/usr/src/linux-5.17.6'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc (GCC) 11.3.1 20220429
  You are using:           cc (GCC) 11.3.1 20220429
  CC [M]  /tmp/open-gpu-kernel-modules/kernel-open/nvidia/nv-caps.o
/tmp/open-gpu-kernel-modules/kernel-open/nvidia/nv-caps.c: In function 'nv_cap_close_fd':
/tmp/open-gpu-kernel-modules/kernel-open/nvidia/nv-caps.c:567:5: error: implicit declaration of function 'sys_close' [-Werror=implicit-function-declaration]
  567 |     sys_close(fd);
      |     ^~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:288: /tmp/open-gpu-kernel-modules/kernel-open/nvidia/nv-caps.o] Error 1
make[2]: *** [Makefile:1831: /tmp/open-gpu-kernel-modules/kernel-open] Error 2
make[2]: Leaving directory '/usr/src/linux-5.17.6'
make[1]: *** [Makefile:82: modules] Error 2
make[1]: Leaving directory '/tmp/open-gpu-kernel-modules/kernel-open'
make: *** [Makefile:50: modules] Error 2

Running with the following
gcc 11.3.1
glibc 2.35
binutils 2.38
Linux kernel: 5.17.6

To Reproduce
Download the latest code from git and type 'make'

Expected behavior
Compiles without any issue,

In-tree build option

Given that the current upstream attempt at interacting with NV hardware is basically
image,
it would be great to be able to pull this repository into the kernel tree similar to what can be done with OpenZFS, PF_RING, XTables-Addons, etc.
This is mostly a matter of converting the makefiles to the kbuild structure and having a copy script which will throw the relevant files into appropriate locations in a user-provided/default kernel tree.

Crashes after waking from sleep state on OpenRC

NVIDIA Driver Version
515.43.04

GPU
1650 Ti Mobile

Describe the bug
I tried sleep state using s2ram works ,
In waking up from sleep power button shows wake state keyboard lights on mouse light offf and display off . Had to hard shutdown .
I saw they changed sleep service in release notes for systemd.
Distro: Gentoo

To Reproduce
Try sleep in OpenRC using s2ram.

Expected behavior
Works fine in 510 drivers

Feature request: add CUDA

Dear NVIDIA, Thank you for this. Many people react with "Finally!". Now the next greatest thing would be to open source CUDA, or at least make it much easier to obtain (i.e. avoid developer site signup and signin).

This is a feature request to add CUDA to this repo.

We can also remember that CUDA rests itself, to some extent, on open source technology, and that utility libraries built on top of CUDA, like CUBLAS, CUFFT, and CUDAPP, are open source. Let's take this one step further!

Thank you & God bless,
Roel Van de Paar

Confusion about some file name formats

Just confused, I see that most of the files in the generated directory have the "nvoc" suffix, so which specific words is this an abbreviation for? I would be very grateful if I could get an answer.

No documentation on which GPUs this driver supports

There is no bleedingly obvious list of what GPU models this driver does and does not support. It's of course safe to assume that this driver supports all of the latest GPUs and at least a generation back, but beyond that it's difficult to ascertain whether you're in the green here. I know that the proprietary driver fairly regularly drops support for older cards. What options are available for folks that have said older cards?

Please provide a clear list of GPUs are that supported by this driver, thanks.

trunk/src/nvidia/src/kernel/gpu/ce/arch/pascal/kernel_ce_gp100.c:137: unclear coding ?

Static analyser cppcheck says:

src/nvidia/src/kernel/gpu/ce/arch/pascal/kernel_ce_gp100.c:137:53: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation]

Source code is

return (NVBIT(pKCe->publicID) & nvlinkP2PCeMask ? NV_TRUE : NV_FALSE);

Presumably

return (NVBIT(pKCe->publicID) & nvlinkP2PCeMask) ? NV_TRUE : NV_FALSE;

was intended ?

(bug) NVRM kgspInitRm_IMPL: missing NVDEC0 engine, cannot initialize GSP-RM

The open source KM fails to load for me with the following error:
[ 3.596579] NVRM kgspInitRm_IMPL: missing NVDEC0 engine, cannot initialize GSP-RM
[ 3.596583] NVRM RmInitAdapter: Cannot initialize GSP firmware RM
[ 3.596745] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x63:0x56:1689)
[ 3.597360] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
[ 3.597537] [drm:nv_drm_load [nvidia_drm]] ERROR [nvidia-drm] [GPU ID 0x00000100] Failed to allocate NvKmsKapiDevice
[ 3.597749] [drm:nv_drm_probe_devices [nvidia_drm]] ERROR [nvidia-drm] [GPU ID 0x00000100] Failed to register device
[ 3.786715] nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
[ 3.786773] ucsi_ccg 1-0008: i2c_transfer failed -110
[ 3.786818] ucsi_ccg 1-0008: ucsi_ccg_init failed - -110

This is on a ubuntu 22.04 system with an RTX 2060, packages are from the cuda apt repo.

After switching back to the proprietary KM using:
$ sudo apt remove nvidia-kernel-open-515 && sudo apt install --reinstall nvidia-dkms-515 && sudo reboot

The proprietary driver loads just fine.

==============NVSMI LOG==============

Timestamp : Thu May 12 14:55:08 2022
Driver Version : 515.43.04
CUDA Version : 11.7

Attached GPUs : 1
GPU 00000000:01:00.0
Product Name : NVIDIA GeForce RTX 2060
Product Brand : GeForce
Product Architecture : Turing
Display Mode : Enabled
Display Active : Enabled
Persistence Mode : Enabled
MIG Mode
Current : N/A
Pending : N/A
Accounting Mode : Disabled
Accounting Mode Buffer Size : 4000
Driver Model
Current : N/A
Pending : N/A
Serial Number : N/A
GPU UUID : GPU-0e997e95-3209-c2c9-6214-347945351445
Minor Number : 0
VBIOS Version : 90.06.2E.C0.0B
MultiGPU Board : No
Board ID : 0x100
GPU Part Number : N/A
Module ID : 0
Inforom Version
Image Version : G001.0000.02.04
OEM Object : 1.1
ECC Object : N/A
Power Management Object : N/A
GPU Operation Mode
Current : N/A
Pending : N/A
GSP Firmware Version : N/A
GPU Virtualization Mode
Virtualization Mode : None
Host VGPU Mode : N/A
IBMNPU
Relaxed Ordering Mode : N/A
PCI
Bus : 0x01
Device : 0x00
Domain : 0x0000
Device Id : 0x1F0810DE
Bus Id : 00000000:01:00.0
Sub System Id : 0x37591028
GPU Link Info
PCIe Generation
Max : 3
Current : 1
Link Width
Max : 16x
Current : 16x
Bridge Chip
Type : N/A
Firmware : N/A
Replays Since Reset : 1816
Replay Number Rollovers : 231
Tx Throughput : 3000 KB/s
Rx Throughput : 0 KB/s
Fan Speed : 32 %
Performance State : P8
Clocks Throttle Reasons
Idle : Active
Applications Clocks Setting : Not Active
SW Power Cap : Not Active
HW Slowdown : Not Active
HW Thermal Slowdown : Not Active
HW Power Brake Slowdown : Not Active
Sync Boost : Not Active
SW Thermal Slowdown : Not Active
Display Clock Setting : Not Active
FB Memory Usage
Total : 6144 MiB
Reserved : 212 MiB
Used : 193 MiB
Free : 5738 MiB
BAR1 Memory Usage
Total : 256 MiB
Used : 5 MiB
Free : 251 MiB
Compute Mode : Default
Utilization
Gpu : 1 %
Memory : 1 %
Encoder : 0 %
Decoder : 0 %
Encoder Stats
Active Sessions : 0
Average FPS : 0
Average Latency : 0
FBC Stats
Active Sessions : 0
Average FPS : 0
Average Latency : 0
Ecc Mode
Current : N/A
Pending : N/A
ECC Errors
Volatile
SRAM Correctable : N/A
SRAM Uncorrectable : N/A
DRAM Correctable : N/A
DRAM Uncorrectable : N/A
Aggregate
SRAM Correctable : N/A
SRAM Uncorrectable : N/A
DRAM Correctable : N/A
DRAM Uncorrectable : N/A
Retired Pages
Single Bit ECC : N/A
Double Bit ECC : N/A
Pending Page Blacklist : N/A
Remapped Rows : N/A
Temperature
GPU Current Temp : 39 C
GPU Shutdown Temp : 93 C
GPU Slowdown Temp : 90 C
GPU Max Operating Temp : 88 C
GPU Target Temperature : 83 C
Memory Current Temp : N/A
Memory Max Operating Temp : N/A
Power Readings
Power Management : Supported
Power Draw : 11.18 W
Power Limit : 160.00 W
Default Power Limit : 160.00 W
Enforced Power Limit : 160.00 W
Min Power Limit : 125.00 W
Max Power Limit : 160.00 W
Clocks
Graphics : 300 MHz
SM : 300 MHz
Memory : 405 MHz
Video : 540 MHz
Applications Clocks
Graphics : N/A
Memory : N/A
Default Applications Clocks
Graphics : N/A
Memory : N/A
Max Clocks
Graphics : 2100 MHz
SM : 2100 MHz
Memory : 7001 MHz
Video : 1950 MHz
Max Customer Boost Clocks
Graphics : N/A
Clock Policy
Auto Boost : N/A
Auto Boost Default : N/A
Voltage
Graphics : N/A
Processes
GPU instance ID : N/A
Compute instance ID : N/A
Process ID : 1257
Type : G
Name : /usr/lib/xorg/Xorg
Used GPU Memory : 70 MiB
GPU instance ID : N/A
Compute instance ID : N/A
Process ID : 1445
Type : G
Name : /usr/libexec/gnome-remote-desktop-daemon
Used GPU Memory : 1 MiB
GPU instance ID : N/A
Compute instance ID : N/A
Process ID : 1485
Type : G
Name : /usr/bin/gnome-shell
Used GPU Memory : 118 MiB

nvenc not available

Hello,

Is nvenc a part of opensource driver stack?

Regards,
Rosen Aleksandrov

Add dependencies to README

I was trying to build on Arch, and I ran into a weird issue with the Makefile not finding the command "hostname"

Turns out I needed the "inetutils" package (I think other distros put it in bind-utils).

It would be helpful if we had some idea of what the build dependencies were beyond gcc

Extranous apostrohpes in a makefile script

NVIDIA Driver Version
515.43.04

Describe the bug
When building the kernel modules, an error popped up /bin/sh: line 1: localhost.localdomain: command not found caused by extra `` around $$(HOSTNAME) in the command GENERATE_NVIDSTRING in utils.mk:L527

Please if possible allow the "Discussion" feature on github for this project.

Hi.

As you might imagine many of us will be eyeing this project due to the potential impacts of its release.

It would be very productive for the community to have the "Discussion" feature activated for this project so people can openly share their questions and results with the work presented.

Thank you for considering.

Any support on older graphics cards

Hi everyone, first thanks nVidia for making this open-sourced, I'm wondering if it's open source, there would be any support for older legacy graphics card with new kernel and new xorgs?

SSL error while signing modules

Currently using 510 on Arch w/ Linux kernel 5.17.6-arch1-1 on an RTX 3080m. Trying to install 515 from this repo.

I'm running into an issue when running sudo make modules_install

make -C kernel-open modules_install
make[1]: Entering directory '<where I downloaded the repo>/open-gpu-kernel-modules/kernel-open'
make[2]: Entering directory '/usr/lib/modules/5.17.6-arch1-1/build'
  INSTALL /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-drm.ko
  INSTALL /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-modeset.ko
  INSTALL /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-peermem.ko
  INSTALL /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-uvm.ko
  INSTALL /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia.ko
  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-peermem.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory
  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-modeset.ko
  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-drm.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory
  ZSTD    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-peermem.ko.zst
  ZSTD    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-modeset.ko.zst
  ZSTD    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-drm.ko.zst
  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory
  ZSTD    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia.ko.zst
  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-uvm.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory
  ZSTD    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia-uvm.ko.zst
  DEPMOD  /lib/modules/5.17.6-arch1-1
make[2]: Leaving directory '/usr/lib/modules/5.17.6-arch1-1/build'
make[1]: Leaving directory '<the download directory>/open-gpu-kernel-modules/kernel-open'

It appears to be an issue with "signing:"

  SIGN    /lib/modules/5.17.6-arch1-1/kernel/drivers/video/nvidia.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:76
sign-file: ./certs/signing_key.pem: No such file or directory

src/nvidia/src/kernel/gpu/mem_mgr/heap.c:1607: unclear coding ?

Static analyser cppcheck says:

src/nvidia/src/kernel/gpu/mem_mgr/heap.c:1607:69: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation]

Source code is

       currentBankInfo = (currentBankInfo & BANK_MEM_GROW_DOWN ? MEM_GROW_DOWN : MEM_GROW_UP);

Presumably

       currentBankInfo = (currentBankInfo & BANK_MEM_GROW_DOWN) ? MEM_GROW_DOWN : MEM_GROW_UP;

was intended.

Clarification on GPU support for Maxwell/Pascal archs and binary/OS relationship

Maxwell and Pascal architecture GPUs are still capable of handling modern gaming, computing, encoding, decoding, etc workloads. Is there no way support could be extended to these GPUs?

If not, what is going to be the relationship between this driver and the binary one? Will there be no more feature updates for the binary release(Vulkan, OpenGL, etc) and be solely a "legacy" driver?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.