nvidia 4363 unter Kernel 2.4.21

René Matthäi

7 Jul 2003 7 Jul '03

16:55

Hallo, hat diese Kombi jemand am Laufen? Bei mir bricht der Kompilierungsvorgang ab mit 'vmalloc_reserve' undeclared in nv.o Im Forum auf www.nvidia.com stehen auch nur 2 Fragen, aber keine Lösung. Grüße, René P. S.: Wäre nett, wenn Antworten an mich auch als PM kämen - GMX hat seine Probleme mit unseren Listen hier immer noch. Vermutlich wechsle ich mal den Provider. Jemand gute Erfahrungen mit anderen FreeMailern (außer WEB.DE und GMX)?

Show replies by date

Thomas Hertweck

8 Jul 8 Jul

20:45

René Matthäi schrieb:

...

hat diese Kombi jemand am Laufen?

Bei mir bricht der Kompilierungsvorgang ab mit

'vmalloc_reserve' undeclared in nv.o

Im Forum auf www.nvidia.com stehen auch nur 2 Fragen, aber keine Lösung.

Das Problem ist, dass sich von SuSE Kernel 2.4.20 zu SuSE Kernel 2.4.21 im Bereich Memory Management etwas geaendert hat. Der Vanilla-Kernel 2.4.21 ist in diesem Bereich kompatibel mit dem SuSE 2.4.20, das Problem mit dem NVIDIA-Treiber duerfte also nur in SuSE 2.4.21 auftreten... Die Fehlermeldung lautet wie oben angegeben, dass vmalloc_reserve nicht definiert ist in nv.c, dort aber verwendet wird. Anbei ist ein Patch, der das Problem loesen sollte - allerdings _ohne_jegliche Gewaehr_. Ich habe damit bei mir den NVIDIA Treiber stabil zum Laufen bekommen unter dem SuSE 2.4.21 Kernel, das kann aber auf anderen Rechnern anders sein. Etwaige Nebenwirkungen sind nicht auszuschliessen, da es nicht so einfach ist, durch den Quellcode duchzusteigen... Bitte beim Anwenden wie folgt vorgehen: 1. Kernel 2.4.21 installieren (z.B. aus dem RPM-File), ebenso dazugehoerenden Kernel-Source (aus RPM oder Tar-File; Achtung: diese beiden Varianten installieren sich in unter- schiedliche Verzeichnisse - da scheint etwas schief gegangen zu sein bei der RPM Erstellung). 2. Booten in Runlevel 3 mit dem neuen Kernel. Den Link /usr/src/linux auf das neue Kernel-Source Verzeichnis zeigen lassen. In dieses Verzeichnis eine alte existierende Konfiguration als .config kopieren und ein "make oldconfig" ausfuehren. Im Makefile bei EXTRAVERSION "-4-athlon" eintragen (normalerweise sollte das SuSE-Makefile automatisch ein richtiges KERNELRELEASE ermitteln, das scheint sich aber auch etwas geandert zu haben; naja, so gehts jedenfalls auf Nummer sicher). Ein "uname -r" sollte jedenfalls Klarheit bringen, welche Ergaenzung der Kernel im Namen traegt. Anschliessend ein "make dep clean" ausfuehren. 3. Das NVIDIA-run File mit "sh ./NVIDIA-Linux-x86-1.0-4363.run --extract-only" entpacken. Anschliessend ins Verzeichnis ./NVIDIA-Linux-x86-1.0-4363/usr/src/nv/ wechseln. 4. Den folgenden Patch (ohne die Gleichheitszeichen oben und unten) zuvor unter z.B. patch.nv abspeichern: ===================================================================== --- nv.c.orig 2003-07-08 22:04:54.000000000 +0200 +++ nv.c 2003-07-08 22:05:42.000000000 +0200 @@ -15,6 +15,8 @@ #include "nv_compiler.h" #include "os-agp.h" +// get nvidia driver working with SuSE 2.4.21 kernels... +unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT; /* * our global state; one per device ===================================================================== 5. Im Verzeichnis den Patch (liegt ebenfalls dort) anwenden: $> patch -p0 < patch.nv Dadurch wird die Datei nv.c gepatcht. 6. Anschliessend mit "make" das Modul uebersetzen und installieren lassen. Es sollte sich laden lassen und dabei eine Warnung ueber "nvidia.o will taint the kernel: non-GPL license - NVIDIA" ausgegeben werden. Das sollte es hoffentlich gewesen sein. Wie gesagt, hier nochmal in aller Deutlichkeit: Anwendung auf eigene Gefahr!! Bei mir laeuft es jetzt jedenfalls stabil... einstein:~ # uname -r 2.4.21-4-athlon einstein:~ # gears 8124 frames in 5.000 seconds = 1624.800 FPS 8130 frames in 5.000 seconds = 1626.000 FPS 8127 frames in 5.000 seconds = 1625.400 FPS (Geforce2MX Grafikkarte) HTH, Thomson PS: Ich hoffe, ich habe nichts vergessen, aber das koennte bei der doch recht komplexen Materie mal vorkommen...

René Matthäi

23:14

Hallo, inwzischen habe ich durch --extract-only, Ändern von MAXMEM in nv.c in einen Ausdruck wie (-0xc000000-(64*1024*1024)) (nur bei CONFIG_1GB in /usr/src/linux/.config :-) die Sache auch in den Griff bekommen. Die Änderung von EXTRAVERSION ist glaub ich nicht nötig, oder? Es gibt halt nur ein kernel-source-RPM für Athlon- und Intel-Kernel. Kopieren (siehe SDB) von autoconf.h version.h und .config reichte glaub ich bei mir auch. Braucht man ja auch für vmware. Würde vielleicht (in Deinem Patch) nicht auch einfach ein include asm/page.h reichen? Nur aus Interesse: Was hast Du für einen Prozessor? Ich habe einen Duron 950 mit Geforce 2 und komme so auf 1100 Frames. Ré Thomas Hertweck schrieb:

...

René Matthäi schrieb:

...
hat diese Kombi jemand am Laufen?

Bei mir bricht der Kompilierungsvorgang ab mit

'vmalloc_reserve' undeclared in nv.o

Im Forum auf www.nvidia.com stehen auch nur 2 Fragen, aber keine Lösung.

Das Problem ist, dass sich von SuSE Kernel 2.4.20 zu SuSE Kernel 2.4.21 im Bereich Memory Management etwas geaendert hat. Der Vanilla-Kernel 2.4.21 ist in diesem Bereich kompatibel mit dem SuSE 2.4.20, das Problem mit dem NVIDIA-Treiber duerfte also nur in SuSE 2.4.21 auftreten... Die Fehlermeldung lautet wie oben angegeben, dass vmalloc_reserve nicht definiert ist in nv.c, dort aber verwendet wird. Anbei ist ein Patch, der das Problem loesen sollte - allerdings _ohne_jegliche Gewaehr_. Ich habe damit bei mir den NVIDIA Treiber stabil zum Laufen bekommen unter dem SuSE 2.4.21 Kernel, das kann aber auf anderen Rechnern anders sein. Etwaige Nebenwirkungen sind nicht auszuschliessen, da es nicht so einfach ist, durch den Quellcode duchzusteigen...

Bitte beim Anwenden wie folgt vorgehen: 1. Kernel 2.4.21 installieren (z.B. aus dem RPM-File), ebenso dazugehoerenden Kernel-Source (aus RPM oder Tar-File; Achtung: diese beiden Varianten installieren sich in unter- schiedliche Verzeichnisse - da scheint etwas schief gegangen zu sein bei der RPM Erstellung). 2. Booten in Runlevel 3 mit dem neuen Kernel. Den Link /usr/src/linux auf das neue Kernel-Source Verzeichnis zeigen lassen. In dieses Verzeichnis eine alte existierende Konfiguration als .config kopieren und ein "make oldconfig" ausfuehren. Im Makefile bei EXTRAVERSION "-4-athlon" eintragen (normalerweise sollte das SuSE-Makefile automatisch ein richtiges KERNELRELEASE ermitteln, das scheint sich aber auch etwas geandert zu haben; naja, so gehts jedenfalls auf Nummer sicher). Ein "uname -r" sollte jedenfalls Klarheit bringen, welche Ergaenzung der Kernel im Namen traegt. Anschliessend ein "make dep clean" ausfuehren. 3. Das NVIDIA-run File mit "sh ./NVIDIA-Linux-x86-1.0-4363.run --extract-only" entpacken. Anschliessend ins Verzeichnis ./NVIDIA-Linux-x86-1.0-4363/usr/src/nv/ wechseln. 4. Den folgenden Patch (ohne die Gleichheitszeichen oben und unten) zuvor unter z.B. patch.nv abspeichern: ===================================================================== --- nv.c.orig 2003-07-08 22:04:54.000000000 +0200 +++ nv.c 2003-07-08 22:05:42.000000000 +0200 @@ -15,6 +15,8 @@ #include "nv_compiler.h" #include "os-agp.h"

+// get nvidia driver working with SuSE 2.4.21 kernels... +unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT;

/* * our global state; one per device ===================================================================== 5. Im Verzeichnis den Patch (liegt ebenfalls dort) anwenden: $> patch -p0 < patch.nv Dadurch wird die Datei nv.c gepatcht. 6. Anschliessend mit "make" das Modul uebersetzen und installieren lassen. Es sollte sich laden lassen und dabei eine Warnung ueber "nvidia.o will taint the kernel: non-GPL license - NVIDIA" ausgegeben werden.

Das sollte es hoffentlich gewesen sein. Wie gesagt, hier nochmal in aller Deutlichkeit: Anwendung auf eigene Gefahr!! Bei mir laeuft es jetzt jedenfalls stabil...

einstein:~ # uname -r 2.4.21-4-athlon einstein:~ # gears 8124 frames in 5.000 seconds = 1624.800 FPS 8130 frames in 5.000 seconds = 1626.000 FPS 8127 frames in 5.000 seconds = 1625.400 FPS (Geforce2MX Grafikkarte)

HTH, Thomson

PS: Ich hoffe, ich habe nichts vergessen, aber das koennte bei der doch recht komplexen Materie mal vorkommen...

Thomas Hertweck

9 Jul 9 Jul

06:51

Rene, bitte quote Emails ordentlich - so ist es mir nun nicht moeglich, mich auf Deine Mail und meine vorherige Antwort zu beziehen. Das was Du produzierst heisst TOFU und macht Threads komplett unuebersichtlich, also vermeide es bitte. Siehe auch http://learn.to/quote/. Danke. René Matthäi wrote:

...

inwzischen habe ich durch --extract-only, Ändern von MAXMEM in nv.c in einen Ausdruck wie (-0xc000000-(64*1024*1024)) (nur bei CONFIG_1GB in /usr/src/linux/.config :-) die Sache auch in den Griff bekommen. Die Änderung von EXTRAVERSION ist glaub ich nicht nötig, oder?

Ich glaube, das haengt davon ab, welche Quellen Du in- stalliert hast, ob per RPM oder per Tar.bz2. Da scheint es Unterschiede zu geben, die Versionen installieren sich auch in unterschiedliche Verzeichnisse. Ich musste jedenfalls eine Anpassung vornehmen, sonst haette es bei mir nicht funktioniert (Kernel ist 2.4.21-4-athlon [by the way, irgendwie scheint da auch ein GB zu fehlen], und das Modul wurde nach einem "make cloneconfig dep" fuer 2.4.21-0 erstellt - das hat dann logischerweise nicht gepasst und ich musste EXTRAVERSION von Hand setzen).

...

Es gibt halt nur ein kernel-source-RPM für Athlon- und Intel-Kernel. Kopieren (siehe SDB) von autoconf.h version.h und .config reichte glaub ich bei mir auch. Braucht man ja auch für vmware.

Bei einem laufenden 2.4.20 habe ich die Sourcen mit einem "make cloneconfig" fuer den 2.4.21 von SuSE geklont - so liess sich dann aber der Kernel 2.4.21 nicht uebersetzen, der Vorgang brach beim Linken mit einem Fehler ab und ich habe bis jetzt nicht herausgefunden, woran es liegt. Eine Referenz kann nicht aufgeloest werden, aber ich finde sie nicht einmal im gesamten Kernelbaum beim Durchsuchen; das ist etwas seltsam...

...

Würde vielleicht (in Deinem Patch) nicht auch einfach ein include asm/page.h reichen?

Ich bin mir nicht sicher, welche Nebenwirkungen das hat (gehen tut es sicher). Da nur eine Referenz gefehlt hat, habe ich die lieber explizit uebernommen. Allerdings ist das Setzen von vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT nur eine Moeglichkeit; im Quellcode von SuSE gibt es noch Unterscheidungen, da bin ich aber nicht ganz durchgestiegen.

...

Nur aus Interesse: Was hast Du für einen Prozessor? Ich habe einen Duron 950 mit Geforce 2 und komme so auf 1100 Frames.

Der Rechner, an dem ich das gestern probiert habe, ist ein Athlon 1.3GHz mit 512MB SD-RAM und GeForce2MX Grafikkarte. Es gab, wie schon gezeigt, ca. 1625 Frames bei gears. Gruesse, Thomson

David Haller

07:46

Hallo, On Wed, 09 Jul 2003, Thomas Hertweck schrieb:

...

Ich bin mir nicht sicher, welche Nebenwirkungen das hat (gehen tut es sicher). Da nur eine Referenz gefehlt hat, habe ich die lieber explizit uebernommen. Allerdings ist das Setzen von vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT nur eine Moeglichkeit; im Quellcode von SuSE gibt es noch Unterscheidungen, da bin ich aber nicht ganz durchgestiegen.

Hm. Ich habe hier grad nur nen 2.4.17.SuSE und vanilla 2.4.16 zur Hand. In letzterem findet sich zu "vmalloc.reserve" nur ein arch/i386/kernel/setup.c:#define VMALLOC_RESERVE (unsigned long)(128 << 20) bei ersterem nur include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm-i386/page.h:#define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE) (sowie ein paar weitere uninteressante sekundaere defines, die [__]VMALLOC_RESERVED verwenden). Gesucht jew. mit: find ... -type f -print0 | xargs -0 grep -i 'vmalloc.reserve' Kannst du mir da evtl. Tips dazu geben, was SuSE da gepatcht hat? Ich wuerde gerne moeglichst gezielt sourcen saugen... ;) -dnh -- / "It took people a long time to figure out which machine was doing it, \ [ and even longer to figure out how. But for some reason it didn't take ] \ them any time at all to figure that I'd done it." -- Paul Tomblin /

Thomas Hertweck

08:50

Hi! David Haller wrote:

...

[...] Hm. Ich habe hier grad nur nen 2.4.17.SuSE und vanilla 2.4.16 zur Hand. In letzterem findet sich zu "vmalloc.reserve" nur ein

arch/i386/kernel/setup.c:#define VMALLOC_RESERVE (unsigned long)(128 << 20)

bei ersterem nur

include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm-i386/page.h:#define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE)

(sowie ein paar weitere uninteressante sekundaere defines, die [__]VMALLOC_RESERVED verwenden).

Gesucht jew. mit:

find ... -type f -print0 | xargs -0 grep -i 'vmalloc.reserve'

Kannst du mir da evtl. Tips dazu geben, was SuSE da gepatcht hat? Ich wuerde gerne moeglichst gezielt sourcen saugen... ;)

Schaun wir mal... Im 2.4.21 gibt es das VMALLOC_RESERVE so nicht mehr, dafuer gibt es ein vmalloc_reserve. Das ist der Unterschied sowohl zu frueheren SusE-Kernel (bis 2.4.20) als auch zum Vanilla-Kernel (dort einschl. 2.4.21) - das bedeutet, das Problem mit den NVIDIA-Treibern tritt erst einmal nur mit dem 2.4.21 von SuSE auf. In ./arch/i386/kernel/setup.c: +/* reserved mapping space for vmalloc and ioremap */ +unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT; +static unsigned long vm_reserve __initdata = -1; [...] + /* + * calculate the default size of vmalloc/ioremap area + * overwrite with the value of the vm_reserve= option + * if set + */ + if (max_pfn >= PFN_UP(KERNEL_MAXMEM - __VMALLOC_RESERVE_DEFAULT)) + vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT; + else + vmalloc_reserve = KERNEL_MAXMEM - PFN_PHYS(max_pfn); + if (vm_reserve != -1) { + if (vm_reserve < __VMALLOC_RESERVE_MIN) + vm_reserve = __VMALLOC_RESERVE_MIN; + if (vm_reserve > __VMALLOC_RESERVE_MAX) + vm_reserve = __VMALLOC_RESERVE_MAX; + vmalloc_reserve = vm_reserve; + } + + printk(KERN_NOTICE "%ldMB vmalloc/ioremap area available.\n", + vmalloc_reserve>>20); + Bliebe die Frage, wo __VMALLOC_RESERVE_MIN etc. definiert wird. Das scheint weiterhin ./include/asm-i386/page.h zu sein: -#define __VMALLOC_RESERVE (128 << 20) +#define __VMALLOC_RESERVE_MIN (32 << 20) +#define __VMALLOC_RESERVE_DEFAULT (128 << 20) +#define __VMALLOC_RESERVE_MAX (480 << 20) +#define __RESERVED_AREA (10 << 20) Das Ganze geht dann noch ein in MAXMEN: #define PAGE_OFFSET ((unsigned long)__PAGE_OFFSET) -#define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE) -#define __MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE) -#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)) +#define KERNEL_MEMORY ((unsigned long)(__FIXADDR_START - __PAGE_OFFSET)) +#define RESERVED_AREA ((unsigned long)__RESERVED_AREA) +#define KERNEL_MAXMEM ((unsigned long)(KERNEL_MEMORY - RESERVED_AREA)) +#define __MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE_MAX) +#define MAXMEM ((unsigned long)(-PAGE_OFFSET-vmalloc_reserve)) #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET) #define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET)) +#ifndef CONFIG_DISCONTIGMEM #define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT)) #define VALID_PAGE(page) ((page - mem_map) < max_mapnr) +#endif /* !CONFIG_DISCONTIGMEM */ Daran ist das Compilieren des NVIDIA Treibers gescheitert, denn MAXMEN wird beim 2.4.21 von SuSE nicht mehr ueber VMALLOC_RESERVE definiert, sondern ueber vmalloc_reserve, und das war unbekannt. Mein Patch hat einfach den Default Wert fuer vmalloc_reserve aus setup.c dem NVIDIA-Treiber bekannt gemacht und damit laesst sich dann der Treiber compilieren. Duch die If-Abfragen in setup.c bin ich aber nicht ganz durchgestiegen... HTH, Thomson

David Haller

10 Jul 10 Jul

12:33

Hallo, On Wed, 09 Jul 2003, Thomas Hertweck schrieb:

...

David Haller wrote:

...
[...] Hm. Ich habe hier grad nur nen 2.4.17.SuSE und vanilla 2.4.16 zur Hand. [..] Kannst du mir da evtl. Tips dazu geben, was SuSE da gepatcht hat? Ich wuerde gerne moeglichst gezielt sourcen saugen... ;) [snip viel info]

Danke :) -dnh -- 169: Veganer Die, die ihre Kinder nicht säugen, weil das für die Mutter Tierquälerei wäre. (Wau Holland)

Philipp Thomas

9 Jul 9 Jul

18:45

Thomas Hertweck :

...

Das Problem ist, dass sich von SuSE Kernel 2.4.20 zu SuSE Kernel 2.4.21 im Bereich Memory Management etwas geaendert hat. Der Vanilla-Kernel 2.4.21 ist in diesem Bereich kompatibel mit dem SuSE 2.4.20, das Problem mit dem NVIDIA-Treiber duerfte also nur in SuSE 2.4.21 auftreten...

Ich werde mir mal morgen den Nvidia-Treiber anschauen. Sofern der Knackpunkt im Quellcode-Teil liegt, sollte er identifizierbar und sauber fixbar sein. Philipp

Thomas Hertweck

18:58

Philipp Thomas schrieb:

...

Thomas Hertweck :

...
Das Problem ist, dass sich von SuSE Kernel 2.4.20 zu SuSE Kernel 2.4.21 im Bereich Memory Management etwas geaendert hat. Der Vanilla-Kernel 2.4.21 ist in diesem Bereich kompatibel mit dem SuSE 2.4.20, das Problem mit dem NVIDIA-Treiber duerfte also nur in SuSE 2.4.21 auftreten...

Ich werde mir mal morgen den Nvidia-Treiber anschauen. Sofern der Knackpunkt im Quellcode-Teil liegt, sollte er identifizierbar und sauber fixbar sein.

Kurze Zusammenfassung des bisherigen: Beim Compilieren des NVIDIA-Treibers (Kernel-Modul) fuer SuSE Kernel 2.4.21 (aus dem FTP Verzeichnis von H. Mantel) bricht der Compiliervorgang bei nv.c ab mit der Meldung vmalloc_reserve sei undefiniert. Dem ist auch so, da vmalloc_reserve im Kernel-Baum in setup.c definiert wird, nicht in einem Header-File, das der NVIDIA- Treiber einbinden kann. Bisher (bis Kernel SuSE 2.4.20 und bis einschliesslich des aktuellen Vanilla 2.4.21) war es so, dass VMALLOC_RESERVE verwendet wurde (statt vmalloc_reserve), was komplett in einem Header-File definiert war. Vielleicht hilft das ein bissl weiter, aber Du kennst Dich da bestimmt 1000mal besser aus als ich. Gruesse, Thomson

René Matthäi

19:19

...

René Matthäi schrieb:

...
hat diese Kombi jemand am Laufen?

Bei mir bricht der Kompilierungsvorgang ab mit

'vmalloc_reserve' undeclared in nv.o

Im Forum auf www.nvidia.com stehen auch nur 2 Fragen, aber keine Lösung.

Das Problem ist, dass sich von SuSE Kernel 2.4.20 zu SuSE Kernel 2.4.21 im Bereich Memory Management etwas geaendert hat. Der Vanilla-Kernel 2.4.21 ist in diesem Bereich kompatibel mit dem SuSE 2.4.20, das Problem mit dem NVIDIA-Treiber duerfte also nur in SuSE 2.4.21 auftreten... Die Fehlermeldung lautet wie oben angegeben, dass vmalloc_reserve nicht definiert ist in nv.c, dort aber verwendet wird. Anbei ist ein Patch, der das Problem loesen sollte - allerdings _ohne_jegliche Gewaehr_. Ich habe damit bei mir den NVIDIA Treiber stabil zum Laufen bekommen unter dem SuSE 2.4.21 Kernel, das kann aber auf anderen Rechnern anders sein. Etwaige Nebenwirkungen sind nicht auszuschliessen, da es nicht so einfach ist, durch den Quellcode duchzusteigen...

Bitte beim Anwenden wie folgt vorgehen: 1. Kernel 2.4.21 installieren (z.B. aus dem RPM-File), ebenso dazugehoerenden Kernel-Source (aus RPM oder Tar-File; Achtung: diese beiden Varianten installieren sich in unter- schiedliche Verzeichnisse - da scheint etwas schief gegangen zu sein bei der RPM Erstellung). 2. Booten in Runlevel 3 mit dem neuen Kernel. Den Link /usr/src/linux auf das neue Kernel-Source Verzeichnis zeigen lassen. In dieses Verzeichnis eine alte existierende Konfiguration als .config kopieren und ein "make oldconfig" ausfuehren. Im Makefile bei EXTRAVERSION "-4-athlon" eintragen (normalerweise sollte das SuSE-Makefile automatisch ein richtiges KERNELRELEASE ermitteln, das scheint sich aber auch etwas geandert zu haben; naja, so gehts jedenfalls auf Nummer sicher). Ein "uname -r" sollte jedenfalls Klarheit bringen, welche Ergaenzung der Kernel im Namen traegt. Anschliessend ein "make dep clean" ausfuehren. 3. Das NVIDIA-run File mit "sh ./NVIDIA-Linux-x86-1.0-4363.run --extract-only" entpacken. Anschliessend ins Verzeichnis ./NVIDIA-Linux-x86-1.0-4363/usr/src/nv/ wechseln. 4. Den folgenden Patch (ohne die Gleichheitszeichen oben und unten) zuvor unter z.B. patch.nv abspeichern: ===================================================================== --- nv.c.orig 2003-07-08 22:04:54.000000000 +0200 +++ nv.c 2003-07-08 22:05:42.000000000 +0200 @@ -15,6 +15,8 @@ #include "nv_compiler.h" #include "os-agp.h"

+// get nvidia driver working with SuSE 2.4.21 kernels... +unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT;

/* * our global state; one per device ===================================================================== 5. Im Verzeichnis den Patch (liegt ebenfalls dort) anwenden: $> patch -p0 < patch.nv Dadurch wird die Datei nv.c gepatcht. 6. Anschliessend mit "make" das Modul uebersetzen und installieren lassen. Es sollte sich laden lassen und dabei eine Warnung ueber "nvidia.o will taint the kernel: non-GPL license - NVIDIA" ausgegeben werden.

Das sollte es hoffentlich gewesen sein. Wie gesagt, hier nochmal in aller Deutlichkeit: Anwendung auf eigene Gefahr!! Bei mir laeuft es jetzt jedenfalls stabil...

einstein:~ # uname -r 2.4.21-4-athlon einstein:~ # gears 8124 frames in 5.000 seconds = 1624.800 FPS 8130 frames in 5.000 seconds = 1626.000 FPS 8127 frames in 5.000 seconds = 1625.400 FPS (Geforce2MX Grafikkarte)

HTH, Thomson

PS: Ich hoffe, ich habe nichts vergessen, aber das koennte bei der doch recht komplexen Materie mal vorkommen...

Christian Ullrich

15 Jul 15 Jul

19:46

* Thomas Hertweck schrieb am Dienstag, 2003-07-08:

...

René Matthäi schrieb:

...
hat diese Kombi jemand am Laufen?

Bei mir bricht der Kompilierungsvorgang ab mit

'vmalloc_reserve' undeclared in nv.o

...

4. Den folgenden Patch (ohne die Gleichheitszeichen oben und unten) zuvor unter z.B. patch.nv abspeichern: ===================================================================== --- nv.c.orig 2003-07-08 22:04:54.000000000 +0200 +++ nv.c 2003-07-08 22:05:42.000000000 +0200 @@ -15,6 +15,8 @@ #include "nv_compiler.h" #include "os-agp.h"

+// get nvidia driver working with SuSE 2.4.21 kernels... +unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT;

/* * our global state; one per device =====================================================================

Nachdem das Problem ja darin besteht, daß der nVidia-Treiber nicht gelinkt werden kann, weil das Symbol nicht sichtbar ist, wäre es da nicht besser, das Symbol einfach zu exportieren, anstatt zwei unterschiedliche und möglicherweise inkompatible Werte für vmalloc_reserve zu haben, einen im Kernel, einen im nVidia-Modul? Alternativvorschlag: --- kernel/ksyms.c.orig 2003-07-15 21:45:07.000000000 +0200 +++ kernel/ksyms.c 2003-07-15 21:26:56.000000000 +0200 @@ -682,3 +682,6 @@ /* for Linux-ABI */ EXPORT_SYMBOL(do_fork); +extern unsigned long vmalloc_reserve; +EXPORT_SYMBOL(vmalloc_reserve); -- Christian Ullrich Registrierter Linux-User #125183 "Remember: 'I am a person. I have a right to the ball.'"

Thomas Hertweck

20:07

Christian Ullrich schrieb:

...

[...] Nachdem das Problem ja darin besteht, daß der nVidia-Treiber nicht gelinkt werden kann, weil das Symbol nicht sichtbar ist, wäre es da nicht besser, das Symbol einfach zu exportieren, anstatt zwei unterschiedliche und möglicherweise inkompatible Werte für vmalloc_reserve zu haben, einen im Kernel, einen im nVidia-Modul?

Natuerlich... Es war auch nur ein Quick & Dirty Workaround, wie ich auch _deutlich_ dazu schrieb.

...

Alternativvorschlag:

--- kernel/ksyms.c.orig 2003-07-15 21:45:07.000000000 +0200 +++ kernel/ksyms.c 2003-07-15 21:26:56.000000000 +0200 @@ -682,3 +682,6 @@ /* for Linux-ABI */ EXPORT_SYMBOL(do_fork);

+extern unsigned long vmalloc_reserve; +EXPORT_SYMBOL(vmalloc_reserve);

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 rein. [snip] Ausprobiert. Es hat sich herausgestellt, das um das extern unsigned long vmalloc_reserve; noch ein #ifndef __ASSEMBLY__ ... #endif muss. =========================================================================== Gruesse, Thomson

René Matthäi

16 Jul 16 Jul

16:30

Hallo, Christian Ullrich schrieb:

...

Alternativvorschlag:

--- kernel/ksyms.c.orig 2003-07-15 21:45:07.000000000 +0200 +++ kernel/ksyms.c 2003-07-15 21:26:56.000000000 +0200

[...]

Aber nv.c zu ändern ist vielleicht besser als Kernelquellen(!) zu ändern, oder? Ré

Philipp Thomas

19:05

René Matthäi [Wed, 16 Jul 2003 18:30:25 +0200]:

...

...
--- kernel/ksyms.c.orig 2003-07-15 21:45:07.000000000 +0200 +++ kernel/ksyms.c 2003-07-15 21:26:56.000000000 +0200

[...]

Aber nv.c zu ändern ist vielleicht besser als Kernelquellen(!) zu ändern, oder?

Was soll daran besser sein? Ein Fehler muss da behoben werden, wo er gemacht wurde und das ist im Kernel. Ausserdem ist die Änderung in nv.c unsauber, denn dann würden Modul und Kernel ggfs. mit unterschiedlichen Werten arbeiten. Philipp

7600

Age (days ago)

7609

Last active (days ago)

List overview

Download

13 comments

5 participants

participants (5)

Christian Ullrich
David Haller
Philipp Thomas
René Matthäi
Thomas Hertweck