Mailinglist Archive: opensuse (2731 mails)

[suse_ground <suse@xxxxxxxx>]

On Monday 18 August 2003 11:25, René Matthäi wrote:

In my case it is responding that it cannot allocate DMA context.
in the FAQ from nvidia I found a answer saying this is related to possible 
diff. between compilers.
What can we do next ? Wait for the next nvidia/suse kernel release ?



> Hi,
>
> I tried to manage to get them run together, according to instructions
> for the 4363 version, of e. g. Thomas Hertweck (in suse-linux) who was
> referencing to a SuSE employee (Karsten Keil). Doesn't work, though.
> Instruction was as follows (shorted translation in brackets):
>
>
> Karsten Keil (SuSE) meinte dazu [wrote]:
> ===========================================================================
> 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.
> [Yes, I had looked in the kernel where __VMALLOC_RESERVE had been used
> and this was only in setup.c, I didn't examine the extern modules, also
> because I didn't know that something in them could play any role.]
>
> Fix ist einfach, ich schick spaeter auch einen neuen patch, wenn noetig.
> in include/asm-i386/page.h noch eine Zeile einfuegen [Fix is easy, later
> I'll send a new patch if neccessary. Insert a new line in
> include/asm-i386/page.h ](z.B. hinter [e. g. behind]
> #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.[Maybe an
> #include... is still neccessary there]
> [snip]
> Ausprobiert. Es hat sich herausgestellt, das um das
> extern unsigned long vmalloc_reserve; noch ein #ifndef __ASSEMBLY__ ...
> #endif  muss.
> [Tested. It turned out that we need and #ifndef...#endif around the
> extern unsigned...]
> ===========================================================================
>
> Error messages:
>
> 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_reserver hence is to blame. Maybe I rather use the quick&dirty
> patches again (only patching nv.c) because I don't know another way.
> What do you think (what does Karsten Keil think)?
>
> Then I only put
>
> unsigned long vmalloc_reserve = __VMALLOC_RESERVE_DEFAULT;
>
> in nv.c
>
> Makes it working.
>
> Greetings,
>
> René