nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Redhat Phoebe - compiling 4191 drivers (http://www.nvnews.net/vbulletin/showthread.php?t=6621)

lordpil 01-24-03 06:06 PM

Redhat Phoebe - compiling 4191 drivers
Okay, I have kernel sources installed, 2.4.20. Note I've tried using the redhat package as well as my own custom kernel with the exact same problem... I'm using RH 8.0.93 beta, it uses gcc 3.2.1. When I attempt to compile from tarball, this is what happens:

[root@resnet130-101 NVIDIA_kernel-1.0-4191]# make
echo \#define NV_COMPILER \"`cc -v 2>&1 | tail -1`\" > nv_compiler.h
cc -c -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith -Wcast-qual -Wno-multichar -O -MD -D__KERNEL__ -DMODULE
In file included from /lib/modules/2.4.20-2.21custom/build/include/linux/mm.h:22,
from /lib/modules/2.4.20-2.21custom/build/include/linux/slab.h:14,
from nv-linux.h:63,
from nv.c:14:
/lib/modules/2.4.20-2.21custom/build/include/linux/sched.h:548:1: warning: "cpu_online" redefined
In file included from /lib/modules/2.4.20-2.21custom/build/include/linux/sched.h:25,
from /lib/modules/2.4.20-2.21custom/build/include/linux/mm.h:22,
from /lib/modules/2.4.20-2.21custom/build/include/linux/slab.h:14,
from nv-linux.h:63,
from nv.c:14:
/lib/modules/2.4.20-2.21custom/build/include/linux/smp.h:87:1: warning: this is
the location of the previous definition
nv.c: In function `nv_get_phys_address':
nv.c:2250: warning: implicit declaration of function `pte_offset'
nv.c:2250: invalid type argument of `unary *'
make: *** [nv.o] Error 1

Source RPM also fails... I realise this is a beta, but I can't figure out what is wrong. I have had problems before a few tiems with nvidia drivers on stable versions similar to this. Any ideas?
The warnings there are the same i get when compiling the modules for the rh8.0.93 kernel .config, I don't know if that has anything to do with it.

Thanks for any help.

bwkaz 01-24-03 06:28 PM

The pte_offset function isn't being declared before it gets used in nv.c.

This means that either nv.c was never including the correct headers (which isn't the case, since it works for a bunch of other people), or the header that the pte_offset function was declared in has changed and nVidia hasn't updated their nv.c file to reflect this change yet. However, that is very unlikely.

In the 2.4.20 vanilla kernel-source that I have, pte_offset is #defined to be something else in include/asm-<arch>/pgtable.h. Once you've configured a kernel (aka run make {menu,old,x,}config), you get a symlink to asm-<arch> named asm, so if you've done that (you said you compiled a vanilla 2.4.20, right?), you can just look at include/asm/pgtable.h and (hopefully) find the definition.

I'd say try this all under a vanilla 2.4.20 kernel again, and make sure that the correct directory is being searched with -I (should be /lib/modules/2.4.20/build/include, as long as uname -r prints 2.4.20).

lordpil 01-24-03 06:54 PM

thank you, i was just comparing the files...

This is from the vanilla kernel:

/* Find an entry in the third-level page table.. */
#define __pte_offset(address) \
((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
#define pte_offset(dir, address) ((pte_t *) pmd_page(*(dir)) + \

This is from the redhat kernel:
/* Find an entry in the third-level page table.. */
#define __pte_offset(address) \
((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
#define pte_offset_kernel(dir, address) \
((pte_t *) pmd_page_kernel(*(dir)) + __pte_offset(address))

it has adifferent name... well i am going to try something now, i'll let you know how it works out

bwkaz 01-24-03 11:25 PM

Hmm, yeah, try changing the name of the "function" (it's a macro in reality, but oh well) call to pte_offset_kernel instead. That should fix it.

Alan666 01-26-03 07:26 PM

Other changes to be aware of...
In kernel-2.4.20-2.25, there has been a change to remap_page_range.

In the stock kernel, it is defined as:

extern int remap_page_range(unsigned long from, unsigned long to, unsigned long size, pgprot_t prot);

In the Redhat version, it is:

extern int remap_page_range(struct vm_area_struct *vma, unsigned long from, unsigned long to, unsigned long size, pgprot_t prot);

It looks like the vma structure needs to be passed, as the first argument. Everything else looks like it should be correct. (I am not certain about this because it is complaining about the calculation used to determine the size. I think it just needs to be cast properly.)

I have not tested my changes yet. I am still expecting to find changes in some of the memory map code.

Alan666 01-26-03 08:59 PM

remap_page_range is going to have a bigger patch footprint than I thought...

In os-interface.c it is used by a couple of functions. (os_map_userspace and os_unmap_userspace.) These functions do not have the vma structure visible to them. This is going to require changing the call passed to the function. If this function is called somewhere outside the scope of the vailable source, then it could get messy.:barf:

I am going to try and hack out a working driver tonight. I hope it will be stable, but I kind of doubt it...

sehh 01-30-03 05:35 PM

Hey people, i'm having the exact same problem,
i'm running RedHat Beta (Phoebe or whatever its
called). I get the same error message, and thus
far i haven't managed to work it out.

Please let me know if anyone has found a solution
to the problem.

Noxerus 01-31-03 12:33 PM

Same prob here..

Please, someone, fix it! :)

sehh 02-02-03 06:12 PM

i think only RedHat is able to fix this, because
they are the ones who make the custom changes
to their kernels.

unless someone else gets lucky :)

Alan666 02-03-03 12:20 AM

Actually there may be a fix to this...
The problem is not something that Redhat can fix. (Unless it backs out the changes to thier kernel.) The same problems occur if you run the 2.5.x kernels.

Look for another thread on Pheobe called "4191 driver and Red Hat Phoebe HOWTO". It has links to the patches that you need to apply and how to get the GL code to work.

I am not happy with the work-arounds. It disables some of the new threading behaviour which a couple of programs I use may or may not depend on.

nVIDIA is going to need to fix a couple things in the driver if they want it to work with the 2.5.x series of kernels.

bwkaz 02-03-03 07:50 AM

Re: Actually there may be a fix to this...

Originally posted by Alan666
nVIDIA is going to need to fix a couple things in the driver if they want it to work with the 2.5.x series of kernels.
But they don't. 2.5 is a development series, and changes too often for nVidia to be able to support it. ;)

2.6 (or 3.0, whatever it ends up being called), OTOH, will be supported eventually. And you are right, they are going to have to make a lot of changes to get it to work with 2.6/3.0.

sehh 02-03-03 08:00 AM

Who mentioned anything about 2.5 kernels? we are
running 2.4.20 here.

All times are GMT -5. The time now is 12:21 AM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.