dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Czernohous <mczernohous@gmail.com>
To: Fab Stz <fabstz-it@yahoo.fr>
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A)
Date: Mon, 08 Jun 2026 21:57:02 +0200	[thread overview]
Message-ID: <6a271e8f.0c2aff9d.374a2c.9275@mx.google.com> (raw)
In-Reply-To: <2c6340fe-2d3f-4d38-ae6c-d89adfea98b6@yahoo.fr>

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.)

  reply	other threads:[~2026-06-08 19:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 17:21 [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A) Marek Czernohous
2026-04-09 17:21 ` [PATCH 1/3] drm/nouveau/pci: use nv46 MSI rearm for G94 (NVAC/MCP79) Marek Czernohous
2026-04-09 17:21 ` [PATCH 2/3] drm/nouveau/kms: add NULL check for CRTC in nv50_sor_atomic_disable Marek Czernohous
2026-04-09 17:21 ` [PATCH 3/3] drm/nouveau/dp: retry link check once on HPD IRQ before disconnect Marek Czernohous
2026-04-26  9:15 ` [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A) -- 3 weeks soak report Marek Czernohous
2026-06-08 18:41 ` [PATCH 0/3] drm/nouveau: stability fixes for NVAC (MCP79/MCP7A) Fab Stz
2026-06-08 19:57   ` Marek Czernohous [this message]
2026-06-09 13:14     ` Fab Stz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a271e8f.0c2aff9d.374a2c.9275@mx.google.com \
    --to=mczernohous@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabstz-it@yahoo.fr \
    --cc=nouveau@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox