Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 01-24-03, 06:06 PM   #1
lordpil
Registered User
 
Join Date: Jan 2003
Posts: 3
Default 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
-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=4191 -DNV_UNIX -DNV_LINUX -DNV_INT64_OK -DNVCPU_X86 -I. -I/lib/modules/2.4.20-2.21custom/build/include -Wno-cast-qual nv.c
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.
lordpil is offline   Reply With Quote
Old 01-24-03, 06:28 PM   #2
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

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).
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 01-24-03, 06:54 PM   #3
lordpil
Registered User
 
Join Date: Jan 2003
Posts: 3
Default

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)) + \
__pte_offset(address))


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
lordpil is offline   Reply With Quote
Old 01-24-03, 11:25 PM   #4
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

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.
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 01-26-03, 07:26 PM   #5
Alan666
Registered User
 
Join Date: Aug 2002
Location: Portland, OR
Posts: 14
Default 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 is offline   Reply With Quote
Old 01-26-03, 08:59 PM   #6
Alan666
Registered User
 
Join Date: Aug 2002
Location: Portland, OR
Posts: 14
Default

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.

I am going to try and hack out a working driver tonight. I hope it will be stable, but I kind of doubt it...
Alan666 is offline   Reply With Quote
Old 01-30-03, 05:35 PM   #7
sehh
GFX 5600 VideoSuite
 
Join Date: Oct 2002
Posts: 60
Default

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.
sehh is offline   Reply With Quote
Old 01-31-03, 12:33 PM   #8
Noxerus
Registered User
 
Join Date: Jan 2003
Posts: 1
Default

Same prob here..

Please, someone, fix it!
Noxerus is offline   Reply With Quote

Old 02-02-03, 06:12 PM   #9
sehh
GFX 5600 VideoSuite
 
Join Date: Oct 2002
Posts: 60
Default

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
sehh is offline   Reply With Quote
Old 02-03-03, 12:20 AM   #10
Alan666
Registered User
 
Join Date: Aug 2002
Location: Portland, OR
Posts: 14
Default 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.
Alan666 is offline   Reply With Quote
Old 02-03-03, 07:50 AM   #11
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default Re: Actually there may be a fix to this...

Quote:
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.
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 02-03-03, 08:00 AM   #12
sehh
GFX 5600 VideoSuite
 
Join Date: Oct 2002
Posts: 60
Default

Who mentioned anything about 2.5 kernels? we are
running 2.4.20 here.
sehh is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Creative drivers ? SparrowHawk General Hardware 39 11-18-02 08:03 AM
Radeon 9700 not all that? sancheuz Other Desktop Graphics Cards 200 10-12-02 09:31 PM
NVidia Drivers HowTo for RedHat 8.0 needed eduardp NVIDIA Linux 10 10-04-02 03:59 AM
Redhat 7.3 + Nvidia drivers 3123 = troubles e-r-a-n NVIDIA Linux 4 09-17-02 12:26 PM
2960 drivers, redhat 7.3, kernel normanpang NVIDIA Linux 6 08-03-02 12:11 AM

All times are GMT -5. The time now is 07:41 PM.


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