NVIDIA / NVIDIA/open-gpu-kernel-modules

PlatformRequestHandler: missing !bInit guard on bSystemParamLimitUpdate causes NV_ERR_INVALID_DATA at boot

Open Beginner friendly
#1,360 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
17.4k
Forks
1.9k
PR merge metrics
No merged PRs in 30d

Description

Problem

At boot, PlatformRequestHandler fires two NV_ERR_INVALID_DATA assertions:

NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed [NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler failed to get target temp from SBIOS @ platform_request_handler_ctrl.c:2174
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed [NV_ERR_INVALID_DATA] (0x00000025) returned from PlatformRequestHandler failed to get platform power mode from SBIOS @ platform_request_handler_ctrl.c:2117

These are boot-only cosmetic (runtime works fine), but the root cause is a missing guard in the driver.

Root Cause

In _pfmreqhndlrCallPshareStatus (platform_request_handler_ctrl.c), the bSystemParamLimitUpdate block at line 2467 has no !bInit guard:

// line 2467 — MISSING guard
if (pPfmreqhndlrData->PFMREQHNDLRACPIData.bSystemParamLimitUpdate)
{
    _pfmreqhndlrUpdateTgpuLimit(pPlatformRequestHandler, pGpu);   // line 2473 → 2174 ASSERT
    _pfmreqhndlrUpdatePpmdLimit(pPlatformRequestHandler, pGpu, NV_FALSE);  // line 2482 → 2117 ASSERT
    pPfmreqhndlrData->PFMREQHNDLRACPIData.bSystemParamLimitUpdate = NV_FALSE;
}

Every other block in the same function has a guard:

Line Block Guard
2387 EDPpeak && !bInit
2442 UserConfigTGP && !bInit
2457 PlatformCustomization (bInit)
2467 bSystemParamLimitUpdate none

During init, PSHARESTATUS (func 0x20) returns _UPDATE_LIMIT_PENDING. The driver immediately calls _pfmreqhndlrUpdateTgpuLimit and _pfmreqhndlrUpdatePpmdLimit before PSHAREPARAMS (func 0x2A) has initialized the TGPU/PPMD sensor counters. The counters are bSupported=false && !bVolatile, so pfmreqhndlrGetPerfSensorCounterById returns NV_ERR_INVALID_DATA.

The init-time PPMD update at line 1218 (after PSHAREPARAMS) already handles boot-time PPMD initialization correctly. The bSystemParamLimitUpdate block should be deferred to runtime, matching the pattern used by every other block.

Fix

One-line change at platform_request_handler_ctrl.c:2467:

// BEFORE:
if (pPfmreqhndlrData->PFMREQHNDLRACPIData.bSystemParamLimitUpdate)

// AFTER:
if (pPfmreqhndlrData->PFMREQHNDLRACPIData.bSystemParamLimitUpdate && !bInit)

Environment

  • Driver: 610.57.04 (open)
  • GPU: RTX 5050 Laptop (GB207M, 10DE:2D98)
  • Kernel: 7.2.3-1-cachyos
  • Platform: Lenovo LOQ 15IRX11

Impact

Boot-only cosmetic. No runtime side effects. The TGPU limit is applied on first runtime PSHARESTATUS with _UPDATE_LIMIT_PENDING. The init-time PPMD update at line 1218 already handles boot-time sensor initialization.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Open platform_request_handler_ctrl.c and inspect _pfmreqhndlrCallPshareStatus around line 2467, comparing the bSystemParamLimitUpdate block with the neighboring guarded blocks. Verify the boot path no longer emits the two NV_ERR_INVALID_DATA assertions while a runtime PSHARESTATUS update still applies the pending limit.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
operating-systems
Issue type
Bug
Difficulty
1/5
Estimated time
Under an hour
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.