On Mon, 2 Nov 2026 at 06:04, Rosen Penev <[email protected]> wrote: > > On Kepler boards without the video decode falcon firmware installed > (msvld/mspdec/msppp), every other VA-API decode attempt binds to an > engine with no ucode loaded. The submitted work never completes, which > leads to a context switch timeout, a channel recovery that cannot reset > the engine, and eviction waits on fences that never signal. The process > ends up stuck in D state, or killed by SIGBUS when it touches a buffer > evicted after the wait times out: > > msvld: unable to load firmware data > msvld: init failed, -19 > fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > vo[5444]: channel 14 killed! > WARNING: drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:117 at > nvkm_runl_rc+0x2a4/0x3b0 [nouveau] > [TTM] Buffer eviction failed > WARNING: drivers/gpu/drm/nouveau/nouveau_bo.c:1092 at > nouveau_bo_move_ntfy.part.0+0x9b/0x100 [nouveau] > > Tracing nvkm_subdev_ref() and nvkm_subdev_init_() shows the pattern: > a reference taken with enabled=0 runs nvkm_falcon_init(), which > returns -ENODEV; the next reference sees enabled=1 and succeeds > without running it. > > Clear use.enabled when init() fails, so that every later reference > retries init and fails cleanly. The other readers of use.enabled are > fini() handlers that use it to skip teardown, which they now also do > after a failed init(). > > On a GK107 (Quadro K1100M) without video firmware, playing H.264 with > mpv --hwdec=auto: without this patch the GPU channel is killed within a > minute and mpv hangs; with it, VA-API decoder creation fails, mpv falls > back to software decoding, and no faults are logged.
Appled to drm-misc-fixes. Thanks, Dave.
