NVIDIA-Wikibook/Troubleshooting: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
K (→‎Probleme mit 3D Desktops: Hint zu verschwundenen Fensterdekorationen eingebaut)
K (→‎Die Fensterdekorationen von Compiz bzw. Compiz-Fusion sind weg)
Zeile 1: Zeile 1:
 
<noinclude>{{NVIDIA Wikibook Titel}}</noinclude>
 
<noinclude>{{NVIDIA Wikibook Titel}}</noinclude>
 
<br /><br />
 
<br /><br />
−
= Troubleshooting =
+
<div style="clear"></div>
 +
=Troubleshooting=
  
 
==Updates==
 
==Updates==
  
 
===Kernelupdates===
 
===Kernelupdates===
 +
====Linux====
 
Nach einem Kernelupdate wird die graphische Oberfläche nicht gestartet werden, wenn man die [[NVIDIA#Allgemeine Installation|allgemeine Installationsmethode]] genutzt hat.  
 
Nach einem Kernelupdate wird die graphische Oberfläche nicht gestartet werden, wenn man die [[NVIDIA#Allgemeine Installation|allgemeine Installationsmethode]] genutzt hat.  
 
Dann sollte man sich einfach im Runevel 3 als root anmelden und  
 
Dann sollte man sich einfach im Runevel 3 als root anmelden und  
  
−
  32bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-100.14.23-pkg1.run -'''K'''
+
  32bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg1.run -'''K'''
−
  64bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-100.14.23-pkg2.run -'''K'''
+
  64bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg2.run -'''K'''
−
eingeben. Man beachte das -K welches dazu dient, der Installationsroutine mitzuteilen dass nur das Kernelmodul neu kompiliert werden soll.
+
eingeben. Man beachte das ''-K'', welches dazu dient der Installationsroutine mitzuteilen, dass nur das Kernelmodul neu kompiliert werden soll.
  
 
Falls man das Installationspaket der NVIDIA-Website nicht mehr auf der Festplatte haben sollte, so kann man auch  
 
Falls man das Installationspaket der NVIDIA-Website nicht mehr auf der Festplatte haben sollte, so kann man auch  
Zeile 32: Zeile 34:
 
=====[[openSUSE]]=====
 
=====[[openSUSE]]=====
  
−
Mittlerweile gibt es im NVIDIA-Repository auch einen neueren Paketsatz, der, sofern die im [[NVIDIA/Nvidia#SuSE.2FOpenSUSE |Installationsabschnitt]] genannten Pakete nicht laufen sollten, stattdessen genommen werden sollte:
+
Mittlerweile gibt es im NVIDIA-Repository auch einen neueren Paketsatz, der, sofern die im [[NVIDIA-Wikibook/Installation nvidia Treiber#SuSE/OpenSUSE |Installationsabschnitt]] genannten Pakete nicht laufen sollten, stattdessen genommen werden sollte:
 
  nvidia-gfxG01-kmp-[KERNELTYP]
 
  nvidia-gfxG01-kmp-[KERNELTYP]
 
und
 
und
Zeile 39: Zeile 41:
 
<br /><br /><br />
 
<br /><br /><br />
  
−
======Updateprobleme mit altem NVIDIA-Treiber und aktuellem openSUSE Kernelupdate(2.6.18-0.5)======
+
======Updateprobleme mit altem NVIDIA-Treiber und openSUSE Kernelupdate(2.6.18-0.5)======
 
Zur Zeit ist wohl zwischen den RPM Repositories und dem aktuellen openSUSE Kernelupdate (Offensichtlich ein 64bit-Problem. Bei einem 32bit-System war der Effekt nicht zu beobachten) leider eine Diskrepanz bezüglich der Treiberaktualität gegeben. Die Folge davon: Wenn man den bisherigen NVDIA-Treiber als RPM-Paket instaliert hat läuft dieser nicht mehr mit dem aktualisierten Kernel zusammen (betrifft das openSUSE Kernelrelease 2.6.18-0.5). Die Lösung: Die RPM-Pakete deinstallieren, den aktuellen Treiber direkt von der NVIDIA-Website herunterladen und gemäß der allgemeinen Installationsmethode für dieses Paket installieren und nochmal die Einrichtung per Sax" wie im Installationskapitel beschrieben durchführen. Dasselbe scheint für die Legacy-treiber zu gelten sofern es dort auch zu denselben problemen kommt (also X nicht mehr weiter als bis zum NVIDIA-Logo startet und sich danach abrupt selbstständig beendet ohne weitere Aktion des Users).
 
Zur Zeit ist wohl zwischen den RPM Repositories und dem aktuellen openSUSE Kernelupdate (Offensichtlich ein 64bit-Problem. Bei einem 32bit-System war der Effekt nicht zu beobachten) leider eine Diskrepanz bezüglich der Treiberaktualität gegeben. Die Folge davon: Wenn man den bisherigen NVDIA-Treiber als RPM-Paket instaliert hat läuft dieser nicht mehr mit dem aktualisierten Kernel zusammen (betrifft das openSUSE Kernelrelease 2.6.18-0.5). Die Lösung: Die RPM-Pakete deinstallieren, den aktuellen Treiber direkt von der NVIDIA-Website herunterladen und gemäß der allgemeinen Installationsmethode für dieses Paket installieren und nochmal die Einrichtung per Sax" wie im Installationskapitel beschrieben durchführen. Dasselbe scheint für die Legacy-treiber zu gelten sofern es dort auch zu denselben problemen kommt (also X nicht mehr weiter als bis zum NVIDIA-Logo startet und sich danach abrupt selbstständig beendet ohne weitere Aktion des Users).
 
Dies sind übrigens auch Gründe weswegen die allgemeine Installationsmethode bevorzugt empfohlen wird, da bei vorheriger Installation mit dieser Methode ein simples  
 
Dies sind übrigens auch Gründe weswegen die allgemeine Installationsmethode bevorzugt empfohlen wird, da bei vorheriger Installation mit dieser Methode ein simples  
Zeile 45: Zeile 47:
 
gefolgt vom erneuten Sax2 Aufruf bereits bekannter Art ausreicht um das Problem zu lösen ;-)
 
gefolgt vom erneuten Sax2 Aufruf bereits bekannter Art ausreicht um das Problem zu lösen ;-)
 
<br /><br /><br />
 
<br /><br /><br />
 +
 
======Updateprobleme mit xorg-x11-server 7.2-143.9======
 
======Updateprobleme mit xorg-x11-server 7.2-143.9======
 
Durch dieses Update wird unter Anderem. die auf dem System befindliche und vom NVIDIA-Treiber stammende libglx.so überschrieben,was auf den meisten Systemen mit NVIDIA-Treiber einen wiederholten Reset des kdm Loginmanagers zur Folge hat. Das lässt sich durch ein beherztes  
 
Durch dieses Update wird unter Anderem. die auf dem System befindliche und vom NVIDIA-Treiber stammende libglx.so überschrieben,was auf den meisten Systemen mit NVIDIA-Treiber einen wiederholten Reset des kdm Loginmanagers zur Folge hat. Das lässt sich durch ein beherztes  
Zeile 52: Zeile 55:
  
 
===Downgrade vom Beta-Treiber auf den regulären Treiber(oder einfach auf eine ältere Version)===
 
===Downgrade vom Beta-Treiber auf den regulären Treiber(oder einfach auf eine ältere Version)===
−
Falls man mal aus Neugierde oder weil man aus Versehen das falsche Paket erwischt hat und statt dem regulären nvidia-Treiber den Beta-Treiber erwischt hat, den Beta-Treiber installiert hat, der typischerweise natürlich nicht unbedingt diesebe Stabilität hat wie der offizielle nvdida-Treiber und manchmal recht seltsame Seiteneffekte gerade im Zusammenhang mit 3D beschleunigten Ausgaben wie bei OpenGL Games oder 3D Desktops offenbart, und man diesen wieder loswerden will um ihn durch den regulären zu ersetzen, dann gibt es einen recht simplen Weg. Man lädt das reguläre NVIDIA-Treiberpaket von http://www.nvidia.com/object/unix.html herunter und wechselt nach dem Ausloggen mit Strg-Alt-F1 auf eine Konsole und dort nach dem einloggen als root per  
+
Falls man mal aus Neugierde oder weil man aus Versehen das falsche Paket erwischt hat und statt dem regulären NVIDIA-Treiber den Beta-Treiber erwischt und installiert hat, der typischerweise natürlich nicht unbedingt dieselbe Stabilität hat wie der offizielle NVIDIA-Treiber und manchmal recht seltsame Seiteneffekte gerade im Zusammenhang mit 3D beschleunigten Ausgaben wie bei OpenGL Games oder 3D Desktops offenbart, und man diesen wieder loswerden will um ihn durch den regulären zu ersetzen, dann gibt es einen recht simplen Weg. Man lädt das reguläre NVIDIA-Treiberpaket von http://www.nvidia.com/object/unix.html herunter und wechselt nach dem Ausloggen mit Strg-Alt-F1 auf eine Konsole und dort nach dem einloggen als root per  
 
  init 3
 
  init 3
 
in den Runlevel 3.
 
in den Runlevel 3.
Zeile 58: Zeile 61:
  
 
Für 32bit:
 
Für 32bit:
−
  sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-100.14.23-pkg1.run -'''f'''
+
  sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg1.run -'''f'''
  
 
Für 64bit:
 
Für 64bit:
−
  sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-100.14.23-pkg2.run -'''f'''
+
  sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg2.run -'''f'''
  
−
Zu beachten ist dabei der Parameter ''-f'' der für ''force'' steht und die Installation des Treibers aus dem heruntergeladenen Paket erzwingt.
+
Zu beachten ist dabei der Parameter ''-f'' der für ''force'' steht und die Installation des Treibers aus dem heruntergeladenen Paket erzwingt. Sollte dies aus irgendwelchen Gründen nicht gelingen, dann kann man vor der Installation des Treibers auf den downgegradet werden soll noch
−
Da ja bereits eine Konfiguration für den X-Server besteht, wird man vermutlich um eine Neukonfiguration des X-Servers herumkommen, es sei denn man hat brandneue Optionen genutzt, die im offiziellen Treiber noch nicht vorhanden sind. Im letzteren Fall ist einfach noch mal der [[NVIDIA/Nvidia#Konfiguration|Abschnitt zur Konfiguration im Wikibook]] durchzuarbeiten.
+
nvidia-installer --uninstall
 +
ausführen um den aktuell installierten treiber zu deinstallieren.
 +
Da ja bereits eine Konfiguration für den X-Server besteht, wird man vermutlich um eine Neukonfiguration des X-Servers herumkommen, es sei denn man hat brandneue Optionen genutzt, die im offizielen Treiber noch nicht vorhanden sind. Im letzteren Fall ist einfach noch mal der [[NVIDIA-Wikibook/Installation nvidia Treiber#Konfiguration|Abschnitt zur Konfiguration im Wikibook]] durchzuarbeiten.
 
Dieselbe Vorgehensweise gilt auch für Downgrades des regulären Treibers auf eine ältere Version oder einen der Legacy Treiber.
 
Dieselbe Vorgehensweise gilt auch für Downgrades des regulären Treibers auf eine ältere Version oder einen der Legacy Treiber.
 +
Mit
 +
init 5
 +
kommt man abschießend wieder auf die grafische Nutzeroberfläche zurück. Sollte man vergessen haben in den Runlevel 3 zu wechseln und sich dazu entschließen den Downgrade erst später durchzuführen, so kommt man auch per Strg-Alt-F7 Tastenkombination wieder auf die ja noch laufende grafische Nutzeroberfläche zurück.
 
<br /><br />
 
<br /><br />
 +
 
===Crossup-/-downgrade vom proprietären nvidia-Treiber auf den freien nv Treiber===
 
===Crossup-/-downgrade vom proprietären nvidia-Treiber auf den freien nv Treiber===
 
Falls man aus versehen sein System dermaßen zerkonfiguriert hat, daß man es nicht so einfach wieder in einen funktionsfähigen Zustand bekommt oder man einfach aus irgendeinem Grund den proprietären Treiber von NVIDIA nicht wirklich instaliert bekommt, so kann man durch den folgenden Sax2 Konfigurationsaufruf zumindest den freien nv Treiber mit reiner 2D Funktion reaktivieren um überhaupt erstmal wieder eine grafische Oberfläöche nutzen zu können bis man das eigentliche Problem behoben hat:
 
Falls man aus versehen sein System dermaßen zerkonfiguriert hat, daß man es nicht so einfach wieder in einen funktionsfähigen Zustand bekommt oder man einfach aus irgendeinem Grund den proprietären Treiber von NVIDIA nicht wirklich instaliert bekommt, so kann man durch den folgenden Sax2 Konfigurationsaufruf zumindest den freien nv Treiber mit reiner 2D Funktion reaktivieren um überhaupt erstmal wieder eine grafische Oberfläöche nutzen zu können bis man das eigentliche Problem behoben hat:
Zeile 102: Zeile 111:
 
  nvidia-settings  
 
  nvidia-settings  
 
den TV-Out Port auch aktivieren.
 
den TV-Out Port auch aktivieren.
 +
<br /><br /><br />
 +
 +
====Wie speichere ich Änderungen durch nvidia-settings dauerhaft ab?====
 +
Um Änderungen per nvidia-settings dauerhaft abzuspeichern muss nvidia-settings mit root-Rechten gestartet werden. Dazu gibt man normalerweise für die Nutzung unter KDE
 +
kdesu nvidia-settings
 +
, für die Nutzung unter Gnome
 +
gnomesu nvidia-settings
 +
und für andere Desktop-Environments
 +
sudo nvidia-settings
 +
in einer Befehlszeile oder einer Terminalemulation/einem Konsolenfenster als normaler User ein. Man muss und sollte sich deswegen nicht extra als User root anmelden.
 
<br /><br /><br />
 
<br /><br /><br />
  
Zeile 113: Zeile 132:
 
nicht starten will, hilft es oft einen weiteren Parameter in den Sax2 Aufruf einzubauen. Man muss Sax2 nur mitteilen welche der vorhandenen GPUs genutzt werden soll. Mit  
 
nicht starten will, hilft es oft einen weiteren Parameter in den Sax2 Aufruf einzubauen. Man muss Sax2 nur mitteilen welche der vorhandenen GPUs genutzt werden soll. Mit  
 
  sax2 -p
 
  sax2 -p
−
bekommt man die Liste der zur Verfügung stehenden GPUs und kann sich dann diejenige an der mindestens ein Monitor angeschlossen ist mit dem -c<GPU-Nummer> passenderweise aussuchen. Beispiel für den dann funktionierenden Aufruf von Sax2 auf einem SLI-System:
+
bekommt man die Liste der zur Verfügung stehenden GPUs und kann sich dann diejenige an der mindestens ein Monitor angeschlossen ist mit dem -c<GPU-Nummer> passenderweise aussuchen. Beispiel für den dann funktionierenden Aufruf von Sax2 auf einem SLI-System(Monitor im Beispiel an der 2. Karte):
−
  sax2 -r -c1 -m 0=nvidia
+
  sax2 -r -c1 -m 1=nvidia
 +
Falls der Monitor an der ersten Karte hängt, sollte
 +
sax2 -r -c0 -m 0=nvidia
 +
stattdessen genutzt werden.
 
Für ein "normales" Multi-GPU System das nicht im SLI-Mode betrieben werden soll wäre es hingegen
 
Für ein "normales" Multi-GPU System das nicht im SLI-Mode betrieben werden soll wäre es hingegen
 
  sax2 -r -c1 -m 0=nvidia,1=nvidia
 
  sax2 -r -c1 -m 0=nvidia,1=nvidia
Zeile 167: Zeile 189:
 
als User root ausschaltet, sollte dieses Problem auch erledigt sein, so daß man dann mit  
 
als User root ausschaltet, sollte dieses Problem auch erledigt sein, so daß man dann mit  
 
  sax2 -r -l -m 0=nvidia
 
  sax2 -r -l -m 0=nvidia
−
wieder ein rudimentäres X konfigurieren kann (sofern der Monitor bis dahin nur eine ''"Out-Of-Range"'' Meldung von sich gab und man daher keinerlei X Windowsystem zur Verfügung hatte) und anschließend (oder eben stattdessen sofern X mit geringer Bildwiederholfrequenz lief) im grafischen Modus per
+
wieder ein rudimentäres X konfigurieren kann (sofern der Monitor bis dahin nur eine ''"Out-Of-Range"'' Meldung von sich gab und man daher keinerlei X Window System zur verfügung hatte) und anschließend (oder eben stattdessen, sofern X mit geringer Bildwiederholfrequenz lief) im grafischen Modus per
 
  kdesu nvidia-settings
 
  kdesu nvidia-settings
 
oder im Falle von Gnome-Nutzung  
 
oder im Falle von Gnome-Nutzung  
Zeile 274: Zeile 296:
 
===Probleme mit der Textkonsole===
 
===Probleme mit der Textkonsole===
 
====Bunte Artefakte oder schwarzer Bildschirm beim Umschalten====
 
====Bunte Artefakte oder schwarzer Bildschirm beim Umschalten====
−
Wenn man vom grafischen Modus auf eine Textkonsole umschalten will und dann entweder recht wirre bunte Artefakte zu sehen bekommt oder auch einen schwarzen Bildschirm , dann hat man einen alten Bug im NVIDIA-Treiber erwischt der nur in wenigen Grafikarten/Treiberversionskombinationen auftritt. Der Grund dafür ist eine Unverträglichkeit des NVIDIA-Treibers mit dem VESA-Framebuffer Konsolentreiber die sich jedoch nur in wenigen Kombinationen von Grafikkarten+Treiberversionen bemerkbar macht. Ein Workaround zur Vermeidung des Bugs ist in der menu.lst von Grub den vga-Mode in den Kernelparametern auf normal zu setzen statt auf einen der VESA-Modi. Der einzige Nachteil ist, daß dann natürlich auch auf den Bootsplash verzichtet werden muss der ja nach Auswahl des jeweiligen Menüpunktes in Grub zum Zuge käme. Der grafische Grub Bootscreen selbst ist davon nicht betroffen.
+
Wenn man vom grafischen Modus auf eine Textkonsole umschalten will und dann entweder recht wirre bunte Artefakte zu sehen bekommt oder auch einen schwarzen Bildschirm , dann hat man einen alten Bug im NVIDIA-Treiber erwischt der nur in wenigen Grafikarten/Treiberversionskombinationen auftritt. Der Grund dafür ist eine Unverträglichkeit des NVIDIA-Treibers mit dem VESA-Framebuffer Konsolentreiber die sich jedoch nur in wenigen Kombinationen von Grafikkarten+Treiberversionen bemerkbar macht. Ein Workaround zur Vermeidung des Bugs ist in der /boot/grub/menu.lst von Grub den vga-Mode in den Kernelparametern auf normal zu setzen statt auf einen der VESA-Modi. Der einzige Nachteil ist, daß dann natürlich auch auf den Bootsplash verzichtet werden muss der ja nach Auswahl des jeweiligen Menüpunktes in Grub zum Zuge käme. Der grafische Grub Bootscreen selbst ist davon nicht betroffen.
 +
 
 +
Eien weitere Möglichkeit die eventuell den VESA-Mode des Bootsplash nicht deaktiviert und oft schon helfen kann wäre das Einfügen der folgenden Option in der Section Device in der /etc/X11/xorg.conf:
 +
 
 +
Option      "IgnoreDisplayDevices"      "TV"
 +
Damit wird der Framebuffer auf der Grafikkarte nicht automatisch für die Nutzung des TV-Out Anschlußes vorbereitet wobei durch eben diese Vorbereitung des Framebuffers oft besagte Probleme mit der Umschaltung auf die Textkonsole auftreten würden.  
 
<br /><br /><br />
 
<br /><br /><br />
  
 
===Probleme mit 3D Desktops===
 
===Probleme mit 3D Desktops===
−
 
−
Generische (also nicht NVIDIA-Grafikkartenspezifische) Proleme und Lösungen zu Compis-Fusion sind im Artikel [[Compiz Fusion FAQ]] zu finden. Hier befinden sich die NVIDIA-Grafikkartenspezifische Probleme+Lösungen.
 
  
 
====NV-GLX scheint langsam zu sein====
 
====NV-GLX scheint langsam zu sein====
Zeile 287: Zeile 312:
  
 
====Der Arbeitsumflächenschalter zeigt unter KDE mit Beryl/Compiz(-Fusion) zuviele Arbeitsflächen====
 
====Der Arbeitsumflächenschalter zeigt unter KDE mit Beryl/Compiz(-Fusion) zuviele Arbeitsflächen====
−
Dieser Abschnitt befindet sich nun unter [[Compiz Fusion FAQ#Warum zeigt der Arbeitsumflächenumschalter unter KDE mit Beryl/Compiz(-Fusion) zuviele Arbeitsflächen?]] da es ein generisches und kein NVIDIA-Grafikartenspezifisches Problem betrifft.
+
 
 +
Das liegt daran, daß Beryl,Compiz und Compiz-Fusion ihre Arbeitsflächen anders aufteilen als KDE es erwartet. Zu diesem Zwecke deaktiviert man in der Kontrollleisteneinrichtung einfach den bisherigen Arbeitsflächenumschalter und setzt stattdessen unter Compiz und Beryl  ''Umschalten zwischen Arbeitsflächen - Compiz'' beziehungsweise unter Compiz-Fusion ''Kpager2'' aus der Miniprogrammliste der Kontrollleisteneinrichtung ein.
 +
 
 +
Da es kpager2 für openSUSE 10.3 noch nicht als fertiges Paket gibt, aber die Version für openSUSE 10.2 offenbar auch unter 10.3 (getestet mit der openSUSE 10.3 64 Bitversion) funktioniert, sei an dieser Stelle vorläufig auf http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/Utilities/kpager2/ verwiesen um sich das Paket herunterzuladen und per
 +
rpm -Uvh <Paketname>
 +
dann im System zu installieren. Für opensuse 10.1 und 10.1 gibt es das Paket im Guru Repository oder wer es selbst kompilieren möchte findet es auf [http://www.kde-apps.org/content/show.php/KPager2+for+Kicker?content=7120 KDE-Look.org].
 +
 
 +
{{Box Achtung|Andere Zählweise für die Arbeitsflächen|
 +
Im Gegensatz zu normalen Desktops ist im Zusamenhang mit 3D Desktops wie Beryl, Compiz oder Compiz-Fusion eine andere Zählweise für Arbeitsflächen im Einsatz als sonst üblich!}}
 +
Als '''einzelne''' Arbeitsflächen, wie sie von kpager2 angezeigt werden, zählen '''die 4 nutzbaren Seiten''' des Würfels, der ja eigentlich aufgrund der Seitenverhältnisse des Monitors ein Quader ist, und die zusammen einen ''Viewport'' bilden. Von kpager2 werden nicht Arbeitsflächen im herkömmlichen Sinne angezeigt sondern eben diese Viewports. Daraus folgt, daß 2 Viewports 2 unabhängige Würfel sind und man somit 8 nutzbare Seiten (=die eigentlichen Arbeitsflächen) hat, bei 3 Viewports entsprechend 12 nutzbare Seiten usw. wodurch jedoch auch der Speicherbedarf entsprechend höher wird.
 
<br /><br /><br />
 
<br /><br /><br />
  
Zeile 297: Zeile 331:
 
  compiz --no-libgl-fallback --replace ccp &
 
  compiz --no-libgl-fallback --replace ccp &
 
Vielfach liest man noch, daß die Variable LIBGL_ALWAYS_INDIRECT=1 gesetzt sein müsste,was jedoch definitiv '''nicht''' zwingend notwendig ist, jedoch auch nicht schadet.
 
Vielfach liest man noch, daß die Variable LIBGL_ALWAYS_INDIRECT=1 gesetzt sein müsste,was jedoch definitiv '''nicht''' zwingend notwendig ist, jedoch auch nicht schadet.
−
Sofern mit Compiz-Fision gearbeitet wird muss man ggf. noch die Datei '''data.py''' abändern. Diese datei befindet sich auf 32 Bit Systemen unter  
+
Sofern mit Compiz-Fision gearbeitet wird muss man ggf. noch die Datei '''data.py''' abändern. Diese Datei befindet sich beispielsweise auf 32 Bit openSUSE Systemen unter  
 
   /usr/lib/python2.5/site-packages/FusionIcon  
 
   /usr/lib/python2.5/site-packages/FusionIcon  
−
und auf 64 Bit Systemen unter
+
und auf 64 Bit openSUSE Systemen unter
 
   /usr/lib64/python2.5/site-packages/FusionIcon
 
   /usr/lib64/python2.5/site-packages/FusionIcon
 
wobei in dieser Datei aus der Zeile  
 
wobei in dieser Datei aus der Zeile  
Zeile 316: Zeile 350:
 
(die per  
 
(die per  
 
  nvidia-xconfig --allow-glx-with-composite
 
  nvidia-xconfig --allow-glx-with-composite
−
in der xorg.conf an der richtigen Stelle, nämlich der Section Device, eingetragen werden kann sofern man sie beim Einrichten von NV-GLX aus irgend einem Grund vergaß) in der Section Device verringert, jedoch nicht ganz ausgeschlossen werden.
+
in der xorg.conf an der richtigen Stelle, nämlich der Section Device, eingetragen werden kann sofern man sie beim Einrichten von NV-GLX aus irgendeinem Grund vergaß) in der Section Device verringert, jedoch nicht ganz ausgeschlossen werden.
 +
<br /><br /><br />
  
 
===Probleme mit der DVB- oder Videowiedergabe===
 
===Probleme mit der DVB- oder Videowiedergabe===
Zeile 322: Zeile 357:
 
Wenn ein Stottereffekt (wie "Scratching" bei Vinylscheiben Audiowiedergabe,nur als unbeabsichtigter Videoeffekt) bei der Videowiedergabe mit Xine/Kaffeine/MPlayer/VLC oder ähnlichen Video+DVB-Abspielprogrammen auftritt, kann es am aktivierten Videooutputtreiber liegen, was durch  
 
Wenn ein Stottereffekt (wie "Scratching" bei Vinylscheiben Audiowiedergabe,nur als unbeabsichtigter Videoeffekt) bei der Videowiedergabe mit Xine/Kaffeine/MPlayer/VLC oder ähnlichen Video+DVB-Abspielprogrammen auftritt, kann es am aktivierten Videooutputtreiber liegen, was durch  
 
  nvidia-xconfig --xvmc-uses-textures
 
  nvidia-xconfig --xvmc-uses-textures
−
als User root aufgerufen, den X-Server neustarten und Kaffeine/Xine auf xv umstellen gelöst werden kann. Der xvmc Videooutputtreiber scheint wider Erwarten nicht wirlich zu funktionieren, mit xv jedoch geht es mit dieser Lösung (zumindest wurde es im Zusammenhang mit NV-GLX auf einem GeForce 6600 GT SLI-System erfolgreich getestet)...  
+
als User root aufgerufen, den X-Server neustarten und Kaffeine/Xine auf xv umstellen gelöst werden kann. Der xvmc Videooutputtreiber scheint wider Erwarten nicht wirklich zu funktionieren, mit xv jedoch geht es mit dieser Lösung (zumindest wurde es im Zusammenhang mit NV-GLX auf einem GeForce 6600 GT SLI-System erfolgreich getestet)...  
 
<br /><br /><br />
 
<br /><br /><br />
  
 
==Hardwarewechsel der Grafikkarte==
 
==Hardwarewechsel der Grafikkarte==
 
===Von [[ATI]] mit [[fglrx]]-Treiber zu [[NVIDIA]]===
 
===Von [[ATI]] mit [[fglrx]]-Treiber zu [[NVIDIA]]===
−
Zuerst startet man den Rechner in Runlevel 3 durch die Eingabe einer simplen 3 in der Eingabezeile des [[GRUB]] beim Systemstart. Dann loggt man sich als root ein um mit  
+
Zuerst startet man den Rechner in Runlevel 3 durch die Eingabe einer simplen 3 in der Eingabezeile des [[Bootmanager|GrUB]] beim Systemstart. Dann loggt man sich als root ein um mit  
 
  ./fglrx-uninstall.sh
 
  ./fglrx-uninstall.sh
 
aus dem Verzeichnis aus dem man früher irgendwann einmal die [[ATI]] Treiber heraus installierte eben diese wieder zu deinstallieren. Ob die Deinstallation erfolgreich war überprüft man am besten per  
 
aus dem Verzeichnis aus dem man früher irgendwann einmal die [[ATI]] Treiber heraus installierte eben diese wieder zu deinstallieren. Ob die Deinstallation erfolgreich war überprüft man am besten per  
 
  rpm -e $(rpm -qa | grep fglrx)
 
  rpm -e $(rpm -qa | grep fglrx)
−
(beziehungsweise unter [[Debian|debianbasierten Distributionen]] mit dem entsprechenden [[dpkg]]-Aufrufspendant)
+
(beziehungsweise unter [[Debian|debianbasierten Distributionen]] mit dem entsprechenden [[Paketmanager|dpkg]]-Aufrufspendant)
−
Danach instaliert man den proprietären NVIDIA-Treiber gemäß dem [[NVIDIA|NVIDIA]] hier  und lässt per  
+
Danach instaliert man den proprietären NVIDIA-Treiber gemäß dem [[NVIDIA|NVIDIA-Wikibook]] hier  und lässt per  
 
  nvidia-xconfig
 
  nvidia-xconfig
 
eine grundlegende X-Serverkonfiguration vornehmen. Man kann dies unter openSUSE natürlich direkt auch per  
 
eine grundlegende X-Serverkonfiguration vornehmen. Man kann dies unter openSUSE natürlich direkt auch per  
Zeile 354: Zeile 389:
 
Es scheint so als wären einige ATI-Chipsätze recht inkompatibel zu diversen NVDIA-Grafikkarten. Eine Lösung könnte möglicherweise ein inoffizieller Patch für das Treiberinstallationspaket von der NVIDIA-Website sein der wie unter  http://www.nvnews.net/vbulletin/showpost.php?p=1325093&postcount=100 beschrieben durchzuführen wäre.
 
Es scheint so als wären einige ATI-Chipsätze recht inkompatibel zu diversen NVDIA-Grafikkarten. Eine Lösung könnte möglicherweise ein inoffizieller Patch für das Treiberinstallationspaket von der NVIDIA-Website sein der wie unter  http://www.nvnews.net/vbulletin/showpost.php?p=1325093&postcount=100 beschrieben durchzuführen wäre.
  
−
'''''Update: Seit Treiberrelease 100.14.19 ist dies wohl nun bereits im Treiber integriert!'''''
+
'''Update: Seit Treiberrelease 100.14.19 ist dies wohl nun bereits im Treiber integriert! '''
 
<br /><br /><br />
 
<br /><br /><br />
  
 
<noinclude>{{NVIDIA Wikibook Footer}}</noinclude>
 
<noinclude>{{NVIDIA Wikibook Footer}}</noinclude>

Version vom 8. April 2008, 03:48 Uhr

NVIDIA    GRAFIKKARTEN    WIKIBOOK   :    INSTALLATION,    KONFIGURATION    UND    TROUBLESHOOTING
NVIDIA: Intro - Installation - Konfiguration - 3D Desktops - Troubleshooting - Hintergrundwissen - Schlusswort



Dieser Artikel wird regelmäßig mit dem Artikel NVIDIA-Wikibook/Troubleshooting des MosNis Projekt Wikis synchronisiert.
Die importierte Version des Artikels in der Linupedia (dem Linux-Club Wiki) unter NVIDIA-Wikibook/Troubleshooting war zum unten vermerkten letzten Artikelsynchronisationszeitpunkt identisch mit dem im MosNis Projekt unter NVIDIA-Wikibook/Troubleshooting zu findenden originalen Artikel. Der Artikel kann gerne überarbeitet werden. Wenn beide Artikel mittlerweie gravierende Differenzen aufweisen sollten, bitte eine Nachricht an TomcatMJ senden, damit die Synchronisation erneut initiiert wird.
Die letzte Synchronisation erfolgte am 27.4.2008 um 2020 Uhr..


NVIDIA-Wikibook/Troubleshooting




Inhaltsverzeichnis

Troubleshooting

Updates

Kernelupdates

Linux

Nach einem Kernelupdate wird die graphische Oberfläche nicht gestartet werden, wenn man die allgemeine Installationsmethode genutzt hat. Dann sollte man sich einfach im Runevel 3 als root anmelden und 

32bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg1.run -K
64bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg2.run -K

eingeben. Man beachte das -K, welches dazu dient der Installationsroutine mitzuteilen, dass nur das Kernelmodul neu kompiliert werden soll.

Falls man das Installationspaket der NVIDIA-Website nicht mehr auf der Festplatte haben sollte, so kann man auch 

nvidia-installer  -K

ausführen, was das gleiche bewirkt.


NVIDIA Treiberupdates

Da ja gelegentlich auch neue Treiber seitens NVIDIA veröffentlicht werden, muss man natürlich auch eine Option zum updaten haben wenn man die allgemeine Installationsvariante genutzt hat. Dies wird mit Hilfe des, mit dem bei der Treiberinstallation mitinstallierten, Tools nvidia-installer realisiert. Damit erspart man sich das herunterladen des kompletten neuen Installationspakets. Man braucht nur noch als User root auf der Textkonsole mit init 3 in den Runlevel 3 zu wechseln und gibt dann folgendes ein (gültig für alle Releases unter allen möglichen Linux Distributionsversionen unter denen die Installation per allgemeiner NVIDIA Treiberpaketinstallation erfolgreich stattfand): 

nvidia-installer --update

Sofern man nicht mit irgendwelchen Rückfragen belästigt werden will, kann man noch die beiden Parameter -a und -q anfügen. Dadurch wird die NVIDIA-Lizenz automatisch akzeptiert und Rückfragen werden dann automatisch mit Ja beantwortet.

Gelegentlich weigert sich der nvidia-installer ein Update durchzuführen trotz Wechsel in den Runlevel 3. Dies passiert wenn trotz dem Runlevelwechsel das nvidia.ko Kernelmodul noch immer geladen ist. Dagegen hilft ein beherztes 

rmmod -f nvidia

woraufhin der nvidia-installer dann das anvisierte Update erfolgreich durchführen kann.


Distributionsspezifische Updates

openSUSE

Mittlerweile gibt es im NVIDIA-Repository auch einen neueren Paketsatz, der, sofern die im Installationsabschnitt genannten Pakete nicht laufen sollten, stattdessen genommen werden sollte: 

nvidia-gfxG01-kmp-[KERNELTYP]

und 

x11-video-nvidiaG01

Offenbar wurde zum Update auf Version 100.14.09 des NVIDIA-Treiberpakets auch eine neue Namenskonvention für die vorgefertigten RPM-Pakete des NVIDIA-Repositories eingeführt und der ältere Treiber denoch dort im Repository behalten.


Updateprobleme mit altem NVIDIA-Treiber und openSUSE Kernelupdate(2.6.18-0.5)

Zur Zeit ist wohl zwischen den RPM Repositories und dem aktuellen openSUSE Kernelupdate (Offensichtlich ein 64bit-Problem. Bei einem 32bit-System war der Effekt nicht zu beobachten) leider eine Diskrepanz bezüglich der Treiberaktualität gegeben. Die Folge davon: Wenn man den bisherigen NVDIA-Treiber als RPM-Paket instaliert hat läuft dieser nicht mehr mit dem aktualisierten Kernel zusammen (betrifft das openSUSE Kernelrelease 2.6.18-0.5). Die Lösung: Die RPM-Pakete deinstallieren, den aktuellen Treiber direkt von der NVIDIA-Website herunterladen und gemäß der allgemeinen Installationsmethode für dieses Paket installieren und nochmal die Einrichtung per Sax" wie im Installationskapitel beschrieben durchführen. Dasselbe scheint für die Legacy-treiber zu gelten sofern es dort auch zu denselben problemen kommt (also X nicht mehr weiter als bis zum NVIDIA-Logo startet und sich danach abrupt selbstständig beendet ohne weitere Aktion des Users). Dies sind übrigens auch Gründe weswegen die allgemeine Installationsmethode bevorzugt empfohlen wird, da bei vorheriger Installation mit dieser Methode ein simples 

nvidia-installer --update

gefolgt vom erneuten Sax2 Aufruf bereits bekannter Art ausreicht um das Problem zu lösen ;-)


Updateprobleme mit xorg-x11-server 7.2-143.9

Durch dieses Update wird unter Anderem. die auf dem System befindliche und vom NVIDIA-Treiber stammende libglx.so überschrieben,was auf den meisten Systemen mit NVIDIA-Treiber einen wiederholten Reset des kdm Loginmanagers zur Folge hat. Das lässt sich durch ein beherztes 

nvidia-installer -f --update

aufgerufen als User root im Runlevel 3 (gegebenenfalls beim Booten im Grub einfach eine 3 eingeben um in den RUnlevel 3 zu booten statt in den Runlevel 5) beheben, sofern die allgemeine Installationsmethode bei der Installation des NVIDIA-Treibers genutzt wurde. Wenn nun aber zum Beispiel noch immer VLC Probleme beim Abspielen machen sollte (=>Bad Alloc Fehlermeldung auf der Konsole durch VLC), dann gibt es unter http://www.linux-club.de/ftopic90384.html einen kleinen Workaround dazu.


Downgrade vom Beta-Treiber auf den regulären Treiber(oder einfach auf eine ältere Version)

Falls man mal aus Neugierde oder weil man aus Versehen das falsche Paket erwischt hat und statt dem regulären NVIDIA-Treiber den Beta-Treiber erwischt und installiert hat, der typischerweise natürlich nicht unbedingt dieselbe Stabilität hat wie der offizielle NVIDIA-Treiber und manchmal recht seltsame Seiteneffekte gerade im Zusammenhang mit 3D beschleunigten Ausgaben wie bei OpenGL Games oder 3D Desktops offenbart, und man diesen wieder loswerden will um ihn durch den regulären zu ersetzen, dann gibt es einen recht simplen Weg. Man lädt das reguläre NVIDIA-Treiberpaket von http://www.nvidia.com/object/unix.html herunter und wechselt nach dem Ausloggen mit Strg-Alt-F1 auf eine Konsole und dort nach dem einloggen als root per 

init 3

in den Runlevel 3. Dort gibt man dann folgendes auf der Konsole ein (USER steht hier für den User in dessen Homeverzeichnis das Paket beim Download abgelegt wurde):

Für 32bit: 

sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg1.run -f

Für 64bit: 

sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-171.05-pkg2.run -f

Zu beachten ist dabei der Parameter -f der für force steht und die Installation des Treibers aus dem heruntergeladenen Paket erzwingt. Sollte dies aus irgendwelchen Gründen nicht gelingen, dann kann man vor der Installation des Treibers auf den downgegradet werden soll noch 

nvidia-installer --uninstall

ausführen um den aktuell installierten treiber zu deinstallieren. Da ja bereits eine Konfiguration für den X-Server besteht, wird man vermutlich um eine Neukonfiguration des X-Servers herumkommen, es sei denn man hat brandneue Optionen genutzt, die im offizielen Treiber noch nicht vorhanden sind. Im letzteren Fall ist einfach noch mal der Abschnitt zur Konfiguration im Wikibook durchzuarbeiten. Dieselbe Vorgehensweise gilt auch für Downgrades des regulären Treibers auf eine ältere Version oder einen der Legacy Treiber. Mit 

init 5

kommt man abschießend wieder auf die grafische Nutzeroberfläche zurück. Sollte man vergessen haben in den Runlevel 3 zu wechseln und sich dazu entschließen den Downgrade erst später durchzuführen, so kommt man auch per Strg-Alt-F7 Tastenkombination wieder auf die ja noch laufende grafische Nutzeroberfläche zurück.

Crossup-/-downgrade vom proprietären nvidia-Treiber auf den freien nv Treiber

Falls man aus versehen sein System dermaßen zerkonfiguriert hat, daß man es nicht so einfach wieder in einen funktionsfähigen Zustand bekommt oder man einfach aus irgendeinem Grund den proprietären Treiber von NVIDIA nicht wirklich instaliert bekommt, so kann man durch den folgenden Sax2 Konfigurationsaufruf zumindest den freien nv Treiber mit reiner 2D Funktion reaktivieren um überhaupt erstmal wieder eine grafische Oberfläöche nutzen zu können bis man das eigentliche Problem behoben hat: 

sax2 -r -m 0=nv

Wenn dieser Treiber jedoch die eigene Grafikkarte nicht unterstützt (zum Beispiel weil sie noch flammneu ist udn bisher gar ein anderer Treiber damit geht oder weil sie nicht nur historisch sondern gar prähistorich ist und der nv Treiber daher von dieser Karte nichts mehr wissen will) so kann man auch per 

sax2 -r -m 0=vesa

stattdessen den VESA-Treiber aktivieren.

Konfigurationsprobleme

Allgemeine NVIDIA-Einstellungsprobleme

Wo ist das NVIDIA-Logo abgeblieben?

Ob beim Start des X-Servers das NVIDIA-Logo angezeigt wird oder nicht hat eigentlich keinerlei Aussagekraft über das Vorhandensein des NIVIDIA-Treibers, da dieses Logo sich normalerweise auch abschalten lässt wie es z.B. unter openSUSE 10.3 bei der Installation der Treiber über das NVIDIA-Repository mittlerweile wohl Standard ist. Will man es jedoch reaktivieren, so hilft ein Aufruf von 

nvidia-xconfig --logo

als User root. Man kann es per 

nvidia-xconfig --no-logo

auch explizit abschalten oder per 

nvidia-xconfig --logo-path=<Pfad zu einer eigenen Logo-datei im png-Format>

ein eigenes Logo einbinden.


Mein TV zeigt nur ein Schwarzweissbild statt dem normalen Farbbild

Per Default nutzt der NVIDIA-Treiber den NTSC-M Standard,der hierzulande(Deutschland) natürlich der Falsche ist. Per 

nvidia-xconfig --tv-standard=PAL-B

lässt sich dies einfach korrigieren. Mögliche andere Werte sind PAL-D, PAL-G, PAL-H, PAL-I, PAL-K1, PAL-M, PAL-N, PAL-NC, NTSC-J, NTSC-M, HD480i, HD480p, HD720p, HD1080i, HD1080p, HD576i sowie HD576p. Den TV-Ausgangsport setzt man am besten per 

nvidia-xconfig --tv-out-format=AUTOSELECT

auf automatische Erkennung. Man kann auch den konkreten Anschußtyp angeben indem man statt "AUTOSELECT" entweder "SVIDEO" oder "COMPOSITE" sowie für HD-TV(auch für HDMI Anschluß) "COMPONENT" angibt. Selten kann man auch noch "SCART" als Anschlußtyp angeben (welche NVIDIA-Karte hat eigentlich direkt einen SCART Anschluß dran?). Danach kann man per 

nvtv

sofern der nvtvd läuft oder aber mit 

nvidia-settings

den TV-Out Port auch aktivieren.


Wie speichere ich Änderungen durch nvidia-settings dauerhaft ab?

Um Änderungen per nvidia-settings dauerhaft abzuspeichern muss nvidia-settings mit root-Rechten gestartet werden. Dazu gibt man normalerweise für die Nutzung unter KDE 

kdesu nvidia-settings

, für die Nutzung unter Gnome 

gnomesu nvidia-settings

und für andere Desktop-Environments 

sudo nvidia-settings

in einer Befehlszeile oder einer Terminalemulation/einem Konsolenfenster als normaler User ein. Man muss und sollte sich deswegen nicht extra als User root anmelden.


Probleme mit SLI-Systemen

X-Server lässt sich nicht konfigurieren

OpenSUSE

Falls man ein SLI-System hat (einige Modelle der GeForce 8xxx Reihe sind auch SLI-Systeme allerdings auf einer einzigen Karte!) und, im Falle von SuSE/OpenSUSE Linux, Sax2 mit dem Aufruf 

sax2 -r -m 0=nvidia

nicht starten will, hilft es oft einen weiteren Parameter in den Sax2 Aufruf einzubauen. Man muss Sax2 nur mitteilen welche der vorhandenen GPUs genutzt werden soll. Mit 

sax2 -p

bekommt man die Liste der zur Verfügung stehenden GPUs und kann sich dann diejenige an der mindestens ein Monitor angeschlossen ist mit dem -c<GPU-Nummer> passenderweise aussuchen. Beispiel für den dann funktionierenden Aufruf von Sax2 auf einem SLI-System(Monitor im Beispiel an der 2. Karte): 

sax2 -r -c1 -m 1=nvidia

Falls der Monitor an der ersten Karte hängt, sollte 

sax2 -r -c0 -m 0=nvidia

stattdessen genutzt werden. Für ein "normales" Multi-GPU System das nicht im SLI-Mode betrieben werden soll wäre es hingegen 

sax2 -r -c1 -m 0=nvidia,1=nvidia

da dort ja jede GPU ihren eigenen X-Server fahren können soll, und nicht abhängig von der/den andere/n GPU/s nur zusätzliche Renderaufgaben übernehmen soll (was ja wiederum den SLI-Mode ausmachen würde).


Andere Distributionen

Bei anderen Distributionen kann genau wie unter SuSE/OpenSUSE per 

nvidia-xconfig --sli=Auto

bzw. 

nvidia-xconfig --mutigpu=Auto

der SLI- bzw. MultiGPU-Mode aktiviert werden sofern es in dem dort vorhandenen X-Server Setuptool genau wie in Sax2 keinen direkten Weg zur Aktivierung dieser Modi gibt. Weitere Optionen können ebenso mit diesem Tool aktiviert werden, auch unter SuSE/OpenSUSE stehen so Optionen zur Verfügung von denen Sax2 noch(?) nichts weiss. Die genaue Optionsliste bekommt man mit 

nvidia-xconfig -A

angezeigt, die Werte dieser Optionen sind im NVIDIA-Readme genauer erläutert welches, zumindest im Falle des Treiberpakets von der NVIDIA-Website, bei der Treiberinstallation mit installiert wurde.


Monitorerkennungsprobleme

Probleme mit dem Sax2 Start unter openSUSE Linux

Sofern beim Aufruf von sax2 der Monitor immer mit einer zu hohen Bildwiederholfrequenz oder Auflösung angesteuert wird (=Out of Range Meldung des Monitors), so kann man dies umgehen indem man entweder mit 

sax2 -r -l -m 0=nvidia

die Standardauflösung für die Einrichtung auf Low Resolution festlegt, was eine Auflösung von 800x600 Pixel bei 60 Hz Bildwiederholfrequenz zur Folge hat oder mit 

sax2 -r --vesa 1024x768@85 -m 0=nvidia

eine VESA-Auflösung von in diesem Fall 1024x768 Pixeln bei 85 Hz erwzingt. Dabei können alle VESA-Standardmodi mit VESA-konformer Bildwiederholfrequenz eingesetzt werden , also z.B. auch 1280x1024@72Hz um eine Auflösung von 1280x1024 Pixeln bei 72 Hz Bildwiederholfrequenz bei der Einrichtung zu erwzingen.


Zu kleine oder nicht änderbare Auflösung

Wenn die Auflösung nicht stimmt da sie zu klein ist und sich nicht größer einstellen lassen will per Sax2, xorgconfig oder xorgcfg, hilft es meist, die Frequenzenzeckdaten (horizontale Ablenkfrequenz und vertikale Refreshrate) für den Monitor in die Section Monitor statt den dort stehenden einzutragen und die Erkennung dieser Eckdaten per EDID per 

nvidia-xconfig --no-use-edid-freqs

und gegebenenfalls auch noch 

nvidia-xconfig --no-use-edid-dpi

abzuschalten.

Achtung: Diese Werte nicht blindlings übernehmen!

Diese folgenden Werte bitte nicht einfach für andere Monitore übernehmen, da diese Werte speziell für besagten Eizo T67S Monitor sind und andere Monitore dadurch eventuell zerstört werden könnten wenn sie nicht genau dieselben Frequenzeckdaten/-grenzwerte haben. Die richtigen Werte für den jeweiligen Monitor sind dem Monitorhandbuch bzw. zugehörigen Datenblatt zu entnehmen, was man normalerweise auch beim Hersteller bekommen kann wenn man eventuell keins mehr zur Hand hat


Beispiel für eine Section Monitor für einen Eizo T67S : 

Section "Monitor"
   Identifier     "Monitor[0]"
   VendorName     "EIZO"
   ModelName      "EIZO T67S"
   UseModes       "Modes[0]"
   DisplaySize     397    317
   HorizSync       30.0 - 95.0
   VertRefresh     50.0 - 160.0
   Option         "CalcAlgorithm" "XServerPool"
   Option         "DPMS"
EndSection




Bildwiederholfrequenz wird nicht richtig erkannt oder ist nicht umstellbar

Sofern obiger Tip nicht bereits das eventuell auftauchende Problem mit falsch erkannten Frequenzeckdaten behoben hat, so liegt dies meist am Vorhandensein der Dynamic Twinview Option, die per Default durch den NVIDIA-Treiber aktiviert ist. Sofern man diese dann durch Eingabe von 

nvidia-xconfig  --no-dynamic-twinview

als User root ausschaltet, sollte dieses Problem auch erledigt sein, so daß man dann mit 

sax2 -r -l -m 0=nvidia

wieder ein rudimentäres X konfigurieren kann (sofern der Monitor bis dahin nur eine "Out-Of-Range" Meldung von sich gab und man daher keinerlei X Window System zur verfügung hatte) und anschließend (oder eben stattdessen, sofern X mit geringer Bildwiederholfrequenz lief) im grafischen Modus per 

kdesu nvidia-settings

oder im Falle von Gnome-Nutzung 

gnomesu nvidia-settings

oder im Falle eines anderen Windowmanagers in einem xterm zuerst 

xhost +

und anschließend 

sudo nvidia-settings

die genauere Frequenzeinstellung gemäß den ja vorher eingegebenen konkreten Frequenzeckdaten des Monitors vornehmen kann. Sollte man jedoch sowieso nur einen Monitor in Betrieb haben und auch kein TV-Out benötigen, so kann man TwinView auch komplett abschalten per 

nvidia-xconfig --no-twinview

sowie 

nvidia-settings --only-one-x-screen
Achtung: Vorsicht! Der Folgende Tip ist nur im äußersten Notfall zu nutzen!

Der folgende Tip sollte nur dann genutzt werden, wenn gar kein anderer Weg mehr funktioniert um zu einer grafischen Darstellung zu kommen, da man wirklich genau(!) wissen muss welches die Grenzfrequenzen des Monitors und maximalen Leistungsgrenzen des RAMDAC der Grafikkarte sind! Falsche Werte können hiermit den Monitor sehr schnell unwiderruflich zerstören und auch die Grafikarte überhitzen!


Wenn also gar nichts anderes mehr funtioniert kann man mit dem Tool xmode Modelines selbst berechnen lassen. Die so berechneten Modelines müssen in die Section Screen, genauer gesagt dort in die SubSection Display, eingefügt werden um sie zu nutzen.

Mögliche Parameter für den xmode Aufruf: 

-r oder --refresh Vertikale Bildwiederholfrequenz/Refreshrate in Hz 
-s oder --sync Horizontale Synchronisationsfrequenz in kHZ
-x oder --xdim X-Auflösung in Pixel
-y odr --ydim Y-Auflösung in Pxel
-d  oder --dacspeed RAMDAC Geschwindigkeit in mHz

Beispielaufruf: 

xmode -r 60 -x 1600 -y 1200

Ausgabe des Beispielaufrufs: 

75
60
Modeline "1600x1200" 160.96 1600 1704 1880 2160 1200 1201 1204 1242

Die letzte Zeile ist diejenige, die man dann in der /etc/X11/xorg.conf an oben genannter Stelle einfügen sollte.

Die Nutzung der so gewonnenen Modeline kann man für per DVI angeschlossene Monitore auch mit Hilfe von 

nvidia-xconfig  --exact-mode-timings-dvi

erzwingen.




Mein DVI-Monitor wird nicht erkannt, am VGA Anschluß per Adapter läuft er aber

Bei DVI kanns in seltenen Fällen sein, daß man die Nutzung dieses Anschlußes erstmal erzwingen muss. Das ginge dann über folgende Optionen in der Section Device der /etc/X11/xorg.conf: 

Option "ConnectedMonitor" "DFP"
Option "UseDisplayDevice" "DFP"

und sofern die Nutzung des VGA-Anschlußes und des TV-Anschlußes komplett ignoriert werden soll da dort vielleicht gar nichts angeschlossen ist noch 

Option "IgnoreDisplayDevices" "CRT, TV"

hinzunehmen und es sollte laufen. Dies kann auch per 

nvidia-xconfig --use-display-device=DFP

mit nvidia-xconfig (ist mit root-Rechten zu starten) eingetragen werden sofern man sich nicht an das manuelle editieren der xorg.conf herantraut.


AGP-Grafikkartenprobleme

Aperture Size zu klein

Bei einigen Grafikkarten kann eine Erhöhung der AGP Aperture Size im BIOS erforderlich sein, da, sofern diese dort zu klein eingestelt ist, das nvidia-Kernelmodul den Betrieb verweigert. Dieser Fehler ist im Forum schon im Zusammenhang mit einer GeForce 6600 GT AGP erläutert worden und meist nicht so einfach zu finden, da er im Logfile /var/log/xorg.log nicht auftaucht,jedoch eine kleine unscheinbare Warnung im Bootlogfile /var/log/boot.msg diesbezüglich zu finden ist.


Chipsatzbedingte AGP-Probleme

Falls man im Logfile /var/log/Xorg.log bzw. /var/log/Xorg.0.log bei der Fehersuche nach Gründen warum der X-Server nicht startet auf AGP-bedingte Fehler stößt und diese offensichtlich mit dem verwendeten Chipsatz zusammenzuhängen scheinen, dann kann über eine Option in der /etx/X11/xorg,conf die Nutzung oder Nichtnutzung des agpgart Kernelmoduls bzw. der NVIDIA eigenen Variante erwzungen werden. Die benötigte Option 

Option "NvAGP" "<Wert>"

kann sich entweder in der Section Screen oder der Section Device befinden. Für <Wert> können dabei folgende Werte eingesetzt werden 

0 	=deaktiviere AGP
1 	=nutze NVIDIAs internen AGP Support sofern es möglich ist
2 	=nutze AGPGART sofern es möglich ist
3 	=nutze irgendeinen AGP Support (zuerst  AGPGART probieren, ansonsten NVIDIAs AGP nutzen)

Welches Kernelmodul letztendlich genutzt wird zeigt 

lsmod | grep agp

auf der Konsole. Die von NVIDIAs NvAGP unterstützten Chipsätze finden sich in Kapitel 12 des NVIDIA Readme Files, welches bei installiertem Treiber auch unter file://usr/share/doc/NVIDIA_GLX-1.0/README.txt zu finden sein dürfte. Sollte selbst die Deaktivierung der AGP-Nutzung in der /etc/X11/xorg.conf nicht weiterhelfen, so kann man auch probieren mit Hilfe des Kernelparameters 

agp=0

über z.B. Eingabe in der GRUB-Bootloadereingabezeile die Konflikte mit der im Kernel eingebauten AGP-Unterstützung durch Abschaltung selbiger zu umgehen.

Sofern die proprietären NVIDIA-Treiber bereits auf dem System instaliert sind, man aber aufgrund von AGP-Problemen den X-Server nicht starten kann, kann man auch mit Eingabe einer simplen 3 im Grub Bootmenü den Rechner im Runlevel 3 hochfahren und mit dem Befehl 

nvidia-xconfig --nvagp=NVAGP

die AGP-Einstellung nachträglich hereinsetzen. Für NVAGP ist dann der gewünschte Wert entsprechend der obigen Tabelle einzusetzen. Dies kann ein händiges Editieren der /etc/X11/xorg.conf ersparen.


XGL Probleme

Wie deaktiviert man XGL wieder?

Eigentlich ist XGL recht einfach zu deaktivieren. Dazu ändert man einfach in /etc/sysconfig/displaymanager 

DISPLAYMANAGER_XSERVER="Xgl"

zurück auf 

DISPLAYMANAGER_XSERVER="Xorg"

und schon ist XGL nach einem Neustart des X-Servers deaktiviert.


Probleme mit dem 96xx-Legacy Treiber

Monitor nicht einstellbar/X-Server startet nicht

Sofern man eine Grafikkarte oder einen Grafikchipsatz besitzt die/der eigentlich in der Kompatibilitätsliste für den 96xx-Legacy-Treiber enthalten ist und man dennoch nichts angezeigt bekommt trotz dem Versuch mit 

nvidia-xconfig --no-use-edid

die automatische Monitorerkennung abzuschalten, dann kann ein Rückgriff auf den noch älteren 7xxx-Legacy-Treiber dieses Problem lösen. Da mit diesem Treiber jedoch kein NV-GLX zur Verfügung gestellt werden kann, muss bei beabsichtigter 3D Desktopnutzung auf XGL zurückgegriffen werden.

Sollte dies jedoch gemäß /var/log/Xorg.0.log bzw. /var/log/nvidia-installer.log mit mangelhaften AGP-Chipsätzen zusammenhängen, dann sollte man den obigen Abschnitt Chipsatzbedingte AGP-Probleme nochmal genauer durchlesen.


Probleme mit der Textkonsole

Bunte Artefakte oder schwarzer Bildschirm beim Umschalten

Wenn man vom grafischen Modus auf eine Textkonsole umschalten will und dann entweder recht wirre bunte Artefakte zu sehen bekommt oder auch einen schwarzen Bildschirm , dann hat man einen alten Bug im NVIDIA-Treiber erwischt der nur in wenigen Grafikarten/Treiberversionskombinationen auftritt. Der Grund dafür ist eine Unverträglichkeit des NVIDIA-Treibers mit dem VESA-Framebuffer Konsolentreiber die sich jedoch nur in wenigen Kombinationen von Grafikkarten+Treiberversionen bemerkbar macht. Ein Workaround zur Vermeidung des Bugs ist in der /boot/grub/menu.lst von Grub den vga-Mode in den Kernelparametern auf normal zu setzen statt auf einen der VESA-Modi. Der einzige Nachteil ist, daß dann natürlich auch auf den Bootsplash verzichtet werden muss der ja nach Auswahl des jeweiligen Menüpunktes in Grub zum Zuge käme. Der grafische Grub Bootscreen selbst ist davon nicht betroffen.

Eien weitere Möglichkeit die eventuell den VESA-Mode des Bootsplash nicht deaktiviert und oft schon helfen kann wäre das Einfügen der folgenden Option in der Section Device in der /etc/X11/xorg.conf: 

Option      "IgnoreDisplayDevices"      "TV"

Damit wird der Framebuffer auf der Grafikkarte nicht automatisch für die Nutzung des TV-Out Anschlußes vorbereitet wobei durch eben diese Vorbereitung des Framebuffers oft besagte Probleme mit der Umschaltung auf die Textkonsole auftreten würden.


Probleme mit 3D Desktops

NV-GLX scheint langsam zu sein

Wenn man durch die Aktivierung von NV-GLX den Eindruck bekommt und/oder messbar die FPS-Rate auf die Bildwiederholfrequenz begrenzt zu sein scheint, dann hilft es in nvidia-settings die Sync to VBlank Option zu deaktivieren, denn damit wird die FPS-Rate mit der Bildwiederholfrequenz synchronisiert, was natürlich eine Bremse darstellt für die meisten OpenGL nutzenden Anwendungen und eben auch 3D Desktopsysteme wie Beryl oder Compiz-Fusion.


Der Arbeitsumflächenschalter zeigt unter KDE mit Beryl/Compiz(-Fusion) zuviele Arbeitsflächen

Das liegt daran, daß Beryl,Compiz und Compiz-Fusion ihre Arbeitsflächen anders aufteilen als KDE es erwartet. Zu diesem Zwecke deaktiviert man in der Kontrollleisteneinrichtung einfach den bisherigen Arbeitsflächenumschalter und setzt stattdessen unter Compiz und Beryl Umschalten zwischen Arbeitsflächen - Compiz beziehungsweise unter Compiz-Fusion Kpager2 aus der Miniprogrammliste der Kontrollleisteneinrichtung ein.

Da es kpager2 für openSUSE 10.3 noch nicht als fertiges Paket gibt, aber die Version für openSUSE 10.2 offenbar auch unter 10.3 (getestet mit der openSUSE 10.3 64 Bitversion) funktioniert, sei an dieser Stelle vorläufig auf http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/Utilities/kpager2/ verwiesen um sich das Paket herunterzuladen und per 

rpm -Uvh <Paketname>

dann im System zu installieren. Für opensuse 10.1 und 10.1 gibt es das Paket im Guru Repository oder wer es selbst kompilieren möchte findet es auf KDE-Look.org.

Achtung: Andere Zählweise für die Arbeitsflächen

Im Gegensatz zu normalen Desktops ist im Zusamenhang mit 3D Desktops wie Beryl, Compiz oder Compiz-Fusion eine andere Zählweise für Arbeitsflächen im Einsatz als sonst üblich!


Als einzelne Arbeitsflächen, wie sie von kpager2 angezeigt werden, zählen die 4 nutzbaren Seiten des Würfels, der ja eigentlich aufgrund der Seitenverhältnisse des Monitors ein Quader ist, und die zusammen einen Viewport bilden. Von kpager2 werden nicht Arbeitsflächen im herkömmlichen Sinne angezeigt sondern eben diese Viewports. Daraus folgt, daß 2 Viewports 2 unabhängige Würfel sind und man somit 8 nutzbare Seiten (=die eigentlichen Arbeitsflächen) hat, bei 3 Viewports entsprechend 12 nutzbare Seiten usw. wodurch jedoch auch der Speicherbedarf entsprechend höher wird.


Die Fensterdekorationen von Compiz bzw. Compiz-Fusion sind weg

Leider passiert es ab der Treiberversion 169.07, daß die Fensterdekoration nicht mehr angezeigt wird. Dieser Fehler läst sich aber beheben. Dazu werden beim Start von compiz die zusätzlichen Parameter --no-libgl-fallback --replace --damage-events ccp& benötigt. Folglich sähe der Aufruf aus einem Script heraus oder der Konsole heraus so aus: 

compiz --no-libgl-fallback --replace ccp &

Vielfach liest man noch, daß die Variable LIBGL_ALWAYS_INDIRECT=1 gesetzt sein müsste,was jedoch definitiv nicht zwingend notwendig ist, jedoch auch nicht schadet. Sofern mit Compiz-Fision gearbeitet wird muss man ggf. noch die Datei data.py abändern. Diese Datei befindet sich beispielsweise auf 32 Bit openSUSE Systemen unter 

 /usr/lib/python2.5/site-packages/FusionIcon

und auf 64 Bit openSUSE Systemen unter 

  /usr/lib64/python2.5/site-packages/FusionIcon

wobei in dieser Datei aus der Zeile 

compiz_args = ['--replace', '--sm-disable', '--ignore-desktop-hints', 'ccp']

die Zeile 

compiz_args = ['--replace', '--sm-disable', '--ignore-desktop-hints', 'ccp', '--no-libgl-fallback', -damage-events']

gemacht werden sollte, also der Aufruf mit den Zusatzparametern --no-libgl-fallback und --damage-events versehen werden sollte, wie auch beim reinen Compiz.


Effekte ohne 3D Desktop

Wo aktiviere ich die Transparenz für KDE?

Um Transparenzeffete von KDE ohne einen Composite-Manager wie Compiz laufen zu haben, benötigt man folgende Option in der Section Extensions am Ende der Konfigurationsdatei /etc/X11/xorg.conf: 

Option "Composite" "Enable"

Diese Option kann sich jedoch mit 3D Desktopeffekten von Compiz-Fusion oder ähnlichen Compositemanagern beissen. Sie beisst sich auf jeden Fall mit XGL. Die Wahrscheinlichkeit von Problemen mit dieser Option und laufenden 3D Desktops unter NV-GLX kann jedoch durch die Option 

 Option         "AllowGLXWithComposite" "True"

(die per 

nvidia-xconfig --allow-glx-with-composite

in der xorg.conf an der richtigen Stelle, nämlich der Section Device, eingetragen werden kann sofern man sie beim Einrichten von NV-GLX aus irgendeinem Grund vergaß) in der Section Device verringert, jedoch nicht ganz ausgeschlossen werden.


Probleme mit der DVB- oder Videowiedergabe

Wenn ein Stottereffekt (wie "Scratching" bei Vinylscheiben Audiowiedergabe,nur als unbeabsichtigter Videoeffekt) bei der Videowiedergabe mit Xine/Kaffeine/MPlayer/VLC oder ähnlichen Video+DVB-Abspielprogrammen auftritt, kann es am aktivierten Videooutputtreiber liegen, was durch 

nvidia-xconfig --xvmc-uses-textures

als User root aufgerufen, den X-Server neustarten und Kaffeine/Xine auf xv umstellen gelöst werden kann. Der xvmc Videooutputtreiber scheint wider Erwarten nicht wirklich zu funktionieren, mit xv jedoch geht es mit dieser Lösung (zumindest wurde es im Zusammenhang mit NV-GLX auf einem GeForce 6600 GT SLI-System erfolgreich getestet)...


Hardwarewechsel der Grafikkarte

Von ATI mit fglrx-Treiber zu NVIDIA

Zuerst startet man den Rechner in Runlevel 3 durch die Eingabe einer simplen 3 in der Eingabezeile des GrUB beim Systemstart. Dann loggt man sich als root ein um mit 

./fglrx-uninstall.sh

aus dem Verzeichnis aus dem man früher irgendwann einmal die ATI Treiber heraus installierte eben diese wieder zu deinstallieren. Ob die Deinstallation erfolgreich war überprüft man am besten per 

rpm -e $(rpm -qa | grep fglrx)

(beziehungsweise unter debianbasierten Distributionen mit dem entsprechenden dpkg-Aufrufspendant) Danach instaliert man den proprietären NVIDIA-Treiber gemäß dem NVIDIA-Wikibook hier und lässt per 

nvidia-xconfig

eine grundlegende X-Serverkonfiguration vornehmen. Man kann dies unter openSUSE natürlich direkt auch per 

sax2 -r -m 0=nvidia

erledigen, jedoch scheint es aufgrund der vorher einmal installierten ATI-Treiber dabei gelegentlich Probleme zu geben, die bei der Nutzung von nvidia-xconfig nicht aufzutreten scheinen. Wenn man eine grundlegende xorg.conf sich auf diesem Wege mit nvidia-xconfig erstellt hat kann man sie unter openSUSE natürlich mit 

sax2 -a -m 0=nvidia

wunschgemäß anpassen, wobei die meisten Anpassungen ja wie bereits in vorherigen Kapiteln beschrieben ebensogut per nvidia-xconfig oder nvidia-settings umsetzbar sind.


Von anderen Grafikkartenherstellern oder generischen Treibern zu NVIDIA

Die einfachste Methode ist nach der Installation der proprietären NVIDIA-Treiber gemäß der vorangegangenen Kapitel die Anpassung der vorhandenen xorg.conf durch 

nvidia-xconfig

automatisch anpassen zu lassen, jedoch funktioniert unter openSUSE 

sax2 -r -m 0=nvidia

meist mindestens ebensogut.


Chipsatzbedingte Kompatibilitätsprobleme

NVIDIA-Grafikkarten auf ATI Mainboard-Chipsätzen

Es scheint so als wären einige ATI-Chipsätze recht inkompatibel zu diversen NVDIA-Grafikkarten. Eine Lösung könnte möglicherweise ein inoffizieller Patch für das Treiberinstallationspaket von der NVIDIA-Website sein der wie unter http://www.nvnews.net/vbulletin/showpost.php?p=1325093&postcount=100 beschrieben durchzuführen wäre.

Update: Seit Treiberrelease 100.14.19 ist dies wohl nun bereits im Treiber integriert!



NVIDIA: Intro - Installation - Konfiguration - 3D Desktops - Troubleshooting - Hintergrundwissen - Schlusswort


zurück zu Grafikkarten und Monitore

Abgerufen von „https://linupedia.org/wiki/mediawiki/index.php?title=NVIDIA-Wikibook/Troubleshooting&oldid=25086“