Wednesday, May 3, 2017
Installation of Fedora 25 went smoothly, time to enable that graphic card...
NVIDIA driver installation
Went ahead and downloaded the latest NVIDIA drivers. That's version 375.39.
First installation did not find the kernel sources, so I ran a dnf install kernel-devel. That still did not work.
It took me a little while to figure out that I had done a dnf update, and I was still running with the old kernel, so it was looking at the wrong sources. Rebooted.
The installation now finds the kernel sources, but still fails to build the NVIDIA modules:
/tmp/selfgz2292/NVIDIA-Linux-x86_64-375.39/kernel/nvidia-drm/nvidia-drm-priv.h:37:25: fatal error: linux/fence.h: No such file or directory #include
Apparently, this is a known issue: NVIDIA 375.39 does not build on kernel 4.10. So let's reboot on 4.8, dnf install kernel-devel-4.8.6-300.fc25.x86_64 and try again.
Still fails, now it says it's unable to load 'nvidia.ko'. Apparently, this is SELinux doing it's thing again, which is, mostly, to annoy people with cryptic error messages and prevent legitimate operations with no easy way to say "Yes, I know what I'm doing" (no, running scripts is not an easy way).
Running SELinux troubleshooter, which forces me to do this:
ausearch -c 'nvidia-installe' --raw | audit2allow -M my-nvidia-installe semodule -X 300 -i my-nvidia-installe.pp
But this time the installer goes farther. It complains about an incomplete installation of libglvnd, but other than that, it works fine. The problem remains that I'm stuck with a 4.8 kernel for now.
Enabled remote desktop, now I can access Turbo as my "third screen", which happens to also be connected to it "natively". But that gives me better integration with the mouse and keyboard. It's fun, because I see the same thing with VNC or directly, but now I don't have to switch keyboards all the time (although I stil can).
Restoring VMs: Disk space issues
Meanwhile, tried to copy VM image files into /var/lib/libvirt/images, immediately ran into a "low disk space" situation.
Building and testing Tao
Rebuilding Tao3D on this machine. Let's see how fast it really is
Well, the machine is quite fast building Tao (about 1 minute 50 includign configuration). But then Tao crashes right away. As usual, the 'debug' version does not crash. I have to investigate where this comes from someday.
But for what I want to test, which is the "3DIVART" collection (a collection of shaders from ShaderToy adapted for auto-stereoscopic visualization), I think that debug vs. opt does not matter much.
It's slightly disappointing, actually. While the Dali Clock works perfectly well, the Manta RayTrace is relatively slow. It certainly does not feel like 30 FPS, even if that's what Tao reports.
It may be a thermal issue, because the playback is very irregular. It starts fast and degrades. I tried disconnecting my VNC session to see if that changes anything, and it does not seem to play much of a role. Even Fractal Mountains is slow (21 FPS), whereas I'm pretty sure it runs quite well on other machines.
It's really a GPU issue: changing the resolution to something smaller, e.g. 1280x720, fixes the problem to a large extent.
Rebuilding Spice branches on Turbo
Transferred the various Spice branches I had salvaged from Muse, which is still undergoing filesystem repair. Building them, I ran into the usual suspects, notably:
make[4]: Entering directory '/home/ddd/Work/spice/spice/spice-common/common' GEN generated_client_demarshallers.c Makefile:809: recipe for target 'generated_client_demarshallers.c' failed make[4]: *** [generated_client_demarshallers.c] Error 1 make[4]: Leaving directory '/home/ddd/Work/spice/spice/spice-common/common' Makefile:455: recipe for target 'all-recursive' failed
which is fixed with pip install six pyparsing. But then I get something that looks new to me:
CC net-utils.lo In file included from net-utils.c:30:0: net-utils.c: In function 'red_socket_set_keepalive': ../spice-common/common/log.h:69:5: error: implicit declaration of function 'fprintf' [-Werror=implicit-function-declaration] fprintf(stderr, "%s: " format "n", __FUNCTION__, ## __VA_ARGS__); ^ net-utils.c:47:13: note: in expansion of macro 'spice_printerr' spice_printerr("setsockopt for keepalive failed, %s", strerror(errno)); ^~~~~~~~~~~~~~ ../spice-common/common/log.h:69:5: error: incompatible implicit declaration of built-in function 'fprintf' [-Werror] fprintf(stderr, "%s: " format "n", __FUNCTION__, ## __VA_ARGS__); ^
That may be a result of my own work on that branch, which I had done "in the dark" on the Mac. So maybe there is some header difference that I need to take into account.