Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Bugzilla won't let me complete this report, but will allow Addl Comments, so here goes: The FlightGear simulator no longer will run on Fedora 24 as a normal user, but will run as root. That's unsanitary, and I won't permit it. I also discovered that glxinfo and glxgears also fail under F24, and not F23. I still have three recent F24 kernels and three less recent F23 kernels in a separate root partition. fgfs (and glxinfo and glxgears) run correctly on all F23 systems and none of the F24's. What I believe to be the relevant packages are perfectly symmetric: [dad@datair ~/f23] $ grep -i flight rpms.3 FlightGear-3.4.0-6.fc23.x86_64 FlightGear-Atlas-0.5.0-0.13.cvs20141002.fc23.x86_64 FlightGear-data-3.4.0-3.fc23.noarch [dad@datair ~/f23] $ grep -i nvidia rpms.3 akmod-nvidia-304xx-304.131-3.fc23.x86_64 kmod-nvidia-304xx-4.5.7-200.fc23.x86_64-304.131-3.fc23.x86_64 kmod-nvidia-304xx-4.5.7-202.fc23.x86_64-304.131-3.fc23.x86_64 kmod-nvidia-304xx-4.6.4-201.fc23.x86_64-304.131-3.fc23.x86_64 xorg-x11-drv-nvidia-304xx-304.131-1.fc23.x86_64 xorg-x11-drv-nvidia-304xx-libs-304.131-1.fc23.x86_64 [dad@datair ~/f23] $ grep -i glx rpms.3 glx-utils-8.2.0-4.fc23.x86_64 [dad@datair ~/f24] $ grep -i flight rpms.2 FlightGear-2016.1.2-2.fc24.x86_64 FlightGear-Atlas-0.5.0-0.23.cvs20141002.fc24.x86_64 FlightGear-data-2016.1.2-1.fc24.noarch [dad@datair ~/f24] $ grep -i nvidia rpms.2 akmod-nvidia-304xx-304.132-1.fc24.x86_64 kmod-nvidia-304xx-4.8.4-200.fc24.x86_64-304.132-1.fc24.x86_64 kmod-nvidia-304xx-4.8.6-201.fc24.x86_64-304.132-1.fc24.x86_64 kmod-nvidia-304xx-4.8.7-200.fc24.x86_64-304.132-1.fc24.x86_64 xorg-x11-drv-nvidia-304xx-304.132-1.fc24.x86_64 xorg-x11-drv-nvidia-304xx-libs-304.132-1.fc24.x86_64 [dad@datair ~/f24] $ grep -i glx rpms.2 glx-utils-8.3.0-3.fc24.x86_64 On F24, running fgfs as dad (me) fails with these error messages: $ fgfs ... Error: Unable to create OpenGL graphics context. getDefaultWindow: failed to create GraphicsContext Error: Unable to create OpenGL graphics context. getDefaultWindow: failed to create GraphicsContext ... That's puzzling. After some further groping in the dark, I discovered that both glxinfo and glxgears also fail to run as regular user but run correctly as root. That seems closer to the real problem, I think. I strongly suspect the fgfs program is entirely blameless. Here's the output of glxinfo, run by dad: (glxgears is similar) $ glxinfo name of display: :0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 87 Current serial number in output stream: 88 So, as a WAG, I'll ascribe this bug to this package: glx-utils-8.3.0-3.fc24.x86_64 Unfortunately, I have no real clue why these failures are occurring.
Your problem seems related to the way your commands interact with the nvidia driver. To debug such cases, you can try to run glxinfo under the strace program to check if glxinfo can access successfully to the nvidia device with /dev/nvidia* If it works as root and not as a regular user, bad permission on these files may be very possible (selinux related ?).
Created attachment 1231319 [details] strace glxinfo (as dad) strace of failed glxinfo
Created attachment 1231320 [details] strace glxinfo (as root)
Fabrice Bellet, thank you for your helpful suggestions. I apologize for my delayed response. 1) selinux is disabled: # sestatus SELinux status: disabled 2) The nvidia device files are fully read/write: # ll /dev/nvid* crw-rw-rw- 1 root root 195, 0 Dec 5 16:03 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Dec 5 16:03 /dev/nvidiactl 3) I ran $ strace glxinfo 2>&1 | tee glxinfo.str.dad and # strace glxinfo 2>&1 | tee glxinfo.str.root I tried to comprehend the dad case, which fails, but cannot detect the problem. Although I can see the beginning of the failure messages, I cannot perceive the triggering cause. That is, there are no failures to open specific files or nvidia devices that I can see that would trigger the "BadValue (integer parameter out of range for operation)" message. I used comm to compare the two files. They are similar up to the point of failure, but again, I cannot detect what fails. (There are an awful lot of getpid()'s in both files. One would think one would be enough.) Perhaps you can see the problem. I have attached both files. Sorry for the size.
This bug is dead, or maybe never existed. On my troublesome machine, I did a fresh install of Fedora 25 from the Live Xfce iso. After installing each batch of new packages, I tested glxinfo as dad and verified it worked correctly, saving nvidia for last. After installing nvidia-304xx, but before rebooting to use it, glxinfo failed! So I removed nvidia-304xx and glxinfo worked again. After some thought (!) I reinstalled nvidia-304xx, and this time rebooted. Eureka! glxinfo worked - as dad. So does fgfs, the FlightGear simulator. Based on the similarity of the error messages with nvidia installed but not being used, it just might be the case that my previous experience is now explained. But of course, I could never admit such idiocy.
Thanks, closing the bug report.