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,
Leo
>
> The complete bpftrace is here https://pastebin.com/Xiju44Cy
> Note that i did this on tag v6.19
>
>
