Re: 2.5.74-mm2 + nvidia (and others)

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On  8 Jul 03 at 13:35, Christian Axelsson wrote:
> On Tue, 2003-07-08 at 13:23, Flameeyes wrote:
> > On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> > > vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> > > But it is not tested, I have enough troubles with 2.5.74 without mm patches...
> > vmnet doesn't compile:
> > 
> > make: Entering directory `/tmp/vmware-config1/vmnet-only'
> > In file included from userif.c:51:
> > pgtbl.h: In function `PgtblVa2PageLocked':
> > pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> > pgtbl.h:82: warning: assignment makes pointer from integer without a
> > cast
> > make: Leaving directory `/tmp/vmware-config1/vmnet-only'
> 
> I get exactly the same errors. BTW I got these on vanilla 2.5.74 aswell.

Either copy compat_pgtable.h from vmmon to vmnet, or grab
vmware-any-any-update36. I forgot to update vmnet's copy of this file.
                                                Petr Vandrovec
                                                

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On  8 Jul 03 at 13:35, Christian Axelsson wrote:
> On Tue, 2003-07-08 at 13:23, Flameeyes wrote:
> > On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> > > vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> > > But it is not tested, I have enough troubles with 2.5.74 without mm patches...
> > vmnet doesn't compile:
> > 
> > make: Entering directory `/tmp/vmware-config1/vmnet-only'
> > In file included from userif.c:51:
> > pgtbl.h: In function `PgtblVa2PageLocked':
> > pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> > pgtbl.h:82: warning: assignment makes pointer from integer without a
> > cast
> > make: Leaving directory `/tmp/vmware-config1/vmnet-only'
> 
> I get exactly the same errors. BTW I got these on vanilla 2.5.74 aswell.

Either copy compat_pgtable.h from vmmon to vmnet, or grab
vmware-any-any-update36. I forgot to update vmnet's copy of this file.
                                                Petr Vandrovec
                                                

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Flameeyes]

On Tue, 2003-07-08 at 14:37, Petr Vandrovec wrote:
> Either copy compat_pgtable.h from vmmon to vmnet, or grab
> vmware-any-any-update36. I forgot to update vmnet's copy of this file.
also vmware-any-any-update36 doesn't work... works only if we copy also
pgtbl.h from vmmon to vmnet.
-- 
Flameeyes <dgp85@users.sf.net>

Re: 2.5.74-mm2 + nvidia (and others)

[Flameeyes]

On Tue, 2003-07-08 at 14:37, Petr Vandrovec wrote:
> Either copy compat_pgtable.h from vmmon to vmnet, or grab
> vmware-any-any-update36. I forgot to update vmnet's copy of this file.
also vmware-any-any-update36 doesn't work... works only if we copy also
pgtbl.h from vmmon to vmnet.
-- 
Flameeyes <dgp85@users.sf.net>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Christian Axelsson]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On Tue, 2003-07-08 at 14:37, Petr Vandrovec wrote:
> On  8 Jul 03 at 13:35, Christian Axelsson wrote:
> > On Tue, 2003-07-08 at 13:23, Flameeyes wrote:
> > > On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> > > > vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> > > > But it is not tested, I have enough troubles with 2.5.74 without mm patches...
> > > vmnet doesn't compile:
> > > 
> > > make: Entering directory `/tmp/vmware-config1/vmnet-only'
> > > In file included from userif.c:51:
> > > pgtbl.h: In function `PgtblVa2PageLocked':
> > > pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> > > pgtbl.h:82: warning: assignment makes pointer from integer without a
> > > cast
> > > make: Leaving directory `/tmp/vmware-config1/vmnet-only'
> > 
> > I get exactly the same errors. BTW I got these on vanilla 2.5.74 aswell.
> 
> Either copy compat_pgtable.h from vmmon to vmnet, or grab
> vmware-any-any-update36. I forgot to update vmnet's copy of this file.

Still getting same errors. However if I copy pgtbl.h from vmmon it
compiles. vmmon uses pmd_offset_map instead of pmd_offset

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On Tue, Jul 08, 2003 at 03:02:37PM +0200, Christian Axelsson wrote:
> On Tue, 2003-07-08 at 14:37, Petr Vandrovec wrote:
> > 
> > Either copy compat_pgtable.h from vmmon to vmnet, or grab
> > vmware-any-any-update36. I forgot to update vmnet's copy of this file.
> 
> Still getting same errors. However if I copy pgtbl.h from vmmon it
> compiles. vmmon uses pmd_offset_map instead of pmd_offset

Yes, I know :-( I forgot that I modified pgtbl.h too. All these files are 
common to vmmon/vmnet and should be same. update36 large 173887 bytes
should have all needed files updated in vmnet too. If it will not work,
I'll download -mm2 and try really building code, as apparently even
trivial changes are too complicated for me today.
							Petr Vandrovec

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On Tue, Jul 08, 2003 at 03:02:37PM +0200, Christian Axelsson wrote:
> On Tue, 2003-07-08 at 14:37, Petr Vandrovec wrote:
> > 
> > Either copy compat_pgtable.h from vmmon to vmnet, or grab
> > vmware-any-any-update36. I forgot to update vmnet's copy of this file.
> 
> Still getting same errors. However if I copy pgtbl.h from vmmon it
> compiles. vmmon uses pmd_offset_map instead of pmd_offset

Yes, I know :-( I forgot that I modified pgtbl.h too. All these files are 
common to vmmon/vmnet and should be same. update36 large 173887 bytes
should have all needed files updated in vmnet too. If it will not work,
I'll download -mm2 and try really building code, as apparently even
trivial changes are too complicated for me today.
							Petr Vandrovec

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

2.5.74-mm2 + nvidia (and others)

[Christian Axelsson]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

Ok, running fine with 2.5.74-mm2 but when I try to insert the nvidia
module (with patches from www.minion.de applied) it gives 

nvidia: Unknown symbol pmd_offset

in dmesg. The vmware vmmon module gives the same error (the others wont
compile but thats a different story).

The nvidia module works fine under plain 2.5.74.

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.5.74-mm2 + nvidia (and others)

[Thomas Schlichter]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Am Monday 07 July 2003 17:08 schrieb Christian Axelsson:
> Ok, running fine with 2.5.74-mm2 but when I try to insert the nvidia
> module (with patches from www.minion.de applied) it gives
>
> nvidia: Unknown symbol pmd_offset
>
> in dmesg. The vmware vmmon module gives the same error (the others wont
> compile but thats a different story).
>
> The nvidia module works fine under plain 2.5.74.

The problem is the highpmd patch in -mm2. There are two options:
1. Revert the highpmd patch.
2. Apply the attached patch to the NVIDIA kernel module sources.

Best regards
   Thomas Schlichter

[-- Attachment #2: NVIDIA_kernel-1.0-4363-highpmd.diff --]
[-- Type: text/x-diff, Size: 1384 bytes --]

--- NVIDIA_kernel-1.0-4363/nv-linux.h.orig	Sun Jul  6 14:42:34 2003
+++ NVIDIA_kernel-1.0-4363/nv-linux.h	Mon Jul  7 14:57:02 2003
@@ -225,6 +225,18 @@
     }
 #endif
 
+#if defined(pmd_offset_map)
+#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
+    { \
+        pmd_t *pg_mid_dir__ = pmd_offset_map(pg_dir, address); \
+        pg_mid_dir = *pg_mid_dir__; \
+        pmd_unmap(pg_mid_dir__); \
+    }
+#else
+#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
+    pg_mid_dir = *pmd_offset(pg_dir, address)
+#endif
+
 #define NV_PAGE_ALIGN(addr)             ( ((addr) + PAGE_SIZE - 1) / PAGE_SIZE)
 #define NV_MASK_OFFSET(addr)            ( (addr) & (PAGE_SIZE - 1) )
 
--- NVIDIA_kernel-1.0-4363/nv.c.orig	Sun Jul  6 14:45:36 2003
+++ NVIDIA_kernel-1.0-4363/nv.c	Sun Jul  6 14:58:55 2003
@@ -2084,7 +2084,7 @@
 nv_get_phys_address(unsigned long address)
 {
     pgd_t *pg_dir;
-    pmd_t *pg_mid_dir;
+    pmd_t pg_mid_dir;
     pte_t pte;
 
 #if defined(NVCPU_IA64)
@@ -2105,11 +2105,12 @@
     if (pgd_none(*pg_dir))
         goto failed;
 
-    pg_mid_dir = pmd_offset(pg_dir, address);
-    if (pmd_none(*pg_mid_dir))
+    NV_PMD_OFFSET(address, pg_dir, pg_mid_dir);
+
+    if (pmd_none(pg_mid_dir))
         goto failed;
 
-    NV_PTE_OFFSET(address, pg_mid_dir, pte);
+    NV_PTE_OFFSET(address, &pg_mid_dir, pte);
 
     if (!pte_present(pte))
         goto failed;

Re: 2.5.74-mm2 + nvidia (and others)

[Christian Axelsson]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Mon, 2003-07-07 at 17:33, Thomas Schlichter wrote:
> The problem is the highpmd patch in -mm2. There are two options:
> 1. Revert the highpmd patch.
> 2. Apply the attached patch to the NVIDIA kernel module sources.

Thanks alot, applying the patch you supplied cured the problem.

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.5.74-mm2 + nvidia (and others)

[Andrew Morton]

Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
>  +#if defined(pmd_offset_map)
>  +#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
>  +    { \
>  +        pmd_t *pg_mid_dir__ = pmd_offset_map(pg_dir, address); \
>  +        pg_mid_dir = *pg_mid_dir__; \
>  +        pmd_unmap(pg_mid_dir__); \
>  +    }
>  +#else
>  +#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
>  +    pg_mid_dir = *pmd_offset(pg_dir, address)
>  +#endif
>  +

Well that will explode if someone enables highpmd and has highmem.
This would be better:

--- nv.c.orig	2003-07-05 22:55:10.000000000 -0700
+++ nv.c	2003-07-05 22:55:58.000000000 -0700
@@ -2105,11 +2105,14 @@
     if (pgd_none(*pg_dir))
         goto failed;
 
-    pg_mid_dir = pmd_offset(pg_dir, address);
-    if (pmd_none(*pg_mid_dir))
+    pg_mid_dir = pmd_offset_map(pg_dir, address);
+    if (pmd_none(*pg_mid_dir)) {
+	pmd_unmap(pg_mid_dir);
         goto failed;
+    }
 
     NV_PTE_OFFSET(address, pg_mid_dir, pte);
+    pmd_unmap(pg_mid_dir);
 
     if (!pte_present(pte))
         goto failed;

Re: 2.5.74-mm2 + nvidia (and others)

[Andrew Morton]

Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
>  +#if defined(pmd_offset_map)
>  +#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
>  +    { \
>  +        pmd_t *pg_mid_dir__ = pmd_offset_map(pg_dir, address); \
>  +        pg_mid_dir = *pg_mid_dir__; \
>  +        pmd_unmap(pg_mid_dir__); \
>  +    }
>  +#else
>  +#define NV_PMD_OFFSET(address, pg_dir, pg_mid_dir) \
>  +    pg_mid_dir = *pmd_offset(pg_dir, address)
>  +#endif
>  +

Well that will explode if someone enables highpmd and has highmem.
This would be better:

--- nv.c.orig	2003-07-05 22:55:10.000000000 -0700
+++ nv.c	2003-07-05 22:55:58.000000000 -0700
@@ -2105,11 +2105,14 @@
     if (pgd_none(*pg_dir))
         goto failed;
 
-    pg_mid_dir = pmd_offset(pg_dir, address);
-    if (pmd_none(*pg_mid_dir))
+    pg_mid_dir = pmd_offset_map(pg_dir, address);
+    if (pmd_none(*pg_mid_dir)) {
+	pmd_unmap(pg_mid_dir);
         goto failed;
+    }
 
     NV_PTE_OFFSET(address, pg_mid_dir, pte);
+    pmd_unmap(pg_mid_dir);
 
     if (!pte_present(pte))
         goto failed;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Mon, 2003-07-07 at 21:30, Andrew Morton wrote:

> Well that will explode if someone enables highpmd and has highmem.
> This would be better:
> 
> --- nv.c.orig	2003-07-05 22:55:10.000000000 -0700
> +++ nv.c	2003-07-05 22:55:58.000000000 -0700
> @@ -2105,11 +2105,14 @@
>      if (pgd_none(*pg_dir))
>          goto failed;
>  
> -    pg_mid_dir = pmd_offset(pg_dir, address);
> -    if (pmd_none(*pg_mid_dir))
> +    pg_mid_dir = pmd_offset_map(pg_dir, address);
> +    if (pmd_none(*pg_mid_dir)) {
> +	pmd_unmap(pg_mid_dir);
>          goto failed;
> +    }
>  
>      NV_PTE_OFFSET(address, pg_mid_dir, pte);
> +    pmd_unmap(pg_mid_dir);
>  
>      if (!pte_present(pte))
>          goto failed;
> 
> -

Bit too specific to -mm2, what about the the attached?


Regards,

-- 
Martin Schlemmer


[-- Attachment #2: NVIDIA_kernel-1.0-4363-highpmd.diff --]
[-- Type: text/x-patch, Size: 1425 bytes --]

diff -urpN NVIDIA_kernel-1.0-4363.orig/nv-linux.h NVIDIA_kernel-1.0-4363/nv-linux.h
--- NVIDIA_kernel-1.0-4363.orig/nv-linux.h	2003-04-20 03:57:19.000000000 +0200
+++ NVIDIA_kernel-1.0-4363/nv-linux.h	2003-07-08 07:53:49.000000000 +0200
@@ -186,6 +186,15 @@
     }
 #endif
 
+#if defined(pmd_offset_map)
+#define NV_PMD_OFFSET(address, pg_dir) \
+    pmd_offset_map(pg_dir, address);
+#define NV_PMD_OFFSET_UNMAP 1
+#else
+#define NV_PMD_OFFSET(address, pg_dir) \
+    pmd_offset(pg_dir, address)
+#endif
+
 #define NV_PAGE_ALIGN(addr)             ( ((addr) + PAGE_SIZE - 1) / PAGE_SIZE)
 #define NV_MASK_OFFSET(addr)            ( (addr) & (PAGE_SIZE - 1) )
 
diff -urpN NVIDIA_kernel-1.0-4363.orig/nv.c NVIDIA_kernel-1.0-4363/nv.c
--- NVIDIA_kernel-1.0-4363.orig/nv.c	2003-04-20 03:57:19.000000000 +0200
+++ NVIDIA_kernel-1.0-4363/nv.c	2003-07-08 07:55:09.000000000 +0200
@@ -2191,11 +2191,18 @@ nv_get_phys_address(unsigned long addres
     if (pgd_none(*pg_dir))
         goto failed;
 
-    pg_mid_dir = pmd_offset(pg_dir, address);
-    if (pmd_none(*pg_mid_dir))
+    pg_mid_dir = NV_PMD_OFFSET(pg_dir, address);
+    if (pmd_none(*pg_mid_dir)) {
+#if defined(NV_PMD_OFFSET_UNMAP)
+       pmd_unmap(pg_mid_dir);
+#endif
         goto failed;
+    }
 
     NV_PTE_OFFSET(address, pg_mid_dir, pte);
+#if defined(NV_PMD_OFFSET_UNMAP)
+    pmd_unmap(pg_mid_dir);
+#endif
 
     if (!pte_present(pte))
         goto failed;

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> Bit too specific to -mm2, what about the the attached?

Well, it'd also help to check whether this is a userspace address or
a kernelspace address. Kernelspace access would only require
pmd_offset_kernel().

Where are these nvidia and vmware patches, anyway? I can maintain
fixups for highpmd for the things and it would at least help me a
bit to see what's going on around the specific areas.


-- wli

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> Bit too specific to -mm2, what about the the attached?

Well, it'd also help to check whether this is a userspace address or
a kernelspace address. Kernelspace access would only require
pmd_offset_kernel().

Where are these nvidia and vmware patches, anyway? I can maintain
fixups for highpmd for the things and it would at least help me a
bit to see what's going on around the specific areas.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Thomas Schlichter]

On Tuesday 08 July 2003 09:26, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> > Bit too specific to -mm2, what about the the attached?
>
> Well, it'd also help to check whether this is a userspace address or
> a kernelspace address. Kernelspace access would only require
> pmd_offset_kernel().
>
> Where are these nvidia and vmware patches, anyway? I can maintain
> fixups for highpmd for the things and it would at least help me a
> bit to see what's going on around the specific areas.

Well, the NVIDIA patches are at
   http://www.minion.de/nvidia.html
but I don't know about the VMWARE patches...

Btw, what do you think about the idea of exporting the follow_pages() function 
from mm/memory.c to kernel modules? So this could be used for modules 
compiled for 2.[56] kernels and the old way just for 2.4 kernels...

Re: 2.5.74-mm2 + nvidia (and others)

[Thomas Schlichter]

On Tuesday 08 July 2003 09:26, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> > Bit too specific to -mm2, what about the the attached?
>
> Well, it'd also help to check whether this is a userspace address or
> a kernelspace address. Kernelspace access would only require
> pmd_offset_kernel().
>
> Where are these nvidia and vmware patches, anyway? I can maintain
> fixups for highpmd for the things and it would at least help me a
> bit to see what's going on around the specific areas.

Well, the NVIDIA patches are at
   http://www.minion.de/nvidia.html
but I don't know about the VMWARE patches...

Btw, what do you think about the idea of exporting the follow_pages() function 
from mm/memory.c to kernel modules? So this could be used for modules 
compiled for 2.[56] kernels and the old way just for 2.4 kernels...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> Well, the NVIDIA patches are at
>    http://www.minion.de/nvidia.html
> but I don't know about the VMWARE patches...

Thanks. I'll grab that and start maintaining highpmd updates for it.


On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> Btw, what do you think about the idea of exporting the follow_pages()
> function from mm/memory.c to kernel modules? So this could be used
> for modules compiled for 2.[56] kernels and the old way just for 2.4
> kernels...

I don't really have an opinion on it, but it's not my call.


-- wli

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> Well, the NVIDIA patches are at
>    http://www.minion.de/nvidia.html
> but I don't know about the VMWARE patches...

Thanks. I'll grab that and start maintaining highpmd updates for it.


On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> Btw, what do you think about the idea of exporting the follow_pages()
> function from mm/memory.c to kernel modules? So this could be used
> for modules compiled for 2.[56] kernels and the old way just for 2.4
> kernels...

I don't really have an opinion on it, but it's not my call.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Peter C. Ndikuwera]

The VMware patches are ...

ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-updateXX.tar.gz

Peter

On Tue, 2003-07-08 at 11:55, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > Well, the NVIDIA patches are at
> >    http://www.minion.de/nvidia.html
> > but I don't know about the VMWARE patches...
> 
> Thanks. I'll grab that and start maintaining highpmd updates for it.
> 
> 
> On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > Btw, what do you think about the idea of exporting the follow_pages()
> > function from mm/memory.c to kernel modules? So this could be used
> > for modules compiled for 2.[56] kernels and the old way just for 2.4
> > kernels...
> 
> I don't really have an opinion on it, but it's not my call.
> 
> 
> -- wli
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.5.74-mm2 + nvidia (and others)

[Peter C. Ndikuwera]

The VMware patches are ...

ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-updateXX.tar.gz

Peter

On Tue, 2003-07-08 at 11:55, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > Well, the NVIDIA patches are at
> >    http://www.minion.de/nvidia.html
> > but I don't know about the VMWARE patches...
> 
> Thanks. I'll grab that and start maintaining highpmd updates for it.
> 
> 
> On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > Btw, what do you think about the idea of exporting the follow_pages()
> > function from mm/memory.c to kernel modules? So this could be used
> > for modules compiled for 2.[56] kernels and the old way just for 2.4
> > kernels...
> 
> I don't really have an opinion on it, but it's not my call.
> 
> 
> -- wli
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On Tue, Jul 08, 2003 at 12:37:26PM +0300, Peter C. Ndikuwera wrote:
> The VMware patches are ...
> 
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-updateXX.tar.gz

vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
But it is not tested, I have enough troubles with 2.5.74 without mm patches...

> > On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > > Btw, what do you think about the idea of exporting the follow_pages()
> > > function from mm/memory.c to kernel modules? So this could be used
> > > for modules compiled for 2.[56] kernels and the old way just for 2.4
> > > kernels...
> > 
> > I don't really have an opinion on it, but it's not my call.

vmmon started using 'get_user_pages' for locking pages some time ago. 
Unfortunately userspace needs looking at VA->PA mapping from time to time 
although it already retrieved this information at the time get_user_pages() 
was invoked :-( It makes userspace simpler, and it was also much faster than
any other solution before pmd/pte moved into the high memory.
						Best regards,
							Petr Vandrovec

Re: 2.5.74-mm2 + nvidia (and others)

[Petr Vandrovec]

On Tue, Jul 08, 2003 at 12:37:26PM +0300, Peter C. Ndikuwera wrote:
> The VMware patches are ...
> 
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-updateXX.tar.gz

vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
But it is not tested, I have enough troubles with 2.5.74 without mm patches...

> > On Tue, Jul 08, 2003 at 10:51:39AM +0200, Thomas Schlichter wrote:
> > > Btw, what do you think about the idea of exporting the follow_pages()
> > > function from mm/memory.c to kernel modules? So this could be used
> > > for modules compiled for 2.[56] kernels and the old way just for 2.4
> > > kernels...
> > 
> > I don't really have an opinion on it, but it's not my call.

vmmon started using 'get_user_pages' for locking pages some time ago. 
Unfortunately userspace needs looking at VA->PA mapping from time to time 
although it already retrieved this information at the time get_user_pages() 
was invoked :-( It makes userspace simpler, and it was also much faster than
any other solution before pmd/pte moved into the high memory.
						Best regards,
							Petr Vandrovec
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Flameeyes]

On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> But it is not tested, I have enough troubles with 2.5.74 without mm patches...
vmnet doesn't compile:

make: Entering directory `/tmp/vmware-config1/vmnet-only'
In file included from userif.c:51:
pgtbl.h: In function `PgtblVa2PageLocked':
pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
pgtbl.h:82: warning: assignment makes pointer from integer without a
cast
make: Leaving directory `/tmp/vmware-config1/vmnet-only'

Re: 2.5.74-mm2 + nvidia (and others)

[Flameeyes]

On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> But it is not tested, I have enough troubles with 2.5.74 without mm patches...
vmnet doesn't compile:

make: Entering directory `/tmp/vmware-config1/vmnet-only'
In file included from userif.c:51:
pgtbl.h: In function `PgtblVa2PageLocked':
pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
pgtbl.h:82: warning: assignment makes pointer from integer without a
cast
make: Leaving directory `/tmp/vmware-config1/vmnet-only'


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
>> vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
>> But it is not tested, I have enough troubles with 2.5.74 without mm patches...

On Tue, Jul 08, 2003 at 01:23:50PM +0200, Flameeyes wrote:
> vmnet doesn't compile:
> make: Entering directory `/tmp/vmware-config1/vmnet-only'
> In file included from userif.c:51:
> pgtbl.h: In function `PgtblVa2PageLocked':
> pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> pgtbl.h:82: warning: assignment makes pointer from integer without a
> cast
> make: Leaving directory `/tmp/vmware-config1/vmnet-only'

I've got some long-running benchmarks going at the moment on my main
dev boxen but I should be able to get a fix going soon.


-- wli

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
>> vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
>> But it is not tested, I have enough troubles with 2.5.74 without mm patches...

On Tue, Jul 08, 2003 at 01:23:50PM +0200, Flameeyes wrote:
> vmnet doesn't compile:
> make: Entering directory `/tmp/vmware-config1/vmnet-only'
> In file included from userif.c:51:
> pgtbl.h: In function `PgtblVa2PageLocked':
> pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> pgtbl.h:82: warning: assignment makes pointer from integer without a
> cast
> make: Leaving directory `/tmp/vmware-config1/vmnet-only'

I've got some long-running benchmarks going at the moment on my main
dev boxen but I should be able to get a fix going soon.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Christian Axelsson]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tue, 2003-07-08 at 13:23, Flameeyes wrote:
> On Tue, 2003-07-08 at 13:01, Petr Vandrovec wrote:
> > vmware-any-any-update35.tar.gz should work on 2.5.74-mm2 too.
> > But it is not tested, I have enough troubles with 2.5.74 without mm patches...
> vmnet doesn't compile:
> 
> make: Entering directory `/tmp/vmware-config1/vmnet-only'
> In file included from userif.c:51:
> pgtbl.h: In function `PgtblVa2PageLocked':
> pgtbl.h:82: warning: implicit declaration of function `pmd_offset'
> pgtbl.h:82: warning: assignment makes pointer from integer without a
> cast
> make: Leaving directory `/tmp/vmware-config1/vmnet-only'

I get exactly the same errors. BTW I got these on vanilla 2.5.74 aswell.

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.5.74-mm2 + nvidia (and others)

[Christian Axelsson]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Tue, 2003-07-08 at 09:03, Martin Schlemmer wrote:
> On Mon, 2003-07-07 at 21:30, Andrew Morton wrote:
> 
> > Well that will explode if someone enables highpmd and has highmem.
> > This would be better:
> > 
> > --- nv.c.orig	2003-07-05 22:55:10.000000000 -0700
> > +++ nv.c	2003-07-05 22:55:58.000000000 -0700
> > @@ -2105,11 +2105,14 @@
> >      if (pgd_none(*pg_dir))
> >          goto failed;
> >  
> > -    pg_mid_dir = pmd_offset(pg_dir, address);
> > -    if (pmd_none(*pg_mid_dir))
> > +    pg_mid_dir = pmd_offset_map(pg_dir, address);
> > +    if (pmd_none(*pg_mid_dir)) {
> > +	pmd_unmap(pg_mid_dir);
> >          goto failed;
> > +    }
> >  
> >      NV_PTE_OFFSET(address, pg_mid_dir, pte);
> > +    pmd_unmap(pg_mid_dir);
> >  
> >      if (!pte_present(pte))
> >          goto failed;
> > 
> > -
> 
> Bit too specific to -mm2, what about the the attached?

Compiles nicely, havent but I havent reloaded it yet.

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> +#if defined(NV_PMD_OFFSET_UNMAP)
> +    pmd_unmap(pg_mid_dir);
> +#endif

You could try defining an NV_PMD_OFFSET_UNMAP() which is a nop for
mainline and DTRT for -mm.


-- wli

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> +#if defined(NV_PMD_OFFSET_UNMAP)
> +    pmd_unmap(pg_mid_dir);
> +#endif

You could try defining an NV_PMD_OFFSET_UNMAP() which is a nop for
mainline and DTRT for -mm.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Martin Schlemmer]

On Sat, 2003-07-12 at 03:21, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> > +#if defined(NV_PMD_OFFSET_UNMAP)
> > +    pmd_unmap(pg_mid_dir);
> > +#endif
> 
> You could try defining an NV_PMD_OFFSET_UNMAP() which is a nop for
> mainline and DTRT for -mm.
> 

Ok, I basically got the latest minion.de (2003/07/13) to look as
follow:

----------------------------------
diff -urpN NVIDIA_kernel-1.0-4363/nv-linux.h
NVIDIA_kernel-1.0-4363.highpmd-fixup/nv-linux.h
--- NVIDIA_kernel-1.0-4363/nv-linux.h   2003-07-14 12:42:00.000000000
+0200
+++ NVIDIA_kernel-1.0-4363.highpmd-fixup/nv-linux.h     2003-07-14
13:38:02.000000000 +0200
@@ -228,14 +228,14 @@

 #if defined(pmd_offset_map)
 #define NV_PMD_OFFSET(address, pgd, pmd) \
-    { \
-        pmd_t *pmd__ = pmd_offset_map(pgd, address); \
-        pmd = *pmd__; \
-        pmd_unmap(pgd__); \
-    }
+    pmd = pmd_offset_map(pgd, address)
+#define NV_PMD_UNMAP(pmd) \
+    pmd_unmap(pmd)
 #else
 #define NV_PMD_OFFSET(address, pgd, pmd) \
-    pmd = *pmd_offset(pgd, address)
+    pmd = pmd_offset(pgd, address)
+#define NV_PMD_UNMAP(pmd) \
+    nop()
 #endif 

 #define NV_PAGE_ALIGN(addr)             ( ((addr) + PAGE_SIZE - 1) /
PAGE_SIZE)
diff -urpN NVIDIA_kernel-1.0-4363/nv.c
NVIDIA_kernel-1.0-4363.highpmd-fixup/nv.c
--- NVIDIA_kernel-1.0-4363/nv.c 2003-07-14 12:42:00.000000000 +0200
+++ NVIDIA_kernel-1.0-4363.highpmd-fixup/nv.c   2003-07-14
13:38:43.000000000 +0200
@@ -2087,7 +2087,7 @@ unsigned long
 nv_get_phys_address(unsigned long address)
 {
     pgd_t *pgd;
-    pmd_t pmd;
+    pmd_t *pmd;
     pte_t pte;
 
 #if defined(NVCPU_IA64)
@@ -2110,10 +2110,14 @@ nv_get_phys_address(unsigned long addres

     NV_PMD_OFFSET(address, pgd, pmd);
 
-    if (pmd_none(pmd))
+    if (pmd_none(*pmd)) {
+        NV_PMD_UNMAP(pmd);
         goto failed;
+    }
+
+    NV_PTE_OFFSET(address, pmd, pte);
 
-    NV_PTE_OFFSET(address, &pmd, pte);
+    NV_PMD_UNMAP(pmd);

     if (!pte_present(pte))
         goto failed;
----------------------------------

so that it will not use a copy of 'pmd' that was already
unmapped.

Question now - what about:

--------------------- nv-linux.h ----------------------
#if defined(pte_offset_atomic)
#define NV_PTE_OFFSET(addres, pmd, pte) \
    { \
        pte_t *pte__ = pte_offset_atomic(pmd, address); \
        pte = *pte__; \
        pte_kunmap(pte__); \
    } 
#elif defined(pte_offset)
#define NV_PTE_OFFSET(addres, pmd, pte) \
    pte = *pte_offset(pmd, address)
#else
#define NV_PTE_OFFSET(addres, pmd, pte) \
    { \
        pte_t *pte__ = pte_offset_map(pmd, address); \
        pte = *pte__; \
        pte_unmap(pte__); \
    }
#endif
-------------------------------------------------------

I cannot think that it is safe as well to use an copy
of an unmapped pte ??  Should this be fixed as well ?


Thanks,

-- 
Martin Schlemmer

Re: 2.5.74-mm2 + nvidia (and others)

[Martin Schlemmer]

On Sat, 2003-07-12 at 03:21, William Lee Irwin III wrote:
> On Tue, Jul 08, 2003 at 09:03:39AM +0200, Martin Schlemmer wrote:
> > +#if defined(NV_PMD_OFFSET_UNMAP)
> > +    pmd_unmap(pg_mid_dir);
> > +#endif
> 
> You could try defining an NV_PMD_OFFSET_UNMAP() which is a nop for
> mainline and DTRT for -mm.
> 

Ok, I basically got the latest minion.de (2003/07/13) to look as
follow:

----------------------------------
diff -urpN NVIDIA_kernel-1.0-4363/nv-linux.h
NVIDIA_kernel-1.0-4363.highpmd-fixup/nv-linux.h
--- NVIDIA_kernel-1.0-4363/nv-linux.h   2003-07-14 12:42:00.000000000
+0200
+++ NVIDIA_kernel-1.0-4363.highpmd-fixup/nv-linux.h     2003-07-14
13:38:02.000000000 +0200
@@ -228,14 +228,14 @@

 #if defined(pmd_offset_map)
 #define NV_PMD_OFFSET(address, pgd, pmd) \
-    { \
-        pmd_t *pmd__ = pmd_offset_map(pgd, address); \
-        pmd = *pmd__; \
-        pmd_unmap(pgd__); \
-    }
+    pmd = pmd_offset_map(pgd, address)
+#define NV_PMD_UNMAP(pmd) \
+    pmd_unmap(pmd)
 #else
 #define NV_PMD_OFFSET(address, pgd, pmd) \
-    pmd = *pmd_offset(pgd, address)
+    pmd = pmd_offset(pgd, address)
+#define NV_PMD_UNMAP(pmd) \
+    nop()
 #endif 

 #define NV_PAGE_ALIGN(addr)             ( ((addr) + PAGE_SIZE - 1) /
PAGE_SIZE)
diff -urpN NVIDIA_kernel-1.0-4363/nv.c
NVIDIA_kernel-1.0-4363.highpmd-fixup/nv.c
--- NVIDIA_kernel-1.0-4363/nv.c 2003-07-14 12:42:00.000000000 +0200
+++ NVIDIA_kernel-1.0-4363.highpmd-fixup/nv.c   2003-07-14
13:38:43.000000000 +0200
@@ -2087,7 +2087,7 @@ unsigned long
 nv_get_phys_address(unsigned long address)
 {
     pgd_t *pgd;
-    pmd_t pmd;
+    pmd_t *pmd;
     pte_t pte;
 
 #if defined(NVCPU_IA64)
@@ -2110,10 +2110,14 @@ nv_get_phys_address(unsigned long addres

     NV_PMD_OFFSET(address, pgd, pmd);
 
-    if (pmd_none(pmd))
+    if (pmd_none(*pmd)) {
+        NV_PMD_UNMAP(pmd);
         goto failed;
+    }
+
+    NV_PTE_OFFSET(address, pmd, pte);
 
-    NV_PTE_OFFSET(address, &pmd, pte);
+    NV_PMD_UNMAP(pmd);

     if (!pte_present(pte))
         goto failed;
----------------------------------

so that it will not use a copy of 'pmd' that was already
unmapped.

Question now - what about:

--------------------- nv-linux.h ----------------------
#if defined(pte_offset_atomic)
#define NV_PTE_OFFSET(addres, pmd, pte) \
    { \
        pte_t *pte__ = pte_offset_atomic(pmd, address); \
        pte = *pte__; \
        pte_kunmap(pte__); \
    } 
#elif defined(pte_offset)
#define NV_PTE_OFFSET(addres, pmd, pte) \
    pte = *pte_offset(pmd, address)
#else
#define NV_PTE_OFFSET(addres, pmd, pte) \
    { \
        pte_t *pte__ = pte_offset_map(pmd, address); \
        pte = *pte__; \
        pte_unmap(pte__); \
    }
#endif
-------------------------------------------------------

I cannot think that it is safe as well to use an copy
of an unmapped pte ??  Should this be fixed as well ?


Thanks,

-- 
Martin Schlemmer


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[Thomas Schlichter]

Hi,

can anyone tell me WHY the NV_PMD_OFFSET() should not work the way it is with 
the new NVIDIA patch? For our memories here it is again:

#define NV_PMD_OFFSET(address, pgd, pmd) \
    { \
        pmd_t *pmd__ = pmd_offset_map(pgd, address); \
        pmd = *pmd__; \
        pmd_unmap(pmd__); \
    }

1.) For a 2 level pagetable it simply results in a:
	pmd = *((pmd_t *) pgd);

So here the correct entry from the first page directory is copied into a 
variable on the stack. No big deal, as the location of this entry is not 
interesting for the further tablewalk, only its contents.

2.) So let's see what happens for a 3 level pagetable.
We get following code after expanding (most of) the macros:

a.) pmd_t *pmd__ = ((pmd_t *)kmap_atomic(pgd_page(*(pgd)), KM_PMD0) + 
pmd_index(addr));
b.) pmd = *pmd__;
c.) kunmap_atomic(pmd__, KM_PMD0);

The most interesting part is the first line of it...
a.) Here the page number is extracted from the pgd entry and converted to a 
pointer to a page_struct (pgd_page). Now the page is mapped (from the high 
memory) into the lower memory (kmap_atomic). The index where the interesting 
pmd entry is located in this page is extracted from the virtual address via 
the pmd_index macro. With this the pointer to the pmd entry is calculated and 
assigned to pmd__.

b.) Now this entry is simply copied into a variable located at the stack. 
(Again not an issue, as the location of the variable is not of interest for 
the rest of the tablewalk anymore.)

c.) At least the page that contains the pmd entry, too, is unmapped, but our 
local copy on the stack stays...


So after both pieces of code the pmd entry is stored in a variable on the 
stack and the further processing does not need to know where it came from, it 
just needs its contents...

So please tell me where this is wrong...! I just can't see it...

Thank you all for all the work!

Best regards
   Thomas Schlichter

Re: 2.5.74-mm2 + nvidia (and others)

[Thomas Schlichter]

Hi,

can anyone tell me WHY the NV_PMD_OFFSET() should not work the way it is with 
the new NVIDIA patch? For our memories here it is again:

#define NV_PMD_OFFSET(address, pgd, pmd) \
    { \
        pmd_t *pmd__ = pmd_offset_map(pgd, address); \
        pmd = *pmd__; \
        pmd_unmap(pmd__); \
    }

1.) For a 2 level pagetable it simply results in a:
	pmd = *((pmd_t *) pgd);

So here the correct entry from the first page directory is copied into a 
variable on the stack. No big deal, as the location of this entry is not 
interesting for the further tablewalk, only its contents.

2.) So let's see what happens for a 3 level pagetable.
We get following code after expanding (most of) the macros:

a.) pmd_t *pmd__ = ((pmd_t *)kmap_atomic(pgd_page(*(pgd)), KM_PMD0) + 
pmd_index(addr));
b.) pmd = *pmd__;
c.) kunmap_atomic(pmd__, KM_PMD0);

The most interesting part is the first line of it...
a.) Here the page number is extracted from the pgd entry and converted to a 
pointer to a page_struct (pgd_page). Now the page is mapped (from the high 
memory) into the lower memory (kmap_atomic). The index where the interesting 
pmd entry is located in this page is extracted from the virtual address via 
the pmd_index macro. With this the pointer to the pmd entry is calculated and 
assigned to pmd__.

b.) Now this entry is simply copied into a variable located at the stack. 
(Again not an issue, as the location of the variable is not of interest for 
the rest of the tablewalk anymore.)

c.) At least the page that contains the pmd entry, too, is unmapped, but our 
local copy on the stack stays...


So after both pieces of code the pmd entry is stored in a variable on the 
stack and the further processing does not need to know where it came from, it 
just needs its contents...

So please tell me where this is wrong...! I just can't see it...

Thank you all for all the work!

Best regards
   Thomas Schlichter
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Mon, Jul 07, 2003 at 05:08:39PM +0200, Christian Axelsson wrote:
> Ok, running fine with 2.5.74-mm2 but when I try to insert the nvidia
> module (with patches from www.minion.de applied) it gives 
> nvidia: Unknown symbol pmd_offset
> in dmesg. The vmware vmmon module gives the same error (the others wont
> compile but thats a different story).
> The nvidia module works fine under plain 2.5.74.

Could you send me the patches for the opensource bits of those in a
private reply?

Thanks.


-- wli

Re: 2.5.74-mm2 + nvidia (and others)

[William Lee Irwin III]

On Mon, Jul 07, 2003 at 05:08:39PM +0200, Christian Axelsson wrote:
> Ok, running fine with 2.5.74-mm2 but when I try to insert the nvidia
> module (with patches from www.minion.de applied) it gives 
> nvidia: Unknown symbol pmd_offset
> in dmesg. The vmware vmmon module gives the same error (the others wont
> compile but thats a different story).
> The nvidia module works fine under plain 2.5.74.

Could you send me the patches for the opensource bits of those in a
private reply?

Thanks.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>