On 1/28/26 11:39, Christian König wrote: > On 1/27/26 23:57, Alex Deucher wrote: >> On Tue, Jan 27, 2026 at 5:53 PM Hamza Mahfooz >> <[email protected]> wrote: >>> >>> On Mon, Jan 26, 2026 at 09:20:55AM -0500, Alex Deucher wrote: >>>> I suspect just calling drm_crtc_send_vblank_event() here on the >>>> relevant crtcs would be enough. >>>> >>> >>> Seems like an interesting idea, though I would imagine we would still >>> want to attempt a reset (of some kind) assuming that the subsequent page >>> flip also experiences a timeout. >> >> Is it actually a timeout or just missed interrupts? I'm wondering if >> some power feature races with the modeset and causes the interrupt to >> get missed from time to time. > > That is my strong suspicion as well. > > Even if we missed a vblank interrupt that thing is reoccurring, so the worst > thing that can happen is that we delayed reporting back success by one frame. > > So something must have turned the CRTC fully off.
Not sure that's a generally valid conclusion (do the gitlab issues talk about the display going black, or about it staying on but freezing?). AFAIR at least in some cases amdgpu uses a dedicated "page flip" interrupt instead of the vblank interrupt, in which case missing a single interrupt could cause a timeout. P.S. Completing the atomic commit and sending the completion event must work even if user space turns off any CRTCs as part of the commit[0]. So your hypothesis would be a kernel bug, accidentally turning off the CRTC and/or not handling a CRTC getting turned off correctly. [0] If any CRTC for which the commit has state is off both before and after the commit though, the commit fails with an error before it could result in a timeout. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
