On 2026-03-03 03:17, Shengyu Qu wrote:
>> Here's a patch that inserts a few trace events.
>> https://pastebin.com/dpLnVSbu
>>
>> Could you try to reproduce the hang again while recording these trace events?
>> Using trace-cmd (with stack trace enabled '-T'):
>
> I think Michele said that the timeout issue would be masked by drm.debug due
> to overhead?
I'm hoping that enabling a few tracepoints would have much less overhead than
enabling drm.debug. Depending on which debug flag, there can be a lot of dmesg
output.
If tracepoints ends up masking the race condition, I wonder if there's a way for
bpftrace to probe the lines where the tracepoints are inserted, and print out
the event's pointer address. If so, that's a viable alternative.
- Leo
>
>>
>> trace-cmd record -e amdgpu_dm_event_arm -e drm_vblank_dbg* -T
>> trace-cmd report trace.dat
>>
>> The timeout can be found by searching 'remaining_wait_ms=0'.
>>
>> Regarding the deferred vblank patchset, if the issue is indeed racing writes
>> of
>> amdgpu_crtc->event, then I don't imagine that patchset would help. It's
>> intended to solve a different race.
>>
>> Thanks,
>> Leo
>>
>>
>>>
>>> fixed [email protected] cc
>>
>
