From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93F0E3E1222 for ; Thu, 20 Aug 2026 21:56:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787262990; cv=none; b=q8BFXJ8bSnYvl6utCsM/DVBm3NorrQ2mLZ0WQlEQljJRYRE4AwvSICRMQ1S3Ysj4LUEGosA02NGLmzBVyydtReoG+jG0r5Norn2xKZcGC6XA3lNEnnfXNUsJUNiDACEAKX8s55hlhsZr00+WNM5LD7lC/lle42UkfCGeQ4gwmag= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787262990; c=relaxed/simple; bh=5p2NdTGwAkNCZXS7bDJemXMz7PWK0XD5hCyf/YfVBEs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=LJ10KGPAmtagGa9aWxB5IAWhEG/OmMdaGOY9V2yPQQcLVizoETo4heUIqbpN9jBUqbaICxiviieYncaaP7eaQ/q640xdI7HSqENTj2US5OOeaij/OSyJXDj5T8F8wVQbM8VXNZDWkzaJxfkvM7IAi37GY+8mc8B4yIlk/aXqLGo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LgMXYmEZ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=qaXkvZAL; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LgMXYmEZ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="qaXkvZAL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787262987; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lzTaBAeZXEpNdEF6mCBk0yTwt9Zf1jS1qQHVYWMdOMI=; b=LgMXYmEZLKgTUJB85yifVJPVMHLI/w/F9mDQsK2jGVAzbbzT6rDogVir+PgfrJ2Iovn8mC cL5cV1CV5ojOlQWgLm6bygAtiPqGZI2yIp0SprgylQa3X2nK0d93YW3AloJ8zTEhkK4Sil 1jvCJYlnQ9wKpV6NHvNCyaOVl72Pw6Q= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-386-nV88Mt_jMeK-KUPD8iUa-g-1; Thu, 20 Aug 2026 17:56:25 -0400 X-MC-Unique: nV88Mt_jMeK-KUPD8iUa-g-1 X-Mimecast-MFC-AGG-ID: nV88Mt_jMeK-KUPD8iUa-g_1787262984 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-92e4f946461so29855085a.2 for ; Thu, 20 Aug 2026 14:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1787262984; x=1787867784; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=lzTaBAeZXEpNdEF6mCBk0yTwt9Zf1jS1qQHVYWMdOMI=; b=qaXkvZAL6ENz+EPFBqhWpUIfMSil4aqBZCkWjleO1SqD4enRVPvHwWLrGB3JnftSE9 GX9YCBYL+1WYjuXc/7GAWybP0juKD2ZsNPsdXV4KE2w26nBjQ8kKHouszhWCQVsArjsy WpRa4WrUZnfD1vuEELh8kjnGuYUYQZbujkHwWT621A6ushi32jx3fp0rpewt5gYwIdls fUmpLpCipO6Qoep1OirvMD4MEZv7QCDrclQCUMKrJma0LhxqLBIACCRbgX0IiRti+1T9 gIP0cnqfcxAYzFNY3UqJBcAVZxme8YamDLuNmFLwOyPVVJno8HVq8TGQ1Vt6IUs4CsTn KUYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787262984; x=1787867784; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=lzTaBAeZXEpNdEF6mCBk0yTwt9Zf1jS1qQHVYWMdOMI=; b=kknZ0GHD5n/lUtPKz/4NF7YjPjB75PVBBMzoiD+Qw57LanpH9O54ylufBBqHSy0P9u i19aQXpX69eXi3PEEaeJPUmYbDX4nYVVccl/4HAXEbOk33osZzfKFIxCA0eiPooqFCd2 ZLB5r/1cIAVZIZZeM7m587gPXX3cqLaR/X/Iep/ava8Jw6Ogqly/mrlK9QOAOFOEJV15 +Q/MweR6EV0erKxA27PBY27yB8H+pg4qBT/z8NVqW0KdobKzcQqgpOLV7tyJDL4AG6UL c+weTxBq6lnOITKPLrSgWxUW716O7nxWb57gPItY1jIALqNLnZ7J9aadSAOjhwuTBGO8 lRrw== X-Gm-Message-State: AOJu0YxeqppJydRPSeYpks3BYyBx9WirP9EyFpoRV2gzQ4q3aOFEGcT1 AjIe1QQ9KuArlzbXNzBjiZ0L2ilkp1yQuA+S4hOUjm7RdJZpypt4UpR7i7v8fUgejJaf/9ySLip 4S3yi6cfXVU0tA87ogG9VqeLX3knzUwt8sJEq+9CVhpSZWmUNhuAZLjNCFtJi3cf7Rw== X-Gm-Gg: AR+sD102l1RnBg5aKTKG9WmIMbZ/o+VtM+8+vbk9OtFJNUeoTm88noyK9oWrjRfuid6 /Z4aliMcJvTQaNP1EYcrfQmQVk1aRm7wXv8z10FYIpTpCwLp2ayntwJ0Rgqb3r4Oz3rdKwC9DFV pXncYGApUhEcElJRkuB/vDIwrYHbD0C5alhtQaiQ4HRmzFy2GEjfGViD8t4rIONrdxCSv6lYZD5 6C1kp6DQHd2L7mJr6YijYYmIUsXd3oCxv9MzKpZekJO7vGY9YjWHls6lhjXN3IgFMbxDsA4tQQ4 hEtnkkQFWc3kORAIhPvQPOoqFWDtbGBg0BvjtGTKbyR8b7miMUs6Fv0k05J8eZMXvFGG9x5H X-Received: by 2002:a05:620a:1132:b0:937:36c0:bf6 with SMTP id af79cd13be357-9373958fcdamr105262685a.16.1787262984429; Thu, 20 Aug 2026 14:56:24 -0700 (PDT) X-Received: by 2002:a05:620a:1132:b0:937:36c0:bf6 with SMTP id af79cd13be357-9373958fcdamr105260085a.16.1787262983921; Thu, 20 Aug 2026 14:56:23 -0700 (PDT) Received: from [192.168.8.4] ([100.0.180.93]) by smtp.gmail.com with ESMTPSA id af79cd13be357-937204aa8a6sm461514385a.11.2026.08.20.14.56.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2026 14:56:22 -0700 (PDT) Message-ID: <9414b8d122b9489056d72ee1605787ee038e62b7.camel@redhat.com> Subject: Re: [PATCH v3 4/4] drm/nouveau: subscribe to channel-kill events on NV50 and newer From: lyude@redhat.com To: Marek Czernohous , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , David Airlie , Simona Vetter , Ben Skeggs Date: Thu, 20 Aug 2026 17:56:21 -0400 In-Reply-To: <20260812231330.705425-5-mczernohous@gmail.com> References: <20260812231330.705425-1-mczernohous@gmail.com> <20260812231330.705425-5-mczernohous@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 This one is going to need some input from others I believe, mostly in that I'd want to really make sure we know what the implications of enabling an event like this on Tesla are and what kind of testing we would need to know this isn't going to break things. If it was a slightly newer generation I wouldn't be as worried. What kind of testing have you done with this so far in terms of workload in addition to what you mentioned on the cover letter? Tried running any games, anything graphics intensive, etc.? On Thu, 2026-08-13 at 01:13 +0200, Marek Czernohous wrote: > From: Marek Czernohous >=20 > nouveau_channel_init() only subscribes to the channel-killed event > for > FERMI_CHANNEL_GPFIFO and newer. On NV50/Tesla the subscription > therefore > never happens, and nvkm_chan_error()'s NVKM_CHAN_EVENT_ERRORED is > delivered into an empty notifier list. >=20 > Today that is harmless, because nothing kills a channel on Tesla: the > only nvkm_chan_error() callers are the Fermi and newer recovery > paths. > So this patch changes no observable behaviour on its own, and that is > deliberate: it removes a latent trap before anything can fall into > it. > I am carrying a Tesla recovery path that does add such a caller and > will > send it separately once it is ready. Without a subscriber in place > the > consequences there are severe: nouveau_channel_killed() never runs, > so > nouveau_fence_context_kill() never runs either, and the pending > fences > of the killed channel are never signalled. Everything waiting on them > waits forever: drm_atomic_helper_wait_for_fences() in the display > commit > tail waits uninterruptibly and without a timeout, and the TTM delayed > delete workers wait in TASK_UNINTERRUPTIBLE. The user sees a frozen > desktop on a machine that is otherwise alive, and nothing in the > kernel > ends that state: both waits pass MAX_SCHEDULE_TIMEOUT, so the fences > cannot time out. They are signalled only when the fence context is > torn > down, that is when the DRM client owning the channel closes its fd > and > nouveau_fence_context_del() runs. Killing the client, or rebooting, > clears it; waiting does not. > That is also a dma-fence contract violation: a fence must always be > signalled, with an error if necessary. >=20 > Lower the class gate to NV50_CHANNEL_GPFIFO. The nvkm side is already > class neutral: the KILLED case hangs the notifier on runl->chid- > >event, > which every fifo owns since the runlist rework, and > nvkm_uchan_uevent() > does not discriminate by class. Pre-NV50 chips keep the old > behaviour, > so NV04 to NV40 are unaffected. >=20 > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Marek Czernohous > --- > =C2=A0drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c > b/drivers/gpu/drm/nouveau/nouveau_chan.c > index 07b0bd1bc519..5c2f4b9342b7 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_chan.c > +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c > @@ -485,7 +485,7 @@ nouveau_channel_init(struct nouveau_channel > *chan, u32 vram, u32 gart) > =C2=A0 * lock and the pending list, so an event arriving in > between would > =C2=A0 * find a non-NULL but unusable context and walk a NULL list > head. > =C2=A0 */ > - if (chan->user.oclass >=3D FERMI_CHANNEL_GPFIFO) { > + if (chan->user.oclass >=3D NV50_CHANNEL_GPFIFO) { > =C2=A0 DEFINE_RAW_FLEX(struct nvif_event_v0, args, data, > =C2=A0 sizeof(struct nvif_chan_event_v0)); > =C2=A0 struct nvif_chan_event_v0 *host =3D