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

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

Post by Thunder from the hil » Thu, 09 May 2002 04:10:08



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");

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Roman Zippe » Thu, 09 May 2002 04:30:11


Hi,


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

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

Yes.

Quote:>  - 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)

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

Yes.

Quote:>  - 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Jan-Benedict Gla » Thu, 09 May 2002 04:30:13




Quote:> >  - 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

--

         -- New APT-Proxy written in shell script --
           http://lug-owl.de/~jbglaw/software/ap2/

  application_pgp-signature_part
< 1K Download
 
 
 

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

Post by Thunder from the hil » Thu, 09 May 2002 05:50:08


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

 #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

 #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)

 #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");

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by David S. Mille » Thu, 09 May 2002 06:30:07



   Date: Tue, 7 May 2002 21:22:13 +0200 (CEST)


   >  - 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by David S. Mille » Thu, 09 May 2002 06:30:13



   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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Thunder from the hil » Thu, 09 May 2002 07:00:07


Hi,


> 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");

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by David S. Mille » Thu, 09 May 2002 07:00:09



   Date: Tue, 7 May 2002 15:52:59 -0600 (MDT)


   > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Roman Zippe » Thu, 09 May 2002 08:20:04


Hi,


> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

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

Post by Roman Zippe » Thu, 09 May 2002 08:20:08


Hi,


> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 0-order allocation failures in LTP run of Last nights bk tree

In the nightly ltp run against the bk 2.5 tree last night I saw this
show up in the logs.

It happened on the 2-way PIII-550, 2gb physical ram, but not on the
smaller UP box I test on.

mtest01: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
...
...

The past few nights it's been failing from compile errors such as the
vmlinux.lds.S error and such so I'm not for certain that this was caused
by something that got introduced yesterday.  It should be from something
pretty recent though.

Thanks,
Paul Larson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Adaptec 1510 SCSI

3. Nightly regression runs against current bk tree

4. Help Needed - Probing Hangs

5. bad: schedule() with irqs disabled! - current bk tree

6. Maxtor 1.2G IDE, please help

7. fix UP links - current bk tree

8. STB Trio64V+ (2Mb) and XFree86 (linux)

9. PANIC caused by dequeue_signal() in current Linus BK tree

10. IDE from current bk tree, UDMA and two channels...

11. fix current BK tree compilation with devfs enabled

12. BUG: Current 2.5-BK tree dies on boot!

13. Nightly regression runs against current bk tree