NVIDIA-Wikibook/Troubleshooting

Aus Linupedia.org
Version vom 2. August 2007, 14:21 Uhr von TomcatMJ (Diskussion | Beiträge) (NVIDIA/Problemlösungen wurde nach NVIDIA-Wikibook/Troubleshooting verschoben: zurück verschieben)
Wechseln zu: Navigation, Suche
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





Troubleshooting

Updates

Kernelupdates

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-100.14.11-pkg1.run -K
64bit: sh /home/USER/nvidia_treiber/NVIDIA-Linux-x86-100.14.11-pkg1.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 aktuellem 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 ;-)


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

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-100.14.11-pkg1.run -f

Für 64bit:

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

Zu beachten ist dabei der Parameter -f der für force steht und die Installation des Treibers aus dem heruntergeladenen Paket erzwingt. 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.

Konfigurationsprobleme

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:

sax2 -r -c1 -m 0=nvidia

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 oder zu kleine, 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, 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.


Bildwiederholfrequenz wird nicht richtig erkannt oder ist nicht umstellbar

Sofern obiger Tip nicht bereits das eventuel 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 anschieß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 swieso nur einen Monitor in Betrieb haben udn 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

Desweiteren kann man, sofern man sich eine entsprechende Modeline per

xmode --dacspeed <RAMDAC Geschwindigkeit in Mhz> --refresh <vertikale Refreshrate in Hz> \
--sync <Horizontale Syncrate in Khz> --xdim <Bildschirmauflösung in X-Richtung in Pixeln> \
--ydim <Bidschirmauflösung in Y-Richtung in Pixeln>

berechnen lassen hat und in der xorg.conf eingetragen hat, die Nutzung eben dieser per

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

erzwingen.


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 NVGLX 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.


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 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.



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



zurück zu Grafikkarten und Monitore