DDC/CI over DisplayPort AUX channel becomes unusable after a single write transaction or after brief inactivity (RTX 3050 / Ampere, open kernel module 610.43.02)

NVIDIA Open GPU Kernel Modules Version

Driver: 610.43.02, open kernel module (nvidia-open)

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

CachyOS (Arch-based)

Kernel Release

Linux 7.0.11-1-cachyos

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

NVIDIA GeForce RTX 3050 (Ampere)

Describe the bug

Summary

On an RTX 3050 (Ampere) using the open kernel module 610.43.02, DDC/CI communication over a DisplayPort-connected monitor exhibits two distinct, reproducible failure modes:

1. Inactivity timeout — after a successful read, the I2C/DDC channel becomes unresponsive within a few seconds if no further I2C traffic occurs. A periodic read keeps it alive.
2. Write kills the channel — a single DDC write (e.g. setting brightness via VCP 0x10) completes successfully (the monitor visibly changes and a follow-up read confirms the new value), but immediately afterward the channel is dead, even if a keep-alive read loop was active.
   In both cases the only reliable way to restore the channel is to physically disconnect and reconnect the DisplayPort cable. A normal OS reboot is not sufficient to recover a channel that has entered the dead state.

Reads (EDID, VCP getvcp) on their own do not trigger the failure; only inactivity or a write does.

This is reproduced entirely with ddcutil talking directly to the kernel i2c-dev interface, so it is independent of any out-of-tree DDC driver.

System information

• GPU: NVIDIA GeForce RTX 3050 (Ampere)
• Driver: 610.43.02, open kernel module (nvidia-open)
• Driver userspace: matching nvidia-utils 610.43.02
• Kernels tested (both affected):
  • 6.18.33 (LTS)
  • 7.0.11
• Distro: CachyOS (Arch-based)
• Desktop / session: GNOME 50 on Wayland (Mutter)
• Connection: DisplayPort (DP-to-DP cable, native DP at both ends)
• Monitor: LG 27GS60F-B (reported as LG ULTRAGEAR, EDID mfg id GSM), DDC/CI / MCCS 2.1
• CPU: Intel Core i3-9100F (no iGPU — single-GPU desktop, no hybrid/Optimus/PRIME involved)
• Tooling: ddcutil 2.2.7
  The I2C adapter exposed by the driver for this connector is reported by ddcutil as:

I2C bus:        /dev/i2c-2
DRM_connector:  card1-DP-1
/sys/bus/i2c/devices/i2c-2/name:  NVIDIA i2c adapter 6 at 1:00.0

To Reproduce

Steps to reproduce

Prerequisite: a DisplayPort monitor that supports DDC/CI, ddcutil installed, and the user with read/write access to /dev/i2c-* (member of group i2c). i2c-dev is loaded.

Channel works immediately after a fresh DP connect

$ ddcutil detect
Display 1
   I2C bus:  /dev/i2c-2
   DRM_connector:           card1-DP-1
   EDID synopsis:
      Mfg id:               GSM - LG Electronics
      Model:                LG ULTRAGEAR
   VCP version:         2.1

Failure Mode 1 — channel dies after brief inactivity

$ ddcutil detect          # succeeds
# wait ~5–10 seconds with no I2C traffic
$ ddcutil detect
No displays found.

A periodic read keeps the channel alive indefinitely:

$ watch -n 2 ddcutil getvcp 10   # channel stays responsive as long as this runs

Failure Mode 2 — a single write kills the channel

Reconnect the DP cable to restore the channel first, then:

$ ddcutil setvcp 10 80 && ddcutil setvcp 10 30 && ddcutil detect
# all three commands succeed; monitor brightness physically changes
Display 1
   ...
   VCP version:         2.1
 
# immediately afterward:
$ ddcutil detect
No displays found.

Notes on the write behavior:

• Several commands chained back-to-back (&&, no pause) all complete; the channel only enters the dead state after the sequence settles.
• The write genuinely reaches the hardware: the panel brightness visibly changes, and a getvcp 10 issued in the same uninterrupted burst returns the newly written value.
• A write kills the channel even when a keep-alive read loop is running, which is what distinguishes Failure Mode 2 from Failure Mode 1.

Recovery

• Physically unplugging and replugging the DisplayPort cable reliably restores a working channel.
• A full OS reboot does not reliably recover a channel that is already in the dead state; the physical re-handshake on the AUX channel appears to be what resets it.

What was investigated / ruled out

• Not an out-of-tree driver issue. The failure reproduces with ddcutil over i2c-dev alone, with no DDC kernel driver bound to the bus.
• Not kernel-version specific. Identical behavior on 6.18.33 LTS and 7.0.11, with the same driver.
• Not hybrid graphics. This is a single-GPU desktop with an "F" CPU (no integrated graphics), so there is no Optimus/PRIME buffer hand-off in play.
• RMUseSwI2c does not help. The legacy workaround was applied and confirmed active:

  $ cat /etc/modprobe.d/nvidia-ddc.conf
  options nvidia NVreg_RegistryDwords="RMUseSwI2c=0x01;RMI2cSpeed=100"
 
  $ grep RegistryDwords /proc/driver/nvidia/params
  RegistryDwords: "RMUseSwI2c=0x01;RMI2cSpeed=100"

With it set, both failure modes still occur (forcing software I2C and RMI2cSpeed=100 changes nothing observable here).

• Monitor-side quirks are separate. This particular panel returns a bad checksum on the 4th capabilities chunk (offset 0x60) when reading the full MCCS capability string, which is a monitor/firmware issue and orthogonal to the channel-death described here — the channel-death is observed with plain getvcp/setvcp/detect, not just during capability reads.

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log

More Info

Hypotheses (for triage — not confirmed)

The observed pattern is consistent with the DP-AUX I2C channel not being kept in a usable state between transactions:

• Failure Mode 1 looks like the AUX/I2C channel being torn down or going to a low-power state after a short idle period, with no transparent re-establishment on the next access.
• Failure Mode 2 looks like the post-write transaction cleanup leaving the channel in an inconsistent state (the write itself succeeds end-to-end, but the channel is not returned to a state that accepts the next transaction).
  Because both can be worked around at the physical layer (cable replug) but not at the OS layer (reboot), the residual state appears to live below the OS — in the driver's AUX/I2C handling and/or GSP firmware.

The relevant I2C handling lives in kernel-open/nvidia/nv-i2c.c. It is worth noting that this file's transaction handler explicitly only supports a narrow set of operations (the code carries a comment to the effect of "we only support basic I2C reads/writes, reject any other commands"), and prior driver-side I2C bugs have been traced to that handler — see "Related" below.

Related

This may share a root area with previously reported NVIDIA I2C transaction-handling problems, even though the symptom is different:

• #41 ("NVIDIA I2C driver issues") — a long-standing driver-side I2C bug where reads worked but certain write transactions were mishandled (block transfers interpreted as word transfers / data read off by one byte). It was eventually fixed driver-side in R565 (565.57.01), then reportedly regressed again on at least one later branch. The pattern there — reads fine, writes mishandled, fix lives in the driver's I2C layer rather than in userspace — is the same shape as what is described here, which is why the I2C transaction path in nv-i2c.c seems like the right place to look.
  The present report is distinct from #41 (it is about the DDC/DisplayPort-AUX channel becoming unusable after a write or after inactivity, not about write payloads being corrupted), but they may stem from the same component.

Additional notes

• Happy to provide nvidia-bug-report.sh output on request.
• Happy to test against a specific driver build or a proprietary (closed) module of the same version to confirm whether the failure is specific to the open kernel module path.
• Reproduction is 100% consistent on this setup.
• This report has also been sent to linux-bugs@nvidia.com for internal triage, as suggested for I2C-related issues in prior threads.

nvidia-bug-report.log.gz

The report identifies kernel-open/nv-i2c.c as the relevant transaction path. Start by reproducing both failure modes with ddcutil detect, getvcp, and setvcp over the listed DisplayPort setup, then inspect how the handler manages inactivity and completed writes. Done means both cases remain usable without a cable reconnect, with the reported read and write behavior validated again.