Further update since Valve is unlikely to respond at elast to me.
The issue with accessing debugfs remains. Likely permitted in SteamOS but allowing users to set kernel trace events is completely the wrong thing to do. ./steamapps/common/SteamVR/bin/linux64/chmod_trace_marker
... is just silly.
The HMD firmware has corrupted itself twice since this happened requiring a reflash with
steamapps/common/SteamVR/tools/lighthouse/bin/linux64/lighthouse_watchman_update
NONE of the issues above happen outside steam. Running vrstartup directly and the hellovr demo from OpenVR for example runs fine. Funny thing is if you can figure out how to launch Valve's applications directly most of them DO work, just not through Steam.
Spamming syslog and the console also appears to pound the USB bus which added to X freezing as I had the vive plugged into a hub shared with the consoles keyboard and mouse. Which brings up the last point -- Make sure your Vive is on a dedicated USB port or you run the risk of saturating not only the USB bandwidth but as I did, power (both controllers were plugged in). The Vive nor software will warn you. An excellent tool is lsusb.py (not to be confused with lsusb).
The system freezes are caused by an NVIDIA driver bug; while we wait for a fixed driver it is recommended to disable the 'Allow Flipping' NVIDIA setting on your main desktop. All the other behaviors you documented are expected.
The built-in GPU profiling tool uses ftrace for data collection, so it is useful to interleave debug messages directly with the other tracepoints by going through this debugfs interface.
Ftrace is not available though, yet the client continues trying.
Re the NVIDIA bug, which one are you refering to?
Both #123 and #53 are probably caused by the NVIDIA driver bug.
It tries opening the trace_marker for every performance debugging message it prints; not ideal, but it's a fast operation if it fails, since it doesn't actually hit the disk. If you enable "GPU profiling" and restart SteamVR, it'll give you the option to run a few commands with sudo, to make trace-record and chmod_trace_marker setuid root, so that ftrace can be used for GPU profiling. Then hitting F6 on the mirror window will cut the last few seconds worth of performance data and open gpuvis for inspection. I don't have any reason to believe trying to open the ftrace device node when GPU profiling disabled is causing any issues at this point, performance or otherwise, but we can make it try less often if you have data showing it does.
$ { date; strace -f -p `pidof vrcompositor` -c & sleep 10; kill $! ;date; }
Thu Oct 18 10:31:52 EDT 2018
[1] 103607
strace: Process 103343 attached with 7 threads
strace: Process 103343 detached
strace: Process 103350 detached
strace: Process 103351 detached
strace: Process 103353 detached
strace: Process 103354 detached
strace: Process 103358 detached
strace: Process 103501 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
46.56 8.589664 43164 199 select
21.11 3.894412 4215 924 nanosleep
16.75 3.089836 1129 2737 poll
6.07 1.119150 12 92979 clock_gettime
4.02 0.741729 13 55298 53514 open
2.45 0.452054 51 8841 456 futex
1.68 0.309183 43 7136 ioctl
0.27 0.049830 18 2769 tgkill
0.21 0.038862 22 1784 close
0.16 0.029523 11 2675 getpid
0.16 0.028802 32 892 read
0.13 0.023504 26 892 munmap
0.12 0.022060 25 892 mmap
0.10 0.018275 20 923 923 recvmsg
0.08 0.015447 17 892 fstat
0.08 0.014434 16 892 stat
0.06 0.010758 12 892 fcntl
0.02 0.003039 1013 3 restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00 18.450562 181620 54893 total
Thu Oct 18 10:32:02 EDT 2018
[1]+ Done strace -f -p `pidof vrcompositor` -c
5.5k calls/s and 18 seconds CPU for a process sitting idle. It is essentially pegging a CPU @ 4GHz
Nothing extracted yet.
How To Collect SteamVR System Information:
Your system information
Please describe your issue in as much detail as possible:
vrcompositor spins consuming CPU when system tracing is unavailable due to debugfs not being mounted. It shouldn't do that. We wont' talk about the fact that this also brings X to it's knees despite the GPU having very little load (25%) nor that simply mounting debugfs drops what little load there is to ~3%. Steam still has no access to debug tracing (what distro allows that??)
Steps for reproducing this issue:
strace
Ater mounting:
You're not reading those timestamps wrong, it's going ballistic.
I don't actually know what is going on now as it's complaining the firmware is out of date yet shows no update available??
Update: I was able to recover the firmware. SteamVR is however hosed to the point it stalls the GPU but not because of CPU. It literally stops rendering frames. FPS display drops to 1.
Eventually these started popping up:
Possibly related: #53 ?
Restarting Steam at all results in a console flood ( hundreds per second) of
The HMD is indeed turned off. At a rate of 30/s Steam is actually spamming the hell out of SYSLOG?? What on earth.
These are no doubt now cascading problems but bugs none the less.