A llvm bisect of the display freeze ended up concluding in mesa at radv: do not reset query pool during creation. I read this as a hint that the issue is on SteamVR's side and digging further on the driver side is peering into undefined driver behavior.
There's other issues going on around this symptom, but reverting that commit at least removes it from the list of failure cases.
I've just hit this with SteamVR 1.9.12, Mesa 19.3.0 and LLVM 9 (1:9~+20191211082622+c1a0a213378-1~exp1~20191211193200.102 for buster from apt.llvm.org). I'm going to switch to LLVM 8 for now, although it would be worth testing LLVM 10.
I haven't seen this issue in an extended period of time, with both SteamVR [beta] and SteamVR [linux_v1.14]. I suspect that something changed in the kernel (5.12) or llvm (12) to resolve this issue.
Nothing extracted yet.
Describe the bug
When starting SteamVR 1.8.6 using a debug build of LLVM 9 and mesa 19.2.0 or mesa git on my Polaris10 test box, the entire desktop can freeze including the mouse plane and no hint in dmesg. This occurs about 8/10 times, with 2/10 times it getting slightly further and getting a gfx ring timeout leading to a gpu reset. Here is the logs and minidumps I could gather from just after a gpu reset:
systemfreeze.tar.gz
Kernels tested: 5.2.11 with "drm/amd/display: Allow commits with no planes active" reverted.
5.3.1 with an equivalent workaround.
Each of the following separately avoids the issue:
Building mesa 19.2.0 and mesa git master against llvm 8.0.1 is not affected by this issue.
Building release builds of llvm 9 and mesa avoids the desktop freeze, but the chance of gfx ring timeout leading to a gpu reset remains.
Reverting to SteamVR 1.7.15 avoids the issue.
Furthermore, running 1.7.15 before 1.8.6 avoids the issue.
To Reproduce
Steps to reproduce the behavior:
System Information (please complete the following information):