NetBSD Problem Report #60926

From www@netbsd.org  Mon Oct 26 01:38:15 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D57C41A923B
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 26 Oct 2026 01:38:15 +0000 (UTC)
Message-Id: <20261026013814.09C191A923C@mollari.NetBSD.org>
Date: Mon, 26 Oct 2026 01:38:13 +0000 (UTC)
From: mrg@eterna23.net
Reply-To: mrg@eterna23.net
To: gnats-bugs@NetBSD.org
Subject: amdgpu triggers assert in ww_mutex, disabling makes it mostly stable (raven ridge)
X-Send-Pr-Version: www-1.0
X-From4GNATS: "mrg@eterna23.net via gnats" <gnats-admin@NetBSD.org>

>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:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 26 01:40:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Sat Nov 07 14:10:01 +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.

>Release-Note:

>Audit-Trail:
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: re: kern/60926: amdgpu triggers assert in ww_mutex, disabling makes it mostly stable (raven ridge)
Date: Mon, 26 Oct 2026 15:10:39 +1100

 i meant to include eg, stack trace info.

 here's what gdb has to say:

 (gdb) bt
 #0  0xffffffff80239fca in cpu_reboot (howto=3Dhowto@entry=3D260, bootstr=3D=
 bootstr@entry=3D0x0) at /usr/src3/sys/arch/amd64/amd64/machdep.c:880
 #1  0xffffffff80d766e8 in kern_reboot (howto=3Dhowto@entry=3D260, bootstr=3D=
 bootstr@entry=3D0x0) at /usr/src3/sys/kern/kern_reboot.c:91
 #2  0xffffffff80dc5a75 in vpanic (fmt=3D0xffffffff813cfb68 "kernel %sasser=
 tion \"%s\" failed: file \"%s\", line %d locking %p against myself: %p",
     ap=3Dap@entry=3D0xffff920942174928) at /usr/src3/sys/kern/subr_prf.c:2=
 88
 #3  0xffffffff80fb0b44 in kern_assert (fmt=3Dfmt@entry=3D0xffffffff813cfb6=
 8 "kernel %sassertion \"%s\" failed: file \"%s\", line %d locking %p again=
 st myself: %p")
     at /usr/src3/sys/lib/libkern/kern_assert.c:51
 #4  0xffffffff80f473c9 in linux_ww_mutex_trylock (mutex=3D0xffff86bc4023d1=
 e0) at ./machine/cpu.h:80
 #5  0xffffffff80f3ae14 in linux_dma_resv_trylock (robj=3D<optimized out>) =
 at /usr/src3/sys/external/bsd/drm2/linux/linux_dma_resv.c:216
 #6  0xffffffff80f49952 in ttm_bo_cleanup_refs_or_queue (bo=3D0xffff86bc3fe=
 51358) at /usr/src3/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c:500
 #7  ttm_bo_release (kref=3D0xffff86bc3fe514f0) at /usr/src3/sys/external/b=
 sd/drm2/dist/drm/ttm/ttm_bo.c:696
 #8  0xffffffff80f4a68d in kref_sub (count=3D1, kref=3D<optimized out>, rel=
 ease=3D0xffffffff80f4985f <ttm_bo_release>)
     at /usr/src3/sys/external/bsd/drm2/include/linux/kref.h:94
 #9  0xffffffff80988fbf in amdgpu_bo_unref (bo=3Dbo@entry=3D0xffff9200450cf=
 8d0) at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_object.=
 c:866
 #10 0xffffffff809e8059 in amdgpu_vm_free_table (entry=3Dentry@entry=3D0xff=
 ff9200450cf8c8) at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amd=
 gpu_vm.c:963
 #11 0xffffffff809e91f3 in amdgpu_vm_free_pts (adev=3D<optimized out>, vm=3D=
 <optimized out>, start=3D0xffff920942174af0)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vm.c:991
 #12 amdgpu_vm_update_ptes (params=3D0xffff920942174b10, start=3D<optimized=
  out>, end=3D34360808448, dst=3D2860515328, flags=3D113)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vm.c:154=
 9
 #13 amdgpu_vm_bo_update_mapping (adev=3Dadev@entry=3D0xffff920043a10008, v=
 m=3Dvm@entry=3D0xffff86bc430c5008, direct=3Ddirect@entry=3Dfalse, exclusiv=
 e=3Dexclusive@entry=3D0x0,
     start=3Dstart@entry=3D34360807424, last=3Dlast@entry=3D34360808447, fl=
 ags=3D113, addr=3D<optimized out>, pages_addr=3D0x0, fence=3Dfence@entry=3D=
 0xffff86bc456c5500)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vm.c:161=
 7
 #14 0xffffffff809ea5f4 in amdgpu_vm_bo_split_mapping (adev=3D0xffff920043a=
 10008, exclusive=3D<optimized out>, pages_addr=3D<optimized out>, vm=3D<op=
 timized out>,
     mapping=3D0xffff86bc3db59348, flags=3D432345564227567729, bo_adev=3D<o=
 ptimized out>, nodes=3D<optimized out>, fence=3D<optimized out>)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vm.c:174=
 4
 #15 amdgpu_vm_bo_update (adev=3Dadev@entry=3D0xffff920043a10008, bo_va=3Db=
 o_va@entry=3D0xffff86bc456c54c8, clear=3Dclear@entry=3Dfalse)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vm.c:183=
 3
 #16 0xffffffff80928af5 in amdgpu_gem_va_update_vm (adev=3D0xffff920043a100=
 08, vm=3D0xffff86bc430c5008, bo_va=3D0xffff86bc456c54c8, operation=3D1)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_gem.c:54=
 0
 #17 amdgpu_gem_va_ioctl (dev=3D<optimized out>, data=3D<optimized out>, fi=
 lp=3D<optimized out>)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_gem.c:70=
 1
 #18 0xffffffff80bb572c in drm_ioctl (fp=3D<optimized out>, cmd=3D<optimize=
 d out>, data=3D0xffff920942174ee0)
     at /usr/src3/sys/external/bsd/drm2/dist/drm/drm_ioctl.c:980
 #19 0xffffffff80b79505 in drm_ioctl_shim (fp=3D<optimized out>, cmd=3D<opt=
 imized out>, data=3D<optimized out>)
     at /usr/src3/sys/external/bsd/drm2/drm/drm_cdevsw.c:393
 #20 0xffffffff80ddd9d0 in sys_ioctl (l=3D<optimized out>, uap=3D0xffff9209=
 42175000, retval=3D<optimized out>) at /usr/src3/sys/kern/sys_generic.c:67=
 5
 #21 0xffffffff805da02d in sy_call (sy=3D0xffffffff816432d0 <sysent+1296>, =
 l=3D0xffff86bc42cfc400, uap=3D0xffff920942175000, rval=3D0xffff920942174fb=
 0)
     at /usr/src3/sys/sys/syscallvar.h:65
 #22 sy_invoke (sy=3D0xffffffff816432d0 <sysent+1296>, l=3D0xffff86bc42cfc4=
 00, uap=3D0xffff920942175000, rval=3D0xffff920942174fb0, code=3D54)
     at /usr/src3/sys/sys/syscallvar.h:94
 #23 syscall (frame=3D0xffff920942175000) at /usr/src3/sys/arch/x86/x86/sys=
 call.c:137
 #24 0xffffffff8021025d in handle_syscall ()

 (gdb) p *mutex
 $3 =3D {
   wwm_state =3D 3 '\003',
   wwm_debug =3D true,
   wwm_u =3D {
     owner =3D 0xffff920942174cf8,
     ctx =3D 0xffff920942174cf8
   },
   wwm_lock =3D {
     u =3D {
       mtxa_owner =3D 67073,
       s =3D {
         mtxs_dummy =3D 1 '\001',
         mtxs_ipl =3D {
           _ipl =3D 6 '\006'
         },
         mtxs_lock =3D 1 '\001',
         mtxs_unused =3D 0 '\000'
       } =

     } =

   },
   wwm_class =3D 0xffffffff8167a740 <linux_reservation_ww_class>,
   wwm_waiters =3D {
     rbt_root =3D 0x0,
     rbt_ops =3D 0xffffffff81282700 <ww_acquire_ctx_rb_ops>,
     rbt_minmax =3D {0xffff86bc4023d200, 0xffff86bc4023d200}
   },
   wwm_cv =3D {
     cv_opaque =3D {0xffff86c32961c800, 0xffffffff81300125}
   } =

 } =


 (gdb) p *$4->l_proc
 [ ... ]
   p_path =3D 0xffff86bc35ef58a0 "/usr/X11R7/bin/X",

 ie, this is X server itself.


 crash shows:

 crash> bt
 __kernel_end() at 0
 kern_reboot() at kern_reboot+0x5f
 vpanic() at vpanic+0x197
 __x86_indirect_thunk_r8() at __x86_indirect_thunk_r8+0xd
 linux_ww_mutex_unlock() at linux_ww_mutex_unlock+0x44
 linux_dma_resv_trylock() at linux_dma_resv_trylock+0x9
 ttm_bo_release() at ttm_bo_release+0x133
 amdgpu_bo_unref() at amdgpu_bo_unref+0x1d
 amdgpu_vm_free_table() at amdgpu_vm_free_table+0x5c
 amdgpu_vm_bo_update_mapping() at amdgpu_vm_bo_update_mapping+0x840
 amdgpu_vm_bo_update() at amdgpu_vm_bo_update+0x2d2
 amdgpu_gem_va_ioctl() at amdgpu_gem_va_ioctl+0x500
 drm_ioctl() at drm_ioctl+0x2ad
 drm_ioctl_shim() at drm_ioctl_shim+0x38
 sys_ioctl() at sys_ioctl+0x256
 syscall() at syscall+0xaf
 --- syscall (number 54) ---

 crash> show lock 0xffff86bc4023d1e0
 lock address : ffff86bc4023d1e0
 type         : sleep/adaptive
 initialized  : linux_dma_resv_init+0x18
 shared holds :                  0 exclusive:                  1
 shares wanted:                  0 exclusive:                  3
 relevant cpu :         4294967295 last held:                  0
 relevant lwp : 000000000000000000 last held: 0xffff86bc42cfc400
 last locked* : ttm_eu_reserve_buffers+0x184
 unlocked     : ttm_bo_delayed_delete+0x13


State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 07 Nov 2026 14:05:17 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10


From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60926 CVS commit: src/sys/external/bsd/drm2/linux
Date: Sat, 7 Nov 2026 14:05:03 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sat Nov  7 14:05:02 UTC 2026

 Modified Files:
 	src/sys/external/bsd/drm2/linux: linux_ww_mutex.c

 Log Message:
 linux ww_mutex: Nix another assertion that trips in sketchy path.

 Under the premise (explained in the comment above) that it is
 legitimate for the upstream Linux code to do ww_mutex_trylock on a
 mutex already held by the current thread, we can't assert

 	mutex->wwm_state != WW_WANTOWN ||
 	    mutex->wwm_u.ctx->wwx_owner != curlwp

 any more than we can assert

 	mutex->wwm_state != WW_CTX ||
 	    mutex->wwm_u.ctx->wwx_owner != curlwp

 because if the latter condition is possible, then any concurrent
 thread tries to acquire the mutex a moment before we test that
 condition will turn it into the former condition, i.e., transition to
 mutex->wwm_state = WW_WANTOWN with mutex->wwm_u.ctx->wwx_owner =
 curlwp.

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


 To generate a diff of this commit:
 cvs rdiff -u -r1.17 -r1.18 src/sys/external/bsd/drm2/linux/linux_ww_mutex.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search