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 EA50B28C009 for ; Tue, 19 May 2026 22:01:53 +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=1779228115; cv=none; b=ZZls87YXV25Ba+eNDT8oveINEjCVI22lOcs8ZCP/+vBNdUKio70178QAjyZsNoUxExpzyD8r2VgULdvNIxgMQWAFvv/3k+r6Ewma3uzIC04TS6bY5zhuWs1+VFw9lAh3e+Cczg2r1z/Q7w6Gbjvz9jjy99nc7fWS01bNkf5SNSc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779228115; c=relaxed/simple; bh=yX/FeS6p1ggTWK2cFLIbTmgp46Xg7x9+qqW6hrD7F0s=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=oKMf1NmYMGTHGpyRZg5jkIPiY0k0A97oCW5csjhchZFJlaLZw/wN9Fd0TtBIadOA6wY7+BXebTZHFs5hkFRjZTw5hVG8RzxMrlPPeA8tOGsjkX8Zh+mu+RxuQS9TxOgaGLvTKWsOeNqr9hrvh3FyRapuMh7v57hliNL1QnL6tKo= 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=AP5Ivdla; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=LABg68Dx; 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="AP5Ivdla"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="LABg68Dx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779228112; 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=yX/FeS6p1ggTWK2cFLIbTmgp46Xg7x9+qqW6hrD7F0s=; b=AP5IvdlawqMR8uRw7o3Jwaojeu6kmIP3Ja33QspsfSuGdOFu7sEot6NFY4OggNvfdgGVBs kbRR2Hg6m6UMESfp9XetEuR+Myw93+xbiF/LDoePDjOIQWXNF6qahXk6778BQY/ubRL3Vn r+OxOLsPhvFYGaFuIRWFxuqV8KXr6is= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-492-ygC_VZrGN32z6gpbm93iKw-1; Tue, 19 May 2026 18:01:51 -0400 X-MC-Unique: ygC_VZrGN32z6gpbm93iKw-1 X-Mimecast-MFC-AGG-ID: ygC_VZrGN32z6gpbm93iKw_1779228111 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-913fcc4c164so925232085a.1 for ; Tue, 19 May 2026 15:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779228111; x=1779832911; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=yX/FeS6p1ggTWK2cFLIbTmgp46Xg7x9+qqW6hrD7F0s=; b=LABg68Dx7fh5EF0iKXQjzWJVhNd+bNlPs35/LSsbXrue/v3bwnyejRMeEj4rEiGEhp cp+RvGILtrA5/D7Bccst2LB6074TKwVdzG9FJ3UJBZ5ihlJ7LxOy2cCmgEm0bVRsGYFC BxGL2a83ew1I9ATD5Wrish/VgYoYeQd5BPv1FjwO38l2EnlOHe7kKevYI3L7DktWEfmn aYG6Vk0+MKjuuXEnmp2eW3cqz1d8UoL8sqek9nMtSBjoowTpRZ/ydn3adcfx5us/bAJJ d3vSYkVFR1gInN8q7W8zv/qIPHgwtbMe6uV9zJba6G99WCU1Btcq91//wwmxYTYHrRH/ ZohA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779228111; x=1779832911; h=mime-version:user-agent:content-transfer-encoding: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; bh=yX/FeS6p1ggTWK2cFLIbTmgp46Xg7x9+qqW6hrD7F0s=; b=d0cmEjER0OyepSaKrrcBxPwfBeJAX4utURf5CwavSA3tKw2qnpW9oXQ5Noc2306hTK 47a4qFdEjPkCQiGxtd/nnOxxPFlLHTpnWGx0uFFOqGxSgFZnY05yZhLVNOHiFr0Kb0wR JKQAmdyPI0JYQXYOgML/55UtbFCF6WyLi9IeltbLKymh6aM3WTBDZDp461Oxylg+aOop 2oh7y8UXjldz59U4VV5///jGlkNuED5vcmxqJ/gOXwJfFxtsYPoNI9w0HsJ3mFRvgn5Z fIwgF6AxaGbAgn9ZLy0qeI8TYTFBv7JnbbcU1qLRlwEfiJeNAOK7auVQvuJHH9AKrV1t TR9Q== X-Forwarded-Encrypted: i=1; AFNElJ/mUvR7zp8wuPvv6m9vRziB0hHGsSpLFEYZYftU+7QJ2rUZOlf1caguhOss4N2x4p9xI+raW2rQq6Cz5mE=@vger.kernel.org X-Gm-Message-State: AOJu0YyxyNqSiXWAkReeJfygXxY/+WB+B5ak/DmnsAupEzCfvtb873AW S5oV7bYrPbjXGuIVLUO9mi+/HroUUD87XC7GygktMuj+WcpH+ceYDghkU38l+qYoNW6Ir+bqR3P Z4Zpkypg6VDdvTyH9osE1SUVcMH02A5zRaxlXNUvcsGxQeU27LU4dbOoqvZW0vJWzNw== X-Gm-Gg: Acq92OGu4lVDAZh2ZDymnzEXBkqZO3wVC2T0wHYSPY09ydY0oGU8sxZgdmxqYmhUHKD U+8Vrkt1TTrD2RO442DTzo42n1IWVKLu/l0Wur4aaO4I81O+oRGvFW4ZqntsZG445IbK9Rvzccz RbG5+Cu53LEnnVh6Ew/1eRo1tB7MhgPM6Zjjb1qaWID8rlZ4ArQCwTdqNfZkWqrwNNQnuFVM6dl emlfdQp/gw3ZcTv3nNxtJTdCGot68S5dehHki2AI75PcAepv8xczBBqz9GKf43Vru/QRxfKgOEH 7AFcpxt9oGzmDxjKr5HcT89KsAjZpiYmke21q88uVA1QoOvcPRnjaR1MvTeAlw0jd9PgSB5ad9M cZrnj5oIO39FOVPjSiQ== X-Received: by 2002:a05:620a:170c:b0:910:5637:4bec with SMTP id af79cd13be357-911cd1752admr3279951685a.18.1779228108235; Tue, 19 May 2026 15:01:48 -0700 (PDT) X-Received: by 2002:a05:620a:170c:b0:910:5637:4bec with SMTP id af79cd13be357-911cd1752admr3279853985a.18.1779228095704; Tue, 19 May 2026 15:01:35 -0700 (PDT) Received: from [192.168.8.4] ([100.0.180.93]) by smtp.gmail.com with ESMTPSA id af79cd13be357-910ba36d137sm1948054085a.1.2026.05.19.15.01.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 15:01:34 -0700 (PDT) Message-ID: <4037b4a4c1768f5f28c7ae1c5dfb2913e675d6ab.camel@redhat.com> Subject: Re: [PATCH 0/2] drm/nouveau: nv04 FIFO cleanup + recovery for Tesla From: lyude@redhat.com To: Marek Czernohous , nouveau@lists.freedesktop.org Cc: Danilo Krummrich , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Marek Czernohous Date: Tue, 19 May 2026 18:01:34 -0400 In-Reply-To: <20260513175014.96599-1-marek@czernohous.de> References: <20260513175014.96599-1-marek@czernohous.de> 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 Hey! I truly apologize for asking, and thank you tremendously in advance if the answer is no. But I had to check since I haven't seen you around before, and these are unusually long commit messages: These patches were written by a person correct? If not, you need to follow the coding assistants guidelines here: https://docs.kernel.org/process/coding-assistants.html On Wed, 2026-05-13 at 19:50 +0200, Marek Czernohous wrote: > Hi all, >=20 > Two-patch series for the legacy nv04_fifo path covering Tesla > (MCP77/MCP79 and G80-GT218). Daily-driven on the reference NVAC > hardware (Apple Mac mini Late 2009, GeForce 9400M) since 2026-05-05. >=20 > Patch 1 demotes a benign CACHE_ERROR that fires once per Mesa session > start on Tesla GPUs. The Mesa NV50 userspace driver issues a method- > 0x0060 / data-0xbeef02xx binding probe that recovers cleanly via > nv04_fifo_swmthd(), but currently logs at error level on every X or > Wayland session, dominating dmesg noise on this hardware class. This > clears the channel for patch 2 to identify real faults from noise. >=20 > Patch 2 adds a two-tier fault-recovery path for Tesla FIFO faults: >=20 > =C2=A0 Tier 1 (per fault). Look up the channel via nvkm_chan_get_chid, > =C2=A0 call nvkm_chan_error(chan, true), fire tracepoint > =C2=A0 nouveau:fifo_chan_killed. Idempotent through the existing > =C2=A0 chan->errored short-circuit. >=20 > =C2=A0 Tier 2 (sliding window). When the per-fifo fault count in a > =C2=A0 configurable window reaches the threshold, schedule a worker that > =C2=A0 calls drm_dev_wedged_event(drm, DRM_WEDGE_RECOVERY_REBIND, NULL) > =C2=A0 and fires tracepoint nouveau:fifo_dev_wedged. Worker context is > =C2=A0 needed because kobject_uevent_env may sleep. >=20 > Motivation: Fermi+ gets channel-kill and device-wedge automatically > through nvkm_runl_rc; Tesla was feature-frozen before the DRM wedge > uAPI existed. Three observable consequences on the reference > hardware: >=20 > =C2=A0 1. Silent state corruption (channel produces wrong output after a > =C2=A0=C2=A0=C2=A0=C2=A0 fault, no notice to userspace). > =C2=A0 2. Observability gap (no counters, tracepoints, or wedge event, > =C2=A0=C2=A0=C2=A0=C2=A0 only dmesg). > =C2=A0 3. Repeated-fault loop (the log-and-reset cycle repeats forever on > =C2=A0=C2=A0=C2=A0=C2=A0 a persistently faulting channel instead of killi= ng it). >=20 > Validation. A debugfs fault-injector (kept on a separate > DO-NOT-MERGE branch, not part of this submission) was used to drive > both Tier-1 and Tier-2 paths through their full state space. Phases > 1-5 of the test plan were exercised that way. Phase 6 (no manual > injection, real workload soak) ran 2026-05-05 through 2026-05-13: > one organic DRM_WEDGE_RECOVERY_REBIND event was captured on > 2026-05-05 09:08; the rest of the soak was fault-free. >=20 > Companion userland tool nouveau-pstate-daemon v0.2.0 [1] subscribes > to the WEDGED=3Drebind uevent in log-only mode and was used to confirm > end-to-end propagation through udev. >=20 > Module parameters: >=20 > =C2=A0 nouveau.fifo_wedge_count=C2=A0=C2=A0=C2=A0=C2=A0 (uint, 0..32, def= ault 10) > =C2=A0 nouveau.fifo_wedge_window_ms (uint, 100..600000, default 60000) >=20 > Setting fifo_wedge_count=3D0 disables Tier-2 entirely while keeping > Tier-1 channel-kill active. >=20 > A note on MAINTAINERS. The series adds a new file > drivers/gpu/drm/nouveau/nvkm/engine/fifo/recover.c. The change is > covered by the existing nouveau MAINTAINERS section > (drivers/gpu/drm/nouveau/), so no MAINTAINERS update is included. > checkpatch.pl flags this as a hint; it is not load-bearing. >=20 > This is a follow-up to the April 9 NVAC stability series [2], which > is still awaiting review. The two patches here are independent of > that series and apply against current Linus master. >=20 > [1] https://github.com/hibbes/nouveau-pstate-daemon=C2=A0(v0.2.0) > [2] > https://lore.kernel.org/dri-devel/20260409-nouveau-nvac-stability-series >=20 > Marek Czernohous (2): > =C2=A0 drm/nouveau/fifo/nv04: filter benign CACHE_ERROR from Mesa NV50 > bind > =C2=A0=C2=A0=C2=A0 probe > =C2=A0 drm/nouveau/fifo: add recovery path for Tesla > cache_error/dma_pusher >=20 > =C2=A0.../drm/nouveau/include/nvkm/engine/fifo.h=C2=A0=C2=A0=C2=A0 |=C2= =A0 12 ++ > =C2=A0.../include/trace/events/nouveau_fifo.h=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 58 +++++++++ > =C2=A0drivers/gpu/drm/nouveau/nouveau_drm.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 29 +++++ > =C2=A0.../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild=C2=A0=C2=A0 |=C2=A0=C2= =A0 1 + > =C2=A0.../gpu/drm/nouveau/nvkm/engine/fifo/base.c=C2=A0=C2=A0 |=C2=A0=C2= =A0 3 + > =C2=A0.../gpu/drm/nouveau/nvkm/engine/fifo/nv04.c=C2=A0=C2=A0 |=C2=A0 29 = ++++- > =C2=A0.../gpu/drm/nouveau/nvkm/engine/fifo/priv.h=C2=A0=C2=A0 |=C2=A0 10 = ++ > =C2=A0.../drm/nouveau/nvkm/engine/fifo/recover.c=C2=A0=C2=A0=C2=A0 | 121 > ++++++++++++++++++ > =C2=A08 files changed, 257 insertions(+), 6 deletions(-) > =C2=A0create mode 100644 > drivers/gpu/drm/nouveau/include/trace/events/nouveau_fifo.h > =C2=A0create mode 100644 > drivers/gpu/drm/nouveau/nvkm/engine/fifo/recover.c >=20 >=20 > base-commit: 1f63dd8ca0dc05a8272bb8155f643c691d29bb11