Ok, running fine with 2.5.74-mm2 but when I try to insert the nvidia
module (with patches from http://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
[email protected]
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 http://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
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
[email protected]
Thomas Schlichter <[email protected]> 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;
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 http://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
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
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
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
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...
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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'
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
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
[email protected]
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
[email protected]
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
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 <[email protected]>
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
[email protected]
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
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
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
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