linux-kernel - Re: [v2,1/2] drm/msm/dpu1: don't choke on disabling the writeback connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2138d887-f1bf-424a-b3e5-e827a39cc855@lausen.nl>
Date: Tue, 19 Nov 2024 09:33:26 -0500
From: Leonard Lausen <leonard@...sen.nl>
To: Johan Hovold <johan@...nel.org>, György Kurucz
 <me@...uczgy.com>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Rob Clark <robdclark@...il.com>
Cc: Abhinav Kumar <quic_abhinavk@...cinc.com>, Sean Paul <sean@...rly.run>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 Jeykumar Sankaran <jsanka@...eaurora.org>, stable@...r.kernel.org,
 Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [v2,1/2] drm/msm/dpu1: don't choke on disabling the writeback
 connector

Hi Johan,

> I'm seeing the same issue as György on the x1e80100 CRD and Lenovo
> ThinkPad T14s. Without this patch, the internal display fails to resume
> properly (switching VT brings it back) and the following errors are
> logged:
> 
> 	[dpu error]connector not connected 3
> 	[drm:drm_mode_config_helper_resume [drm_kms_helper]] *ERROR* Failed to resume (-22)
> 
> I see the same symptoms with Xorg as well as sway.

The issue of "internal display fails to resume properly (switching VT brings it back)"
also affects sc7180 platform during some resumes. Do you see the issue consistently
during every resume?

> Can we please get this fixed and backported as soon as possible?
> 
> Even if there are further issues with some "Night Light" functionality
> on one machine, keeping this bug as workaround does not seem warranted
> given that it breaks basic functionality for users.

I suspect this is not about "further issues with some 'Night Light' functionality
on one machine", but rather a more fundamental issue or race condition in the qcom
DRM devices stack, that is exposed when applying this patch. With this patch applied
DRM device state is lost after resume and setting the state is no longer possible.
Lots of kernel errors are printed if attempting to set DRM state such as the
Color Transform Matrix, when running a kernel with this patch applied.
Back in July 2024 I tested this patch on top of 6.9.8 and next-20240709,
observing below snippet being logged tens of times:

[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0
[drm:_dpu_rm_make_reservation] [dpu error]unable to find appropriate mixers
[drm:dpu_rm_reserve] [dpu error]failed to reserve hw resources: -119

Full logs are attached at https://gitlab.freedesktop.org/drm/msm/-/issues/58.

> The x1e80100 is the only platform I have access to with a writeback
> connector, but this regression potentially affects a whole host of older
> platforms as well.

Have you attempted setting CTM or other DRM state when running with this patch?

Best regards
Leonard