I am looking for technical insights regarding a persistent communication failure between the dGPU and the system on my laptop. The issue started after a specific sequence of firmware updates and OS state changes. I would appreciate any feedback on what might be occurring at the firmware or GSP level.
Device Specifications:
-
Model: MSI Vector 16 HX AI (MS-15M3)
-
GPU: NVIDIA GeForce RTX 5080 Laptop (16GB GDDR7)
-
CPU: Intel Core Ultra 9 275HX
-
OS: Dual-boot Windows 11 + Kali Linux
The Timeline of Events:
-
On Kali Linux, NVIDIA drivers were installed manually using the official .run file.
-
Envycontrol was used to manage GPU power states and switching.
-
While the system was in this Linux-managed environment, a VBIOS update was performed through the Windows environment.
-
Following the update, the dGPU started exhibiting inconsistent behavior regarding system integration.
Current Technical Observations:
-
Physical Performance (Discrete Mode): When forced into Discrete Graphics Mode via the MUX switch, the hardware appears physically healthy. Stress tests show the GPU reaching its full 179W TGP and maintaining a 2047 MHz core clock.
-
MSHybrid/Optimus Failure: When the system is switched to MSHybrid mode, the dGPU is entirely invisible to the OS. It does not appear in the Device Manager or any hardware polling tools.
-
Display Synchronization Issues: In Discrete mode, G-Sync is unavailable. Attempting to force-enable G-Sync via the NVIDIA App results in immediate screen flickering and a “Display not supported” error. There is also significant ghosting/latency during display output.
-
NVFlash Error: Any attempt to re-flash or rollback the VBIOS is met with a 0x9F (Command Rejected) error.
Seeking Technical Feedback: I am trying to understand how the Linux-based power/switching state during the VBIOS flash might have affected the GSP (GPU Security Processor) or the InfoROM/CCC partitions.
-
Is it possible that the manual driver installation (.run file) or envycontrol’s ACPI manipulations caused a persistent synchronization mismatch during the firmware write?
-
Could this be a state where the hardware is operational but the secure handshake for display features and MSHybrid visibility is failing?
I would be very grateful for any technical explanations or suggestions on what to investigate next.
Hi @sertacyucedag87 , thanks for reporting this issue.
Could you kindly attach a full bug report here taken using sudo nvidia-bug-report.sh ? Thanks.
Hi @vanditd,
I have installed the acpidump tool on the Live USB and re-ran the script to ensure you get the complete ACPI routing tables and logs. The new nvidia-bug-report.log.gz is attached to this message.
To give you the exact context of this log and why I am seeking your help:
-
My main drive currently only has Windows 11 installed (the dual-boot was wiped for testing). I generated this report using a Linux Live USB.
-
Before booting into the Live USB, the hardware was set to MSHybrid mode via MSI Center in Windows.
The Core Issue: MSI Global Support has reviewed my case and dismissed it, claiming the machine is “functioning normally.” However, I am absolutely certain there is a deep synchronization issue at the firmware/hardware layer.
It behaves as though the MUX switch or display pipeline is trapped in a crossed, locked, or “ghost” state at the firmware level, regardless of what the OS is reporting.
I am hoping the ACPI dumps and GSP state logs in this report will finally reveal the locked firmware state that MSI is missing. I would deeply appreciate your expert analysis on this.
Thanks again for your time!
nvidia-bug-report.log.gz (1.6 MB)
Hi @vanditd,
I have a massive and shocking update regarding this issue.
Today, I visited the official MSI Service Center to initiate an RMA process for my laptop. While I was there, the technician brought out another exact same model (MSI Vector 16 HX AI) from their lab to compare. That secondary unit had a clean Windows installation, all official drivers, and the latest official VBIOS provided by MSI.
The Shocking Discovery:
That second laptop exhibited the exact same hardware/firmware anomalies as mine. Most importantly, its InfoROM was also completely wiped/empty! This completely changes the situation:
-
This proves my issue was not caused by my Linux dual-boot setup or Envycontrol ACPI manipulations.
-
This is a chronic, widespread firmware disaster caused by MSI’s official VBIOS update. Their official update file is literally wiping or locking the InfoROM (including the CCC/License partitions and GSP data) across their entire product line. This explains why G-Sync permanently disappeared after the update and why the MUX switch is physically failing to route the display away from the Intel iGPU.
I took my laptop back and cancelled the immediate repair, because replacing the motherboard will achieve absolutely nothing if MSI continues to flash it with the same broken firmware that destroys the InfoROM.
Given that this is now confirmed as a widespread OEM firmware failure, is there anything your engineering team can see in the nvidia-bug-report logs I provided that definitively points to this InfoROM wipe or GSP handshake failure?
Any official technical observation from you confirming that the InfoROM data is missing/corrupted would be incredibly helpful for me as I prepare to initiate a legal refund process against MSI for selling a chronically defective product.
Thank you so much for your time and support!
Hi @sertacyucedag87, sorry for the delayed follow-up, and thank you for the detailed update.
I reviewed the attached NVIDIA bug report. From that log, I do not see evidence that the GPU InfoROM is wiped or unreadable. The GPU is enumerated and initialized, and nvidia-smi reports:
GPU: NVIDIA GeForce RTX 5080 Laptop GPU
VBIOS Version: 98.03.A1.00.11
GPU UUID: GPU-9bd565d7-2b4c-c80c-43f8-9e99ec8d66d6
Inforom Image Version: G005.0000.98.01
OEM Object: 2.1
The ECC Object and Power Management Object showing N/A does not by itself indicate InfoROM corruption, it can simply mean that the specific object is not supported or not present for that product/configuration.
I also do not see any Xid errors / call traces in the captured NVIDIA driver log. The driver appears to load and bind to the GPU normally.
The most useful next step would be to compare against the previous VBIOS/BIOS/EC combination where MSHybrid and G-Sync were known to work. From the NVIDIA Linux bug report currently attached, I cannot confirm an InfoROM wipe or a GPU/GSP driver initialization failure. Thanks.
Hi @vanditd,
To eliminate any ambiguity from the OS-level logs, I am directly attaching the raw RM203.rom EEPROM dump extracted from my RTX 5080 using nvflash64.exe.
Could you or your engineering team please analyze this specific ROM file using your internal hex/firmware diagnostic tools?
When you examine the InfoROM region within this dump, you will clearly see the exact hardware anomaly I am reporting: while the InfoROM filesystem structure and partition headers (such as OEM, OBD, and PTD) are present and intact, their actual data payloads are completely empty (100% filled with 0x00 bytes).
This explains exactly why nvidia-smi superficially enumerates the InfoROM (by reading the surviving headers) and why the GPU core still renders correctly, while the critical SPDM/CCC certificate required for the MUX handshake is physically missing from the chip.
I would greatly appreciate it if you could parse this attached .rom file on your end to officially verify that the payloads are wiped.
Thank you again for your time and deep technical assistance!
GB203.zip (1.1 MB)