Message-ID: <ab52825d-8f26-4b52-af5d-4051760b2aa4@mailbox.org>
Date: Wed, 28 Jan 2026 15:25:09 +0100
From: Michel Dänzer <michel.daenzer@...lbox.org>
To: Christian König <christian.koenig@....com>,
 Timur Kristóf <timur.kristof@...il.com>,
 Alex Deucher <alexdeucher@...il.com>,
 Hamza Mahfooz <someguy@...ective-light.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
 dri-devel@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>,
 Rodrigo Siqueira <siqueira@...lia.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Sunil Khatri <sunil.khatri@....com>, Ce Sun <cesun102@....com>,
 Lijo Lazar <lijo.lazar@....com>, Kenneth Feng <kenneth.feng@....com>,
 Ivan Lipski <ivan.lipski@....com>, Alex Hung <alex.hung@....com>,
 Tom Chung <chiahsuan.chung@....com>, Melissa Wen <mwen@...lia.com>,
 Fangzhi Zuo <Jerry.Zuo@....com>, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout()

On 1/28/26 13:48, Christian König wrote:
> On 1/28/26 13:14, Timur Kristóf wrote:
>> On Wednesday, January 28, 2026 12:26:20 PM Central European Standard Time 
>> Michel Dänzer wrote:
>>> On 1/28/26 11:39, Christian König wrote:
>>>>
>>>> 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?).
>>
>> In all the bug reports I've seen about page flip timeouts, and in all the 
>> timeouts I've seen on my machine, the screen remains on, but frozen.
>> It doesn't go black and doesn't turn off.
>>
>> Christian, why would the CRTC be turned off?
> 
> Exactly that's the question we need to answer.
> 
> But from what you describe the CRTC keeps on, just doesn't send any more vblank events.

The vblank interrupt source getting accidentally disabled might be one possible cause though.


>>> 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].
> 
> Wait a second. What happens if we never complete that? So when the completion event is never signaled?
> 
> Does the kernel then reject any new atomic commit as well?

Fundamentally, current atomic KMS UAPI is that any attempt to do a commit before the previous one completes fails with EBUSY.

(Another possible scenario is that the commit completes as far as the kernel is concerned, but the completion events for it are never sent to user space for some reason. In that case, user space would hang waiting for the completion events. That's not the scenario we're talking about here though, or there would be no timeout in the kernel)


> If yes then I think that is not defensive at all. In other words when you are right and the page flip interrupt is used and missed then we are stuck forever.

I guess it's basically up to the driver to prevent that from happening. Other drivers don't seem to have such issues.


> In other words could it be that userspace does something illegal which the kernel fails to reject?

That's possible in theory, we haven't ruled out all simpler explanations on the kernel side though.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Powered by blists - more mailing lists