Source: linux
Version: 7.1.13-1
Severity: normal
Tags: upstream
Dear Maintainer,
I have an ASUS G550JK, muxless Optimus laptop. All four display outputs are
wired to the Intel iGPU and the GTX 850M has no DRM connectors at all, so the
card is only ever used for render offload.
Rendering on it fails most of the time: the kernel kills the channel and the
client dies with ENODEV. The card itself is fine; the runs that do get through
render correctly and fast, around 2400-2500 FPS on the glmark2 texture scene,
where the iGPU scores 1846 overall. On 7.1.13 roughly one run in three works.
I'm filing this against the kernel rather than Mesa for two reasons. It happens
on 7.0.13, 7.1.8 and 7.1.13 with Mesa unchanged at 26.1.6-1. And it hits Mesa's
GL driver and NVK in the same way, both ending with the channel killed and
ENODEV. Please reassign if you disagree.
Hardware and versions:
01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 850M]
[10de:1391] (rev a2)
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller [8086:0416] (rev 06)
Debian forky/sid amd64, GNOME 50 on Wayland
kernel 7.1.13+deb14-amd64, also tested on 7.1.8+deb14.1 and 7.0.13+deb14
Mesa 26.1.6-1, libdrm2 2.4.134-3
nouveau issues no firmware request on this chip and none fails; GM107 doesn't
need the signed ACR blobs.
How I test:
for i in 1 2 3 4 5 6; do
DRI_PRIME=1 timeout 90 glmark2 --off-screen -b texture:duration=3
sleep 4
done
--off-screen is deliberate; it renders into an FBO, so the PRIME copy and the
presentation path aren't involved. The same command without DRI_PRIME=1 runs on
the iGPU and never fails.
Result on 7.1.13, six runs:
run 1 fail, exit 139, "nouveau: kernel rejected pushbuf: No such device"
run 2 ok, 2486 FPS
run 3 fail, exit 124, hung until the timeout without printing anything
run 4 fail, exit 1, same rejected pushbuf message
run 5 ok, 2366 FPS
run 6 fail, exit 124, hung again
I didn't have dmesg capture running during those six, so I only have the exit
codes for them.
On 7.0.13 the same loop failed 6 times out of 6, and there the fault was
completely deterministic; same reason, same address, same channel every time:
nouveau 0000:01:00.0: fifo: fault 00 [READ] at 00000000026c0000 engine 07
[HOST0] client 06 [HUB/HOST] reason 01 [PDE_SIZE] on channel 3 [00ff726000
glmark2[8338]]
nouveau 0000:01:00.0: fifo:000000:0003:[glmark2[8338]] rc scheduled
nouveau 0000:01:00.0: fifo:000000:0003:0003:[glmark2[8338]] errored -
disabling channel
nouveau 0000:01:00.0: glmark2[8338]: channel 3 killed!
nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 619444 [ PRIVRING ]
Engine 07 [HOST0], client 06 [HUB/HOST], READ: that's the FIFO host fetching
push buffer entries, not a shader or a texture fetch. The faulting address
0x026c0000 was byte-identical across all six runs and on 7.1.8 as well.
On 7.1.8 I got a different signature, [PBENTRY] with "error fencing pushbuf:
-19", and for a while a strict success/failure alternation over 11 consecutive
runs. That alternation no longer holds on 7.1.13; runs 3 and 4 above are two
failures in a row.
The same thing happens with Vulkan. NVK now supports this GM107 (it reports
apiVersion 1.3.354), so I ran vkcube against nouveau_icd.json:
run 1..4: exit 134, "cube.c:1127: demo_draw: Assertion `!err' failed."
Four runs, four failures. The Vulkan device is created without trouble; it dies
at draw/submit. The same vkcube binary on the iGPU completes its 60 frames and
exits 0. Kernel side, on 7.1.13:
nouveau 0000:01:00.0: gr: TRAP ch 4 [00ff796000 vkcube[102592]]
nouveau 0000:01:00.0: gr: GPC0/TPC0/TEX: 80000041
nouveau 0000:01:00.0: gr: GPC0/TPC1/TEX: 80000041
nouveau 0000:01:00.0: gr: GPC0/TPC2/TEX: 80000041
nouveau 0000:01:00.0: gr: GPC0/TPC3/TEX: 80000041
nouveau 0000:01:00.0: gr: GPC0/TPC4/TEX: 80000041
nouveau 0000:01:00.0: fifo:000000:0004:0004:[vkcube[102592]] errored -
disabling channel
nouveau 0000:01:00.0: vkcube[102592]: channel 4 killed!
nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 619444 [ PRIVRING ]
nouveau 0000:01:00.0: fifo: fault 00 [READ] at 000000b5bcd68000 engine 07
[HOST0] client 06 [HUB/HOST] reason 00 [PDE] on channel 3 [00ff797000
vkcube[102592]]
nouveau 0000:01:00.0: fifo: fault 00 [READ] at 00000036fd548000 engine 00
[gr] client 01 [GPC0/T1_0] reason 00 [PDE] on channel 4 [00ff796000
vkcube[102732]]
nouveau 0000:01:00.0: vkcube[102732]: error fencing pushbuf: -19
0xb5bcd68000 and 0x36fd548000 are nonsense addresses for a card with 4 GiB of
VRAM. I saw the same kind of thing on 2026-08-28 (0x88a3927000, 0x5cdd773000).
So depending on the boot I get reason 01 [PDE_SIZE] at one fixed plausible
address, or reason 00 [PDE] at wild ones. I have no idea what decides which.
One more data point. Since the faulting access is the host reading the push
buffer, and nouveau puts push buffers in GART by default, I tried
nouveau.vram_pushbuf=1 (verified present in the initramfs). The [PDE_SIZE]
faults disappear entirely and are replaced by:
nouveau 0000:01:00.0: fifo: PBDMA0: 00000008 [HCE_ILLEGAL_MTHD] ch 3 00001c9c
00013000
nouveau 0000:01:00.0: fifo: PBDMA0: 00000008 [HCE_ILLEGAL_MTHD] ch 3 00001c9c
fde02dd5
nouveau 0000:01:00.0: glmark2[19837]: failed to idle channel 3
Rendering still fails, but the rejected data words mix plausible values with
what looks like garbage. I'm not able to tell whether that's the same bug seen
from another angle or a second one. The system is back on the default (GART)
setting now.
Things I checked and ruled out: runtime PM (runtime_status read "suspended"
right before each run of a series, results unchanged), the PRIME copy path
(--off-screen bypasses it), clocks (the card stays at 405/810 MHz; forcing
pstate 0f gives 911/2002 and changes nothing), missing firmware (no request is
made), leftovers from the proprietary driver (nothing installed, no nouveau
blacklist, no glx diversions). The proprietary driver isn't a workaround either:
Debian only ships branch 550 since 580 dropped Maxwell, and with 550.163.01
loaded, nvidia-smi works fine but vkCreateDevice fails with
VK_ERROR_INITIALIZATION_FAILED for every client I tried.
I also tested Mesa 26.2.1-2 from experimental: no more SIGSEGV, but rendering
drops to about 1 FPS with ~1000 [DEVICE] FIFO errors and the channel never
idles. That was a single run though, before I understood that results vary from
run to run, so it probably deserves a retest with the loop above.
Happy to test patches, try other kernels, or collect anything else that would
help; apitrace, MESA_DEBUG, nouveau debug parameters, full dmesg.
-- System Information:
Debian Release: forky/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 7.1.13+deb14-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
