From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F264241663 for ; Wed, 28 Jan 2026 14:25:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769610324; cv=none; b=nkaQlE7xg6PyS9XvL/MtX/GN9dUFUeFOYPNAx0WHkvB+ilnhGEyK1oJdPts/1JafDZZ1zpg1c64eQAdl62pcx9Y9QEYYqJHEqG5Ov6vQcWbWOKf8gJ+Gp0Jb+t9EcLdFG0YFpevtBxWJEZEkbD8o36W1ovK+nScSq9IiEcQQlKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769610324; c=relaxed/simple; bh=n8yRdItJP9PJIxbakXfnOmJ/20W4FN6HI5RiC4rTIgQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eaiSdYWbz8MxqP+emHAqjDWOlYwokj82xWtwdygEvv+wLVE/FtgZCLqn2wiUM833t3y58HGX95o7PwWa7pM6U4BsDUITYQvky4Dde8u5ogF0qBRY8LcrjxYXo4kjeJHmQD/CunRgSlwcp8PIOANFoOGRAECldy2tOroNB/6JIdA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=bMa52G8O; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="bMa52G8O" Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4f1Pgf4tKQz9tjX; Wed, 28 Jan 2026 15:25:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1769610318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xo2PUTC7FFhnXypRzYjVg5zeByp0vVFeAjVGsUVuktU=; b=bMa52G8OAzbGFL2ILE7gP9CjU3nc0NM8cNvGHSzE8eI99EIbiuNdWqrFhOQ5xiV4ZPfHci AQ7cIcAtjgnZpKFNMHvrYhjrusC352sSxs92OMVMWKWSNny0folG6JyrtJEODt623DZ2CW VDVo2VKYRFItnDnZORkLB7XayD4Ub/owHd3bcAfovHb32mrQVkYikz/mXcwnGPQUkuGwBP 7zKAK2YxDbt5W8MzAUsBaphBFoV+m+0xqyIZlOQjZRCVF/9P+e1oCNIAFnrtjZ7kc4A3mp 4sNouoo+WrptnXW23uO3Rt9MnNanAcuuOoLGykUMJ/f8u2iCF18Zy5uCJIuP7g== Message-ID: Date: Wed, 28 Jan 2026 15:25:09 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout() To: =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Timur_Krist=C3=B3f?= , Alex Deucher , Hamza Mahfooz Cc: Mario Limonciello , dri-devel@lists.freedesktop.org, Alex Deucher , David Airlie , Simona Vetter , Harry Wentland , Leo Li , Rodrigo Siqueira , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Sunil Khatri , Ce Sun , Lijo Lazar , Kenneth Feng , Ivan Lipski , Alex Hung , Tom Chung , Melissa Wen , Fangzhi Zuo , amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260123000537.2450496-1-someguy@effective-light.com> <17cd6378-e3fa-419b-90d3-7e0549817110@amd.com> <2203806.9o76ZdvQCi@timur-hyperion> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: 9dd2d33cda4345fcdbb X-MBO-RS-META: oz8pm1kmkkhg3ezazqfhnxbg8hnzzqbk 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