pfn-Functionset out of order for sparc64 in current Bk tree?

pfn-Functionset out of order for sparc64 in current Bk tree?

[Thunder from the hill]

Hi,

Someone introduced, by Linus' request I remember, pfn_valid() instead of 
PAGE_INVALID() and such. Now I try to compile on Sparc, and /mm/memory.c 
is the first file which hits missing macros: pte_pfn, pfn_valid, 
pfn_to_page nd pfn_pte. I grepped for some declaration and hit only the 
two in the two-/three-level pagetable of i386. The only other occurrences 
of pte_pfn in *.[ch] were uses, not declarations. Global grep returned 
only two more occurrences in the Changeset.

 - pfn_to_page(pfn) is declared as (mem_map + (pfn)) for i386. Can this 
   apply to Sparc64 as well?
 - pte_pfn(x) is declared as
   ((unsigned long)(((x).pte_low >> PAGE_SHIFT)))
   in 2-level pgtable,
   (((x).pte_low >> PAGE_SHIFT) | ((x).pte_high << (32 - PAGE_SHIFT)))
   in 3-level. I suppose 2-level shouldn't exactly match here, how far 
   must the 3-level version be changed in order to fit sparc64? A lot?
 - pfn_valid(pfn) is described as ((pfn) < max_mapnr). Suppose this is OK 
   on Sparc64 either?
 - pfn_pte(page,prot) is defined as
   __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
   How far does this go for Sparc64?

The compile error was:

# sparc64-linux-gcc -D__KERNEL__ -I/usr/src/thunder-2.5/include -Wall 
-Wstrict-pr\ototypes -Wno-trigraphs -O2  -fno-strict-aliasing -fno-common 
-m64 -pipe -mno-f\pu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 
-fcall-used-g5 -fcall-used-g7 -W\no-sign-compare -Wa,--undeclared-regs -pg 
-DKBUILD_BASENAME=memory  -c -o mm/m\emory.o mm/memory.c
mm/memory.c: In function `__free_pte':
mm/memory.c:80: warning: implicit declaration of function `pte_pfn'
mm/memory.c:81: warning: implicit declaration of function `pfn_valid'
mm/memory.c:83: warning: implicit declaration of function `pfn_to_page'
mm/memory.c:83: warning: assignment makes pointer from integer without a 
cast
mm/memory.c: In function `copy_page_range':
mm/memory.c:289: warning: assignment makes pointer from integer without a 
cast
mm/memory.c: In function `zap_pte_range':
mm/memory.c:369: warning: assignment makes pointer from integer without a 
cast
mm/memory.c: In function `follow_page':
mm/memory.c:490: warning: return makes pointer from integer without a cast
mm/memory.c: In function `remap_pte_range':
mm/memory.c:879: invalid type argument of `->'
mm/memory.c:880: warning: implicit declaration of function `pfn_pte'
mm/memory.c: In function `do_wp_page':
mm/memory.c:996: warning: assignment makes pointer from integer without a 
cast

							       Regards,
								Thunder
--
if (errno == ENOTAVAIL)
    fprintf(stderr, "Error: Talking to Microsoft server!\n");

RE: pfn-Functionset out of order for sparc64 in current Bk tree?

[Holzrichter, Bruce]

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

>  - pfn_to_page(pfn) is declared as (mem_map + (pfn)) for 
> i386. Can this 
>    apply to Sparc64 as well?
>  - pte_pfn(x) is declared as
>    ((unsigned long)(((x).pte_low >> PAGE_SHIFT)))
>    in 2-level pgtable,
>    (((x).pte_low >> PAGE_SHIFT) | ((x).pte_high << (32 - PAGE_SHIFT)))
>    in 3-level. I suppose 2-level shouldn't exactly match 
> here, how far 
>    must the 3-level version be changed in order to fit sparc64? A lot?
>  - pfn_valid(pfn) is described as ((pfn) < max_mapnr). 
> Suppose this is OK 
>    on Sparc64 either?
>  - pfn_pte(page,prot) is defined as
>    __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
>    How far does this go for Sparc64?
> 

I think about an hour or so ago, Tom Duffy posted some fixes to the
Sparclinux mailing list that may help you out.  I cc'd them here.  They may
help you out, I havn't looked at them yet, so YMMV.

Bruce H.

<snip>
On Sun, 2002-05-05 at 23:27, Keith Owens wrote:
> kbuild-2.5-common-2.5.14-1 and kbuild-2.5-i386-2.5.14-1 are available.
> Upgraded to kernel 2.5.14.

here is the sparc64 kbuild against core-11 and 2.5.14

you must apply the linux-2.5.14-sparc64-hacks.patch first to get sparc64
to build on 2.5.14 (even using kbuild 2.4)

0) untar linux-2.5.14.tar.bz2
1) apply linux-2.5.14-sparc64-hacks.patch
2) apply kbuild-2.5-core-11
3) apply kbuild-2.5-common-2.5.14-1
4) apply kbuild-2.5-sparc64-2.5.14-1

you should be good to go...

this patch still needs work on the asm-offsets to get it work The Right
Way (tm)

-tduffy
</snip>


[-- Attachment #2: linux-2.5.14-sparc64-hacks.patch --]
[-- Type: application/octet-stream, Size: 2923 bytes --]

--- linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1/include/asm-sparc64/page.h	Sun May  5 20:38:01 2002
+++ linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1+sparc64-1/include/asm-sparc64/page.h	Mon May  6 11:02:04 2002
@@ -113,8 +113,17 @@
 
 #define __pa(x)			((unsigned long)(x) - PAGE_OFFSET)
 #define __va(x)			((void *)((unsigned long) (x) + PAGE_OFFSET))
+
+#if 0
 #define virt_to_page(kaddr)	(mem_map + ((__pa(kaddr)-phys_base) >> PAGE_SHIFT))
 #define VALID_PAGE(page)	((page - mem_map) < max_mapnr)
+#endif
+
+#define pfn_to_page(pfn)	(mem_map + (pfn))
+#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
+#define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr-phys_base) >> PAGE_SHIFT)
+#define pfn_valid(pfn)		((pfn) < max_mapnr)
+#define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr-phys_base) >> PAGE_SHIFT)
 
 #define virt_to_phys __pa
 #define phys_to_virt __va
--- linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1/arch/sparc64/kernel/ioctl32.c	Sun May  5 20:37:59 2002
+++ linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1+sparc64-1/arch/sparc64/kernel/ioctl32.c	Mon May  6 11:17:15 2002
@@ -4553,8 +4553,8 @@
 COMPATIBLE_IOCTL(HCIDEVUP)
 COMPATIBLE_IOCTL(HCIDEVDOWN)
 COMPATIBLE_IOCTL(HCIDEVRESET)
-COMPATIBLE_IOCTL(HCIRESETSTAT)
-COMPATIBLE_IOCTL(HCIGETINFO)
+/* COMPATIBLE_IOCTL(HCIRESETSTAT) */
+/* COMPATIBLE_IOCTL(HCIGETINFO) */
 COMPATIBLE_IOCTL(HCIGETDEVLIST)
 COMPATIBLE_IOCTL(HCISETRAW)
 COMPATIBLE_IOCTL(HCISETSCAN)
--- linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1/include/asm-sparc64/pgtable.h	Sun May  5 20:37:53 2002
+++ linux-2.5.14+kbuild-v2.1+common-1+core-11+i386-1+sparc64-1/include/asm-sparc64/pgtable.h	Tue May  7 09:41:53 2002
@@ -194,13 +194,22 @@
 extern struct page *mem_map_zero;
 #define ZERO_PAGE(vaddr)	(mem_map_zero)
 
+#if 0
 /* Warning: These take pointers to page structs now... */
 #define mk_pte(page, pgprot)		\
 	__pte((((page - mem_map) << PAGE_SHIFT)+phys_base) | pgprot_val(pgprot) | _PAGE_SZBITS)
+#endif
+
+#define pfn_pte(pfn, pgprot)		\
+	__pte((((pfn) << PAGE_SHIFT)+phys_base) | pgprot_val(pgprot) | _PAGE_SZBITS)
+#define mk_pte(page, pgprot)	pfn_pte(page_to_pfn(page), (pgprot))
+
 #define page_pte_prot(page, prot)	mk_pte(page, prot)
 #define page_pte(page)			page_pte_prot(page, __pgprot(0))
 
+#if 0
 #define mk_pte_phys(physpage, pgprot)	(__pte((physpage) | pgprot_val(pgprot) | _PAGE_SZBITS))
+#endif
 
 extern inline pte_t pte_modify(pte_t orig_pte, pgprot_t new_prot)
 {
@@ -246,7 +255,12 @@
 /* Permanent address of a page. */
 #define __page_address(page)	page_address(page)
 
+#if 0
 #define pte_page(x) (mem_map+(((pte_val(x)&_PAGE_PADDR)-phys_base)>>PAGE_SHIFT))
+#endif
+
+#define pte_page(x) pfn_to_page(pte_pfn(x))
+#define pte_pfn(x) (((pte_val(x)&_PAGE_PADDR)-phys_base)>>PAGE_SHIFT)
 
 /* Be very careful when you change these three, they are delicate. */
 #define pte_mkyoung(pte)	(__pte(pte_val(pte) | _PAGE_ACCESSED | _PAGE_R))

[-- Attachment #3: kbuild-2.5-sparc64-2.5.14-1.bz2 --]
[-- Type: application/octet-stream, Size: 6641 bytes --]

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Thunder from the hill wrote:

As long as CONFIG_DISCONTIGMEM isn't used the replacement functions are
quite simple.

>  - pfn_to_page(pfn) is declared as (mem_map + (pfn)) for i386. Can this 
>    apply to Sparc64 as well?

Yes.

>  - pte_pfn(x) is declared as
>    ((unsigned long)(((x).pte_low >> PAGE_SHIFT)))
>    in 2-level pgtable,
>    (((x).pte_low >> PAGE_SHIFT) | ((x).pte_high << (32 - PAGE_SHIFT)))
>    in 3-level. I suppose 2-level shouldn't exactly match here, how far 
>    must the 3-level version be changed in order to fit sparc64? A lot?

#define pte_pfn(x) (pte_val(x) >> PAGE_SHIFT)

>  - pfn_valid(pfn) is described as ((pfn) < max_mapnr). Suppose this is OK 
>    on Sparc64 either?

Yes.

>  - pfn_pte(page,prot) is defined as
>    __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
>    How far does this go for Sparc64?

#define pfn_pte(pfn,prot) mk_pte_phys(pfn << PAGE_SHIFT, prot)
but you should better replace mk_pte_phys completely.

bye, Roman

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Jan-Benedict Glaw]

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

On Tue, 2002-05-07 14:12:29 -0500, Holzrichter, Bruce <bruce.holzrichter@monster.com>
wrote in message <61DB42B180EAB34E9D28346C11535A783A75DF@nocmail101.ma.tmpw.net>:
> >  - pfn_to_page(pfn) is declared as (mem_map + (pfn)) for 

[ pfn stuff removed ]

Well, the pfn stuff is 100 rifle shots into feet. It broke so far all
architectures (not only Sparc64), but also Alpha and all the others.
It would have been nice if they were worked out and submitted with the
initial patch...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Thunder from the hill]

Hi,

On Tue, 7 May 2002, Roman Zippel wrote advises on pfn.

So this compiles for me.

							       Regards,
								Thunder

diff -Nur linus-2.5/include/asm-sparc64/page.h thunder-2.5/include/asm-sparc64/page.h
--- linus-2.5/include/asm-sparc64/page.h	Tue May  7 14:30:00 2002
+++ thunder-2.5/include/asm-sparc64/page.h	Tue May  7 14:08:48 2002
@@ -114,6 +114,8 @@
 #define __pa(x)			((unsigned long)(x) - PAGE_OFFSET)
 #define __va(x)			((void *)((unsigned long) (x) + PAGE_OFFSET))
 #define virt_to_page(kaddr)	(mem_map + ((__pa(kaddr)-phys_base) >> PAGE_SHIFT))
+#define pfn_valid(pfn)		((pfn) < max_mapnr)
+
 #define VALID_PAGE(page)	((page - mem_map) < max_mapnr)
 
 #define virt_to_phys __pa
diff -Nur linus-2.5/include/asm-sparc64/pgtable.h thunder-2.5/include/asm-sparc64/pgtable.h
--- linus-2.5/include/asm-sparc64/pgtable.h	Tue May  7 14:30:00 2002
+++ thunder-2.5/include/asm-sparc64/pgtable.h	Tue May  7 14:10:46 2002
@@ -201,6 +201,7 @@
 #define page_pte(page)			page_pte_prot(page, __pgprot(0))
 
 #define mk_pte_phys(physpage, pgprot)	(__pte((physpage) | pgprot_val(pgprot) | _PAGE_SZBITS))
+#define pfn_pte(pfn,prot)		mk_pte_phys(pfn << PAGE_SHIFT, prot)
 
 extern inline pte_t pte_modify(pte_t orig_pte, pgprot_t new_prot)
 {
@@ -272,6 +273,8 @@
 #define pte_offset_map_nested		__pte_offset
 #define pte_unmap(pte)			do { } while (0)
 #define pte_unmap_nested(pte)		do { } while (0)
+#define pfn_to_page(pfn)		(mem_map + (pfn))
+#define pte_pfn(x)			(pte_val(x) >> PAGE_SHIFT)
 
 extern pgd_t swapper_pg_dir[1];
 
-- 
if (errno == ENOTAVAIL)
    fprintf(stderr, "Error: Talking to Microsoft server!\n");

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[David S. Miller]

   From: Roman Zippel <zippel@linux-m68k.org>
   Date: Tue, 7 May 2002 21:22:13 +0200 (CEST)

   On Tue, 7 May 2002, Thunder from the hill wrote:
   
   >  - pte_pfn(x) is declared as
   >    ((unsigned long)(((x).pte_low >> PAGE_SHIFT)))
   >    in 2-level pgtable,
   >    (((x).pte_low >> PAGE_SHIFT) | ((x).pte_high << (32 - PAGE_SHIFT)))
   >    in 3-level. I suppose 2-level shouldn't exactly match here, how far 
   >    must the 3-level version be changed in order to fit sparc64? A lot?
   
   #define pte_pfn(x) (pte_val(x) >> PAGE_SHIFT)
   
   >  - pfn_valid(pfn) is described as ((pfn) < max_mapnr). Suppose this is OK 
   >    on Sparc64 either?
   
   Yes.
   
   >  - pfn_pte(page,prot) is defined as
   >    __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
   >    How far does this go for Sparc64?
   
   #define pfn_pte(pfn,prot) mk_pte_phys(pfn << PAGE_SHIFT, prot)
   but you should better replace mk_pte_phys completely.

All of this is ignoring the fact that phys_base has to be subtracted
from any physical address before applying as an index to mem_map on
sparc64.

I have the correct fixes for sparc64 in my tree and I'll merge it
all to Linus.

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[David S. Miller]

   From: Thunder from the hill <thunder@ngforever.de>
   Date: Tue, 7 May 2002 14:43:08 -0600 (MDT)

   +#define pfn_to_page(pfn)		(mem_map + (pfn))
   +#define pte_pfn(x)			(pte_val(x) >> PAGE_SHIFT)

Wrong wrong wrong, you aren't factoring in 'phys_base'
This is required on sparc64.

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[David S. Miller]

   From: Thunder from the hill <thunder@ngforever.de>
   Date: Tue, 7 May 2002 15:52:59 -0600 (MDT)

   On Tue, 7 May 2002, David S. Miller wrote:
   > I have the correct fixes for sparc64 in my tree and I'll merge it
   > all to Linus.
   
   That's good. Where do I find a patch, or is it already merged?

Not merged, still testing and tweaking.  It will be merged
after I am done with that.

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Thunder from the hill]

Hi,

On Tue, 7 May 2002, David S. Miller wrote:
> I have the correct fixes for sparc64 in my tree and I'll merge it
> all to Linus.

That's good. Where do I find a patch, or is it already merged?

Regards,
Thunder
-- 
if (errno == ENOTAVAIL)
    fprintf(stderr, "Error: Talking to Microsoft server!\n");

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Jan-Benedict Glaw wrote:

> Well, the pfn stuff is 100 rifle shots into feet. It broke so far all
> architectures (not only Sparc64), but also Alpha and all the others.
> It would have been nice if they were worked out and submitted with the
> initial patch...

Providing some lame substitution would have certainly be possible, but
the arch maintainers usually know better how to implement it
efficiently. If there is any problem they know where to ask.

bye, Roman

Re: pfn-Functionset out of order for sparc64 in current Bk tree?

[Roman Zippel]

Hi,

On Tue, 7 May 2002, David S. Miller wrote:

> All of this is ignoring the fact that phys_base has to be subtracted
> from any physical address before applying as an index to mem_map on
> sparc64.

Not only on sparc64. :)
I was a bit in a hurry and forgot to mention that "detail"..., sorry. :)

bye, Roman