nvidia-treiber und kernel-2.6.0-test4

[Eremit]

hallo,

ich bekomme einfach die nvidia-treiber nicht ans laufen.
mein kernel ist 2.6.0-test4 und die anleitung dazu habe hier hier gezogen:
http://www.minion.de/files/NVIDIA_kernel-1.0-4496.README

der treiber selber lief auch beim "make install" durch und alles schien bestens. XF86Config geändert mit "Load glx" und "Driver" als "nvidia" anstatt "nv". also rechner neu gestartet und wenn X startet hängt der rechner einfach und friert ein. dieses steht auch in der readme drin. also habe ich beim starten dem kernel ein "mem=nopentium acpi=off" mitgegeben. gleiches ergebnis.
was ich in der kurzen readme nicht verstehe warum es dort 2 anleitungen gibt. einmal scheinbar "normal" und einmal so: "If you wish to install the NVIDIA 1.0-4496 driver on a virgin Linux 2.6 system that doesn't have the user space driver components installed, you can use a Linux 2.6 compatible version of the official installer."

warum und was sagt mir das? was sind die "user space driver components"?

hoffe ihr könnt mir helfen.

anbei noch meine kernel-config-datei. vielleicht hilft das ja.

mfg

Eremit

[zander]

Ich würde zunächst folgendes ausprobieren: rivafb ist traditionell nicht mit den NVIDIA Treibern kompatibel und sollte daher nicht benutzt werden; Du kannst zu Testzwecken den Kernel mit video=riva:off vga=normal starten oder gleich den Kernel ohne CONFIG_FB_RIVA übersetzen. Mit etwas Glück behebt das bereits Dein Problem. Weiterhin ist es möglich, daß es Probleme mit AGPGART gibt, in Linux 2.6 gab es mit diesem Treiber wiederholt Probleme. Sollte also rivafb nicht für Dein Problem verantwortlich sein, empfiehlt es sich, AGP zunächst vollständig abzuschalten und dann ggf. die NVIDIA AGP GART Treiber zu benutzen.

Weiterhin ist die Option mem=nopentium im Zusammenhang mit Linux 2.6 problematisch und sollte nicht benutzt werden; sie ist auch überflüssig, da Linux 2.6 einen Mechanismus anbietet, der es dem NVIDIA Treiber erlaubt, das Problem, das unter anderem mit besagter Option umgangen werden soll, von vorne herein zu vermeiden.

Die beiden Anleitungen in der README beschreiben die Installation des Kernelmoduls für den Fall, daß die NVIDIA Treiber bereits vollständig, z.B. mit Hilfe des Installationsprogramms, installiert wurden (Linux 2.2/2.4) oder die Anpassung des Installationspaketes für Linux 2.6 für den Fall, daß nicht nur das Kernelmodul sondern der vollständige NVIDIA Treiber installiert werden soll. Der Terminus userspace components steht für das NVIDIA XFree86 Treiber- und XFree86 GLX Erweiterungsmodul sowie die NVIDIA OpenGL und XVMC Bibliotheken.

[Eremit]

hallo,

danke für die kompetente antwort.

die treiber laufen nun. fast.
das nvidia-logo erscheint und sowohl glxinfo als auch glxgears geben vernünftige werte aus bzw. laufen einwandfrei.
das ganze funktionierte erst nachdem ich sowohl CONFIG_FB_RIVA und AGPGART aus dem kernel entfernt habe.

nun noch mein letztes problem. wenn ich mich aus kde auslogge bzw. den x-server neustarte oder auf die konsole wechsle friert das system ein. der bildschirm wird schwarz aber der monitor bleibt an. es wird also keine ungültige frequenz oder so aufgerufen. der rechner kann dann auch nicht mehr heruntergefahren werden. somit muss ich jedesmal meinen rechner resetten. ist nicht gerade schön.

gibt es hierzu noch eine lösung?
als anhang was die datei kern.log dazu meint. sieht wirklich kryptisch aus.....


mfg

Eremit

[zander]

Sieht abenteurlich aus, passiert das jedes Mal? In diesem speziellen Fall scheint dem Kernel der Speicher ausgegangen zu sein...

[Eremit]

hallo,

das passiert jedesmal. der rechner stürzt immer ab, wenn der x-server beendet wird, neu startet oder ich auf die konsole wechseln will.

mein system:
amd athlon 2400
speicher: 512 mb ddr-ram
system: gentoo-rc4

gibt es da noch irgendeine lösung?


mfg

Eremit

[zander]

Tritt das Problem auch mit Linux 2.6.0-test3 auf? Möglicherweise hängt das Problem mit 2.6.0-test4 zusammen, es wäre gut diese Theorie bestätigen oder wiederlegen zu können.

[Eremit]

hallo,

habe gerade kernel-2.6.0-test3 ausprobiert und muss feststellen, dass dort das gleiche problem existiert. leider. :(

muss man noch irgend etwas beachten? bin bei der installation nach der ersten methode aus der readme vorgegangen.

mfg

Eremit

[zander]

Eigentlich nicht; irgendetwas besonderes in der Konfigurationsdatei des Kernels?

[Eremit]

ich denke nicht.
habe die kerneldatei von 2.6.0-test3 mal mitangegeben.

was passiert denn genau beim verlassen des x-servers? ich meine, der server wird beim system-boot ja gestartet. nun müsste er doch in der lage sein diesen auch wieder erneut zu starten. zumal der rechner auch abstürzt wenn ich nur in die console wechsle. vielleicht liegt es gar nicht am server sondern es hakt irgendwo anders.
wo finde ich denn genauere fehlermeldungen? die xfree-log-datei wird scheinbar jedesmal überschrieben.

mfg

Eremit

nachtrag:
braucht man noch irgendwelche aktuellen tools? irgendwelche modutils oder was es da alles so gibt?
z.b.: module-init-tools version 0.9.13-pre2

[zander]

Nun, normal ist das Verhalten nicht, der X Server sollte sich normalerweise natürlich problemlos beendern lassen. Ausser den module-init-tools, die zum Laden/Verwalten der Module benötigt werden, sind noch einige andere Vorraussetzungen zu erfüllen, siehe dazu die Kerneldokumentation und ggf. den halloween Text zu Linux 2.5/2.6. Dein Problem lässt sich aber eigentlich nicht durch fehlerhafte Konfiguration erklären; um es besser verstehen zu können wäre es hilfreich, wenn Du den Kernel mit DEBUG Funktionalität übersetzen und über eine serielle Konsole beobachten könntest.

[zander]

Kannst Du Deine Konfigurationsdatei anhängen?

[Eremit]

upps.
die kernelconfig hatte ich glatt vergessen.

[zander]

Ich habe Deine -test3 Konfigurationsdatei mit meiner alten -test3-bk2 Konfigurationsdatei verglichen; es gibt natürgemäß einige Unterschiede, aber nichts auffälliges. Eine mögliche Ausnahme ist die Option CONFIG_HUGETLB_PAGE, die ich nicht gesetzt habe; ich halte es zwar für unwahrscheinlich, aber macht es einen Unterschied, wenn Du sie ebenfalls deaktivierst?

[Eremit]

tag,

habe CONFIG_HUGETLB_PAGE nun deaktiviert aber immer noch das gleiche ergebnis. der rechner friert ein sobald ich den xserver neu starte. beim ersten start funktioniert alles einwandfrei. nur ausloggen oder den rechner herunterfahren kann ich nicht.

folgendes habe ich noch in der kdm.log gefunden:
NV: could not open control device /dev/nvidiactl (No such file or directory)
(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!
(EE) NVIDIA(0): *** Aborting ***
(EE) Screen(s) found, but none have a usable configuration.



hier noch mal der auszug aus der datei kern.log:
Sep 4 20:43:31 eremitpc kernel: nvidia: module license 'NVIDIA' taints kernel.
Sep 4 20:43:31 eremitpc kernel: 0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed Jul 16 19:03:09 PDT 2003
Sep 4 20:43:43 eremitpc kernel: Debug: sleeping function called from invalid context at mm/slab.c:1817
Sep 4 20:43:43 eremitpc kernel: Call Trace:
Sep 4 20:43:43 eremitpc kernel: [<c011aa7f>] __might_sleep+0x5f/0x70
Sep 4 20:43:43 eremitpc kernel: [<c013e515>] kmem_cache_alloc+0x65/0x70
Sep 4 20:43:43 eremitpc kernel: [<c014c9b1>] __get_vm_area+0x21/0x100
Sep 4 20:43:43 eremitpc kernel: [<c014cac3>] get_vm_area+0x33/0x40
Sep 4 20:43:43 eremitpc kernel: [<c0118323>] __ioremap+0xb3/0x100
Sep 4 20:43:43 eremitpc kernel: [<c0118399>] ioremap_nocache+0x29/0xc0
Sep 4 20:43:43 eremitpc kernel: [<e0da250c>] os_map_kernel_space+0x4c/0x80 [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<e0c77377>] __nvsym00568+0x1f/0x2c [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<e0c79496>] __nvsym00775+0x6e/0xe0 [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<e0c79526>] __nvsym00781+0x1e/0x190 [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<c015b741>] exact_lock+0x11/0x20
Sep 4 20:43:43 eremitpc kernel: [<e0c7afac>] rm_init_adapter+0xc/0x10 [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<e0d9f4ed>] nv_kern_open+0x11d/0x230 [nvidia]
Sep 4 20:43:43 eremitpc kernel: [<c015b720>] exact_match+0x0/0x10
Sep 4 20:43:43 eremitpc kernel: [<c015b474>] chrdev_open+0xf4/0x220
Sep 4 20:43:43 eremitpc kernel: [<c01ba04b>] devfs_open+0xeb/0x110
Sep 4 20:43:43 eremitpc kernel: [<c01514bb>] dentry_open+0x14b/0x220
Sep 4 20:43:43 eremitpc kernel: [<c0151366>] filp_open+0x66/0x70
Sep 4 20:43:43 eremitpc kernel: [<c0151803>] sys_open+0x53/0x90
Sep 4 20:43:43 eremitpc kernel: [<c01093ab>] syscall_call+0x7/0xb
Sep 4 20:43:43 eremitpc kernel:
Sep 4 20:43:44 eremitpc kernel: Debug: sleeping function called from invalid context at mm/slab.c:1817
Sep 4 20:43:44 eremitpc kernel: Call Trace:
Sep 4 20:43:44 eremitpc kernel: [<c011aa7f>] __might_sleep+0x5f/0x70
Sep 4 20:43:44 eremitpc kernel: [<c013e515>] kmem_cache_alloc+0x65/0x70
Sep 4 20:43:44 eremitpc kernel: [<c014c9b1>] __get_vm_area+0x21/0x100
Sep 4 20:43:44 eremitpc kernel: [<c014cac3>] get_vm_area+0x33/0x40
Sep 4 20:43:44 eremitpc kernel: [<c0118323>] __ioremap+0xb3/0x100
Sep 4 20:43:44 eremitpc kernel: [<c0118399>] ioremap_nocache+0x29/0xc0
Sep 4 20:43:44 eremitpc kernel: [<e0da250c>] os_map_kernel_space+0x4c/0x80 [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<e0c77377>] __nvsym00568+0x1f/0x2c [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<e0c79496>] __nvsym00775+0x6e/0xe0 [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<e0c79526>] __nvsym00781+0x1e/0x190 [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<e0c7afac>] rm_init_adapter+0xc/0x10 [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<e0d9f4ed>] nv_kern_open+0x11d/0x230 [nvidia]
Sep 4 20:43:44 eremitpc kernel: [<c015b474>] chrdev_open+0xf4/0x220
Sep 4 20:43:44 eremitpc kernel: [<c01ba04b>] devfs_open+0xeb/0x110
Sep 4 20:43:44 eremitpc kernel: [<c01514bb>] dentry_open+0x14b/0x220
Sep 4 20:43:44 eremitpc kernel: [<c0151366>] filp_open+0x66/0x70
Sep 4 20:43:44 eremitpc kernel: [<c0151803>] sys_open+0x53/0x90
Sep 4 20:43:44 eremitpc kernel: [<c01093ab>] syscall_call+0x7/0xb
Sep 4 20:43:44 eremitpc kernel:


was hat es denn mit der sleep-funktion auf sich???


mfg

Eremit

[zander]

Die Debug: sleeping function called from invalid context at... Warnungen werden ausgegeben, weil Du CONFIG_DEBUG_SPINLOCK_SLEEP gesetzt hast und weil der NVIDIA Treiber bestimmte Funktionen des Linux Kernels mit gehaltenen spin locks aufruft, die unter Umständen 'schlafen' können. Das hat sich in der Praxis als unproblematisch herausgestellt. Um Dein eigentliches Problem besser verstehen zu können wäre es vorteilhaft, wenn man über eine serielle Konsole (eventuelle mit kdb) verfolgen könnte, was genau passiert.

[Eremit]

hallo,

bin mir jetzt nicht ganz sicher was du genau mit kdb meinst. habe bei google gestöbert und herausgefunden, dass es kerne-patches für irgendwas sind. jedenfalls habe ich nichts für kernel 2.6-x gefunden.
auch weiss ich nicht genau was du mit "serielle konsole" meinst. habe hier aber ein netzwerk am laufen. kann sich nicht über das netz anzeigen lassen, was beim abschmieren des x-servers passiert?

mfg

Eremit

[zander]

kdb ist nicht zwingend notwendig; mit einer seriellen Konsole meine ich, daß ein zweiter Rechner, z.B. ein Notebook, über ein serielles Nullmodemkabel direkt an den Zielrechner angeschlossen wird. Danach werden dem Kernel des Zielrechners Paramater übergeben, die ihn dazu anweisen, Meldungen nicht nur an die lokale Konsole zu schicken, sondern auch an die serielle Konsole (siehe .../Documentation/serial-console.txt). Eine netzwerkfähige Variante gibt es derzeit soviel ich weiß nicht.