# HP Victus hybrid Intel/NVIDIA: NVIDIA open modules trigger Intel eDP failure after s2idle resume **URL:** \ **Category:** Linux\ **Tags:** kernel\ **Created:** [July 24, 2026, 1:11pm UTC](https://forums.developer.nvidia.com/t/hp-victus-hybrid-intel-nvidia-nvidia-open-modules-trigger-intel-edp-failure-after-s2idle-resume/378051 "2026-07-24T13:11:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![umutangi3](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@umutangi3](https://forums.developer.nvidia.com/u/umutangi3)\ **Post date:** [July 24, 2026, 1:11pm UTC](https://forums.developer.nvidia.com/t/hp-victus-hybrid-intel-nvidia-nvidia-open-modules-trigger-intel-edp-failure-after-s2idle-resume/378051/1 "2026-07-24T13:11:33Z")
[11\_nvidia-bug-report.log.gz](https://forums.developer.nvidia.com/uploads/short-url/dCRsOf7H5FsLnJCgLJnbLdo12WO.gz) (95.6 KB) [18\_nvidia\_evidence.zip](https://forums.developer.nvidia.com/uploads/short-url/eCaI2mtFe3hHdXSKM2BSSWMmXps.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: > **[\[i915\]\[Raptor Lake-P\]\[s2idle\] eDP link training fails after resume when...](https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16691)** > > Summary of the issue On an HP Victus 15-fa1054nt hybrid Intel/NVIDIA laptop,... 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: ```auto 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: ```auto 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. ---
**Author:** ![Alphamaster08](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/alphamaster08/32/527980_2.png) [@Alphamaster08](https://forums.developer.nvidia.com/u/Alphamaster08)\ **Post date:** [July 28, 2026, 6:07am UTC](https://forums.developer.nvidia.com/t/hp-victus-hybrid-intel-nvidia-nvidia-open-modules-trigger-intel-edp-failure-after-s2idle-resume/378051/2 "2026-07-28T06:07:20Z")
> **[Freeze after wake from sleep/suspend with Raptor Lake and Alder Lake-P - Intel...](https://wiki.archlinux.org/title/Intel_graphics#Freeze_after_wake_from_sleep/suspend_with_Raptor_Lake_and_Alder_Lake-P)** > > Users with Raptor Lake and Alder Lake-P 12th gen mobile processor laptops from various vendors experienced freeze and black-screen after waking up from suspending. It is because many laptop vendors ship an incorrect VBT (Video BIOS Table), as... have you tried this ? ---
**Author:** ![jurgen.turrekens](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jurgen.turrekens](https://forums.developer.nvidia.com/u/jurgen.turrekens)\ **Post date:** [October 13, 2026, 7:53am UTC](https://forums.developer.nvidia.com/t/hp-victus-hybrid-intel-nvidia-nvidia-open-modules-trigger-intel-edp-failure-after-s2idle-resume/378051/3 "2026-10-13T07:53:48Z")
> > > \### Pre-flight checklist > > \- \[x\] I have searched existing issues and this is not …a duplicate. > \- \[x\] I have read the \[Contributing Guidelines\](https://github.com/CachyOS/linux-cachyos/blob/master/CONTRIBUTING.md). > \- \[x\] I have verified the issue is reproducible with the latest available CachyOS kernel. > \- \[x\] I have tried to reproduce the issue on Arch Linux's \`linux\` kernel. > > \### Upstream / vanilla kernel check > > I have not tested with a vanilla/upstream kernel > > \### Kernel variant > > linux-cachyos (EEVDF, Clang) > > \### System information (cachyos-bugreport.sh) > > \`\`\`text > ❯ sudo cachyos-bugreport.sh > \[sudo\] password for luimi: > Starting with bugreport > Redacting personal information... > Do you want to upload this log to https://paste.cachyos.org? \[Y\]es/\[N\]o: y > Uploading Log > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 292.0k 100 10 100 292.0k 4 134.8k 00:02 00:02 205.7k > https://paste.cachyos.org/p/86599be.log > \`\`\` > > \### Manual system information (if cachyos-bugreport.sh is unavailable) > > \`\`\`text > > \`\`\` > > \### Bug description > > I am experiencing an intermittent internal display failure after suspend/resume on an HP Victus 15-fa1xxx. > > The system uses s2idle as its only suspend mode. Suspend itself completes, but after resume the internal eDP panel sometimes takes several seconds to return, briefly appears and goes black again, or remains black until I hard power off the laptop. > > The problem is intermittent: some suspend/resume cycles work correctly, while others fail. > > Normal KDE/Wayland display power-off without actual suspend generally resumes correctly. The failure appears specifically around real s2idle suspend/resume cycles. > > The kernel consistently logs i915/eDP errors around the problematic resumes: > > i915 0000:00:02.0: \[drm\] \*ERROR\* > \[CONNECTOR:508:eDP-1\]\[ENCODER:507:DDI A/PHY A\]\[DPRX\] > Failed to enable link training > > I also see: > > \[transcoder A\] PSR aux error > > i915 raw-wakerefs=1 wakelocks=1 on cleanup > > WARNING at: > drivers/gpu/drm/i915/intel\_runtime\_pm.c > intel\_runtime\_pm\_driver\_release > > and occasionally during boot: > > failed to retrieve link info, disabling eDP > > Hardware: > \- HP Victus 15-fa1xxx > \- SKU: 8B3R1UA#ABA > \- Intel Alder Lake-P Iris Xe (i915) > \- NVIDIA GeForce RTX 4060 Laptop GPU > \- nvidia-open 615.71.09 > \- KDE Plasma / Wayland > \- linux-cachyos 7.2.4-3 > \- suspend mode: \[s2idle\] > \- BIOS F.18 > > NVIDIA suspend handling appears normal for the current driver: > \- PreserveVideoMemoryAllocations: 2 > \- UseKernelSuspendNotifiers: 1 > \- Runtime D3: Enabled (fine-grained) > > There appears to be a recent upstream Intel i915 patch series addressing this exact type of eDP/DPCD resume failure: > > "drm/i915/dp: On DPCD init/caps wake the DPRx" > > Patchwork series, rev6: > https://patchwork.freedesktop.org/series/161818/ > > A v6 test was performed on another HP Victus 15 using Linux 7.2.2. The tester reported multiple successful suspend/resume and lid-close cycles with zero "Failed to enable link training" errors: > > https://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg384512.html > > Would it be possible to consider carrying/backporting this patch in linux-cachyos once the maintainers consider the revision sufficiently safe or once it is accepted upstream? > > I am happy to test a CachyOS kernel containing the patch and provide additional logs if useful. > > Note regarding the pre-flight checklist: > > I have NOT actually tested this on Arch Linux's stock \`linux\` kernel. > The issue form currently requires the checkbox to be selected in order to submit the report. > > I am running CachyOS only, and the "Upstream / vanilla kernel check" field above correctly reflects that I have not tested with a vanilla/upstream kernel. > > \### Steps to reproduce > > 1. Boot CachyOS using linux-cachyos 7.2.4-3. > 2. Log into KDE Plasma Wayland. > 3. Allow the laptop to enter suspend, or run: > systemctl suspend > 4. Resume the laptop by opening the lid or using an input device. > 5. Repeat several times because the failure is intermittent. > 6. Inspect the kernel log with: > journalctl -b -k > 7. On failed/problematic resumes, i915 reports: > \[DPRX\] Failed to enable link training > > \### Expected behavior > > The internal eDP display should wake immediately and remain stable after every suspend/resume cycle, without requiring a hard shutdown. > > \### Actual behavior > > Resume is intermittent. > > Sometimes the internal display returns normally. Other times it takes several seconds to recover, briefly displays an image and goes black again, or remains black until the laptop is forcibly powered off. > > The kernel reports i915 eDP link-training and AUX errors after the affected resumes. > > \### Logs / stack traces > > \`\`\`text > PM: suspend entry (s2idle) > ... > PM: suspend exit > ... > kwin\_wayland: Applying output configuration failed! > ... > i915 0000:00:02.0: \[drm\] \*ERROR\* > \[CONNECTOR:508:eDP-1\]\[ENCODER:507:DDI A/PHY A\]\[DPRX\] > Failed to enable link training > \`\`\` > > \### Additional system information > > The internal display is driven by Intel i915. The NVIDIA GPU uses nvidia-open. > > DPMS/display power-off without a real suspend generally works correctly, which is why I suspect the issue is specifically in the i915/eDP resume path rather than KDE's normal display blanking. > > A similar issue exists outside CachyOS as well: > https://github.com/pop-os/pop/issues/3874 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.