HP Victus hybrid Intel/NVIDIA: NVIDIA open modules trigger Intel eDP failure after s2idle resume

Graphics / Linux Linux
1

11_nvidia-bug-report.log.gz (95.6 KB)

18_nvidia_evidence.zip (133.8 KB)

Hi,

I am reporting an intermittent s2idle resume failure on an HP Victus
15-fa1054nt hybrid-graphics laptop. The internal BOE eDP panel is connected
to the Intel iGPU, but controlled comparisons indicate that loading the
NVIDIA open graphics modules participates in triggering the subsequent
Intel eDP link-training failure.

The corresponding Intel i915 report is public here:

SYSTEM

  • Laptop: HP Victus 15-fa1054nt / product 8U844EA#AB8 / board 8C40
  • BIOS: HP F.23 dated 2026-03-30
  • CPU/iGPU: Intel Core i7-13700H, Raptor Lake-P Iris Xe 8086:a7a0
  • Intel driver: i915; the Intel iGPU drives the internal panel
  • Internal panel: BOE094D, eDP-1, 1920x1080 at 144 Hz
  • dGPU: NVIDIA AD107M RTX 4060 Laptop, 10de:28a0
  • NVIDIA module type: open kernel module, Dual MIT/GPL
  • Distribution: Fedora 43
  • Desktop: KDE Plasma/KWin 6.7.3 on Wayland
  • Suspend mode: s2idle
  • Affected NVIDIA versions: 580.173.02 and 580.95.05
  • Affected kernels: 6.17.1-300, 7.0.12-101, 7.1.3-100, and
    7.1.4-104.fc43.x86_64

The normal nvidia-suspend.service, nvidia-resume.service, and
nvidia-hibernate.service hooks are enabled.

EXPECTED BEHAVIOR

After keyboard wake, the internal eDP panel should return once and remain
stable.

ACTUAL BEHAVIOR

The internal display commonly blacks out or flickers once or twice after
resume. Intermittently it enters a sustained on/off loop at roughly
one-second intervals until the machine is forcibly powered off.

During the severe loop, the graphical session appears unresponsive, but
system services and journaling continue. There is no matching kernel panic,
watchdog lockup, GPU reset/wedge, or input-device disconnect.

An affected resume records:

PM: suspend entry (s2idle)
i915 raw-wakerefs=1 wakelocks=1 on cleanup
[eDP-1] Failed to enable link training
PM: suspend exit
kwin_wayland: Applying output configuration failed!
[transcoder A] PSR aux error
[transcoder A] PSR aux error

Severe cycles additionally recorded Intel/KWin bad-link reports and a
temporary KWin main-thread hang.

REPRODUCTION

  1. Boot Fedora with i915 driving the internal eDP panel and the NVIDIA open
    graphics modules loaded.
  2. Log in to KDE Plasma Wayland.
  3. Leave the panel at 1920x1080/144 Hz.
  4. Run systemctl suspend.
  5. Wake with the built-in keyboard.
  6. Observe the internal panel and inspect the journal.

The visual severity is intermittent. The backend eDP/KWin/PSR signature can
occur even when a cycle looks visually clean.

CONTROLLED NVIDIA COMPARISON

Normal kernel 7.1.4 + NVIDIA 580.173.02 + enabled NVIDIA sleep hooks:

  • Valid s2idle cycle.
  • One visible flicker.
  • Complete Intel eDP/KWin/PSR failure signature.

Kernel 7.1.4 with all NVIDIA/nouveau graphics modules blacklisted, cycle 1:

  • Valid s2idle cycle.
  • No visible flicker.
  • No resume-time eDP link-training, KWin output, atomic-commit, or PSR AUX
    error.

Kernel 7.1.4 with all NVIDIA/nouveau graphics modules blacklisted, cycle 2:

  • Again a valid, visually clean s2idle cycle.
  • Again no resume-time eDP/KWin/PSR failure signature.

The blacklisted modules were:

nvidia nvidia_drm nvidia_modeset nvidia_uvm nvidia_peermem nouveau nova_core

i915 remained loaded and continued driving eDP-1. NVIDIA PCI function
01:00.0 was unbound.

NVIDIA loaded but sleep hooks disabled:

  • This was not a valid sleep comparison.
  • The NVIDIA PCI suspend callback returned -5 (EIO), and systemd aborted
    suspend.
  • After re-enabling the hooks in the same boot, a valid suspend completed
    and reproduced the Intel eDP failure.

Kernel 6.17.1 + NVIDIA 580.95.05:

  • The first controlled cycle had no visible flicker.
  • The backend still reproduced the complete Intel eDP/KWin/PSR signature
    and device resume took approximately 12.7 seconds.
  • Therefore 580.95.05 is not considered a confirmed fix.

Windows 11 control:

  • Five valid S0 Modern Standby cycles after BIOS F.23, three on AC and two
    on battery.
  • No visible flicker and no display, graphics, ACPI, WHEA, TDR, DWM, or
    LiveKernelReport error.

TESTED NVIDIA PARAMETERS

The following did not clear the backend failure:

  • nvidia_drm.modeset=0
  • nvidia_drm.fbdev=0
  • nvidia.NVreg_DynamicPowerManagement=0x00
  • nvidia.NVreg_PreserveVideoMemoryAllocations=0
  • nvidia.NVreg_EnableS0ixPowerManagement=0
  • The DRM and power parameters tested together

Multiple Intel-side mitigations and kernel fallbacks also reproduced the
fault. Full details are in the attached report and Intel issue.

ATTACHMENTS

I am attaching:

  • 11_nvidia-bug-report.log.gz
    Official NVIDIA safe-mode diagnostic, sanitized only for local username,
    home path, UUIDs, MAC addresses, and serial-number values.
  • 18_nvidia_evidence.zip

QUESTIONS

  1. Is there a known suspend/resume ordering or timing interaction between
    the NVIDIA open modules and Intel i915 eDP PPS/link training on hybrid
    Raptor Lake-P laptops?
  2. What additional NVIDIA tracing or diagnostics would best compare a
    failing NVIDIA-loaded cycle with a clean NVIDIA-blacklisted cycle?
  3. Should this be tracked internally as an NVIDIA power-management issue,
    an Intel DRM issue, or a cross-driver/platform integration issue?

Thank you.

2

have you tried this ?

3

It’s a phantom eDP on DDI B in HP’s VBT.

eDP thinks there are two panels to initialize, s2idle link training on DDI A fails.

Loading a VBT via i915.vbt_firmware= that is identical to the BIOS VBT except that the DP-B child’s device type is set to 0 fixes the issue completely.