NetBSD Problem Report #58745

From mrg@eterna23.net  Sat Oct 12 01:20:25 2024
Return-Path: <mrg@eterna23.net>
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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E670C1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 12 Oct 2024 01:20:24 +0000 (UTC)
Message-Id: <20241012012009.8991E1590B6@splode.eterna23.net>
Date: Sat, 12 Oct 2024 12:20:09 +1100 (AEDT)
From: mrg@eterna23.net
Reply-To: mrg@eterna23.net
To: gnats-bugs@NetBSD.org
Subject: nouveau triggered assert in linux_dma_fence.c
X-Send-Pr-Version: 3.95

>Number:         58745
>Category:       kern
>Synopsis:       nouveau triggered assert in linux_dma_fence.c
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    riastradh
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 12 01:25:00 +0000 2024
>Last-Modified:  Sat Oct 12 02:30:01 +0000 2024
>Originator:     matthew green
>Release:        NetBSD 10.99.12
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
System: NetBSD aches.eterna23.net 10.99.12 NetBSD 10.99.12 (_aches_) #52: Sat Sep 14 15:08:46 CDT 2024  mrg@aches.eterna23.net:/var/obj/amd64-x86_64/usr/src/sys/arch/amd64/compile/_aches_ amd64
Architecture: amd64
>Description:

	on a ryzen 5600G system that was recently moved from a radeon
	hd 6450 to a nvidia GT 730 (the 6450 does not work with two
	larger monitors), i saw this while playing a video:

	[ 312382.0409707] nouveau0: autoconfiguration error: error: fifo: fault 01 [WRITE] at 00000000082e0000 engine 1b [CE2] client 18 [HUB/GR_CE] reason 02 [PTE] on channel 2 [007f952000 user]
	[ 312382.0409707] nouveau0: notice: fifo: channel 2: killed
	[ 312382.0409707] nouveau0: notice: fifo: runlist 0: scheduled for recovery
	[ 312382.0409707] nouveau0: warn: user: channel 2 killed!
	[ 312382.0409707] nouveau0: notice: fifo: engine 0: scheduled for recovery
	[ 312382.0409707] nouveau0: notice: fifo: engine 7: scheduled for recovery

	at this point, X crashed, and as i've seen this on 710, 730,
	and 1030 cards and been able to restart, i restarted X but it
	then died immediately:

	[ 313138.7008055] nouveau0: autoconfiguration error: error: gr: TRAP ch 7 [007f7bc000 user]
	[ 313138.7008055] nouveau0: autoconfiguration error: error: gr: GPC0/TPC0/TEX: 80000041
	[ 313138.7008055] nouveau0: autoconfiguration error: error: gr: GPC0/TPC1/TEX: 80000041
	[ 313138.7008055] nouveau0: autoconfiguration error: error: fifo: fault 00 [READ] at 0000000000ed2000 engine 00 [GR] client 04 [GPC0/T1_1] reason 02 [PTE] on channel 7 [007f7bc000 user]
	[ 313138.7008055] nouveau0: notice: fifo: channel 7: killed
	[ 313138.7008055] nouveau0: notice: fifo: runlist 0: scheduled for recovery
	[ 313138.7008055] nouveau0: notice: fifo: engine 0: scheduled for recovery
	[ 313138.7008055] nouveau0: warn: user: channel 7 killed!

	and then:

	panic: kernel diagnostic assertion "(atomic_load_relaxed(&fence->flags) & (1u << DMA_FENCE_FLAG_SIGNALED_BIT)) == 0" failed: file "/usr/src/sys/external/bsd/drm2/linux/linux_dma_fence.c", line 696

	it may be the assert is checking something that linux does not
	enforce, and an uncommon error code path we haven't seen before.
	i have had this error not restart but simply fail and need a
	reboot to work properly, but not crash before.  eg, perhaps the
	fence was signaled _twice_ in the error case, and the second one
	is triggering the assert.

	i have a core file and a netbsd.gdb for this one.  the backtrace
	is not especially interesting i think:

	vpanic() at vpanic+0x17b
	kern_assert() at __x86_indirect_thunk_rax
	linux_dma_fence_set_error() at linux_dma_fence_set_error+0x160
	nouveau_fence_context_kill() at nouveau_fence_context_kill+0x44
	nouveau_channel_killed() at nouveau_channel_killed+0x5c
	nvif_notify_work() at nvif_notify_work+0x2b
	linux_workqueue_thread() at linux_workqueue_thread+0x154

>How-To-Repeat:
>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Sat, 12 Oct 2024 02:28:19 +0000
Responsible-Changed-Why:
mine


From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, mrg@eterna23.net
Subject: Re: kern/58745 (nouveau triggered assert in linux_dma_fence.c)
Date: Sat, 12 Oct 2024 02:29:12 +0000

 This is a multi-part message in MIME format.
 --=_jGdl80rZzbJ3AV6nW+2j7DYaEAx46dnv

 Attached patch works around it.  On the fence about whether to commit
 this (and introduce another local diff) or just relax the assertion.

 --=_jGdl80rZzbJ3AV6nW+2j7DYaEAx46dnv
 Content-Type: text/plain; charset="ISO-8859-1"; name="pr58745-nvfencechanerr"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="pr58745-nvfencechanerr.patch"

 # HG changeset patch
 # User Taylor R Campbell <riastradh@NetBSD.org>
 # Date 1728700032 0
 #      Sat Oct 12 02:27:12 2024 +0000
 # Branch trunk
 # Node ID 8465cbb178fcac2a01a66c33646eb41f7b497283
 # Parent  94b69b01d60e6b02d6aefbbb562c511991aba09f
 # EXP-Topic riastradh-pr58745-nvfencechanerr
 nouveau: Don't set dma fence error if already signaled.

 This happens asynchronously on hardware error.  Upstream Linux trips
 WARN_ON in this case; our dma_fence_set_error trips KASSERT instead.
 We could maybe switch dma_fence_set_error to use WARN_ON too but it's
 probably better not to take this path anyway -- this assertion trips
 on logic that is incoherent, if not outright wrong.

 PR kern/58745: nouveau triggered assert in linux_dma_fence.c

 diff -r 94b69b01d60e -r 8465cbb178fc sys/external/bsd/drm2/dist/drm/nouveau=
 /nouveau_fence.c
 --- a/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c	Thu Oct 10 21:=
 42:24 2024 +0000
 +++ b/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c	Sat Oct 12 02:=
 27:12 2024 +0000
 @@ -102,7 +102,7 @@ nouveau_fence_context_kill(struct nouvea
  	while (!list_empty(&fctx->pending)) {
  		fence =3D list_entry(fctx->pending.next, typeof(*fence), head);
 =20
 -		if (error)
 +		if (error && !dma_fence_is_signaled_locked(&fence->base))
  			dma_fence_set_error(&fence->base, error);
 =20
  		if (nouveau_fence_signal(fence))

 --=_jGdl80rZzbJ3AV6nW+2j7DYaEAx46dnv--

>Unformatted:

Home	PR Database Search