On 2026-03-04 09:00, Michele Palazzi wrote:
> On 3/3/26 20:07, Leo Li wrote:
>>
>>
>> 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
> So far i could not reproduce with your tracing patch applied, i could try to
> use bpftrace instead but it will take some time, i am quite busy these days.
Understood. If you haven't tried already, maybe dropping the stack trace (-T)
flag is worth a shot.
- Leo
