[PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)

[PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)

[Marek Czernohous]

Hi,

this is my first patch series for the kernel. I'm running an Apple Mac
Mini with an NVAC (MCP79) chipset and DisplayPort output, and hit three
separate stability issues with the nouveau driver on kernel 6.18.

The patches are independent but together they bring the NVAC from
"needs NvMSI=0 workaround and can't run Wayland" to fully stable
operation with MSI enabled, working DPMS, and functional Wayland
(tested with Weston).

Patch 1: The MSI re-arm function for G94 uses memory-mapped register
access (nv40), which is unreliable on NVAC — the sister chipset NVAA
already has MSI disabled entirely for this reason. Switching to the
PCI config space method (nv46) fixes sporadic FIFO errors and hangs.

Patch 2: nv50_sor_atomic_disable() dereferences nv_encoder->crtc
unconditionally via container_of(). Under Wayland atomic modesetting,
the CRTC can become NULL between check and commit, causing a kernel
crash. Adding a NULL guard fixes Wayland session teardown.

Patch 3: Transient DisplayPort link glitches on NVAC cause unnecessary
disconnect/reconnect cycles. A single 100ms retry in the HPD IRQ
handler catches these without affecting real unplug detection.

All three patches were tested on the same machine (NVAC 0xac080b1,
DP output) over multiple days with DPMS cycling, VT switching, and
Wayland sessions.

Thanks,
Marek

Marek Czernohous (3):
  drm/nouveau/pci: use nv46 MSI rearm for G94 (NVAC/MCP79)
  drm/nouveau/kms: add NULL check for CRTC in nv50_sor_atomic_disable
  drm/nouveau/dp: retry link check once on HPD IRQ before disconnect

 drivers/gpu/drm/nouveau/dispnv50/disp.c       | 8 +++++++-
 drivers/gpu/drm/nouveau/nouveau_display.c     | 4 ++++
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c | 2 +-
 3 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.52.0

[PATCH 1/3] drm/nouveau/pci: use nv46 MSI rearm for G94 (NVAC/MCP79)

[Marek Czernohous]

The G94 PCI function uses nv40_pci_msi_rearm(), which re-arms MSI
interrupts via memory-mapped register access. On NVAC (MCP79/MCP7A)
chipsets this method is unreliable, causing sporadic FIFO errors and
GPU hangs.

The closely related NVAA (MCP77/MCP73) chipset has MSI disabled
entirely in the driver (.msi_rearm is not set), with a comment marking
it as "reported broken". NVAC shares the same integrated GPU
architecture (both are NV50/Tesla family, memory-mapped through the
host bridge) but was not given the same treatment.

Switch to nv46_pci_msi_rearm(), which re-arms MSI via direct PCI
config space access (pci_write_config_byte at offset 0x68). This
method bypasses the memory-mapped register path that is problematic on
these integrated chipsets.

Tested on Apple Mac Mini (MCP79, NVAC 0xac080b1) with DisplayPort
output. System is stable with MSI enabled (no NvMSI=0 workaround
needed), zero FIFO errors observed over extended operation including
DPMS cycles.

Signed-off-by: Marek Czernohous <marek@czernohous.de>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c
index df745d069..9dc28a4bc 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c
@@ -28,7 +28,7 @@ g94_pci_func = {
 	.cfg = { .addr = 0x088000, .size = 0x1000 },
 
 	.init = g84_pci_init,
-	.msi_rearm = nv40_pci_msi_rearm,
+	.msi_rearm = nv46_pci_msi_rearm,
 
 	.pcie.init = g84_pcie_init,
 	.pcie.set_link = g84_pcie_set_link,
-- 
2.52.0

[PATCH 2/3] drm/nouveau/kms: add NULL check for CRTC in nv50_sor_atomic_disable

[Marek Czernohous]

nv50_sor_atomic_disable() calls nv50_head(nv_encoder->crtc) without
checking whether nv_encoder->crtc is NULL. Under Wayland compositors
that use atomic modesetting, a race condition can occur between
atomic_check and atomic_commit: the encoder's CRTC reference may
become NULL after validation but before the disable callback runs.

When this happens, nv50_head() receives a NULL drm_crtc pointer,
and container_of() produces a garbage pointer, leading to a kernel
crash (NULL pointer dereference or page fault).

Add an explicit NULL check for nv_encoder->crtc before dereferencing.
If the CRTC is already gone, release the output resource and return
early — there is nothing left to disable.

Note: checking nv50_head()'s return value would not work here because
container_of(NULL, ...) never returns NULL; the bogus pointer must be
prevented at the source.

Tested on NVAC (MCP79) with Weston --backend=drm. Without this patch,
switching VTs or closing a Wayland session triggers a kernel oops.
With this patch, Wayland session teardown and DPMS cycles are stable.

Signed-off-by: Marek Czernohous <marek@czernohous.de>
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6c3a8712d..42080874a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1565,7 +1565,13 @@ static void
 nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
 	struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-	struct nv50_head *head = nv50_head(nv_encoder->crtc);
+	struct nv50_head *head;
+
+	if (!nv_encoder->crtc) {
+		nvif_outp_release(&nv_encoder->outp);
+		return;
+	}
+	head = nv50_head(nv_encoder->crtc);
 #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
 	struct nouveau_connector *nv_connector = nv50_outp_get_old_connector(state, nv_encoder);
 	struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
-- 
2.52.0

[PATCH 3/3] drm/nouveau/dp: retry link check once on HPD IRQ before disconnect

[Marek Czernohous]

On NV50/G94-family chipsets with DisplayPort, transient link glitches
can trigger an HPD IRQ where the first nouveau_dp_link_check() fails
momentarily. The driver then falls through to connector status
re-detection, treating it as a disconnect event. This causes a brief
display blackout followed by a re-plug, which is disruptive under
both X11 and Wayland.

Add a single retry with a 100ms delay before giving up on the link.
DisplayPort link training typically completes within a few
milliseconds; 100ms is generous enough to cover worst-case
re-negotiation on older hardware without adding perceptible latency
for genuine unplug events.

The retry is bounded (exactly one attempt) and only applies to the
IRQ path — plug/unplug events are not affected.

Tested on NVAC (MCP79) with DisplayPort output over extended DPMS
on/off cycles. Without this patch, occasional display flickers were
observed after DPMS resume. With this patch, all DPMS transitions are
clean.

Signed-off-by: Marek Czernohous <marek@czernohous.de>
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index d71dcfc6e..b6e40794b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -465,6 +465,10 @@ nouveau_display_hpd_work(struct work_struct *work)
 		if (bits & NVIF_CONN_EVENT_V0_IRQ) {
 			if (nouveau_dp_link_check(nv_connector))
 				continue;
+			/* Retry once after 100ms for transient DP glitches (NV50/G94) */
+			msleep(100);
+			if (nouveau_dp_link_check(nv_connector))
+				continue;
 		}
 
 		connector->status = drm_helper_probe_detect(connector, NULL, false);
-- 
2.52.0

Re: [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A) -- 3 weeks soak report

[Marek Czernohous]

Hi,

just a soak-test follow-up on this series (submitted 2026-04-09).

The three patches have been running on my Mac mini (Late 2009), MCP79
chipset with the integrated GeForce 9400M / NVAC, as my daily-driver
graphics stack across 17 reboots on the patched kernels (14 boots on
v6.18.18 and 3 boots on v6.18.22) since 2026-04-09. No regressions and
no new failure modes attributable to the series:

  - No FIFO errors (PATCH 1/3, nv46 MSI rearm)
  - No NULL deref under labwc/Wayland atomic modesetting (PATCH 2/3,
    CRTC NULL check)
  - No spurious DisplayPort disconnects on HPD IRQ glitches (PATCH 3/3,
    DP retry link check)

Regards,
Marek

Re: [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)

[Fab Stz]

Hello Marek,

I have a very similar device iMac9.1, also with MCP79

03:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 [GeForce 9400] [10de:0867] (rev b1)

I'm facing various issues, including the bug below

https://lore.freedesktop.org/nouveau/b7f523dc-fe41-4514-a1a5-747005311cbe@yahoo.fr/T/#u

Do you think your patch would fix this? Would it apply also to kernel 6.12 or does it depend on some new changes in 6.18.

Regards
Fab


Le 09/04/2026 à 17:09, Marek Czernohous a écrit :
> Hi,
> 
> this is my first patch series for the kernel. I'm running an Apple Mac
> Mini with an NVAC (MCP79) chipset and DisplayPort output, and hit three
> separate stability issues with the nouveau driver on kernel 6.18.
> 
> The patches are independent but together they bring the NVAC from
> "needs NvMSI=0 workaround and can't run Wayland" to fully stable
> operation with MSI enabled, working DPMS, and functional Wayland
> (tested with Weston).
> 
> Patch 1: The MSI re-arm function for G94 uses memory-mapped register
> access (nv40), which is unreliable on NVAC — the sister chipset NVAA
> already has MSI disabled entirely for this reason. Switching to the
> PCI config space method (nv46) fixes sporadic FIFO errors and hangs.
> 
> Patch 2: nv50_sor_atomic_disable() dereferences nv_encoder->crtc
> unconditionally via container_of(). Under Wayland atomic modesetting,
> the CRTC can become NULL between check and commit, causing a kernel
> crash. Adding a NULL guard fixes Wayland session teardown.
> 
> Patch 3: Transient DisplayPort link glitches on NVAC cause unnecessary
> disconnect/reconnect cycles. A single 100ms retry in the HPD IRQ
> handler catches these without affecting real unplug detection.
> 
> All three patches were tested on the same machine (NVAC 0xac080b1,
> DP output) over multiple days with DPMS cycling, VT switching, and
> Wayland sessions.
> 
> Thanks,
> Marek
> 
> Marek Czernohous (3):
>    drm/nouveau/pci: use nv46 MSI rearm for G94 (NVAC/MCP79)
>    drm/nouveau/kms: add NULL check for CRTC in nv50_sor_atomic_disable
>    drm/nouveau/dp: retry link check once on HPD IRQ before disconnect
> 
>   drivers/gpu/drm/nouveau/dispnv50/disp.c       | 8 +++++++-
>   drivers/gpu/drm/nouveau/nouveau_display.c     | 4 ++++
>   drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c | 2 +-
>   3 files changed, 12 insertions(+), 2 deletions(-)
> 

Re: [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)

[Marek Czernohous]

Hi Fab,

Thanks for reaching out.

On the crash you linked (gitlab #443): I had a careful look and I don't
think this series will fix that one. The oops is in nouveau_fence_sync(),
on the TTM buffer-eviction / nouveau_bo_move() path, hit while a renderer
process allocates a GEM buffer and the IGP runs out of instance memory
(the "imem: OOM ... -28" line right before it). My patches are all
elsewhere:

  1/3 swaps the MSI re-arm method (interrupt delivery / FIFO stability).
  2/3 adds a NULL check in nv50_sor_atomic_disable() (display-encoder
      teardown). That is also a NULL deref, but in the modeset path, not
      the fence/BO path, so it is a different bug.
  3/3 retries a DisplayPort link check on an HPD IRQ.

None of them touch nouveau_fence.c or nouveau_bo.c, so they won't help
that specific crash, and I didn't want to give you false hope. For #443
itself, the fence/eviction code was reworked quite a bit after 6.12
(around 6.15/6.16), so the most useful next step is probably to check
whether a current kernel (6.15+ or 6.18) still reproduces it, and if so
attach a fresh oops to the gitlab issue. That part of the driver is
outside what I work on, so the maintainers there are better placed than I
am to chase it.

Where the series might actually help you is if you also see any of these,
which is exactly what it targets:

  - sporadic FIFO errors / hangs that you work around with NvMSI=0
    (nouveau.config=NvMSI=0)                  -> patch 1/3
  - a kernel oops in nv50_sor_atomic_disable() when ending a Wayland
    session or switching VTs                  -> patch 2/3
  - DisplayPort flicker or a brief blackout after DPMS / monitor wake
                                              -> patch 3/3

It was developed on 6.18 but does not depend on anything 6.18-only, so it
is easy to try on 6.12:

  - Patches 2/3 and 3/3 apply to 6.12 as-is.
  - Patch 1/3 needs a one-line manual edit, because the g94_pci_func
    struct was reorganised between 6.12 and 6.18. The change is identical:
    in drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.c set
        .msi_rearm = nv46_pci_msi_rearm,
    instead of nv40_pci_msi_rearm. nv46_pci_msi_rearm already exists in
    6.12, so that single line is the whole change.

If you give them a try and they help with the MSI or display symptoms, I
would be glad to hear back. A Tested-by on the list would also genuinely
help the case for getting these merged.

Regards,
Marek

(Disclosure: drafted with help from an AI assistant, Claude; conclusions
are mine and verified.)

Re: [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)

[Fab Stz]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Hello Marek,

I applied your patches 0001 to 0005 (taken from [1] commit 471ee25) to 6.12.90 (BTW I never used the nouveau.config=NvMSI=0 kernel parameter).

System boots well and Xorg is running fine until now (I don't use wayland). There are still some graphic glitches when closing/opening windows (on KDE6, compositor enabled), but system seems stable (more than without your patches).

I tried to make it crash like in [3] but couldn't reproduce it yet.

With mesa 25.0.7, I don't have any nouveau error outputted by dmesg. With mesa 26.0.8 however I have multiple errors (see attachments).

Would it be possible to add the tag that would permit your patches to enter also the previous stable (longterm) versions of the kernel? IIRC it's by adding something like "Cc: All applicable <stable@vger.kernel.org>" to the commit description. [2] states:

If you are fixing a bug, think about whether the fix should go into the next stable update. If so, stable@vger.kernel.org should get a copy of the patch. Also add a “Cc: stable@vger.kernel.org” to the tags within the patch itself; that will cause the stable team to get a notification when your fix goes into the mainline.

Thanks for your work !! Hopefully I can use the iMac9,1 without fearing a kernel crash because of the graphic driver.
BTW, it seems your Macmini3,1 is a "early 2009" device as written here [4], and note "late 2009".

[1] https://github.com/hibbes/nouveau-nvac-patches
[2] https://docs.kernel.org/process/5.Posting.html
[3] https://lore.freedesktop.org/nouveau/b7f523dc-fe41-4514-a1a5-747005311cbe@yahoo.fr/T/#u
[4] https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-2-duo-2.0-early-2009-nvidia-specs.html

Regards
Fab

[-- Attachment #2: kernel-6.12.90-withNouveauPatches1to5-mesa-26.0.8-CSM-boot.log.gz --]
[-- Type: application/gzip, Size: 18256 bytes --]

[-- Attachment #3: kernel-6.12.90-withNouveauPatches1to5-mesa-26.0.8-EFI-boot.log.gz --]
[-- Type: application/gzip, Size: 20342 bytes --]