Re: [PATCH] drm/nouveau/disp: Prevent division-by-zero during DisplayPort link training transitions

[lyude]

Hi, can you please clarify whether or not you used generative AI for
this patch series? If so, this needs to be noted as part of the commit
message. Additionally, both of these patches look to be identical
except that one prints a message and the other doesn't. You can just
send a single version, we will figure out how to handle that part
after.

On Thu, 2026-07-16 at 16:55 +0200, Arjan Filius wrote:
> Dear Nouveau Maintainers,
>  
> Please find below a proposed patch to prevent a division-by-zero
> kernel oops and subsequent lockup in the Nouveau display supervisor
> engine when DisplayPort links transition to 0 active lanes. This bug
> was observed and patched/tested against the mainline kernel version
> **7.1.3**, but is present in all current upstream code.
>  
> ---
>  
> ### BRIEF EXPLANATION
>  
> During screen sleep transitions or multi-input display switches (KVM
> switching), the active lane count of a DisplayPort link can
> temporarily drop to 0 (`ior->dp.nr == 0`). 
>  
> When this occurs, the DisplayPort supervisor function
> `nv50_disp_super_2_2_dp` is invoked via modeset interrupts. Without
> an early-exit guard, the function attempts to perform symbols/hblank
> and link rate calculations that divide by `ior->dp.nr`, resulting in
> a kernel division-by-zero math exception, lockup, and system freeze.
>  
> This patch adds an early-exit check at the beginning of
> `nv50_disp_super_2_2_dp` to abort display configuration when the link
> training lanes count is zero.
> 
> *   **Tested Kernel Version:** `7.1.3` (mainline stable branch)
> 
> ---
> 
> ### EXTREMELY DETAILED TECHNICAL BREAKDOWN
> 
> #### 1. Hardware Context
> This bug has been consistently reproduced on a Lenovo ThinkPad T430
> (Intel HD 4000 + discrete NVIDIA NVS 5400M / GF108 chipset) connected
> to a Lenovo ThinkPad Mini Dock Plus Series 3 (Model 4338) with dual
> external monitors on dock DisplayPorts (`DP-2` and `DP-3`). 
> 
> #### 2. Root Cause Analysis (Code Level)
> Inside `drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c`, when `ior-
> >dp.nr == 0`, the driver executes the following lines in
> `nv50_disp_super_2_2_dp()`:
> 
> *   **Line 1179:** Calculations for horizontal blank symbols:
>     ```c
>     h = h - (3 * ior->dp.ef) - (12 / ior->dp.nr);
>     ```
> *   **Line 1185:** Calculations for vertical blank symbols:
>     ```c
>     v = v - ((36 / ior->dp.nr) + 3) - 1;
>     ```
> *   **Line 1190:** Calculations for active link data rate:
>     ```c
>     link_data_rate = (khz * head->asy.or.depth / 8) / ior->dp.nr;
>     ```
> 
> In all three instances, the denominator `ior->dp.nr` is `0`, causing
> an immediate kernel math exception in the display workqueue
> (`nouveau_display_hpd_work` or `nv50_disp_super`), locking up the
> graphics pipeline, freezing the screen, and hanging any reboot
> attempts (requiring a physical hard reset).
> 
> #### 3. Daily Workday Trigger Scenario
> 1.  The T430 (via dock) and a secondary workstation are both
> connected to different inputs on the same external monitors.
> 2.  The monitors' input sources are switched to the secondary
> workstation.
> 3.  At the end of the day, the secondary workstation goes to sleep or
> is shut down.
> 4.  With no active inputs, the external monitors enter power-saving
> standby mode.
> 5.  When the user subsequently wakes up or interacts with the T430,
> the driver attempts a modeset refresh. Since the monitors are asleep
> and inputs are switched away, the lanes count is read as `0`,
> triggering the division-by-zero oops.
> 
> #### 4. Stack Trace (Oops Log)
> ```text
> [di jul 23 10:28:25 2024] nouveau 0000:01:00.0: DRM: DDC responded,
> but no EDID for DP-2
> [di jul 23 10:28:25 2024] nouveau 0000:01:00.0: DRM: DDC responded,
> but no EDID for DP-3
> [di jul 23 10:28:26 2024] Workqueue: nvkm-disp nv50_disp_super
> [nouveau]
> [di jul 23 10:28:26 2024] RIP: 0010:nv50_disp_super_2_2_dp+0xa7/0x320
> [nouveau]
> [di jul 23 10:28:26 2024]  ? nv50_disp_super_2_2_dp+0xa7/0x320
> [nouveau]
> [di jul 23 10:28:26 2024]  nv50_disp_super_2_2+0xf2/0x160 [nouveau]
> [di jul 23 10:28:26 2024]  nv50_disp_super+0x139/0x280 [nouveau]
> ```
> 
> #### 5. Verification Proof (Bypass Log)
> With the patch applied and running on kernel `7.1.3-custom #2`, the
> screen standby transition was bypassed cleanly. The driver caught the
> lane count of 0, bypassed display configuration, and proceeded to put
> the graphics chip into its low-power runtime suspend state
> (`suspended`) without locking up the OS:
> ```text
> [45162.232371] nouveau 0000:01:00.0: disp: DP link is inactive (lanes
> = 0), skipping display configuration.
> [45162.232402] nouveau 0000:01:00.0: disp: DP link is inactive (lanes
> = 0), skipping display configuration.
> [45178.605627] nouveau 0000:01:00.0: timeout
> [45178.605629] WARNING: nv50_disp_dmac_fini+0x168/0x1c0 [nouveau]
> [45180.608524] nouveau 0000:01:00.0: disp: ch 1 fini timeout,
> 8e061008
> [45182.608521] nouveau 0000:01:00.0: timeout
> [45182.608523] WARNING: nv50_disp_core_fini+0x143/0x190 [nouveau]
> ```
> 
> ---
> 
> Signed-off-by: Arjan Filius <iafilius@xxxxxxxxx>
> ---
> 
> ### CHOOSE ONE OF THE PATCH OPTIONS BELOW TO APPEND:
> 
> #### OPTION A: The Silent Production Patch (RECOMMENDED FOR UPSTREAM)
> *Note: Kernel maintainers generally reject warnings or print spam for
> expected hardware sleep/disconnect transitions. A silent return is
> the preferred upstream pattern.*
> 
> ```diff
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> index 51c045bdfcbb..ab1bc0898def 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> @@ -1157,6 +1157,10 @@ nv50_disp_super_2_2_dp(struct nvkm_head *head,
> struct nvkm_ior *ior)
>  {
>  	struct nvkm_subdev *subdev = &head->disp->engine.subdev;
>  
> +	/* If the DisplayPort link is inactive (0 lanes), skip
> configuration */
> +	if (ior->dp.nr == 0)
> +		return;
> +
>  	const u32 khz = head->asy.hz / 1000;
>  	const u32 linkKBps = ior->dp.bw * 27000;
>  	const u32 symbol = 100000;
> ```
> 
> #### OPTION B: The Warning/Verbose Patch (What was tested locally)
> *Note: Prints warning logs to the kernel buffer for validation and
> troubleshooting.*
> 
> ```diff
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> index 51c045bdfcbb..ab1bc0898def 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
> @@ -1157,6 +1157,12 @@ nv50_disp_super_2_2_dp(struct nvkm_head *head,
> struct nvkm_ior *ior)
>  {
>  	struct nvkm_subdev *subdev = &head->disp->engine.subdev;
>  
> +	/* If the DisplayPort link is inactive (0 lanes), skip
> configuration */
> +	if (ior->dp.nr == 0) {
> +		nvkm_warn(subdev, "DP link is inactive (lanes = 0),
> skipping display configuration.\n");
> +		return;
> +	}
> +
>  	const u32 khz = head->asy.hz / 1000;
>  	const u32 linkKBps = ior->dp.bw * 27000;
>  	const u32 symbol = 100000;
> ```