Update 2026-08-10 — 5th occurrence; root cause now fully understood; workaround identified ==========================================================================================
SUMMARY ------- The crash occurred again today (Aug 10) on kernel 7.0.0-28-generic with firmware linux-firmware-amd-graphics 20260319.git217ca6e4-0ubuntu3.1. Neither the kernel update nor the firmware update from Jul 24 resolved the issue. This boot produced the most complete trace yet, revealing that Chrome's GPU process enters a permanently broken state after a Teams video call and continues submitting null pointers to the GPU for the remainder of the session — with each submission being a lottery on whether it kills gnome-shell. THIS BOOT: THREE CHROME GPU FAULTS, ONE FATAL (session lost at 11:25) ---------------------------------------------------------------------- 09:33:50 Chrome GPU pid 13682 addr 0x000000003f800000 ring gfx_0.0.0 victim: Chrome ring reset succeeded -> session survived 09:39:40 Chrome GPU pid 118498 addr 0x0000000000000000 ring gfx_0.0.0 victim: Chrome ring reset succeeded -> session survived 11:25:06 Chrome GPU pid 118498 addr 0x0000000000000000 ring gfx_0.1.0 victim: gnome-shell ring reset FAILED, MODE2 reset -> SESSION LOST The counter in the fatal crash was "GPU reset(3) succeeded!", confirming resets 1 and 2 occurred silently earlier in the session without the user noticing. DETAILED SEQUENCE ----------------- ~09:32 — Teams video call started. Chrome immediately logged an internal Wayland display sync error: [wayland_frame_manager.cc:692] The server has buggy presentation feedback. Discarding all presentation feedback requests in all frames except the last 3. 09:33:50 — Chrome GPU process (pid 13682) submitted an invalid address to the GPU. gfx_0.0.0 ring timed out with Chrome as the victim. Ring-level reset succeeded. Chrome displayed a visible error notification to the user. User dismissed it. 09:33–09:35 — Chrome restarted its GPU process (new pid 118498). Screen sharing started. OpenH264 (Chrome's software video encoder) began logging broken frame timing: [OpenH264] Actual input framerate 0.000000 is different from framerate in setting 30.000000 [OpenH264] Actual input framerate 0.000000 is different from framerate in setting 15.000000 These continued for several minutes, indicating the screen capture pipeline was stalled while the encoder kept running. 09:39:40 — Chrome GPU process pid 118498 submitted a null pointer (0x0000000000000000) to the GPU. gfx_0.0.0 ring timed out, Chrome was the victim, ring reset succeeded. User saw nothing — session survived. 09:39–11:25 — Teams call ended. User continued working (GitLab in Chrome). Chrome's GPU process pid 118498 remained running in its degraded state. 11:25:06 — Chrome GPU process pid 118498 submitted another null pointer (0x0000000000000000) to the GPU, 1h45m after the Teams call ended. This time gfx_0.1.0 timed out with gnome-shell (pid 7661) as the victim. Ring-level reset failed. Full MODE2 GPU reset triggered. gnome-shell lost its GPU context and exited with SIGABRT. All Wayland clients disconnected. Session lost. KEY OBSERVATIONS ---------------- 1. Chrome submits null pointers to the GPU after a Teams video call. The fault address 0x0000000000000000 appears in two of the three faults. This is not a marginal bad address — it is address zero. Chrome's GPU process is dereferencing a null pointer in its command buffer after the OpenH264/screen-share pipeline stalls. 2. The session loss is probabilistic, not deterministic. Whether gnome-shell dies depends entirely on which GPU ring it happens to be submitting work to at the moment Chrome's fault triggers the timeout. Two identical null pointer faults (09:39, 11:25) had opposite outcomes based purely on ring assignment. The user has no way to know the session is at risk. 3. Chrome's GPU process stays broken for hours after the video call ends. The process that caused the fatal crash (pid 118498) was the same process that survived the 09:39 fault. It continued submitting null pointers intermittently for 1h45m after the Teams call ended before finally hitting a fatal combination. 4. The ring-level reset reliably fails when gnome-shell is the victim. In all occurrences across all boots, "Ring gfx_0.1.0 reset failed" (with gnome-shell as victim) is always followed by a full MODE2 GPU reset. In contrast, "Ring gfx_0.0.0 reset" (with Chrome as victim) has always succeeded. This asymmetry in reset behaviour is a separate kernel/driver issue — gnome-shell should not be unrecoverable. WORKAROUND APPLIED ------------------ Adding the following to ~/.config/google-chrome/chrome_flags prevents Chrome from using the GPU for video decode/encode and rasterisation, eliminating the null pointer GPU submissions: --disable-features=VaapiVideoDecodeLinuxGL,VaapiVideoDecoder,VaapiVideoEncoder --disable-gpu-rasterization This forces Chrome's media pipeline through software paths only. The workaround is effective but lossy (higher CPU usage during video calls, no hardware video acceleration). SYSTEM STATE AT TIME OF CRASH ------------------------------ Kernel: 7.0.0-28-generic GPU: AMD Granite Ridge iGPU 1002:13c0 at 0000:70:00.0 AMD firmware: linux-firmware-amd-graphics 20260319.git217ca6e4-0ubuntu3.1 Mesa: 26.0.3-1ubuntu1 Chrome: 150.0.7871.186 Trigger: Microsoft Teams (web, in Chrome), screen sharing + video call CONCLUSION ---------- There are likely two bugs here that together cause the session loss: 1. (Chrome) Chrome's GPU process submits null pointers (0x0) to the GPU after the OpenH264/screen-share pipeline stalls during or after a Teams video call. Chrome should isolate GPU process crashes so they do not propagate to the system GPU. 2. (amdgpu / kernel) When gnome-shell is the victim of a ring timeout caused by another process's fault, gfx_0.1.0 ring reset consistently fails, requiring a full MODE2 GPU reset that destroys gnome-shell's context. The driver should be able to reset the ring and recover gnome-shell's context without a full device reset, as it already does successfully when Chrome is the sole victim on gfx_0.0.0. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2158614 Title: amdgpu: Granite Ridge iGPU gfx ring timeout after Chrome GPU page fault causes gnome-shell SIGABRT and session loss To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158614/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
