[drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out - when using vblank_mode=0

Brief summary of the problem:

The whole system freezes and I need to reboot it every time this happens.

Hardware description:

CPU: Intel i5-4460
RAM: 16 GB
GPU: AMD R9 380
(Maybe related) Tripple monitor setup: 1 x 1600x900 (DVI), 1 x 1920x1080 (DVI), 1 x 1920x1080 (HDMI)

System information:

Kernel: 5.14 (5.14.2-1-MANJARO)
Mesa 21.2.1-1
Window manager: KWin

Additional info:

One day it happens 4/5 times and the next day everything works just fine. No idea what causes that crash.

Logs from one of the crashes: https://pastebin.com/wfKwpc3B

Full dmesg log captured right after the crash occurred: dmesg.txt

changed the description

added AMDgpu DC labels

can you attach whole dmesg? You also can try the following patches: https://lore.kernel.org/all/20210920163922.313113287@linuxfoundation.org/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f02abeb0779700c308e661a412451b38962b8a0b

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8066008482e533e91934bee49765bf8b4a7c40db

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fefc01f042f44ede373ee66773b8238dd8fdcb55

changed the description

I attached the whole dmesg log as you asked.

As for the patches, I can try them but as the bug is not easily reproducible it's not easy to say if any of them worked or if the code responsible for the bug didn't got executed yet.

If I'm not mistaken all of these patches were included in the latest 5.15-rc2 release, so I can try them by using this kernel version right?

yes, You can try 5.15-rc2. But it seems that your case are different. It has no error "AMD-Vi: Event logged [IO_PAGE_FAULT...]".

It's not like I'm impatient, but due to this bug I lost my work countless times and sometimes I'm scared to start some real work because I know it will interrupt me half way. I even had to write this post twice because of it. Is there a way I can help / provide more info which would prove helpful in further debugging this issue?

Does setting pci=noats on the kernel command line in grub help?

I'm gonna try this and post if it makes any difference. But it's not easy to say as I don't know what exactly causes this bug.

So it crashed again, dmesg attached.

I changed the linux line in the grub config (on boot). (current contents of /proc/cmdline): BOOT_IMAGE=/boot/vmlinuz-5.14-x86_64 root=UUID=8fe7bcb7-ed34-4705-a0a1-33083806ce28 rw quiet apparmor=1 security=apparmor udev.log_priority=3 resume=/dev/sdb2 pci=noats

Some things I want to add:

• It seems to happen most of the times when I interact with the X11 windows. So opening, closing, minimizing, maximizing a window.
• My current "workaround" is to switch to another TTY and kill the startplasma_x11 process which then reopens and brings up the SDDM. (but I loose all the opened applications)

dmesg.txt

Does this relate to my issue? #1715 (closed)

Is there a way to NOT loose all the opened apps if the driver crashes? This would be my actual workaround until this get's fixed.

Nope. At least not in Manjaro. Have you installed AMD drivers for X btw? Not sure exactly which drivers R9 380 should have.

iommu=pt in the kernel command line might help with the AMD-Vi Page Fault errors.

I'm not sure if that's what you meant but I am using the amdgpu kernel module + pacman -Q | grep amd shows two packages: mhwd-amdgpu and xf86-video-amdgpu.

I will try setting the iommu=pt kernel option but I'm not sure if that's related to the crash.

Have you tried booting the kernel with pci=nomsi? Just to rule out any masking issues.

Which firmware version are you running? (linux-firmware package)

The linux-firmware version I'm using: 20210919.d526e04-1

I will let you know if the pci=nomsi option makes any difference.

Were you stable on linux-firmware 20210315?

I'm not sure. I have this problem since around beginning of September and there were multiple updates since then. But judging by the name if this 20210315 version is from March, then it most likely worked just fine.

Just figuring if a rollback of linux-firmware would be ok to make your system stable.