PlatformRequestHandler: missing !bInit guard on bSystemParamLimitUpdate causes NV_ERR_INVALID_DATA at boot
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 88/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c
- Domain
- operating-systems
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.
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.
- Dominant language
- C
- Stars
- 17.4k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA/open-gpu-kernel-modules
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NVIDIA/open-gpu-kernel-modules#1343 · 3 comments ·
Maintainers usually reply within 1 day
-
HKC G27H7Pro redundant long-HPD loop after DisplayPort link training (RTX 5060 Laptop, 610.57.04)Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
NVIDIA/open-gpu-kernel-modules#1323 ·
Maintainers usually reply within 1 day
-
build-problem
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/open-gpu-kernel-modules#1155 · 1 comment ·
Maintainers usually reply within 1 day
-
build-problem
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
NVIDIA/open-gpu-kernel-modules#1154 · 10 comments ·
Maintainers usually reply within 1 day
-
Bug template is outdatedPossibly taken @Rohithmatham12 claimed this 120 days ago. Openbug
Difficulty 1/5 Under an hour Newbie friendliness 78/100
NVIDIA/open-gpu-kernel-modules#1147 ·
Maintainers usually reply within 1 day
All issues in NVIDIA/open-gpu-kernel-modules
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
HarbourMasters/Shipwright#7320 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
FujiNetWIFI/fujinet-firmware#1834 ·
Maintainers usually reply within 1 day
-
Bug Status: Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
yanet-platform/yanet2#2874 ·
Maintainers usually reply within 1 day