[Bug 2165201] Re: GT216GLM display hangs when changing Nouveau pstate during an active graphics workload

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165201 Title: GT216GLM display hangs when changing Nouveau pstate during an active graphics workload Status in linux package in Ubuntu: New Bug description: I encountered a complete display freeze while manually selecting Nouveau performance states through the debugfs pstate interface on an NVIDIA GT216GLM (Quadro FX 880M). The freeze occurred during a repeated-transition test with glxgears active and required a forced powerdown. Hardware and software: - Lenovo ThinkPad W510 - NVIDIA GT216GLM / Quadro FX 880M, PCI ID 10de:0a3c, revision A2 - GPU subsystem ID 17aa:2145 - GPU VBIOS 70.16.5f.00.0d - Linux Mint 22.2, based on Ubuntu 24.04 Noble - Kernel 7.0.0-30-generic #30~24.04.1-Ubuntu - Kernel version signature Ubuntu 7.0.0-30.30~24.04.1-generic 7.0.12 - Mesa 25.2.8-0ubuntu0.24.04.2 - libdrm 2.4.125-1ubuntu0.1~24.04.2 - Xorg server 21.1.12-1ubuntu1.6 - xf86-video-nouveau 1.0.17-2ubuntu0.1 Only Nouveau was loaded for the GPU. The proprietary NVIDIA driver, nvidiafb, and rivafb were not loaded. Nouveau exposes the following states through /sys/kernel/debug/dri/0000:01:00.0/pstate: 03 core 135 MHz, shader 270 MHz, memory 135 MHz 07 core 405 MHz, shader 810 MHz, memory 324 MHz 0f core 550 MHz, shader 1210 MHz, memory 790 MHz A small experimental userspace governor selected 03 after ten seconds of inactivity and 0f after detecting graphics activity. It changed states by writing the two-character hexadecimal state followed by a newline to the debugfs pstate file. Write attempts were limited to no more than one per second and were made only when the requested state differed from the last retained state. Several isolated pstate transitions and complete 03 to 0f to 03 cycles completed without visible display problems. A hardware VDPAU decoding test also completed a full 03 to 0f to 03 transition successfully. For the failing test, the governor was left running while glxgears was started and stopped repeatedly to exercise multiple LOW-to-HIGH-to-LOW transitions. The display froze during the third graphics-workload cycle. Expected result: Nouveau should either complete a supported manual pstate transition safely or reject or defer the request without hanging PGRAPH and the display server. Actual result: The kernel log first reported an illegal graphics method from glxgears and a trapped PGRAPH write from Xorg. Two seconds later, the Nouveau pstate worker timed out in gt215_clk_pre(). Nouveau then repeatedly reported PGRAPH TLB flush idle timeout fail, and Xorg eventually failed to idle its channel. The initial failure sequence was: nouveau 0000:01:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] nouveau 0000:01:00.0: gr: TRAP DISPATCH_QUERY nouveau 0000:01:00.0: gr: no stuck command? nouveau 0000:01:00.0: gr: 00300010 [ILLEGAL_MTHD] ch 8 [003efdc000 glxgears[41630]] subc 3 class 8597 mthd 15e0 data a9a80000 nouveau 0000:01:00.0: fb: trapped write at 0000000000 on channel 2 [3fa90000 Xorg[1130]] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 02 [QUERY] reason 00000006 [NULL_DMAOBJ] nouveau 0000:01:00.0: gr: PGRAPH TLB flush idle timeout fail nouveau 0000:01:00.0: gr: PGRAPH_STATUS 0007ff13 [BUSY DISPATCH UNK4 CTXPROG VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL ENG2D RMASK] nouveau 0000:01:00.0: timeout WARNING: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:331 at gt215_clk_pre+0x270/0x280 [nouveau] Workqueue: events nvkm_pstate_work [nouveau] Call Trace: gt215_clk_prog+0x38/0x230 [nouveau] nvkm_cstate_prog.constprop.0+0x260/0x280 [nouveau] nvkm_pstate_work+0x1a3/0x280 [nouveau] The PGRAPH TLB flush idle timeout fail message repeated approximately every two seconds until shutdown. The last relevant message was: nouveau 0000:01:00.0: Xorg[1130]: failed to idle channel 8 [Xorg[1130]] I have not attempted to reproduce this again because it risks another forced powerdown. A similar gt215_clk_pre() timeout followed by PGRAPH TLB-flush failures was reported when reclocking a GT218 during an active WebGL workload in 2016: https://www.mail-archive.com/dri-devel%40lists.freedesktop.org/msg153861.html Older GT215 reports also show the same repeated PGRAPH TLB-flush failure pattern: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/977588 Regression status is unknown. I have not repeated this hazardous test using another kernel. I would particularly like to know whether manual GT216 pstate selection is expected to be safe while graphics channels are active, whether there is a known fix for this gt215_clk_pre() timeout, and whether the driver can reject or defer reclocking when PGRAPH cannot become idle. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165201/+subscriptions