Nvidia 1.0-4496 und 2.4.21 Kernel
Hi, ich hab versucht, das hinzubekommen, nach Anleitungen zur 4363-Version, von z. B. Thomas Hertweck, der sich auch auf einen SuSE-Mitarbeiter bezog. Geht aber so nicht. Anleitung war wie folgt: Karsten Keil (SuSE) meinte dazu: =========================================================================== Ja, ich hatte im kernel gesucht wo das __VMALLOC_RESERVE verwendet wird und das war nur im setup.c, die externen Module habe ich nicht untersucht, auch weil mir nicht klar war, das es dort irgendwo eine Rolle spielen koennte. Fix ist einfach, ich schick spaeter auch einen neuen patch, wenn noetig. in include/asm-i386/page.h noch eine Zeile einfuegen (z.B. hinter #define __RESERVED_AREA extern unsigned long vmalloc_reserve; und in arch/i386/kernel/i386_ksyms.c ein EXPORT_SYMBOL(vmalloc_reserve); eventuell muss auch noch ein #include <asm/page.h> rein. [snip] Ausprobiert. Es hat sich herausgestellt, das um das extern unsigned long vmalloc_reserve; noch ein #ifndef __ASSEMBLY__ ... #endif muss. =========================================================================== Fehlermeldungen: cc -c -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith -Wcast-qual -Wno-multichar -O -MD -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DNTRM -D_GNU_SOURCE -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=4496 -DNV_UNIX -DNV_LINUX -DNV_INT64_OK -DNVCPU_X86 -DREMAP_PAGE_RANGE_4 -I. -I/lib/modules/2.4.21-4-athlon/build/include -Wno-cast-qual os-registry.c In file included from /lib/modules/2.4.21-4-athlon/build/include/linux/vmalloc.h:8, from nv-linux.h:72, from os-registry.c:14: /lib/modules/2.4.21-4-athlon/build/include/linux/highmem.h: In function `bh_kmap': /lib/modules/2.4.21-4-athlon/build/include/linux/highmem.h:23: warning: pointer of type `void *' used in arithmetic In file included from os-registry.c:14: nv-linux.h: In function `calc_order': nv-linux.h:497: warning: comparison between signed and unsigned ld -r -o nv-linux.o nv.o os-agp.o os-interface.o os-registry.o ld -r -o nvidia.o nv-linux.o nv-kernel.o depmod: *** Unresolved symbols in /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o: unresolved symbol vmalloc_reserve /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o: Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. The module may be trying to access GPLONLY symbols but the problem is more likely to be a coding or user error. Contact the module supplier for assistance, only they can help you. /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o: insmod /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o failed /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o: insmod nvidia failed make: *** [package-install] Error 255 vmalloc_reserve ist also das Schuldige. Soll ich lieber doch wieder die Quick&Dirty-Patche probieren (nv.c),weil's ja immer noch keinen Patch dafür gibt (Was sagt Karsten Keil dazu)? unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT; René
René Matthäi schrieb:
Karsten Keil (SuSE) meinte dazu: =========================================================================== Ja, ich hatte im kernel gesucht wo das __VMALLOC_RESERVE verwendet wird und das war nur im setup.c, die externen Module habe ich nicht untersucht, auch weil mir nicht klar war, das es dort irgendwo eine Rolle spielen koennte. Fix ist einfach, ich schick spaeter auch einen neuen patch, wenn noetig. in include/asm-i386/page.h noch eine Zeile einfuegen (z.B. hinter #define __RESERVED_AREA
extern unsigned long vmalloc_reserve;
und in arch/i386/kernel/i386_ksyms.c ein
EXPORT_SYMBOL(vmalloc_reserve);
eventuell muss auch noch ein #include <asm/page.h> rein. [snip] Ausprobiert. Es hat sich herausgestellt, das um das extern unsigned long vmalloc_reserve; noch ein #ifndef __ASSEMBLY__ ... #endif muss. ===========================================================================
Fehlermeldungen: [...] depmod: *** Unresolved symbols in /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o /lib/modules/2.4.21-4-athlon/kernel/drivers/video/nvidia.o: unresolved symbol vmalloc_reserve [...]
Ich hab zwar keine Loesung, aber ich kann das Verhalten von Rene bestaetigen. Die Loesung von Karsten Keil funktioniert mit Nvidia- Treiber 1.0-4496 und 2.4.21-4 Kernel von SuSE (H. Mantel) nicht!! Rene, vielleicht solltest Du mal direkt eine Email an H. Mantel schreiben, dass dieser Fehler endlich aus der Welt geraeumt wird. Ich habe gesehen, dass Du auch auf der englischen Liste schon ent- sprechend gefragt hast, Du hast also vermutlich alle relevanten Info schon beisammen. Ich denke, SuSE braucht hier Feedback...! CU, Thomson
Am Dienstag, 19. August 2003 19:13 schrieb Thomas Hertweck:
Ich hab zwar keine Loesung, aber ich kann das Verhalten von Rene bestaetigen. Die Loesung von Karsten Keil funktioniert mit Nvidia- Treiber 1.0-4496 und 2.4.21-4 Kernel von SuSE (H. Mantel) nicht!!
Demnächst stehen mir einige PCs mit Nvidia-Grafikkarte bevor, was ist die _augenblicklich_ beste Lösung mit einem SuSE-Kernel? Hier geht es um Geforce2 und Geforce4-Karten, die geringfügig mit 3D verwendet werden sollen. Funktioniert NVIDIA-Linux-x86-1.0-4363.run mit dem 2.4.21-4-Mantel-Kernel? Funktionieren die mit you upgedateten 2.4.20 Kernel mit NVIDIA-Linux-x86-1.0-4363.run oder NVIDIA-Linux-x86-1.0-4496-pkg2.run? Ich glaube, dass du Thomas, geschrieben hast, dass es mit einem Vanilla-Kernel fuktioniert. Hast du da den 4363 oder 4496 verwendet? Al
Al Bogner schrieb:
Demnächst stehen mir einige PCs mit Nvidia-Grafikkarte bevor, was ist die _augenblicklich_ beste Lösung mit einem SuSE-Kernel?
Verwende den Standard-SuSE Kernel 2.4.20 (incl. Updates) und es geht alles, meide den SuSE-Kernel 2.4.21. Mit Vanilla-Kernel (auch den aktuellen) scheint alles ebenfalls zu gehen.
Hier geht es um Geforce2 und Geforce4-Karten, die geringfügig mit 3D verwendet werden sollen.
Funktioniert NVIDIA-Linux-x86-1.0-4363.run mit dem 2.4.21-4-Mantel-Kernel?
Weiss ich nicht, kann ich mir aber nicht vorstellen, da das Problem eher am neuen SuSE-Kernel liegt und nicht am NVIDIA- Treiber...
Funktionieren die mit you upgedateten 2.4.20 Kernel mit NVIDIA-Linux-x86-1.0-4363.run oder NVIDIA-Linux-x86-1.0-4496-pkg2.run?
Ja.
Ich glaube, dass du Thomas, geschrieben hast, dass es mit einem Vanilla-Kernel fuktioniert. Hast du da den 4363 oder 4496 verwendet?
Hier ist momentan 1.0-4496 am Laufen. CU, Thomson
Am Dienstag, 19. August 2003 22:23 schrieb Thomas Hertweck:
Verwende den Standard-SuSE Kernel 2.4.20 (incl. Updates) und es geht alles, meide den SuSE-Kernel 2.4.21. Mit Vanilla-Kernel (auch den aktuellen) scheint alles ebenfalls zu gehen.
Ok, grundsätzlich funktioniert alles, aber nun bin ich wieder bei meinem alten Thread: Am Sonntag, 20. April 2003 12:02 schrieb Al Bogner: 8.2: nvidia - 3D - Refresh rate bei 55Hz
gears 4593 frames in 5.013 seconds = 916.218 FPS
Sowohl damals als auch heute war es 8.2 mit allen You-Updates. Damals wurde der nvidia-Treiber aber noch per you installiert. Heute habe ich mit NVIDIA-Linux-x86-1.0-4496-pkg2.run um die 2000fps (Geforce2 - MX400) und an der eventuell problematische PCI-Slot-Belegung hat sich nichts geändert. Starte ich Tuxracer mit der Standardkonfiguration so schaltete sich der Monitor wieder auf 55Hz RefreshRate, nach ändern der Tuxracer-Konfiguration bin ich nun auf 107Hz, wobei mir noch nicht klar ist, was das auslöste, denn für die RefreshRate gibt es keinen eigenen Parameter. Wie mache ich nun am besten (bei einem anderen PC) einen Downgrade des Kernels vom Mantel 2.4.21-Kernel auf 2.4.20? Einfach mit yast den Kernel von der 8.2 CD installieren und dann die Updates machen? Al
Al Bogner wrote:
[...] Wie mache ich nun am besten (bei einem anderen PC) einen Downgrade des Kernels vom Mantel 2.4.21-Kernel auf 2.4.20? Einfach mit yast den Kernel von der 8.2 CD installieren und dann die Updates machen?
Wenn Du "ordentlich" vorgegangen bist, hast Du den 2.4.21 parallel zum alten Kernel installiert und brauchst nun nur den alten Kernel booten und in der Bootloader-Konfiguration wieder zum Standard machen :-) Falls dem wider Erwarten nicht so sein sollte und Du leicht- sinnigerweise den alten Kernel runtergeschmissen hast, dann musst Du den per RPM wieder von der CD installieren und nach dem Rebooten die Patches einspielen. Nach dem Einspielen des Original-Kernel-RPMs und _vor_ dem Rebooten solltest Du na- tuerlich Deine Bootloaderkonfigurations nochmal ueberpruefen und auch ueberpruefen, dass eine initrd korrekt kreiert wur- de, eine Ausgabe dafuer muss auf dem Terminal erscheinen beim Installieren des RPMs. CU, Thomson
participants (4)
-
Al Bogner
-
René Falk
-
René Matthäi
-
Thomas Hertweck