clbr
commented
10 years ago I haven't once tested without an X session already running, as it didn't really make sense to measure graphics without graphics (no wayland here yet etc.).
The issue is not multiple processes holding it open (as that would happen fine when you start X first and radeontop / any 3d app afterwards), but the first opener getting master status.
Please try adding "drmDropMaster(drm_fd);" right before "const drmVersion * const ver = drmGetVersion(drm_fd);", or line 139 in detect.c. I cannot test that VRAM measurements still function with it as that machine has already been dismantled, so I'll need a confirmation that dropping master does not break VRAM reporting when running 3.15+ kernels.
OmegaPhil
I lost ~2-3 days of my main machine last weekend due to radeontop (0.8-1) holding on to '/dev/dri/card0' - this was a disaster that I originally attributed to a libdrm bug. This is the worst X issue I have ever faced, I literally had no idea how to fight it, and got me very angry (this is the kind of crap that resulted in me reinstalling Windows in the days of old).
radeontop is ran via 'radeontop -d -' in a script that processes its output and dumps to file, running permanently and started off at runlevel 2 via an init.d script. I haven't seen this issue before (and I have ran this setup for months), so I assume the latest update caused it. radeontop is no longer being ran because of this, but I don't mind reenabling to help with tracking the bug down.