kern/60926: amdgpu triggers assert in ww_mutex, disabling makes it mostly stable (raven ridge)

["mrg%eterna23.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60926
>Category:       kern
>Synopsis:       amdgpu triggers assert in ww_mutex, disabling makes it mostly stable (raven ridge)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 26 01:40:00 +0000 2026
>Originator:     matthew green
>Release:        -current
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
amd64
>Description:
been trying to make a thinkpad A485 work nicely.  most of the time,
it hangs around the mountroot point, but the output varies so much
it was never clear what was wrong.  sometimes before you'd see the
amdgpu second attach phase, sometimes before, and sometimes it will
work and boot fully.

after booting, it would usually spew a few timeout messages:

warning: [drm] Fence fallback timer expired on ring gfx
warning: [drm] Fence fallback timer expired on ring comp_1.0.0
[ .. many other comp_* ]

when starting X, this appears frequently (the frequency varies, from
once a second, to twice every 2+8 seconds, etc.):

warning: [drm] Fence fallback timer expired on ring gfx

i have a tiny hack in my tree that make it mostly work, if sometimes
a little slow:

diff -p -u -r1.17 linux_ww_mutex.c
--- external/bsd/drm2/linux/linux_ww_mutex.c    16 Aug 2026 21:52:42 -0000      1.17
+++ external/bsd/drm2/linux/linux_ww_mutex.c    26 Oct 2026 01:30:17 -0000
@@ -1024,9 +1024,11 @@ ww_mutex_trylock(struct ww_mutex *mutex)
                    (mutex->wwm_u.ctx->wwx_owner != curlwp)),
                    "locking %p against myself: %p", mutex, curlwp);
 #endif
+#if 0 // XXXMRG
                KASSERTMSG(((mutex->wwm_state != WW_WANTOWN) ||
                    (mutex->wwm_u.ctx->wwx_owner != curlwp)),
                    "locking %p against myself: %p", mutex, curlwp);
+#endif
                ret = 0;
        }
        mutex_exit(&mutex->wwm_lock);

the core file absolutely indicates that wwm_state is WW_WANTOWN and the
owner is curlwp, and my surveying of the usage of WW_WANTOWN should this
shouldn't happen, so i don't know _what_ is happening yet, but since this
is all in linux_ww_mutex.c i plan to add instrumentation there to figure
it out.  (dtrace is hard here, since mostly it hangs at boot.)
>How-To-Repeat:
boot -current on a thinkpad a485.
>Fix:
see hack above.  with this, the laptop becomes at least usable...sigh.