HELP
Hi everyone,
I'm trying to troubleshoot a reproducible suspend/resume display problem on an HP Victus 15-fa1xxx.
After suspending with the lid / entering s2idle and then waking the laptop, the internal display often takes 20–30 seconds to return. Sometimes it takes several minutes, and sometimes the display never properly recovers and continues blinking/going black until I reboot.
The system itself appears to resume, but the internal eDP display fails to come back normally.
HARDWARE
Laptop:
HP Victus 15-fa1xxx
CPU:
12th Gen Intel(R) Core(TM) i5-12450H
iGPU:
Intel Alder Lake-P GT1 [UHD Graphics]
PCI ID: 8086:46a3
Driver: i915
dGPU:
NVIDIA GeForce RTX 2050
Driver: nvidia / nvidia-drm
Internal display:
1920x1080
144 Hz
eDP-1
Physically connected to the Intel iGPU
BIOS:
F.23 (03/30/2026)
SOFTWARE
OS:
EndeavourOS / Arch Linux
Desktop:
XFCE
Session:
Wayland
Suspend mode:
s2idle only
Kernels tested:
7.1.11-arch1-1
6.18.48-1-lts
NVIDIA driver:
610.57.04
Current kernel parameters include:
i915.enable_psr=0
i915.enable_dc=0
nvidia-drm.modeset=1
THE PROBLEM
After suspend/resume, the internal eDP display may remain black or blink repeatedly.
The kernel repeatedly reports:
[i915] [drm] ERROR [CONNECTOR:...:eDP-1][ENCODER:...:DDI A/PHY A][DPRX]
Failed to enable link training
The error can repeat roughly every 12 seconds while the display is trying to recover.
I also get this during BOOT, before the desktop is fully running:
[i915] [drm] [ENCODER:...:DDI B/PHY B]
failed to retrieve link info, disabling eDP
Immediately around that boot-time error I also get:
drm_WARN_ON(intel_dp->pps.vdd_wakeref)
WARNING:
intel_pps_vdd_on_unlocked
The call stack points into:
intel_pps_vdd_on_unlocked()
intel_pps_vdd_on()
intel_dp_detect()
intel_display_driver_register()
i915_driver_probe()
After some suspend/resume failures I have also seen:
i915 raw-wakerefs=1 wakelocks=1 on cleanup
and:
intel_runtime_pm_driver_release
WHAT I HAVE TESTED
i915.enable_psr=0
- Did not fix the problem.
- Resume still took around 2.5 minutes on one test.
i915.enable_dc=0
- Did not fix the underlying problem.
- On some cycles it reduced the very long hangs, but the system still took around 25 seconds to recover.
- The kernel still reported the eDP link-training failure.
Tested both kernels:
- linux 7.1.11-arch1-1
- linux-lts 6.18.48-1-lts
- Both reproduce the same basic problem.
Tested 144 Hz vs 60 Hz
- 60 Hz did not solve it.
- One test still resulted in a >10 minute display failure.
Tested NVIDIA runtime power management
- The NVIDIA GPU was successfully put into runtime suspended state.
- The internal panel still failed to resume correctly.
Tested the Intel Xe driver experimentally
- Forced the Intel GPU to Xe with:
i915.force_probe=!46a3 xe.force_probe=46a3
- This did NOT solve the problem.
- Instead I got PSR AUX errors, severe display corruption and another very long/infinite-looking recovery loop.
- I therefore returned to i915.
The laptop only supports s2idle:
cat /sys/power/mem_sleep
returns:
[s2idle]
Attempting "deep" gives:
Invalid argument
IMPORTANT OBSERVATION
The internal display is driven by the Intel iGPU, not directly by the NVIDIA GPU.
The DRM devices show:
card0 -> NVIDIA
card1 -> i915
and the internal connector is:
card1-eDP-1
QUESTION
Has anyone seen this combination on an HP Victus 15-fa1xxx or similar Alder Lake/Raptor Lake HP laptop?
In particular, I'm interested in whether the following messages point to a known i915 PPS / panel-power-sequencing / firmware issue:
failed to retrieve link info, disabling eDP
drm_WARN_ON(intel_dp->pps.vdd_wakeref)
intel_pps_vdd_on_unlocked()
Failed to enable link training
Could this be an HP BIOS/firmware interaction with Intel i915 during s2idle?
Is there a known kernel patch, quirk, or workaround for this particular PPS/VDD wakeref + eDP link-training problem?
I'm especially interested in advice from anyone familiar with i915/eDP/DRM power sequencing or HP Victus hybrid Intel/NVIDIA systems.
I would prefer to fix the underlying suspend/resume problem rather than simply disable suspend or lid handling.
ADDITIONAL ACPI WARNINGS
There are also ACPI BIOS errors in the kernel log, including:
AE_NOT_FOUND involving:
_SB.PC00.CNVW.IFUN
_SB.PC00.CNVW._DSM
and:
AE_AML_BUFFER_LIMIT involving:
_SB.WMID.WQBZ
_SB.WMID.WQBE
I'm not sure whether these are related to the display problem or are unrelated HP WMI/ACPI issues.
Thanks!