Re: [PATCH] drm/i915/vrr: partial revert of dda7dcd9da73c5327aef42b89f0519bb51e84217

[Benjamin Tissoires]

On Feb 20 2026, Nautiyal, Ankit K wrote:
> 
> On 2/18/2026 9:53 PM, Benjamin Tissoires wrote:
> > Commit dda7dcd9da73 ("drm/i915/vrr: Use fixed timings for platforms that
> > support VRR") introduced a regression on my Ice Lake laptop with an Iris
> > Plus G7.
> > 
> > The screen can go blank (screen lock or just idle), but if I try to wake
> > it up, there is an immediate kernel lock. The netconsole was really
> > unhelpful here, and a bisect gave me the commit above to be the culprit.
> > 
> > For reference, the netconsole I could get was:
> > [  103.553110] netconsole: network logging started
> > [  125.642395] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: ba00000011000402
> > [  125.642400] mce: [Hardware Error]: RIP !INEXACT! 33:<00007fa4471665ec>
> > [  125.642403] mce: [Hardware Error]: TSC 38282e339d
> > [  125.642404] mce: [Hardware Error]: PROCESSOR 0:706e5 TIME 1771365482 SOCKET 0 APIC 0 microcode ca
> > [  125.642406] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
> > [  125.642406] mce: [Hardware Error]: Machine check: Processor context corrupt
> > [  125.642407] Kernel panic - not syncing: Fatal machine check
> > [  125.642415] Kernel Offset: 0x1d400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> > 
> > and then the backtrace lead to the netconsole in itself.
> > 
> > If I restore the early return when vmin >= vmax (in my case vmin==vmax),
> > then I can use my machine again after it goes idle.
> > 
> > I have strictly no ideas if this is the correct solution, so please take
> > this with a grain of salt, but this is effectively preventing me to use
> > distro kernel since v6.16.
> 
> 
> Hi Benjamin,
> 
> Thanks for bisecting and getting the problematic commit.
> 
> This seem to be an issue while trying to fill few VRR related stuff. Your
> change effectively makes an early return from the
> intel_vrr_compute_config(), probably avoiding setting those VRR related
> parameters in sw state.
> 
> To understand the issue better and to debug further I request you to file a
> bug for i915 in gitlab [1] . More details in [2].
> 
> Also request you to test with the latest drm-tip : [3], and attach the logs
> from boot. The link [2] has the necessary details.

Both done:
- drm-tip still shows the crash
- issue filed at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15777

Sorry for not coming back earlier, got my plate full this week.

Cheers,
Benjamin

> 
> 
> Links:
> 
> [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues
> 
> [2] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
> 
> [3] https://gitlab.freedesktop.org/drm/tip/-/commits/drm-tip
> 
> 
> Thanks & Regards,
> 
> Ankit
> 
> 
> 
> > 
> > Signed-off-by: Benjamin Tissoires <bentiss@xxxxxxxxxx>
> > ---
> > I've been experiencing this bug since kernel v6.16.
> > 
> > System Information
> >          Manufacturer: Dell Inc.
> >          Product Name: XPS 13 7390 2-in-1
> > 
> > cpu: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > 
> > lspci:
> > 00:00.0 Host bridge [0600]: Intel Corporation Ice Lake-LP Processor Host Bridge/DRAM Registers [8086:8a12] (rev 03)
> > 	Subsystem: Dell Device [1028:08b0]
> > 	Flags: bus master, fast devsel, latency 0, IOMMU group 2
> > 	Capabilities: <access denied>
> > 	Kernel driver in use: icl_uncore
> > 
> > 00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Plus Graphics G7 [8086:8a52] (rev 07) (prog-if 00 [VGA controller])
> > 	DeviceName: To Be Filled by O.E.M.
> > 	Subsystem: Dell Device [1028:08b0]
> > 	Flags: bus master, fast devsel, latency 0, IRQ 188, IOMMU group 1
> > 	Memory at 603d000000 (64-bit, non-prefetchable) [size=16M]
> > 	Memory at 4000000000 (64-bit, prefetchable) [size=256M]
> > 	I/O ports at 4000 [size=64]
> > 	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
> > 	Capabilities: <access denied>
> > 	Kernel driver in use: i915
> > 	Kernel modules: i915
> > 
> > Again, I have really no idea if this is the correct fix, but it would be
> > nice if the issue could be solved in v7.0 and backported to older
> > kernels.
> > 
> > Please tell me if I need to provide more information.
> > 
> > Cheers,
> > Benjamin
> > ---
> >   drivers/gpu/drm/i915/display/intel_vrr.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index b92c42fde937..3d16dd4611d9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -377,6 +377,9 @@ intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> >   		vmax = vmin;
> >   	}
> > +	if (vmin >= vmax)
> > +		return;
> > +
> >   	if (crtc_state->uapi.vrr_enabled && vmin < vmax)
> >   		intel_vrr_compute_vrr_timings(crtc_state, vmin, vmax);
> >   	else if (is_cmrr_frac_required(crtc_state) && is_edp)
> > 
> > ---
> > base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
> > change-id: 20260218-wip-fix-iris-plus-28a916221bdc
> > 
> > Best regards,