On Mon, Nov 29, 2021 at 04:31:57PM +0800, Jian-Hong Pan wrote: > Maxime Ripard <maxime@xxxxxxxxxx> 於 2021年11月26日 週五 下午11:45寫道： > > > > On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote: > > > Maxime Ripard <maxime@xxxxxxxxxx> 於 2021年11月18日 週四 下午6:40寫道： > > > > > > > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote: > > > > > Maxime Ripard <maxime@xxxxxxxxxx> 於 2021年11月17日 週三 下午5:45寫道： > > > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to > > > > > > atomic helpers") introduced a number of issues in corner cases, most of them > > > > > > showing themselves in the form of either a vblank timeout or use-after-free > > > > > > error. > > > > > > > > > > > > These patches should fix most of them, some of them still being debugged. > > > > > > > > > > > > Maxime > > > > > > > > > > > > Changes from v1: > > > > > > - Prevent a null pointer dereference > > > > > > > > > > > > Maxime Ripard (6): > > > > > > drm/vc4: kms: Wait for the commit before increasing our clock rate > > > > > > drm/vc4: kms: Fix return code check > > > > > > drm/vc4: kms: Add missing drm_crtc_commit_put > > > > > > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > > > > > > drm/vc4: kms: Don't duplicate pending commit > > > > > > drm/vc4: kms: Fix previous HVS commit wait > > > > > > > > > > > > drivers/gpu/drm/vc4/vc4_kms.c | 42 ++++++++++++++++------------------- > > > > > > 1 file changed, 19 insertions(+), 23 deletions(-) > > > > > > > > > > I tested the v2 patches based on latest mainline kernel with RPi 4B. > > > > > System can boot up into desktop environment. > > > > > > > > So the thing that was broken initially isn't anymore? > > > > > > No. It does not appear anymore. > > > > > > > > Although it still hit the bug [1], which might be under debugging, I > > > > > think these patches LGTM. > > > > > > > > The vblank timeout stuff is a symptom of various different bugs. Can you > > > > share your setup, your config.txt, and what you're doing to trigger it? > > > > > > I get the RPi boot firmware files from raspberrypi's repository at tag > > > 1.20211029 [1] > > > And, make system boots: > > > RPi firmware -> U-Boot -> Linux kernel (aarch64) with corresponding DTB > > > > > > The config.txt only has: > > > enable_uart=1 > > > arm_64bit=1 > > > kernel=uboot.bin > > > > > > This bug can be reproduced with es2gears command easily. May need to > > > wait it running a while. > > > > > > Mesa: 21.2.2 > > > libdrm: 2.4.107 > > > xserver/wayland: 1.20.11 Using wayland > > > > > > This bug happens with direct boot path as well: > > > RPi firmware -> Linux kernel (aarch64) with corresponding DTB > > > > > > I tried with Endless OS and Ubuntu's RPi 4B images. > > > An easy setup is using Ubuntu 21.10 RPi 4B image [2]. Then, replace > > > the kernel & device tree blob and edit the config.txt. > > > > Does it still appear if you raise the core clock in the config.txt file > > using: core_freq_min=600 ? > > It still appears when I raise the core clock in the config.txt file: > core_freq_min=600 That's weird, we had some issues like that already but could never point exactly what was going on. Is testing the official raspberrypi kernel an option for you? If so, trying the same workload with fkms would certainly help Maxime
Attachment:
signature.asc
Description: PGP signature
