I’m trying to understand an issue - I installed some NCAR python visualization software (vapor), but it gives me this error message when I try to display data:
Message: GL Vendor String is MESA.
Graphics drivers may need to be reinstalled
I don’t really understand this - Is this due to the default 3D graphics that opensuse has now? (I thought that was called Neuveau or something…) I haven’t installed graphics drivers for my NVideo card since 11.something. I think it’s really tricky to do so now, but it might be the only way I can use this software. Is there a DIY on installing the NVidia drivers for 12.1 without getting into an unbootable system? I have a Zotoc GTX 550 Ti Nvidia knock-off actually. I have 12.1 x64 installed.
I found “Nvidia the hard way” - is that the only reliable way? Or is this a reliable way? SDB:NVIDIA drivers - openSUSE
Ok, installed default YaST NVidia driver for this video card, now the software complains:
patti@OS121-> ./vaporgui
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Segmentation fault
patti@OS121->
Does this mean anything to anyone? This looks worse than the MESA error I saw before.
I took a look in /etc/X11 and don’t see an xorg.conf - maybe something changed in opensuse since the last time I tried to configure displays, and this might be as simple as setting up an old-style xorg.conf file?
I guess I’ll try reverting to the non-NVidia drivers and see if xorg.conf appears.
The issue is beginning to look complicated. I left the NVidia drivers from YaST installed, and installed google earth. So it’s an opensuse problem, not a problem with that “vapor” code…
patti@OS121:/opt/google/earth/free> ./googleearth
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Xlib: extension "GLX" missing on display ":0".
Google Earth has caught signal 11.
We apologize for the inconvenience, but Google Earth has crashed.
This is a bug in the program, and should never happen under normal
circumstances. A bug report and debugging data have been written
to this text file:
/home/patti/.googleearth/crashlogs/crashlog-504a1709.txt
Please include this file if you submit a bug report to Google.
patti@OS121:/opt/google/earth/free>
I’ve been googling this issue - here is some relevant output - can anyone help diagnose?
(I wound up leaving the NVidia repo YaST drivers installed - but something didn’t install correctly)
OS121:/home/patti # glxinfo |grep renderer
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Error: couldn’t find RGB GLX visual
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
Xlib: extension “GLX” missing on display “:0”.
OS121:/home/patti #
EDIT: I’m out of my league here - every time I run nvidia-xconfig as root, it breaks xorg. Luckily I know enough command-line stuff to copy a backup xorg.conf file and get kde back. But right now I see:
OS121:/etc/X11 # ls -l
total 72
drwxr-xr-x 2 root root 4096 Jun 11 20:36 fs
drwxr-xr-x 2 root root 4096 Jun 11 20:36 lbxproxy
drwxr-xr-x 2 root root 4096 Jun 11 20:36 proxymngr
-rw-r–r-- 1 root root 797 Aug 28 17:48 qt_plugins_3.3rc
-rw------- 1 root root 0 Aug 28 17:48 .qt_plugins_3.3rc.lock
-rw-r–r-- 1 root root 954 Oct 29 2011 qtrc
-rw------- 1 root root 0 Aug 28 17:48 .qtrc.lock
drwxr-xr-x 4 root root 4096 Jun 11 20:36 rstart
drwxr-xr-x 2 root root 4096 Sep 7 08:30 xdm
-rw-r–r-- 1 root root 5708 Oct 22 2011 xim
drwxr-xr-x 2 root root 4096 Nov 10 2011 xim.d
drwxr-xr-x 3 root root 4096 Jul 17 00:35 xinit
-rw-r–r-- 1 root root 1353 Apr 12 2003 Xmodmap
-rw-r–r-- 1 root root 1049 Jun 20 2001 Xmodmap.remote
-rw-r–r-- 1 root root 0 Sep 7 09:10 xorg.conf
-rw-r–r-- 1 root root 0 Sep 7 09:01 xorg.conf.backup
-rw-r–r-- 1 root root 1325 Sep 7 08:53 xorg.conf-broke
-rw-r–r-- 1 root root 1325 Sep 7 09:01 xorg.conf.broke2
drwxr-xr-x 2 root root 4096 Jun 11 20:06 xorg.conf.d
-rw-r–r-- 1 root root 849 Jun 11 19:49 xorg.conf.install
-rw-r–r-- 1 root root 0 Sep 7 09:01 xorg.conf.nvidia-xconfig-original
-rw-r–r-- 1 root root 4017 Apr 22 2009 Xresources
OS121:/etc/X11 #
…I don’t understand why a working xorg.conf has zero bytes.
Any thoughts on how to get this working? I’ve been googling this error:
Xlib: extension “GLX” missing on display “:0”.
…and there doesn’t seem to be a simple fix. All I can tell is that it’s related to how my system is set up somehow.
Maybe I should try rolling back to the nuveau drivers? (not sure how to do that safely - without breaking kde-gui)
Thank You,
Patricia
EDIT: Hopefully helpful info…here is the xorg.conf that nvidia-xconfig created, but upon rebooting it would dump me to a console login (and startx would not work after logging on)
It looks like I’ve borked my video - I see both nouveau and nvidia
[FONT=arial](BTW: I just discovered an interesting bug in the website - if you try to change the font in an “CODE” section to monospace so it’s easier to read, the page freezes.)
[/FONT]
So you definitely want to use the proprietary driver from what I
understand. It looks as if noveau was not blacklisted for you.
In 12.1 it should work just to add
nomodeset
to the kernel parameters in the grub boot line.
To be sure that the nvidia driver you installed is compatible with your
kernel please post the output of
uname -a
cat /proc/cmdline
the first line shows your kernel, the second the parameters wich are at
the moment passed at startup.
I am a bit surprised about the nvidia-gfxG02-kmp-default you use, I
would expect on a standard system to see nvidia-gfxG02-kmp-desktop instead.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
OK - so is xorg.conf no longer used? I used to keep a backup of xorg.conf-works so that when kde gets broken, I can just reinstate it in order to get some sort of gui. I think it used to be called xorg.conf_install - if it indeed is now gone, is there a recommended replacement procedure to get a gui going in cases like this?
You have the wrong nvidia kernel module installed.
To answer your question about xorg.conf, it is used when it is there,
but a zero byte one will for sure lead to trouble and before you
experiment with a new one let us test without xorg.conf.
Install now nvidia-gfxG02-kmp-desktop and without xorg.conf do a reboot
afterwards. Let’s see if that was enough to make it work.
su -
zypper in nvidia-gfxG02-kmp-desktop
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Thank you again for the explanation. OK, I will do that, but first, I see in YaST that the nouveau x11 driver is installed - do I uninstall that one?
Also, is there a new file that replaces xorg.conf? If so, I should back it up and then if I break the desktop (so it dumps me to a command line after boot), I can replace it from backup in the command line.
Am 07.09.2012 23:46, schrieb PattiMichelle:
>
> Thank you again for the explanation. OK, I will do that, but first, I
> see in YaST that the nouveau x11 driver is installed - do I uninstall
> that one?
>
There is no need to uninstall it. From your output that glx is missing,
it is clear that your partial installation of the nvidia driver already
disabled KMS which is needed by noveau to work.
If you want to be absolutely sure uninstall it.
> Also, is there a new file that replaces xorg.conf?
No single file, xorg.conf is replaced by the directory
/etc/X11/xorg.conf.d/ and all what it contains, of course you can backup
that if you want to be on the safe side and also the xorg.conf.install
which is not used but contains what the system identified during the
installation phase.
> If so, I should
> back it up and then if I break the desktop (so it dumps me to a command
> line after boot), I can replace it from backup in the command line.
>
You likely have more success simply to boot to failsafe mode if you run
into trouble with X11, the failsafe mode will run a driver which is very
generic.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Thank you very much - now nvidia-settings doesn’t give the error, and google earth starts up OK. Thank you for taking the time to help. I’m really trying to learn a lot in a short time about how to build some NOAA/NCAR weather forecasting software, and these system problems are a thorn in the side.
Do you still recommend putting the nomodeset (I think that was the command) line in the startup menu.lst?
Have a great weekend! I’ll be trying to build fortran software:\
> Do you still recommend putting the nomodeset (I think that was the
> command) line in the startup menu.lst?
>
Not needed, this first idea was just to stop the KMS, the pure fact that
nvidia runs now shows it is not needed.
Your kernel and nvidia module are now consistent.
You can check
glxinfo | grep -i opengl
and should see the nvidia driver mention and an OpenGL version of 4.x
with your card.
> Have a great weekend! I’ll be trying to build fortran software:
>
Have much fun, I am programming myself Fortran since it was FORTRAN,
these days of course rarely and if (once or twice per year) it is
Fortran 2003 which has not much in common what it was a few decades ago
(not that I regret that).
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Thanks again - it does seem correct now…
OS121:/home/patti/00_GCMs/EMS_WRF/wrfems/runs/Korea2006/wrfprd # glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 550 Ti/PCIe/SSE2
OpenGL version string: 4.2.0 NVIDIA 304.43
OpenGL extensions:
OS121:/home/patti/00_GCMs/EMS_WRF/wrfems/runs/Korea2006/wrfprd #
But I started getting segfaults on some numerical software - that’s probably just coincidence - but there is sligltly weird video behavior… The black lines in gui boxes on some software acts as if it’s showing little line segments of an underlying window that is on another screen. This is an alpha blending problem in the video driver, I believe. It is ostensibely black, but it’s actually clear showing up another window (on another screen). I’ve never seen it before. I’m going to try the nomodeset and see if that changes anything.
EDIT: The nomodeset addition seemed to take care of that weird behavior. Probably the segfaults were unrelated, but you never know. I have a Phenom II x6 overclocked to 4GHz and am stressing it a lot with numerical calculations. I did several tests (“burn” and memtest86) to make sure it was stable. Do you know of a good memory/cpu tester under OpenSuSE?
Hah! I am just trying to learn Fortran on-the-job. I rely a lot of good GUIs and helpfiles that have syntax highlighting and ever correction. I used to use QUickbasic and Turbo Pascal (which I loved). Nowadays, I gotta learn Fortran… 77 and 90 seem to be what everyone uses.
I also have to learn Perl and Python. Geany seems to make the Python learning experience easier and I’m pretty sure one can use Python to write scripts instead of Perl. I was told Perl is “write only” so I am afraid of trying to learn it from reading other’s scripts.
Am 08.09.2012 17:16, schrieb PattiMichelle:
> EDIT: The nomodeset addition seemed to take care of that weird
> behavior.
That is interesting, I checked that I do not need it with 12.1 and 12.2,
but I have different nvidia models on my systems, so I cannot directly
compare that to your card.
> Probably the segfaults were unrelated, but you never know.
Most likely unrelated unless your software does calculations in the
graphics card, but even then I would expect useless results instead of
segfaults.
> have a Phenom II x6 overclocked to 4GHz and am stressing it a lot
> with numerical calculations. I did several tests (“burn” and
> memtest86) to make sure it was stable. Do you know of a good
> memory/cpu tester under OpenSuSE?
>
I am not experienced with overclocking and how to ensure proper system
functionality with it. I think your best option is to open a new thread
about that with a descriptive title to get the attention of the
overclocking experts.
It also makes sense to tell which software exactly it is which segfaults
and what it outputs. Is it self compiled? If so compile it with
debugging symbols and run it with gdb to be able to get a stack trace.
Maybe you used an optimization switch which is incompatible with your
hardware, does it use special numerical libraries (optimized BLAS like
ATLAS or GPU calculations with CUDA)?
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.4 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
I sometimes notice that non-NVidia brands (like Zotoc) vary in their
abilities to properly utilize whatever chipset they’re using - maybe
leave certain I/O ports unbound or improperly bound? I don’t know
how much leeway manufacturers have in implementing chip microcode
on video chipsets.
> Probably the segfaults were unrelated, but you never know.
Most likely unrelated unless your software does calculations in the
graphics card, but even then I would expect useless results instead of
segfaults.
I agree, but code leaks, memory leaks, etc., do occur which may
impact the use of the Hypertransport and Memory busses in an
unknown way. Also, I’m a bug magnet.
It also makes sense to tell which software exactly it is which segfaults
and what it outputs. Is it self compiled? If so compile it with
debugging symbols and run it with gdb to be able to get a stack trace.
Maybe you used an optimization switch which is incompatible with your
hardware, does it use special numerical libraries (optimized BLAS like
ATLAS or GPU calculations with CUDA)?
Yes, self-compiled, but it is very general in setup for different systems,
so it doesn’t use unusual switches. Also it had been running well before
the new video drivers were installed, so it’s related to the driver. No CUDA.
But as I said, you never know about interacting code/driver/hardware problems,
especially when you’re pushing your motherboard/CPU/memory closer
to a limit.
Also, having nomodeset clear up that bizarre video behavior when it is
not supposed to be needed indicates that the drivers aren’t “perfect” or
else aren’t “perfectly implemented” (within OpenSuSE) yet, if you take
my meaning.