Investigating the 3D acceleration issues that I ran into last week.
3D acceleration investigation
I will spend some time trying to isolate which component causes problems for 3D acceleration. My current hypothesis is that the issue was with some dnf update.
Status
The current status is the following:
- On Big, the VM stopped working. It was updated after installation
- On Muse, a VM built from the original Fedora 25 ISO image works
Cloning VM and updating
I cloned the Fedora 25 VM. Then I updated it with dnf udpate. This confirms that the problem resides in this update. The full install log is here.
I also confirmed that Extreme Tux Racer works perfectly well on the original ISO file. The bad news, though, is that I installed it with the Software application, and that in that case, it does not seem like what has been installed shows up in /var/log/dnf.log.
Undoing last transaction does not work
Undoing the whole update. Listing the update with dnf history list. This shows that the update was transaction #6. Unfortunately, trying to undo this transaction with dnf history undo 6 fails telling me
No package ffmpeg-libs-0:3.1.6-1.fc25.x86_64 available.
So the operation cannot be undone that easily. Time to use the clone to upgrade invidual packages.
Upgrading step by step
My first candidate is Mesa. Running dnf udpate mesa-dri-drivers actually adds mesa-filesystem. But then, glxgears does not work anymore, giving me:
The subsystem type is not supported yet.
Downgrading just that package works. I had made a filesystem BTRFS snapshot, just in case 🙂
Updating all the other mesa packages:
$ dnf update mesa-dri-drivers mesa-filesystem mesa-libEGL mesa-libEGL-devel mesa-libGL mesa-libGL-devel mesa-libGLES mesa-libgbm mesa-libglapi mesa-libwayland-egl mesa-libxatracker
Still failing with a segfault after showing
The subsystem type is not supported yet.
There is a patch that removed that message “recently” (october 2016). That does not explain the segmentation fault. But that may indicate that there is a relationship with the kernel. Updating all kernels components and rebooting. Things still work. Kernel ruled out.
Updating xorg-x11-server-Xorg. Things still work.
Updating xorg-x11-qxl driver. Things still work.
Updating all other xorg-x11 components. Things still work.
Re-trying the mesa components update after having updated both QXL and Xorg. Still the same failure mode (Subsystem type). Reverting.
Updating all libX11 components. Things still work. Mesa update still fails the same way, reverting again.
Updating libdrm and libdrm-devel. Things still work. Updating Mesa now works. So this is interesting, because now I have most of the stuff I thought could cause the problem active, and it works.
Updating further llvm-libs. OK. Updating SDL2. OK. Ah, wait, no. I now have the following error message:
libGL error: MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. GL_RENDERER = Gallium 0.4 on virgl GL_VERSION = 3.0 Mesa 13.0.3 GL_VENDOR = Red Hat
So I guess I need to backtrack a bit. Undoing SDL2 and llvm-libs still gives me the same error message. Undoing mesa brings me back a functional system without error message.
Time to split mesa into individual chunks. I was lucky, the first one, mesa-dri-drivers + mesa-filesystem broke things. I tried to install only the rest, I still get one MESA-LOADER error (instead of two).
Downgrading the bad system
For a scenario like this, you have to love dnf downgrade. Tried downgrading libdrm, and I get the same subsystem type error. That’s consistent.
Downgrading mesa-dri-drivers and mesa-filesystems, still not good. Same with all the mesa components, but no error message with MESA-LOADER anymore. Again, that paints a consistent picture compared to the upgraded system.
Downgraded a few other big chunks, so far without much luck…
