General

• "Change ECC State" and "Enable Error Correction Code" do not change synchronously when ECC state changes. 3838953
• CUDA kernels that use the sparsity feature of tensor cores through the mma.sp PTX instruction on Hopper architecture GPUs may intermittently experience silent data corruption resulting in incorrect results. NVIDIA libraries currently do not provide access to tensor cores with sparsity so only kernels directly developed using the mma.sp PTX instruction are impacted. This issue will be fixed in an upcoming release. 4254491

• MPAM Support

  MPAM is not supported in this release. To enable MPAM support in the future, changes to the SBIOS are in progress. To use the MPAM capabilities at that time, you need an MPAM-enabled kernel.

• cpufreq-info is not reporting correct core frequency on Grace. 4253549

  The CPU frequency reported by the Linux kernel might vary significantly from the actual value.

  WorkaroundThere is currently no workaround, and this issue will be resolved in a future kernel version.

• Unable to allocate full GPU memory. 4278263

  On CPU+GPU coherent memory platforms, such as Grace Hopper, GPU memory is added to the Linux kernel as an NUMA node and is managed by the kernel. The kernel minimum watermark threshold might prevent GPU applications from allocating the full GPU memory.

  Workaround

  To allocate full GPU memory, users can manually tune /proc/sys/vm/min_free_kbytes.

• CPU TempAvg Low event log Threshold message is wrong. 4299244

  When the temperature goes below the low warning/critical threshold, there is a Redfish event log with the threshold value. The expected threshold value should be the low warning/critical threshold, but the high warning/critical threshold value is selected instead.

  As a result, users cannot get the correct threshold value from the Redfish low warning/critical Redfish event.

  WorkaroundWhen you inspect a low warning/critical Redfish event, get the correct low threshold value from the sensor URI (/redfish/v1/Chassis/CPU_0/Sensors/ProcessorModule_0_CPU_0_TempAvg_0).

• [IPMI] Duplicate sensor name. 3999921

  Sensor names are unique but, as per the current specification, IPMI has a 16-character for the name field. Sensors that have the same initial 16-characters appear as duplicate sensors in the SDR.

  Workaround

  There is currently no workaround, and this issue will be resolved in a future release of the BMC. Until then, you can safely ignore the duplicate sensor.

• A driver library mismatch error after a successful installation and subsequent reboot causes GPU programs to not start. 4302438

  GPU programs work immediately after installing the driver, but fail to load after rebooting, and messages like the following appear in the kernel log:

  API mismatch: the client has the version xxx.xx but this kernel module has the version yyy.yy. Please make sure that this kernel module and all NVIDIA driver components have the same version.

  This is most likely because kernel modules from a previous driver version are in the initramfs.

  Workaround

  Rebuild the initramfs and reboot the system. If a reboot is not immediately possible, you can temporarily work around the issue by unloading and reloading the NVIDIA kernel modules.

• Grace is doing a seemingly unnecessary munmap of the untouched host memory when CUDA context is active. 4052424

  Customers who use older stable/longterm trees should update to the latest upstream subversion, and customers who are using another tree should cherry-pick the subversion from one of the trees (versions linux-6.5.y, linux-6.1.y, or linux-5.15.y).

  Workaround

  There is currently no workaround.

• On GH200, a pyt_bart inference perf regression occurs after a driver update. 4308011

  On GH200 systems, copies between pageable memory and the device can be offloaded to copy engines. While this provides many performance and functional benefits, a subset of copies that involve addresses that are not resident in the main memory were observed to be slow. To mitigate this performance bottleneck, a performance optimization that actively fetches the non-resident pages into memory before the copy operation starts has been introduced.

  The pre-fetching operation involves some overhead, so users can tweak the page read latency, and then the paging operation starts. Users can set the threshold value for page read operations beyond which CUDA will actively try to page in non-resident pages. The default value is 0.008 milliseconds.

  To reduce the number of page-in ops, users can set the value to 0.01 or 0.02 milliseconds in the CUDA_BUFFER_PAGE_IN_THRESHOLD_MS= environment variable.

• ipmitool mc information does not show the firmware versions. 4299371

  The NVIDIA OpenBMC Reference solution does not provide firmware inventory versions through IPMI.

  You can find the firmware inventory versions in the Redfish interface.

• System not powering back on when performing power cycle from BMC. 4305610

  When performing a power cycle command from the BMC, such as IPMI Chassis Power Cycle, the system will shut down correctly, but it might not automatically restart.

  Workaround

  Manually restart the system after the shutdown. This issue will be addressed in a future NVIDIA OpenBMC Reference Firmware release.

• Some errors are set after a clean boot. 4312911

  The Correctable Error (the CorrErr bit) and Unsupported Request (the UnsupReq bit) in the Device Status register (part of the PCI Express Capabilities set of registers) and the Advisory Non-Fatal Error (the AdvNonFatalErr bit) in the Correctable Error Status register of the Advanced Error Status (AER) set of registers are getting set because the enumeration process occurs in the Linux kernel. During this process, when there is a read for a non-existent device downstream of the root port, the kernel receives a response as an Unsupported Request, so the UnsuppReq bit is set.

  Since Grace is configured to treat UnsuppReq responses as Advisory Non-Fatal Error, and the AdvNonFatalErr bit is set, there will not be an Uncorrectable Error. Instead, a Correctable Error is raised, and the orrErr bit is set. Grace is configured to have a software leaky bucket for all the correctable errors, so unless the number of correctable errors observed is greater than 32 in one minute, the errors are not reported to the OS. As a result, these errors are set after a clean boot.

  WorkaroundCurrently, there is no workaround available.

• GPU firmware update fails with an "Update.1.0.VerificationFailed" message during upgrade-downgrade testing. 4332232

  If the GPU accesses its SPI flash at approximately the same time the ERoT attempts to verify the GPU firmware image, the ERoT might time out. The PLDM firmware update might fail with VerifyResult equal to 0x99, which is reported in the Redfish task status as Update.1.0.VerificationFailed.

  Workaround

  1. Ensure a proper firmware update sequence and status checking is implemented for each iteration of upgrade-downgrade testing.

  2. After each firmware update, issue A/C power cycle for the firmware update to take effect

  3. After the A/C power cycle, wait for the host to be ready before verifying the firmware inventory.

  4. After the A/C power cycle, wait for background copy completion before initiating the next firmware update.

• Support for 4k page size in nv-p2p.

  The NVIDIA driver's kernel mode GPUDirect RDMA APIs that are used for Peer-direct support in MLNX_OFED and GPUDirect Storage are not supported on GH200 platforms when used with Linux kernels that are configured with the 4K page size. These APIs are not functional and might lead to a kernel memory corruption.

  Users are strongly encouraged to move their software stack to the dma-buf APIs, which require the open-source GPU driver, Linux kernel 5.12 or later (if upstream kernel GPUDirect RDMA support for RDMA networking is required), and NVIDIA Turing™ + GPU. Since the dma-buf APIs work correctly on 4K page kernels, using those APIs is the ideal mitigation for this issue.

• Reduced fan speed does not display with correct severity in the event log. 4241946

  When running the NVIDIA BMC reference code, the severity of a fan under the critical threshold is not correct. It should be Critical, but it is reported as OK in Redfish.

  Workaround

  There is no workaround unless you modify the BMC reference source code.

• Graphics functionalities, such as EGL, GLX, and Vulcan, are currently not supported under the 4K OS page size. 4333780

  Workaround

  We recommend that you use a 64K page size.

• The peak message rate varies greatly. 4329895

  In some circumstances, PCIe strict ordering might not work well in Grace Hopper. Users might experience low message rates when the PCIe write traffic targeting GPU memory is high.

  Workaround

  You can use PCIe relaxed ordering, for example, by using ibv_reg_mr with the IBV_ACCESS_RELAXED_ORDERING flag.

• NaNs reported in longevity tests when ECC error injection and video error injection are enabled. – 4051897

  Although rare, during longevity and stress testing, some sensors might randomly display NaN readings. However, this issue typically occurs only once for a few readings, and subsequent readings during the sensor polling loop return to normal. So far, we have not encountered any cases where a sensor displayed consecutive NaN readings.

  To handle occasional NaN readings, the host BMC or any client software that consumes sensor information should implement a retry mechanism so that it is resilient.

• Set_declare SMBPBI Master caps will return success. – 3977576

  The undocumented SMBPBI opcode 0x8 does not return ERR_OPCODE in conformance with the SMBPBI specification. This opcode is not supported on the Hopper HGX 8-GPU baseboard and should not be used.

• Fail to pass Redfish Protocol Validator (1.1.6). – 4109466

  The Redfish validator test case POST /redfish/v1/AccountService/Accounts fails because of a Redfish validator error, but there is no impact on the system functionality.

  Work around

  No workaround is required.

  Refer to the https://github.com/DMTF/Redfish-Protocol-Validator/issues/57 validator issue for more information.

• Instead of a failed action, a success action is displayed when a AccountLockoutDuration PATCH request is sent in AccountService. – 4109596

  When a PATCH request is sent with a value less than ACCOUNT_UNLOCK_TIMEOUT = 600 seconds (default), 200 OK is returned instead of throwing an error.

  Here is an example:

  # curl -s -k -H "X-Auth-Token: $token" -X PATCH
  https://192.168.31.1/redfish/v1/AccountService -d '{"AccountLockoutDuration": 300}'
  200 Ok
  {
     "@Message.ExtendedInfo": [ 
        {
            "@odata.type": "#Message.v1_1_1.Message",
            "Message": "The request completed successfully.",
            "MessageArgs": [],
            "MessageId": "Base.1.15.0.Success",
            "MessageSeverity": "OK",
            "Resolution": "None"
         }
     ]
  # curl -k -H "X-Auth-Token: $token" -X GET https://192.168.31.1/redfish/v1/AccountService
  | grep AccountLockout
      "AccountLockoutDuration": 600,
      "AccountLockoutThreshold": 3,
                              

  600 seconds is the default waiting time before trying to log in again when the account is locked due to multiple login failures. This value cannot be changed to a value that is less than 600 seconds using PATCH request.

  In the current implementation, the issue is happening because of the inability to handle values less than the compile time limit (for example, ACCOUNT_UNLOCK_TIMEOUT = 600 seconds). When a 200 OK response is returned, users think that they have updated the account timeout value, but the original behavior does not change.

  Workaround

  There is no workaround at this time.

• During a stress test, the HMC ERoT failed to get the SPDM measurements. – 4130662

  During a stress test, where the firmware update and the SPDM attestation data are being completed simultaneously, the SPDM attestation API sometimes fails to get the SPDM Attestation data.

  Workaround

  Retrying the operation might result in a successful outcome. The fix will be included in the v1.3.0 GA release.

• Redfish Service Validator reports the following errors: – 4099508

  • ERROR - 1 err.SessionCollection.SessionCollection errors in /redfish/v1/
  • ERROR - 1 failMandatoryExist errors in /redfish/v1/
  • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Managers/HGX_BMC_0
  • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Managers/HGX_BMC_0/LogServices/Journal
  • ERROR - 1 err.PCIeDevice.PCIeTypes errors in /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0
  • ERROR - 1 failProp errors in /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0
  • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Systems/HGX_Baseboard_0/LogServices/DebugTokenService
  • ERROR - Validation has failed: 5 problems found

  • The Id property does not match the last segment of the URI:

    • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Managers/HGX_BMC_0

    • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Managers/HGX_BMC_0/LogServices/Journal

    • ERROR - 1 failRedfishUriStrict errors in /redfish/v1/Systems/HGX_Baseboard_0/LogServices/DebugTokenService

  WorkaroundThere is no functional impact and no workaround at this moment.

  • ERROR - PCIeType shows "empty string": Value Enum not found in ['Gen1', 'Gen2', 'Gen3', 'Gen4', 'Gen5']

  • ERROR - 1 err.PCIeDevice.PCIeTypes errors in /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0

  • ERROR - 1 failProp errors in /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0

  WorkaroundCheck the CurrentSpeedGbps property on the Port resource of the FPGA:

  • /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0/Ports/PCIeToHost_0

  • /redfish/v1/Systems/HGX_Baseboard_0/Processors/FPGA_0/Ports/PCIeToHMC_0

• The PCIeSwitch ERoT Recovery event does not generate a corresponding event on the PCIeSwitch AP Chassis URI. – 4325634

  When the PCIeSwitch ERoT Recovery event is generated, there is no corresponding event in the Conditions array of the /redfish/v1/Chassis/HGX_PCIeSwitch_0 URI.

  Workaround

  If the PCIeSwitch Health or HealthRollup shows Critical, customers can check the ERoT Chassis URI (/redfish/v1/Chassis/HGX_ERoT_PCIeSwitch_0) for Conditions.

• 4333486 CUDA initialization failure on MIG and forward compatibility setups. – 4333486

  CUDA will not work in Multi Instance GPU (MIG) mode on CUDA forward compatibility setups with display driver major version 470 or earlier.

  CUDA will not initialize correctly when run in forward compatibility mode with display driver from major version 470 and earlier when MIG is enabled. The CUDA APIs will return cudaErrorNoDevice/CUDA_ERROR_NO_DEVICE errors when run on such a setup.

  Workaround

  Update the display driver to a major version, which is supported in CUDA forward compatibility and that is later than 470 (for example, version 510 or later).

• AutoClearResolvedLogEnabled is not defined in the Complex NVIDIA NvidiaLogService.v1_0_0.NvidiaLogService. 4313643

  The following message is displayed in the Redfish service validator:

  ERROR - 1 failAdditional.complex errors in /redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog

  This issue occurs on the /redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog URI because the Oem.Nvidia @odata.type property has the NvidiaLogService.v1_0_0.NvidiaLogService value instead of the NvidiaLogService.v1_1_0.NvidiaLogService value.

  Here is the sample output of the /redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog URI:

  {

      "@odata.id":
        "/redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog",

  "@odata.type": "#LogService.v1_1_0.LogService",

  "Actions": {

  "#LogService.ClearLog": {

              "target":
          "/redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog/Actions/LogService.ClearLog"

  }

  },

  "DateTime": "2020-08-23T23:51:08+00:00",

  "DateTimeLocalOffset": "+00:00",

  "Description": "System Event Log Service",

  "Entries": {

          "@odata.id":
          "/redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog/Entries"

  },

  "Id": "EventLog",

  "Name": "Event Log Service",

  "Oem": {

  "Nvidia": {

              "@odata.type":
          "#NvidiaLogService.v1_0_0.NvidiaLogService",

  "AutoClearResolvedLogEnabled": false,

  "LatestEntryID": "443",

              "LatestEntryTimeStamp":
        "2020-08-23T23:51:06+00:00"

  }

  },

  "OverWritePolicy": "WrapsWhenFull"

  }

  Workaround

  There is no functional impact and no workaround at this time.

• No Secure boot failure event is generated. – 4299429

  The HMC supports secure boot failure, SPI flash error, boot complete failure, heartbeat failure, ERoT fatal, ERoT recovery, and MCTP runtime error ERoT-related events at bootup and runtime. Issues with incoming firmware packages during the firmware update process are also reported by the HMC. A secure boot failure as the result of a key revocation will be detected when users attempt to flash a firmware update package with a revoked key. When this occurs, the following message is displayed in the firmware update task log:

  {

  "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",

        "Message": "The resource property 'HGX_FW_BMC_0' has detected errors of type
          'Security keys revoked'.",

  "MessageArgs": [

  "HGX_FW_BMC_0",

  "Security keys revoked"

  ],

  "MessageId": "ResourceEvent.1.0.ResourceErrorsDetected",

  "Resolution": "Verify the contents of the FW package",

  "Severity": "Critical"

  }

  However, when the image already on the AP flash is signed with a key that is revoked, no Secure boot failure event is generated. In this case the device Health/HealthRollup becomes Critical.

  If the AP fails to boot because both images are signed with a revoked key, the ERoT fatal event is raised on the associated ERoT Chassis URI, and for GPU/NVSwitch a NACK From Device event on the AP Chassis URI is also seen. A secure boot failure as the result of a signature authentication failure is still reported during the firmware update and at boot or runtime. This scenario triggers the following Redfish event, which shows in the Conditions of the AP Chassis URI:

  {

        "@odata.id":
          "/redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog/Entries/2",

  "@odata.type": "#LogEntry.v1_9_0.LogEntry",

        "AdditionalDataURI":
          "/redfish/v1/Systems/HGX_Baseboard_0/LogServices/EventLog/Entries/2/attachment",

  "Created": "2034-09-11T23:22:25+00:00",

  "EntryType": "Event",

  "Id": "2",

  "Links": {

  "OriginOfCondition": {

            "@odata.id":
          "/redfish/v1/UpdateService/FirmwareInventory/HGX_FW_NVSwitch_0"

  }

  },

        "Message": "The resource property NVSwitch_0 Firmware has detected errors of
          type 'Secure Boot Failure'.",

  "MessageArgs": [

  "NVSwitch_0 Firmware",

  "Secure Boot Failure"

  ],

  "MessageId": "ResourceEvent.1.0.ResourceErrorsDetected",

  "Name": "System Event Log Entry",

        "Resolution": "ERoT will try to recover AP by a reset/reboot. If there is
          still a problem, collect ERoT logs and reflash AP firmware with recovery
        flow.",

  "Resolved": false,

  "Severity": "Critical"

  },

• OpenCL is not supported in the confidential compute mode available with Hopper (https://www.nvidia.com/en-in/data-center/solutions/confidential-computing/) . Any attempt to run OpenCL apps in this mode will result in clGetPlatformIDs returning an error CL_INVALID_DEVICE.
• All Mellanox ports are shown by command "nvidia-smi topo -m" after dual-port NICs are bonded.
• When polling the H100 GPU via SMBPBI using GPU Performance Monitoring metrics, driver reloads or GPU resets can result in driver errors that manifest as PID (X62) errors on Linux. NVIDIA is investigating this issue.
• On NVIDIA H800, monitoring software such as DCGM or NVML might report lower double-precision (FP64) utilization metrics. This is expected as per the NVIDIA H800 product configuration. Refer to the NVIDIA H800 product brief for more details.
• The GPU driver build system might not pick the Module.symvers file, produced when building the ofa_kernel module from MLNX_OFED, from the right subdirectory. Because of that, nvidia_peermem.ko does not have the right kernel symbol versions for the APIs exported by the IB core driver, and therefore it does not load correctly. That happens when using MLNX_OFED 5.5 or newer on a Linux Arm64 or ppc64le platform.
  To work around this issue, perform the following:

  1. Verify that nvidia_peermem.ko does not load correctly.
  2. Uninstall old MLNX_OFED if one was installed.
  3. Manually remove /usr/src/ofa_kernel/default if one exists.
  4. Install MLNX_OFED 5.5 or newer.
  5. Manually create a soft link:

      /usr/src/ofa_kernel/default -> /usr/src/ofa_kernel/$(uname -m)/$(uname -r)

  6. Reinstall the GPU driver.
• If you encounter an error on RHEL7 when installing with cuda-drivers-fabricmanager packages, use the following alternate instructions. For example:

  If you are upgrading from a different branch, for example to driver 515.65.01:

  new_version=515.65.01
  sudo yum swap nvidia-driver-latest-dkms nvidia-driver-latest-dkms-${new_version}
  sudo yum install nvidia-fabric-manager-${new_version}

• When installing a driver on SLES15 or openSUSE15 that previously had an R515 driver installed, users need to run the following command afterwards to finalize the installation:

  sudo zypper install --force nvidia-gfxG05-kmp-default 

  Without doing this, users may see the kernel objects as missing.

• nvidia-release-upgrade

  may report that not all updates have been installed and exit.
  When running the

  nvidia-release-upgrade

  command on DGX systems running DGX OS 4.99.x, it may exit and tell users: "Please install all available updates for your release before upgrading" even though all upgrades have been installed.
  Users who see this can run the following command:

  sudo apt install -y nvidia-fabricmanager-450/bionic-updates --allow-downgrades

  After running this, proceed with the regular upgrade steps:

  sudo apt update
  sudo apt full-upgrade -y 
  sudo apt install -y nvidia-release-upgrade 
  sudo nvidia-release-upgrade

• By default, Fabric Manager runs as a systemd service. If using

  DAEMONIZE=0

  in the Fabric Manager configuration file, then the following steps may be required.
  1. Disable FM service from auto starting.

     systemctl disable nvidia-fabricmanager

  2. Once the system is booted, manually start FM process.

     /usr/bin/nv-fabricmanager -c /usr/share/nvidia/nvswitch/fabricmanager.cfg

     Note, since the process is not a daemon, the SSH/Shell prompt will not be returned (use another SSH shell for other activities or run FM as a background task).
• Important correctness fix for H100 GPU instructions used by cuBLAS, other CUDA libraries, and user CUDA code

  An issue was discovered recently with H100 GPUs (H100 PCIe and HGX H100) where certain operations put the GPU in an invalid state that allowed some GPU instructions to operate at unsupported frequency that can result in incorrect computation results and faster than expected performance. The affected GPU instructions are used by cuBLAS, other CUDA libraries, and can also be used for user CUDA code.

  The operations that allow the GPU to enter an invalid state are the following:

  • Enabling MIG
  • Deinitialize and reinitialize the GPU (for example, turn off persistence mode and turn it back on or reload the nvidia.ko driver)
  • Any Compute Engine error (for example, MMU fault, Out of Range warp error, and so on)
  Once the GPU enters the invalid state, the performance for some GPU instructions is increased by 7-10%, but the computation results may be incorrect.

  The current release fixes this issue, and it is no longer possible to enter the invalid GPU state. This issue has been present in all drivers since the H100 launch, and we recommend that you upgrade to the current release as soon as possible. If upgrading is not immediately possible, a GPU reset can restore the GPU back to the correct operational state, except for when MIG is being used. For MIG, the new driver is required, and there is no workaround available.

• Uninstalling the driver fails, and the system reboots automatically.
  On Windows 2019 and 2022 servers, uninstalling the driver causes the system to restart automatically before the uninstallation is completed. The issue also occurs when you upgrade the driver from an older version to a new version, even after selecting the Perform Clean Installation option in the installer UI.

  Note: This issue does not occur in Linux.

  Workaround

  We strongly recommend that you always install, uninstall, and upgrade drivers from Safe mode.

• In Shared Switch virtualization mode, the guest VM GPU driver load and unload stress test fails after certain iteration

  In the Shared Switch virtualization mode, the stress test to load and unload the GPU driver on Guest VM in every 30 second interval runs into issues approximately after three hours of the test.

  Workaround

  Do not run the stress reload driver cycle at this time.

• A few Async SMBPBI commands do not function as intended when the driver is unloaded.

  When the driver is unloaded, the following Async SMBPBI commands do not operate as specified:

  • Arg1 0x00: Reads total GPU power limit control data.
  • Arg1 0x01: Sets the total GPU power limit.
  • Arg1 0x02: Reads the total GPU power limit policy information.
  Due to this issue, some properties of the following Redfish URIs are impacted:

  • PowerLimitWatts.SetPoint:

    /redfish/v1/Systems/HGX_Baseboard_0/Processors/GPU_SXM_[1-8]/EnvironmentMetrics

  • SpeedLimitMHz, SpeedLocked:

    /redfish/v1/Systems/HGX_Baseboard_0/Processors/GPU_SXM_[1-8]

  The Patch operation of the following URIs are impacted:

  • PowerLimitWatts.SetPoint:

    /redfish/v1/Systems/HGX_Baseboard_0/Processors/GPU_SXM_[1-8]/EnvironmentMetrics

  • Oem.Nvidia.PowerMode "MaxP" or "MaxQ":

    /redfish/v1/Chassis/HGX_Chassis_0/EnvironmentMetrics

  • SpeedLimitMHz, SpeedLocked:

    /redfish/v1/Systems/HGX_Baseboard_0/Processors/GPU_SXM_[1-8]

  Workaround

  Load the driver for these URIs to work properly.

• Fabric Manager state is not reported accurately on NVSwitch OOB query

  The NVSwitch SMPBI query that reports Fabric Manager state (Manager State) is not reporting the actual FM state.

• Instructions to reset all GPUs Using the nvidia-smi -r Command

  When resetting all GPUs using the nvidia-smi command with the -r option instead of a resetting specific GPU using the -i <gpu_index> option, all the NVSwitches will also be reset. This process wipes out the NVSwitch routing entries, and subsequent CUDA application launches will fail. The Fabric Manager service will also show interaction errors with the NVSwitch device via the switch driver.

  Workaround

  1. Stop the Fabric Manager service.
  2. To reset all GPUs, run nvidia-smi -r.
  3. After the reset is finished, start the Fabric Manager service.

GPU Performance Counters

The use of developer tools from NVIDIA that access various performance counters requires administrator privileges. See this note for more details. For example, reading NVLink utilization metrics from nvidia-smi (nvidia-smi nvlink -g 0) would require administrator privileges.

NoScanout Mode

NoScanout mode is no longer supported on NVIDIA Data Center GPU products. If NoScanout mode was previously used, then the following line in the “screen” section of /etc/X11/xorg.conf should be removed to ensure that X server starts on data center products:

Option         "UseDisplayDevice" "None"

NVIDIA Data Center GPU products now support one display of up to 2560x1600 resolution.

Unified Memory Support

CUDA and unified memory is not supported when used with Linux power management states S3/S4.

IMPU FRU for Volta GPUs

OpenCL 3.0 Known Issues

Device side enqueue

• Device-Side-Enqueue related queries may return 0 values, although corresponding built-ins can be safely used by kernel. This is in accordance with conformance requirements described at https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_API.html#opencl-3.0-backwardscompatibility

• Shared virtual memory - the current implementation of shared virtual memory is limited to 64-bit platforms only.

Confidential Compute

• Confidential Compute applications will not work on this release. Please continue to use 535.104.05 for this use case.