is there a nvidia patch available to make it work with rmap?
nirvana:~/NVIDIA_kernel-1.0-3123# 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
-DRM_HEAPMGR -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE
-DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=3123
-DNV_UNIX -DNV_LINUX -DNVCPU_X86 -I.
-I/lib/modules/2.4.20-xfs-rmap15b/build/include -Wno-cast-qual nv.c
nv.c: In function `nv_get_phys_address':
nv.c:2182: warning: implicit declaration of function `pte_offset'
nv.c:2182: invalid type argument of `unary *'
make: *** [nv.o] Error 1
On Sat, Dec 14, 2002 at 10:36:10PM +1300, mdew wrote:
> is there a nvidia patch available to make it work with rmap?
>
> nirvana:~/NVIDIA_kernel-1.0-3123# 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
> -DRM_HEAPMGR -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE
> -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=3123
> -DNV_UNIX -DNV_LINUX -DNVCPU_X86 -I.
> -I/lib/modules/2.4.20-xfs-rmap15b/build/include -Wno-cast-qual nv.c
> nv.c: In function `nv_get_phys_address':
> nv.c:2182: warning: implicit declaration of function `pte_offset'
> nv.c:2182: invalid type argument of `unary *'
> make: *** [nv.o] Error 1
Use pte_offset_map() with a corresponding pte_unmap().
Bill
On Sat, 2002-12-14 at 22:38, William Lee Irwin III wrote:
> On Sat, Dec 14, 2002 at 10:36:10PM +1300, mdew wrote:
> > is there a nvidia patch available to make it work with rmap?
> >
> > nirvana:~/NVIDIA_kernel-1.0-3123# 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
> > -DRM_HEAPMGR -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE
> > -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=3123
> > -DNV_UNIX -DNV_LINUX -DNVCPU_X86 -I.
> > -I/lib/modules/2.4.20-xfs-rmap15b/build/include -Wno-cast-qual nv.c
> > nv.c: In function `nv_get_phys_address':
> > nv.c:2182: warning: implicit declaration of function `pte_offset'
> > nv.c:2182: invalid type argument of `unary *'
> > make: *** [nv.o] Error 1
>
> Use pte_offset_map() with a corresponding pte_unmap().
err pardon?
On Sat, 14 Dec 2002, mdew wrote:
> On Sat, 2002-12-14 at 22:38, William Lee Irwin III wrote:
> > On Sat, Dec 14, 2002 at 10:36:10PM +1300, mdew wrote:
> > > nv.c: In function `nv_get_phys_address':
> > > nv.c:2182: warning: implicit declaration of function `pte_offset'
> > > nv.c:2182: invalid type argument of `unary *'
> >
> > Use pte_offset_map() with a corresponding pte_unmap().
>
> err pardon?
wli just gave you the information you need to create a patch
for the nvidia driver.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Rik van Riel wrote:
>
> On Sat, 14 Dec 2002, mdew wrote:
> > On Sat, 2002-12-14 at 22:38, William Lee Irwin III wrote:
> > > On Sat, Dec 14, 2002 at 10:36:10PM +1300, mdew wrote:
> > > > nv.c: In function `nv_get_phys_address':
> > > > nv.c:2182: warning: implicit declaration of function `pte_offset'
> > > > nv.c:2182: invalid type argument of `unary *'
> > >
> > > Use pte_offset_map() with a corresponding pte_unmap().
> >
> > err pardon?
>
> wli just gave you the information you need to create a patch
> for the nvidia driver.
The replies for people in the know (Rik, wli) give a clue but not an
answer. Use mere mortals want a proper patch in order to build and
use this kernel.
I will summarise my understanding so far; The original code says:
unsigned long
nv_get_phys_address(unsigned long address)
{
pgd_t *pg_dir;
pmd_t *pg_mid_dir;
pte_t *pte__, pte;
.....
#if defined (pte_offset_atomic)
pte__ = pte_offset_atomic(pg_mid_dir, address);
pte = *pte__;
pte_kunmap(pte__);
#else
pte__ = NULL;
pte = *pte_offset(pg_mid_dir, address);
#endif
if (!pte_present(pte))
goto failed;
return ((pte_val(pte) & KERN_PAGE_MASK) | NV_MASK_OFFSET(address));
.....
}
The last line above is the problem. So far I could see two possible
changes that will compile, but I do not know which will function
correctly. The first replacement option:
pte = *pte_offset(pg_mid_dir, address);
The second replacement option is more involved:
pte__ = pte_offset_map(pg_mid_dir, address);
pte = *pte__;
if (!pte_present(pte))
goto failed;
pte_unmap(pte__);
Reading the patch itself I see places where the first approach is used,
while elsewhere the second is used. I do not know what pte_val(pte)
requires though. Can we do the pte_unmap(pte__) earlier or is the
mapping
necessary for pte_present(pte)? Will this work:
pte__ = pte_offset_map(pg_mid_dir, address);
pte = *pte__;
pte_unmap(pte__);
In summary, you can see that for someone who is not intimately involved
the answers so far do not provide a working patch.
Thanks everybody.
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
Eyal Lebedinsky wrote:
8<
> The replies for people in the know (Rik, wli) give a clue but not an
> answer. Use mere mortals want a proper patch in order to build and
> use this kernel.
8<
This driver, you mean ;-)
Philip Dodd wrote:
>
> Eyal Lebedinsky wrote:
> 8<
> > The replies for people in the know (Rik, wli) give a clue but not an
> > answer. Use mere mortals want a proper patch in order to build and
> > use this kernel.
>
> This driver, you mean ;-)
Well, yes and no. This kernel is of no use to me without this driver
right now.
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
On Sun, Dec 15, 2002 at 12:40:48PM +1100, Eyal Lebedinsky wrote:
> Philip Dodd wrote:
> >
> > Eyal Lebedinsky wrote:
> > 8<
> > > The replies for people in the know (Rik, wli) give a clue but not an
> > > answer. Use mere mortals want a proper patch in order to build and
> > > use this kernel.
> >
> > This driver, you mean ;-)
>
> Well, yes and no. This kernel is of no use to me without this driver
> right now.
>
Ah, OK. You need to play quake3 with this kernel, I guess.
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
The 2.5 patches at http://www.minion.de/nvidia.html
may give some clue. They use pte_offset_map , yes,
but no corresponding pte_unmap ...
On Mon, Dec 16, 2002 at 04:25:11PM +0200, O. Sezer wrote:
> The 2.5 patches at http://www.minion.de/nvidia.html
> may give some clue. They use pte_offset_map , yes,
> but no corresponding pte_unmap ...
That will BUG() with highmem debugging on. Put the pte_unmap() in the
appropriate place.
Bill
Come on, think laptops. XFree86 doesn't support all the NVidias without
that driver. Well, except in vesa framebuffer mode, which is horrible.
--On Monday, December 16, 2002 14:32:23 +0100 Ducrot Bruno
<[email protected]> wrote:
> On Sun, Dec 15, 2002 at 12:40:48PM +1100, Eyal Lebedinsky wrote:
>> Philip Dodd wrote:
>> >
>> > Eyal Lebedinsky wrote:
>> > 8<
>> > > The replies for people in the know (Rik, wli) give a clue but not an
>> > > answer. Use mere mortals want a proper patch in order to build and
>> > > use this kernel.
>> >
>> > This driver, you mean ;-)
>>
>> Well, yes and no. This kernel is of no use to me without this driver
>> right now.
>>
>
> Ah, OK. You need to play quake3 with this kernel, I guess.
>
> --
> Ducrot Bruno
> http://www.poupinou.org Page profaissionelle
> http://toto.tu-me-saoules.com Haume page
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
diff -urN NVIDIA_kernel-1.0-4191/nv.c NVIDIA_kernel.rmap15b/nv.c
--- NVIDIA_kernel-1.0-4191/nv.c 2002-12-09 22:27:15.000000000 +0200
+++ NVIDIA_kernel.rmap15b/nv.c 2002-12-17 00:03:12.000000000 +0200
@@ -2217,7 +2217,7 @@
{
pgd_t *pg_dir;
pmd_t *pg_mid_dir;
- pte_t *pte__, pte;
+ pte_t pte;
#if defined(NVCPU_IA64)
if (address > __IA64_UNCACHED_OFFSET)
@@ -2241,14 +2241,7 @@
if (pmd_none(*pg_mid_dir))
goto failed;
-#if defined (pte_offset_atomic)
- pte__ = pte_offset_atomic(pg_mid_dir, address);
- pte = *pte__;
- pte_kunmap(pte__);
-#else
- pte__ = NULL;
- pte = *pte_offset(pg_mid_dir, address);
-#endif
+ PTE_OFFSET(pg_mid_dir, address, pte);
if (!pte_present(pte))
goto failed;
diff -urN NVIDIA_kernel-1.0-4191/nv-linux.h NVIDIA_kernel.rmap15b/nv-linux.h
--- NVIDIA_kernel-1.0-4191/nv-linux.h 2002-12-09 22:27:15.000000000 +0200
+++ NVIDIA_kernel.rmap15b/nv-linux.h 2002-12-17 00:02:19.000000000 +0200
@@ -146,6 +146,28 @@
# define VMA_PRIVATE(vma) ((void*)((vma)->vm_pte))
#endif
+#ifdef pte_offset_map /* rmap-vm or 2.5 */
+#define PTE_OFFSET(pmd, address, pte) \
+ { \
+ pte_t *pPTE; \
+ pPTE = pte_offset_map(pmd, address); \
+ pte = *pPTE; \
+ pte_unmap(pPTE); \
+ }
+#else
+#ifdef pte_offset_atomic /* aa-vm */
+#define PTE_OFFSET(pmd, address, pte) \
+ { \
+ pte_t *pPTE; \
+ pPTE = pte_offset_atomic(pmd, address); \
+ pte = *pPTE; \
+ pte_kunmap(pPTE); \
+ }
+#else /* !pte_offset_atomic */
+#define PTE_OFFSET(pmd, address, pte) (pte = *pte_offset(pmd, address))
+#endif /* pte_offset_atomic */
+#endif /* pte_offset_map */
+
#define NV_PAGE_ALIGN(addr) ( ((addr) + PAGE_SIZE - 1) / PAGE_SIZE)
#define NV_MASK_OFFSET(addr) ( (addr) & (PAGE_SIZE - 1) )
"O.Sezer" wrote:
>
> Is this patch correct in any way?
> (Ripped out of the 2.5 patch and modified some).
The equivalent minimal patch for nv.c in 2.4 will then be:
--- modules/nvidia/NVIDIA_kernel/nv.c.orig Tue Dec 10 07:27:15 2002
+++ modules/nvidia/NVIDIA_kernel/nv.c Tue Dec 17 10:07:37 2002
@@ -2247,7 +2247,13 @@
pte_kunmap(pte__);
#else
pte__ = NULL;
+#ifdef pte_offset
pte = *pte_offset(pg_mid_dir, address);
+#else /* rmap-vm */
+ pte__ = pte_offset_map(pg_mid_dir, address);
+ pte = *pte__;
+ pte_unmap(pte__);
+#endif
#endif
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
The bit calling pte_unmap in nv-linux.h is the only difference from the
current minion.de patch, but it works, doesn't oops any more, nor does it
leak memory any more :-)
Great! X on 2.5 on my laptop!
Andrew
--On Tuesday, December 17, 2002 00:22:34 +0200 "O.Sezer"
<[email protected]> wrote:
> Is this patch correct in any way?
> (Ripped out of the 2.5 patch and modified some).
>
> Thanks.
>
So, first apply the patch for 4191 from http://www.minion.de, then the attached
one based on yours. Been running overnight and beaten on by XScreesaver,
no memory leak anymore.
Andrew
--On Tuesday, December 17, 2002 00:22:34 +0200 "O.Sezer"
<[email protected]> wrote:
> Is this patch correct in any way?
> (Ripped out of the 2.5 patch and modified some).
>
> Thanks.
>
So, we should thank to wli for the information.
Andrew McGregor wrote:
> So, first apply the patch for 4191 from http://www.minion.de, then the attached
> one based on yours. Been running overnight and beaten on by
> XScreesaver, no memory leak anymore.
>
> Andrew
>
> --On Tuesday, December 17, 2002 00:22:34 +0200 "O.Sezer"
> <[email protected]> wrote:
>
>> Is this patch correct in any way?
>> (Ripped out of the 2.5 patch and modified some).
>>
>> Thanks.
>>
>