Where it all Started
I just joined the linux cult last year by dual booting into ubuntu 24.10 and it had been going good so far,but one issue was keep bugging me , there was this error screen that showed whenever i sit to work in my laptop .
At first it just delayed the system by few seconds,but after some time it really started getting really annoying ,Even my friends started calling it as my loading screen.
I had no idea what any of this meant. I just knew my laptop was slow to wake up and something was clearly wrong with the display driver.
Diagnosing the Errors
After two to three months(ik i was lazy) or so i had enough of this and starting google asking gpts for all sorts of fixes , but nothing worked.
Before moving i would like to give a brief of the problem i was facing . First of all it was related to i915 kernel Driver
But What Is the i915 Driver?
The i915 is the Linux kernel driver for Intel graphics. It manages everything related to your Intel GPU — rendering, power management, display output. On my HP Victus (Intel Raptor Lake + NVIDIA RTX 3050), the Intel GPU handles the internal display (eDP — embedded DisplayPort).
When something goes wrong with the display during suspend/resume, i915 is usually involved.
With all this knowledge and after some research, I filed a detailed bug report on the freedesktop GitLab issue tracker with my hardware details, dmesg output, and a description of the symptoms.
The dmesg (diagnostic message) command is used in Linux to examine and control the kernel ring buffer, which stores low-level messages related to hardware initialization, device drivers, and system diagnostics
This got the attention of Arun Raghavendra Murthy, an Intel kernel developer, who started guiding me through the debugging process.
The Beginning of the new journey:
He asked to share dmesg logs with drm.debug=0xe enabled. This required:
- Adding kernel parameters to GRUB
- Triggering the bug (closing and opening the lid)
- Capturing the full kernel log
drm.debug=0xe is a Linux kernel boot parameter that enables specific categories of debug logging for the Direct Rendering Manager (DRM) graphics subsystem.
I also ran sleepgraph — an Intel tool that creates a visual timeline of the suspend/resume process. It revealed something significant:
Kernel Suspend Time: 3170 ms
Kernel Resume Time: 33337 ms ← 33 second stall!
And i915 was the only device with an abnormal suspend time — 35ms vs 0.001ms for everything else.
After i went to build the drm-tip kernel to share the dmesg logs and to check if the tip version had already fixed this issue.
This ran into few struggles as i had no space in my linux system and used GParted to resize my partition to make up the space for it.
And several failed attempts (running out of disk space, Secure Boot issues, DKMS failures), I got it working.
After that Arun submitted a patch :
[PATCHv3] drm/i915/dp: On DPCD init wake the DPRx for eDP
This patch added a function to wake the display sink before attempting link training. After testing, link training started passing — but a different warning persisted:
i915 raw-wakerefs=1 wakelocks=1 on cleanup
WARNING: intel_runtime_pm.c:522
One problem partially fixed, another still present.
The ref_tracker Breakthrough
Arun sent a debug patch that added wakeref tracking — a way to record who grabs each power reference and whether they release it. After building a full kernel (not just the i915 module) with debug configs enabled:
CONFIG_DRM_I915_DEBUG=y
CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y
CONFIG_DRM_I915_DEBUG_WAKEREF=y
CONFIG_STACKDEPOT=y
After a suspend/resume cycle, the log finally revealed:
ref_tracker: intel_runtime_pm has 1/1 users at:
intel_display_power_get
pps_vdd_init ← wakeref grabbed HERE at boot!
intel_pps_init
intel_dp_init_connector
intel_ddi_init
intel_bios_for_each_encoder
intel_setup_outputs
i915_driver_probe ← during driver initialization
The wakeref was grabbed at boot time during driver initialization — and never released before suspend.
Understanding the Root Cause
Here's what was happening in plain English:
When Linux boots, the Intel display driver (i915) initializes your screen. During this process, a function called pps_vdd_init() notices that the BIOS left the panel power (VDD) on. It grabs a wakeref — think of it as a key that says "I am using this power, don't turn it off."
The code comment even says:
/* grab this reference and schedule a vdd off,
so we don't hold on to the reference indefinitely */
But here's the bug. Later, when intel_pps_vdd_on_unlocked() tries to turn VDD on again, it checks the hardware register (edp_have_panel_vdd()). But by this time, something — DC states, DMC firmware, or the BIOS — had already reset that hardware bit, even though the software wakeref was still held.
/* OLD CODE */
drm_WARN_ON(display->drm, intel_dp->pps.vdd_wakeref); ← warning fires
intel_dp->pps.vdd_wakeref = intel_display_power_get(...);← OVERWRITES old wakeref!
It grabbed a new wakeref and overwrote the old one — orphaning the original wakeref from boot. That orphaned wakeref was never released, causing the warning at every suspend.
The Fix
Arun's v2 patch fixed this elegantly:
/* NEW CODE */
if (!intel_dp->pps.vdd_wakeref)
intel_dp->pps.vdd_wakeref =
intel_display_power_get(display,
intel_aux_power_domain(dig_port));
Only grab a new wakeref if we don't already have one. If the software already holds a reference, reuse it — don't overwrite and orphan it.
The hardware VDD bit is then re-asserted either way. This makes vdd_wakeref the single source of truth, regardless of what the hardware register shows.
Confirming the Fix
After building and installing the patched kernel, I tested across 3 suspend/resume cycles:
Before:
i915 raw-wakerefs=1 wakelocks=1 on cleanup
WARNING: intel_runtime_pm.c:531
After:
[DPRX] Link Training passed
(no warnings)
Zero warnings. Three times in a row. Bug fixed.
Now seeing this for first time was something else.I was behind this bug for 2 months and just seeing "Link Training Passed" was not at all in my to-do list.
What I Learned:
Technically:
- How Linux manages hardware power through wakerefs
- How the Intel i915 display driver initializes and manages eDP panels
- How to use sleepgraph, drm.debug, and ref_tracker for kernel debugging
- How to build, install, and test custom kernels
- How kernel patches are formatted and submitted
About Open Source:
- Real kernel developers are approachable and responsive to well-documented bug reports
- The hardest part isn't writing code — it's collecting the right diagnostic data
- A detailed bug report with logs is often more valuable than a patch
About Persistence:
- This took months of on-and-off debugging
- Most attempts led to dead ends — wrong code paths, OOT module limitations, disk space issues
- Every piece of data collected narrowed down the problem
I know most of them left halfway through this , but if you reading this i want to say that Open source isn't about solving everyone's problem but trying to solve your problems.It is about sharing contributions to things you use so that others can use and benefit from them.
Recommendation: Watch this to understand what open source truly is.
The best way to contribute to the Linux kernel is to start with a bug that affects your own hardware. You have the hardware to reproduce it, you feel the pain, and you have the motivation to see it fixed.
Getting a "Tested By" in the vast sea of linux community is itself a huge achievement.It's a small credit but a real one — permanently in the Linux kernel git log.Hoping to get it soon.
Resources That Helped Me
kernelnewbies.org — best starting point for kernel contribution
Elixir Cross Referencer — browse kernel source with clickable links
freedesktop GitLab— where i915 development happens
pm-graph/sleepgraph — Intel's suspend/resume analysis tool
drm.debug=0xe kernel parameter — enables verbose DRM logging
Special thanks to Arun Raghavendra Murthy (Intel) for
the patience and guidance throughout this process.
This fix wouldn't exist without him.
This is my first post and not have any experience on writing any vlogs,but we all have to start somewhere right, so I would love to hear your suggestions and opinions on this vlogs and what i do to improve this
Top comments (0)