From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF0D1424D6C for ; Fri, 21 Aug 2026 15:23:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787325787; cv=none; b=saydQQJmWeSPIoFreVfPS40GtZthX52c8gLL8kBYpQkxNdXNSJLiaaVJck1SlWBeX+DoR+YgUkDf8BXKBMAId6JM19fy/PPA+Mrm3sa0yTc1etiAPUpxP8z9bMQSjY+3R0vXbt62l0+wN08LCBX00CUz01t6JbKPylGFKzTdDAM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787325787; c=relaxed/simple; bh=r67CvARYqYY21jZaZE8IIjfB2CX7PO89+p21l777/vo=; h=From:Date:Subject:To:Cc:Message-ID:MIME-Version:Content-Type; b=Jwe9sJhE4/ivsXyVYFTVj2zZaUmO0iMcveJDix1ihKn1mj0VW4kokCGec/HRJ3zCXhrMGKY/GkJfUPdW6uhTNG2OGMm4LhlKociLOT2f2EsGVNT3k6qxpMgivt6xx7Qtv+Nm4u7KMI7DOxvdesp6SfT37c/frz3KC/Vdie+8g2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WIFd9i6T; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WIFd9i6T" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c15df0c154dso12657466b.1 for ; Fri, 21 Aug 2026 08:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787325784; x=1787930584; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:cc :to:subject:date:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Wt70YXWaIggScCHa2VlJmb1FulxNMTZ4XUn6wxtJEjg=; b=WIFd9i6TyWX2WS5sciAD62TeWZl2Mmej/U89TDsbT/t5snRdyu5KvEkeN9RwvBAqFV Ggyd90/L8QNGVfQjH+ZfruU9gNLfbpFzpxlymiRC/nZK7Zk2LzvznmsszmNkfG7cawrm AtQA3SjDWNaXzJBrHEbZZe02fbPgSncLb7SFBVjWolKON+5+Eq1A096zPNL44J+/T4u5 zbXlaLawktC2HrLcB7uLrzXYhGFQ7VOo8NYkCmhfsqSF3iOlMXG87gQuy175Ga/EDYru afifSOqEtArlJL/EbDKJgtsvw3Q6srCWBgZFCI2FiF+GnQ0Y6+dOWQz7bfhkmRyr3/WF npIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787325784; x=1787930584; h=content-transfer-encoding:content-type:mime-version:message-id:cc :to:subject:date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Wt70YXWaIggScCHa2VlJmb1FulxNMTZ4XUn6wxtJEjg=; b=koAZuUyCWu6+lM1EVDrmxwILmY/phMLub7NPL7+zbBYlQaX+vlItSAMFUGum/CuJp1 hETmLKlbWUVfrPd5uulIAOxyogxiNlaTZW5aYly1vDiBt+ga6j71I7bBZCLAxYe+2Fpk /24qIBX5NQ8CbhJVr08M/cpA/cnUD6iqVmv5IkLk86uBxFZUI/L4iQHkckly5faSy2Pu yNrfWHASi10L2XdHxhO+7Z+u+0BeF8n0an8tYLKZu6dCG8iMCD4c8mfE7XXLT5Fqjpji wJ6TXpEUMwCd4XS+YyCoJAlIamSreT3FDIL6ORZqdecQ+0XrwpERfTFzDKvgEiVAabdI YBmg== X-Gm-Message-State: AFuF++kMFhdK7jClboGf4dIiwxYNA5y9pujUpnvjUPGqDxTPRfjHCbVN F66PoAzTMEUj+GeNR6DTCLatIQOgNFvcbCUJHwpTu4DpjWuWFuf+XX/q X-Gm-Gg: AR+sD12iaGr4gSdr61A5ICQzsIlyMbBeWgBNnC5vTSn1tqczK13ayaf4/MJ9P4dZ+sH 2BiuObu+uc/7tR1Xh+4S+9CEihyL5z9p40CshKL/1rUEUuPNIrtkaCOBOBRbhU0c9DUBjgKxlYa lf+dkj4kSGiFcf6M5Ce1C6vjs+2RYy/6hUmljjN9IWK4OSOkffbTvSyBbX45RCotU4OXTgGxRWp Yn/ts8JK9XkwoMk/DBuSUiWBZLgwbeNsg8BLU/a58y1yBwviQ/MZwEvT9/3Q2Csg5ZNYTKadNxH oLVIVmEqVyMVln5m97TmKH/KHRnnPcHmrYGq3QrZbR0hZKd5mJG2htzxi9uFuW/By52aNfTPURj /flRpl5I8yJTnlwLLCLTphQABg5y+5fxSwMX1Lm5TXLDXXD+ZkEYwMtEha8yxAwEl7HSBrGK1wt /jRUICm6u7XrQOrGTUe8MVHxMbibmQhQP3deUJmYgOHLRUMmhkVg5T9bbu6KxmcUV5HpJiX8gaJ uCFNl3g87mSfeSiN//1Z+lOu/M7mskOdl1Z+KWHJ3IZhDRTBEXoTqaWzDy3tZw8 X-Received: by 2002:a17:907:97c1:b0:c21:764c:9417 with SMTP id a640c23a62f3a-c246a2eb944mr404614866b.1.1787325783909; Fri, 21 Aug 2026 08:23:03 -0700 (PDT) Received: from [127.0.0.1] (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24591dc662sm506198566b.42.2026.08.21.08.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 08:23:03 -0700 (PDT) From: Marek Czernohous X-Google-Original-From: Marek Czernohous Date: Fri, 21 Aug 2026 17:23:01 +0200 Subject: [PATCH v4 0/3] drm/nouveau: channel-kill event ordering fixes, and lower the gate to NV50 To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Lyude Paul , Danilo Krummrich , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Ben Skeggs Message-ID: <178732578167.167481.5619512544301226563@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is v4. v3 is here: https://lore.kernel.org/all/20260812231330.705425-1-mczernohous@gmail.com/ Thank you for the review. Changes since v3: 1/3 unchanged, and now carries Lyude's Reviewed-by. 2/3 rewritten. v3 moved the subscription behind context_new(), which traded a half-built fence context for a missed kill. Lyude pointed out that the subscription does not have to move at all: give the fence context a flag and have the two sides hand the kill over. 3/3 is v3's 4/4, unchanged in code. Lyude asked what testing this has had on Tesla and said it will need input from others; the testing question is answered under Testing below. It is last in the series so it can be dropped without disturbing the two fixes, and I am happy for it to wait for that input rather than go with them. Withdrawn since v3 v3 carried a patch that demoted one specific CACHE_ERROR to debug level and attributed it to a Mesa bind probe. I am withdrawing it, because that attribution does not survive a look at the tree. Method 0x0060 on this class is SET_CONTEXT_DMA_SEMAPHORE (nvhw/class/cl826f.h), and the writer is the kernel itself, nv84_fence_emit32() and nv84_fence_sync32(), on subchannel 0 (nvif/push006c.h). The data is the VRAM ctxdma handle that Mesa picks (nouveau_screen.c, .vram = 0xbeef0201) and the kernel binds at channel creation. All 99 logged occurrences behind that patch read "subc 0 mthd 0060 data beef0201". Mesa's NV50 Gallium never writes on subchannel 0. So this is the driver's own semaphore-context rebind being rejected by the puller now and then, and I have not established why. I will look at it separately rather than carry it here. On 2/3, and the two places where it differs from the sketch The sketch checks chan->killed before setting ->ready, but each side has to store its own flag before loading the other's, or one interleaving loses the kill even under sequential consistency; swapped, with smp_mb() on both sides, it is the store-buffering pattern. And the kill side cannot take fctx->lock, because that lock is exactly what must not be touched before the context is built, so ->ready is a plain bool read outside the lock, published with release and read with acquire. The commit message has the full argument. On the aside about writing the respin without Claude This work is AI assisted, as the Assisted-by trailers say. The advice is right, and I would rather say so than let it pass. The honest position, though, is that I doubt I would have got to these bugs at all without the assistance. Testing Reference hardware: Apple Mac mini Late 2009, MCP79 / GeForce 9400M (NVAC), Core 2 Duo, Wayland (labwc). Build. Built against the base commit named at the end of this mail. The nouveau module compiles and links with W=1 and no new warnings. checkpatch.pl --strict is clean on all three patches. Deliberate channel kills on Tesla, which is Lyude's question on 3/3. The kill path on this hardware has been exercised on purpose, not only observed, and under a real 3D workload. A local debug patch, which is not part of this series, synthesises a CACHE_ERROR on a nominated channel. The victim was SuperTuxKart, with its channel live under load. Verbatim, timestamps and unrelated lines elided: nouveau 0000:02:00.0: fifo: inject: ch 2 [labwc[5670]] errored 0 nouveau 0000:02:00.0: fifo: inject: ch 3 [labwc[5670]] errored 0 nouveau 0000:02:00.0: fifo: inject: ch 4 [Xwayland[242990]] errored 0 nouveau 0000:02:00.0: fifo: inject: ch 5 [supertuxkart[1181685]] errored 0 [...] nouveau 0000:02:00.0: fifo: ch 5 fault 1/3 in 10000ms window, skipping method and resuming (Tier-0) nouveau 0000:02:00.0: fifo: ch 5 fault 2/3 in 10000ms window, skipping method and resuming (Tier-0) nouveau 0000:02:00.0: fifo:000000:0005:0005:[supertuxkart[1181685]] errored - disabling channel nouveau 0000:02:00.0: Xwayland[242990]: channel 5 killed! supertuxkart[1181685]: segfault at 560800000000 ip 00007f617c0d5ba6 [...] in libgallium So on NVAC, with 3/3 in place, the ERRORED event is delivered, the handler runs, the fence context is killed, and the compositor is unaffected. Two limits on what that proves. The escalation that disabled the channel is local and not in this series; what this series contributes is that the event reaches a subscriber at all instead of being dropped into an empty notifier list. And the victim did not survive its own channel being killed: it segfaulted inside Mesa rather than handling the -ENODEV fences. Without the subscription it would have hung instead. Games and sustained 3D. glxgears without vsync for ten minutes, and SuperTuxKart for a full race, ten and a half minutes, both with 3/3 in place. In both runs everything the kernel said came at window creation and was the known benign gr DATA_ERROR trap: 71 of those for glxgears, three for SuperTuxKart, and none at all once either was running. No wedge, no unexpected kill, and the session came through both unchanged. Soak. Code equivalent to 1/3 and 3/3 has been running on this machine since 2026-07-25, across the kernel bumps 7.1.5 through 7.1.8, with no regression. The 2/3 in this posting has NOT been soaked. What has been running since 2026-08-06 is the v3 form of it, which moved the subscription; the handover in this version is new as of today. I will report back once it has run. What the soak does not show, stated plainly: that tree carries local patches this series does not, including a cap on the plane-fence wait in the nonblocking commit tail. So the soak says these changes do not misbehave in daily use. It is not an independent demonstration of the failure modes above. 1/3 and 2/3 are ordering fixes for windows I have not managed to hit deliberately; the reasoning is from the source. Marek Czernohous (3): drm/nouveau: unsubscribe the channel-kill event before the fence context drm/nouveau: don't kill a fence context that is not ready yet drm/nouveau: subscribe to channel-kill events on NV50 and newer drivers/gpu/drm/nouveau/nouveau_chan.c | 30 ++++++++++++++++++++----- drivers/gpu/drm/nouveau/nouveau_fence.c | 19 ++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_fence.h | 8 +++++++ 3 files changed, 52 insertions(+), 5 deletions(-) base-commit: c21bb4193868a8de71fc4693fa741e195fdf5d86 -- 2.54.0