Some test report: https://gitlab.freedesktop.org/drm/amd/-/issues/2950#note_3366575
在 2026/3/11 7:50, Leo Li 写道:
On 2026-03-09 12:49, Michele Palazzi wrote:On 3/6/26 09:37, Michele Palazzi wrote:Your new patch is an approach i already tried, and in my previous testing i still had flip timeouts, so while i think separating the cursor events makes sense and is correct, the root cause could be different from what i initially assumed and sending the cursor events immediately was masking it by relieving pressure.Leo i finally reproduced with a bpftrace that tracks event ARM (flip vs cursor) and DELIVER using kprobe offsets into the inlined prepare_flip_isr. The hung commit is a cursor-only update on CRTC 0: 31088420 dm_pflip_high_irq [tid=0] 31088420 DELIVER event=ffff8b519225c580 crtc=0 [tid=0] 31088420 WAIT_FLIP EXIT 2ms [tid=203071] 31088421 ARM flip event=ffff8b4f26184c00 acrtc=ffff8b4ed1ddd000 [tid=203071] 31088421 commit_hw_done [tid=203071] 31088421 WAIT_FLIP ENTER [tid=203071] 31088422 dm_pflip_high_irq [tid=0] 31088422 DELIVER event=ffff8b4f26184c00 crtc=1 [tid=0] 31088422 WAIT_FLIP EXIT 1ms [tid=203071] 31088425 ARM cursor event=ffff8b519225ce00 acrtc=ffff8b4ed1dde000 [tid=203071] 31088425 commit_hw_done [tid=203071] 31088425 WAIT_FLIP ENTER [tid=203071] 31088428 ARM flip event=ffff8b4f26184480 acrtc=ffff8b4ed1ddd000 [tid=208580] 31088428 commit_hw_done [tid=208580] 31088428 WAIT_FLIP ENTER [tid=208580] 31088429 dm_pflip_high_irq [tid=0] 31088429 DELIVER event=ffff8b4f26184480 crtc=1 [tid=0] 31088429 WAIT_FLIP EXIT 1ms [tid=208580] ... 10036ms silence for tid=203071 no dm_pflip_high_irq, no DELIVER, no drm_vblank_disable_and_save on CRTC 0 CRTC 1 continues normally throughout ... 31098462 WAIT_FLIP !!!TIMEOUT!!! waited 10036ms [tid=203071] acrtc ffff8b4ed1dde000 = CRTC 0 (confirmed from ARM+DELIVER correlation) acrtc ffff8b4ed1ddd000 = CRTC 1 Event ffff8b519225ce00 was armed as cursor on CRTC 0 and never delivered. No dm_pflip_high_irq fired for CRTC 0 during the entire 10s wait, and vblank was not disabled (no drm_vblank_disable_and_save in that window). CRTC 1 kept flowing normally throughout.Hi Michele, no dm_pflip_high_irq firing makes sense, since there's no new fb addresses being programmed on CRTC 0 due to the timeout. Did you see any dm_crtc_high_irq() or dm_vupdate_high_irq() on crtc0 after the timeout? An easy way to check would be to enable DRM vblank debug once you hit the flip_done timeout. The drm_dbg_vbl prints will start outputting to dmesg: echo 0x20 > /sys/module/drm/parameters/debug I'm also curious what the acrtc->event and ->pflip_status end up being when the timeout is hit. This debug diff should dump that without masking the issue: https://pastebin.com/u7hGR7L4 Thanks, LeoThe complete bpftrace is here https://pastebin.com/Xiju44Cy Note that i did this on tag v6.19
OpenPGP_0xE3520CC91929C8E7.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
