* [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Mel Gorman @ 2007-11-15 10:13 UTC (permalink / raw)
To: akpm; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
This patch is a fix for 2.6.24.
Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that do
not support hugepages, HPAGE_SHIFT becomes 0. This results in pageblock_order
being set to -PAGE_SHIFT and a crash results shortly afterwards.
This patch sets HUGETLB_PAGE_SIZE_VARIABLE for PPC64 and adds a function
to select a sensible value for pageblock order by default. It checks that
HPAGE_SHIFT is a sensible value before using the hugepage size; if it is
not MAX_ORDER-1 is used.
Credit goes to Stephen Rothwell for identifying the bug and testing candidate
patches. Additional credit goes to Andy Whitcroft for spotting a problem
with respects to IA-64 before releasing. Additional credit to David Gibson
for testing with the libhugetlbfs test suite.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 5 +++++
mm/page_alloc.c | 14 ++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig
--- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig 2007-11-14 11:38:05.000000000 +0000
+++ linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig 2007-11-14 11:39:12.000000000 +0000
@@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
default "9" if PPC_64K_PAGES
default "13"
+config HUGETLB_PAGE_SIZE_VARIABLE
+ bool
+ depends on HUGETLB_PAGE
+ default y
+
config MATH_EMULATION
bool "Math emulation"
depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c
--- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c 2007-11-14 11:38:08.000000000 +0000
+++ linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c 2007-11-14 13:45:19.000000000 +0000
@@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
#endif /* CONFIG_SPARSEMEM */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
+
+/* Return a sensible default order for the pageblock size. */
+static inline int __init pageblock_default_order(void)
+{
+ if (HPAGE_SHIFT > PAGE_SHIFT)
+ return HUGETLB_PAGE_ORDER;
+
+ return MAX_ORDER-1;
+}
+
/* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
static inline void __init set_pageblock_order(unsigned int order)
{
@@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
}
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
-/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
+#define pageblock_default_order(x) (0)
#define set_pageblock_order(x) do {} while (0)
#endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
@@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
if (!size)
continue;
- set_pageblock_order(HUGETLB_PAGE_ORDER);
+ set_pageblock_order(pageblock_default_order());
setup_usemap(pgdat, zone, size);
ret = init_currently_empty_zone(zone, zone_start_pfn,
size, MEMMAP_EARLY);
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Do not depend on MAX_ORDER when grouping pages by mobility
From: Mel Gorman @ 2007-11-15 10:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20071115141740.d22acb0e.sfr@canb.auug.org.au>
On (15/11/07 14:17), Stephen Rothwell didst pronounce:
> Hi Mel,
>
> On Wed, 14 Nov 2007 18:10:45 +0000 mel@skynet.ie (Mel Gorman) wrote:
> >
> > libhugetlbfs test suite and boot test on iSeries is sufficient in this
> > case. However, the version I sent would break on IA-64 due to the lack of
> > a definition for HPAGE_SHIFT when CONFIG_HUGETLB_PAGE is not set. Can you
> > confirm this patch still fixes the problem please? If it does, I'll send
> > it to Andrew as a fix for 2.6.24. Whether iSeries is legacy or not, this is
> > breakage and should be fixed.
>
> The new patch works fine. I reran the libhugetlbfs tests on a Power5+
> machine and the ppc64_defconfig boots on legacy iSeries.
>
Thanks a million for reporting and testing. I've pushed the patch to Andrew.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Andrew Morton @ 2007-11-15 10:32 UTC (permalink / raw)
To: Mel Gorman; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
In-Reply-To: <20071115101322.GA5128@skynet.ie>
On Thu, 15 Nov 2007 10:13:22 +0000 mel@skynet.ie (Mel Gorman) wrote:
> This patch is a fix for 2.6.24.
>
> Ordinarily the size of a pageblock is determined at compile-time based on the
> hugepage size. On PPC64, the hugepage size is determined at runtime based on
> what is supported by the machine. With legacy machines such as iSeries that do
> not support hugepages, HPAGE_SHIFT becomes 0. This results in pageblock_order
> being set to -PAGE_SHIFT and a crash results shortly afterwards.
>
> This patch sets HUGETLB_PAGE_SIZE_VARIABLE for PPC64 and adds a function
> to select a sensible value for pageblock order by default. It checks that
> HPAGE_SHIFT is a sensible value before using the hugepage size; if it is
> not MAX_ORDER-1 is used.
>
> Credit goes to Stephen Rothwell for identifying the bug and testing candidate
> patches. Additional credit goes to Andy Whitcroft for spotting a problem
> with respects to IA-64 before releasing. Additional credit to David Gibson
> for testing with the libhugetlbfs test suite.
>
umm.
> +
> +/* Return a sensible default order for the pageblock size. */
> +static inline int __init pageblock_default_order(void)
inline and __init doesn't make sense.
> +{
> + if (HPAGE_SHIFT > PAGE_SHIFT)
> + return HUGETLB_PAGE_ORDER;
> +
> + return MAX_ORDER-1;
> +}
> +
> /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
> static inline void __init set_pageblock_order(unsigned int order)
> {
> @@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
> }
> #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
>
> -/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
> +#define pageblock_default_order(x) (0)
that won't compile.
> #define set_pageblock_order(x) do {} while (0)
>
> #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> @@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
> if (!size)
> continue;
>
> - set_pageblock_order(HUGETLB_PAGE_ORDER);
> + set_pageblock_order(pageblock_default_order());
> setup_usemap(pgdat, zone, size);
> ret = init_currently_empty_zone(zone, zone_start_pfn,
--- a/mm/page_alloc.c~fix-boot-problem-with-iseries-lacking-hugepage-support-fix
+++ a/mm/page_alloc.c
@@ -3268,7 +3268,7 @@ static void inline setup_usemap(struct p
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
/* Return a sensible default order for the pageblock size. */
-static inline int __init pageblock_default_order(void)
+static inline int pageblock_default_order(void)
{
if (HPAGE_SHIFT > PAGE_SHIFT)
return HUGETLB_PAGE_ORDER;
@@ -3291,7 +3291,11 @@ static inline void __init set_pageblock_
}
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
-#define pageblock_default_order(x) (0)
+static inline int pageblock_default_order(void)
+{
+ return 0;
+}
+
#define set_pageblock_order(x) do {} while (0)
#endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
_
please avoid adding macros when C could have been used. C is nicer to look
at and has typechecking and stuff.
^ permalink raw reply
* Re: [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Andrew Morton @ 2007-11-15 10:39 UTC (permalink / raw)
To: Mel Gorman; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
In-Reply-To: <20071115101322.GA5128@skynet.ie>
On Thu, 15 Nov 2007 10:13:22 +0000 mel@skynet.ie (Mel Gorman) wrote:
> This patch is a fix for 2.6.24.
>
> Ordinarily the size of a pageblock is determined at compile-time based on the
> hugepage size. On PPC64, the hugepage size is determined at runtime based on
> what is supported by the machine. With legacy machines such as iSeries that do
> not support hugepages, HPAGE_SHIFT becomes 0. This results in pageblock_order
> being set to -PAGE_SHIFT and a crash results shortly afterwards.
>
> This patch sets HUGETLB_PAGE_SIZE_VARIABLE for PPC64 and adds a function
> to select a sensible value for pageblock order by default. It checks that
> HPAGE_SHIFT is a sensible value before using the hugepage size; if it is
> not MAX_ORDER-1 is used.
>
> Credit goes to Stephen Rothwell for identifying the bug and testing candidate
> patches. Additional credit goes to Andy Whitcroft for spotting a problem
> with respects to IA-64 before releasing. Additional credit to David Gibson
> for testing with the libhugetlbfs test suite.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> ---
> arch/powerpc/Kconfig | 5 +++++
> mm/page_alloc.c | 14 ++++++++++++--
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig
> --- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig 2007-11-14 11:38:05.000000000 +0000
> +++ linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig 2007-11-14 11:39:12.000000000 +0000
> @@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
> default "9" if PPC_64K_PAGES
> default "13"
>
> +config HUGETLB_PAGE_SIZE_VARIABLE
> + bool
> + depends on HUGETLB_PAGE
> + default y
> +
> config MATH_EMULATION
> bool "Math emulation"
> depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c
> --- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c 2007-11-14 11:38:08.000000000 +0000
> +++ linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c 2007-11-14 13:45:19.000000000 +0000
> @@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
> #endif /* CONFIG_SPARSEMEM */
>
> #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> +
> +/* Return a sensible default order for the pageblock size. */
> +static inline int __init pageblock_default_order(void)
> +{
> + if (HPAGE_SHIFT > PAGE_SHIFT)
> + return HUGETLB_PAGE_ORDER;
> +
> + return MAX_ORDER-1;
> +}
> +
> /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
> static inline void __init set_pageblock_order(unsigned int order)
> {
> @@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
> }
> #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
>
> -/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
> +#define pageblock_default_order(x) (0)
Shouldn't this have been HUGETLB_PAGE_ORDER?
> #define set_pageblock_order(x) do {} while (0)
>
> #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> @@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
> if (!size)
> continue;
>
> - set_pageblock_order(HUGETLB_PAGE_ORDER);
> + set_pageblock_order(pageblock_default_order());
> setup_usemap(pgdat, zone, size);
> ret = init_currently_empty_zone(zone, zone_start_pfn,
> size, MEMMAP_EARLY);
> --
> --
> Mel Gorman
> Part-time Phd Student Linux Technology Center
> University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Mel Gorman @ 2007-11-15 10:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
In-Reply-To: <20071115023943.a54b0464.akpm@linux-foundation.org>
On (15/11/07 02:39), Andrew Morton didst pronounce:
> On Thu, 15 Nov 2007 10:13:22 +0000 mel@skynet.ie (Mel Gorman) wrote:
>
> > This patch is a fix for 2.6.24.
> >
> > Ordinarily the size of a pageblock is determined at compile-time based on the
> > hugepage size. On PPC64, the hugepage size is determined at runtime based on
> > what is supported by the machine. With legacy machines such as iSeries that do
> > not support hugepages, HPAGE_SHIFT becomes 0. This results in pageblock_order
> > being set to -PAGE_SHIFT and a crash results shortly afterwards.
> >
> > This patch sets HUGETLB_PAGE_SIZE_VARIABLE for PPC64 and adds a function
> > to select a sensible value for pageblock order by default. It checks that
> > HPAGE_SHIFT is a sensible value before using the hugepage size; if it is
> > not MAX_ORDER-1 is used.
> >
> > Credit goes to Stephen Rothwell for identifying the bug and testing candidate
> > patches. Additional credit goes to Andy Whitcroft for spotting a problem
> > with respects to IA-64 before releasing. Additional credit to David Gibson
> > for testing with the libhugetlbfs test suite.
> >
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > ---
> > arch/powerpc/Kconfig | 5 +++++
> > mm/page_alloc.c | 14 ++++++++++++--
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig
> > --- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig 2007-11-14 11:38:05.000000000 +0000
> > +++ linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig 2007-11-14 11:39:12.000000000 +0000
> > @@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
> > default "9" if PPC_64K_PAGES
> > default "13"
> >
> > +config HUGETLB_PAGE_SIZE_VARIABLE
> > + bool
> > + depends on HUGETLB_PAGE
> > + default y
> > +
> > config MATH_EMULATION
> > bool "Math emulation"
> > depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c
> > --- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c 2007-11-14 11:38:08.000000000 +0000
> > +++ linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c 2007-11-14 13:45:19.000000000 +0000
> > @@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
> > #endif /* CONFIG_SPARSEMEM */
> >
> > #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> > +
> > +/* Return a sensible default order for the pageblock size. */
> > +static inline int __init pageblock_default_order(void)
> > +{
> > + if (HPAGE_SHIFT > PAGE_SHIFT)
> > + return HUGETLB_PAGE_ORDER;
> > +
> > + return MAX_ORDER-1;
> > +}
> > +
> > /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
> > static inline void __init set_pageblock_order(unsigned int order)
> > {
> > @@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
> > }
> > #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> >
> > -/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
> > +#define pageblock_default_order(x) (0)
>
> Shouldn't this have been HUGETLB_PAGE_ORDER?
>
As a #define, possibly but as a static inline - definitly not.
In this context, the define is not used because set_pageblock_order()
is a no-op when CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is unset.
pageblock_default_order() is only defined for symmetry as set_pageblock_order()
is defined in both contexts. However, as a #define it might make more sense
to a casual reader to see HUGETLB_PAGE_ORDER even if it has no effect. I
can send a version of the patch that does this with a comment explaining
what is going on with set_pageblock_order() if you like.
However, in a follow-up fix, you make pageblock_default_order() a static
inline. If it tries to return HUGETLB_PAGE_ORDER, it will fail to compile
when CONFIG_HUGETLB_PAGE is not set.
Which would you prefer?
> > #define set_pageblock_order(x) do {} while (0)
> >
> > #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> > @@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
> > if (!size)
> > continue;
> >
> > - set_pageblock_order(HUGETLB_PAGE_ORDER);
> > + set_pageblock_order(pageblock_default_order());
> > setup_usemap(pgdat, zone, size);
> > ret = init_currently_empty_zone(zone, zone_start_pfn,
> > size, MEMMAP_EARLY);
> > --
> > --
> > Mel Gorman
> > Part-time Phd Student Linux Technology Center
> > University of Limerick IBM Dublin Software Lab
>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH 0/2] PS3 patches for 2.6.24
From: Geert Uytterhoeven @ 2007-11-15 10:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 938 bytes --]
Hi Andrew,
Here are 2 more patches for PS3 we would like to get in 2.6.24:
[1] ps3: Prefix all ps3-specific kernel modules with `ps3'
[2] ps3fb: video memory size cleanups
The first one fixes 2 PS3-specific modules having generic names.
The second one fixes a possible system lock up.
Please apply and forward to Linus, thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Andrew Morton @ 2007-11-15 10:59 UTC (permalink / raw)
To: Mel Gorman; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
In-Reply-To: <20071115105237.GD5128@skynet.ie>
On Thu, 15 Nov 2007 10:52:38 +0000 mel@skynet.ie (Mel Gorman) wrote:
> > Shouldn't this have been HUGETLB_PAGE_ORDER?
> >
>
> As a #define, possibly but as a static inline - definitly not.
>
> In this context, the define is not used because set_pageblock_order()
> is a no-op when CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is unset.
> pageblock_default_order() is only defined for symmetry as set_pageblock_order()
> is defined in both contexts. However, as a #define it might make more sense
> to a casual reader to see HUGETLB_PAGE_ORDER even if it has no effect. I
> can send a version of the patch that does this with a comment explaining
> what is going on with set_pageblock_order() if you like.
>
> However, in a follow-up fix, you make pageblock_default_order() a static
> inline. If it tries to return HUGETLB_PAGE_ORDER, it will fail to compile
> when CONFIG_HUGETLB_PAGE is not set.
>
> Which would you prefer?
Don't care really. Something which is fixed up ;)
^ permalink raw reply
* Re: [PATCH] Fix boot problem with iSeries lacking hugepage support
From: Mel Gorman @ 2007-11-15 11:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linuxppc-dev, linux-kernel, sfr
In-Reply-To: <20071115023216.44002c28.akpm@linux-foundation.org>
On (15/11/07 02:32), Andrew Morton didst pronounce:
> On Thu, 15 Nov 2007 10:13:22 +0000 mel@skynet.ie (Mel Gorman) wrote:
>
> > This patch is a fix for 2.6.24.
> >
> > Ordinarily the size of a pageblock is determined at compile-time based on the
> > hugepage size. On PPC64, the hugepage size is determined at runtime based on
> > what is supported by the machine. With legacy machines such as iSeries that do
> > not support hugepages, HPAGE_SHIFT becomes 0. This results in pageblock_order
> > being set to -PAGE_SHIFT and a crash results shortly afterwards.
> >
> > This patch sets HUGETLB_PAGE_SIZE_VARIABLE for PPC64 and adds a function
> > to select a sensible value for pageblock order by default. It checks that
> > HPAGE_SHIFT is a sensible value before using the hugepage size; if it is
> > not MAX_ORDER-1 is used.
> >
> > Credit goes to Stephen Rothwell for identifying the bug and testing candidate
> > patches. Additional credit goes to Andy Whitcroft for spotting a problem
> > with respects to IA-64 before releasing. Additional credit to David Gibson
> > for testing with the libhugetlbfs test suite.
> >
>
> umm.
>
> > +
> > +/* Return a sensible default order for the pageblock size. */
> > +static inline int __init pageblock_default_order(void)
>
> inline and __init doesn't make sense.
>
I know the __init is meaningless in this context. It is there as a guide
if someone decides to drop the inline for some reason that it should
remain as __init. I can post a version with just the inline.
> > +{
> > + if (HPAGE_SHIFT > PAGE_SHIFT)
> > + return HUGETLB_PAGE_ORDER;
> > +
> > + return MAX_ORDER-1;
> > +}
> > +
> > /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
> > static inline void __init set_pageblock_order(unsigned int order)
> > {
> > @@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
> > }
> > #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> >
> > -/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
> > +#define pageblock_default_order(x) (0)
>
> that won't compile.
>
It's never used so it could have been anything and still compiled. I admit
this is confusing. I've posted a version below that changes this to a static
inline, returns MAX_ORDER-1 which is a sensible value even if unused and
comments on what is happening.
> > #define set_pageblock_order(x) do {} while (0)
> >
> > #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> > @@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
> > if (!size)
> > continue;
> >
> > - set_pageblock_order(HUGETLB_PAGE_ORDER);
> > + set_pageblock_order(pageblock_default_order());
> > setup_usemap(pgdat, zone, size);
> > ret = init_currently_empty_zone(zone, zone_start_pfn,
>
>
> --- a/mm/page_alloc.c~fix-boot-problem-with-iseries-lacking-hugepage-support-fix
> +++ a/mm/page_alloc.c
> @@ -3268,7 +3268,7 @@ static void inline setup_usemap(struct p
> #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
>
> /* Return a sensible default order for the pageblock size. */
> -static inline int __init pageblock_default_order(void)
> +static inline int pageblock_default_order(void)
> {
> if (HPAGE_SHIFT > PAGE_SHIFT)
> return HUGETLB_PAGE_ORDER;
> @@ -3291,7 +3291,11 @@ static inline void __init set_pageblock_
> }
> #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
>
> -#define pageblock_default_order(x) (0)
> +static inline int pageblock_default_order(void)
> +{
> + return 0;
> +}
> +
> #define set_pageblock_order(x) do {} while (0)
>
> #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> _
>
>
> please avoid adding macros when C could have been used. C is nicer to look
> at and has typechecking and stuff.
>
Understood. Here is an updated version. It is functionally equivilant to
the earlier patch but may be easier on the eye
===
Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that
do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
being set to -PAGE_SHIFT and a crash results shortly afterwards.
This patch adds a function to select a sensible value for pageblock order by
default when HUGETLB_PAGE_SIZE_VARIABLE is set. It checks that HPAGE_SHIFT
is a sensible value before using the hugepage size; if it is not MAX_ORDER-1
is used.
This is a fix for 2.6.24.
Credit goes to Stephen Rothwell for identifying the bug and testing candidate
patches. Additional credit goes to Andy Whitcroft for spotting a problem
with respects to IA-64 before releasing. Additional credit to David Gibson
for testing with the libhugetlbfs test suite.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 5 +++++
mm/page_alloc.c | 23 +++++++++++++++++++++--
2 files changed, 26 insertions(+), 2 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig linux-2.6.24-rc2-mm1-varpage-fix/arch/powerpc/Kconfig
--- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig 2007-11-14 11:38:05.000000000 +0000
+++ linux-2.6.24-rc2-mm1-varpage-fix/arch/powerpc/Kconfig 2007-11-15 10:44:38.000000000 +0000
@@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
default "9" if PPC_64K_PAGES
default "13"
+config HUGETLB_PAGE_SIZE_VARIABLE
+ bool
+ depends on HUGETLB_PAGE
+ default y
+
config MATH_EMULATION
bool "Math emulation"
depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c linux-2.6.24-rc2-mm1-varpage-fix/mm/page_alloc.c
--- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c 2007-11-14 11:38:08.000000000 +0000
+++ linux-2.6.24-rc2-mm1-varpage-fix/mm/page_alloc.c 2007-11-15 11:01:13.000000000 +0000
@@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
#endif /* CONFIG_SPARSEMEM */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
+
+/* Return a sensible default order for the pageblock size. */
+static inline int pageblock_default_order(void)
+{
+ if (HPAGE_SHIFT > PAGE_SHIFT)
+ return HUGETLB_PAGE_ORDER;
+
+ return MAX_ORDER-1;
+}
+
/* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
static inline void __init set_pageblock_order(unsigned int order)
{
@@ -3357,7 +3367,16 @@ static inline void __init set_pageblock_
}
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
-/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
+/*
+ * When CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is not set, set_pageblock_order()
+ * and pageblock_default_order() are unused as pageblock_order is set
+ * at compile-time. See include/linux/pageblock-flags.h for the values of
+ * pageblock_order based on the kernel config
+ */
+static inline int pageblock_default_order(unsigned int order)
+{
+ return MAX_ORDER-1;
+}
#define set_pageblock_order(x) do {} while (0)
#endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
@@ -3442,7 +3461,7 @@ static void __meminit free_area_init_cor
if (!size)
continue;
- set_pageblock_order(HUGETLB_PAGE_ORDER);
+ set_pageblock_order(pageblock_default_order());
setup_usemap(pgdat, zone, size);
ret = init_currently_empty_zone(zone, zone_start_pfn,
size, MEMMAP_EARLY);
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-15 11:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071115102149.898061fb.sfr@canb.auug.org.au>
Hi Stephen,
Stephen Rothwell wrote:
>
> On Wed, 14 Nov 2007 11:21:37 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +#include <asm/time.h>
>> +#include <asm/machdep.h>
>> +#include <asm/mpc52xx.h>
>
> You still need asm/prom.h because you use of_get_flat_dt_root() and
> of_flat_dt_is_compatible().
>
>> +/* list of the supported boards */
>> +static const char *board[] __initdata = {
>
> Unfortunately you can't use "const" and "__initdata", so just remove the
> "const". (const changes the attributes on the section that __initdata is
> stored in.)
Arghh, too much of a hurry it seems, thanks for catching it.
Cheers,
m.
^ permalink raw reply
* [PATCH v6 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-15 11:40 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' property is present in one of the
gpt nodes, then it is safe to use such gpt to reset the board,
- PCI is supported if enabled in the kernel configuration
and if there is a PCI bus node defined in the device tree.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
Once more, this is a updated version of the patch 04/13 from
the patchset that adds arch/powerpc support for three MPC5200 based boards:
TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO.
Thanks to Stephen Rothwell for catching inconsistencies that
sneaked in.
Cheers,
Marian Balakowicz
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/platforms/52xx/Kconfig | 22 ++++++-
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc5200_simple.c | 85 ++++++++++++++++++++++++++
5 files changed, 108 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 6731763..5902362 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200","generic-mpc5200";
+ compatible = "fsl,lite5200";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index b540388..b509129 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b","generic-mpc5200";
+ compatible = "fsl,lite5200b";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..36e880b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,26 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_SIMPLE
+ bool "Generic support for simple MPC5200 based boards"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select PPC_MPC5200
+ default n
+ help
+ This option enables support for a simple MPC52xx based boards which
+ do not need a custom platform specific setup. Such boards are
+ supported assuming the following:
+
+ - GPIO pins are configured by the firmware,
+ - CDM configuration (clocking) is setup correctly by firmware,
+ - if the 'fsl,has-wdt' property is present in one of the
+ gpt nodes, then it is safe to use such gpt to reset the board,
+ - PCI is supported if enabled in the kernel configuration
+ and if there is a PCI bus node defined in the device tree.
+
+ Boards that are compatible with this generic platform support
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
@@ -34,5 +54,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..fe1b81b 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
new file mode 100644
index 0000000..754aa93
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -0,0 +1,85 @@
+/*
+ * Support for 'mpc5200-simple-platform' compatible boards.
+ *
+ * Written by Marian Balakowicz <m8@semihalf.com>
+ * Copyright (C) 2007 Semihalf
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Description:
+ * This code implements support for a simple MPC52xx based boards which
+ * do not need a custom platform specific setup. Such boards are
+ * supported assuming the following:
+ *
+ * - GPIO pins are configured by the firmware,
+ * - CDM configuration (clocking) is setup correctly by firmware,
+ * - if the 'fsl,has-wdt' property is present in one of the
+ * gpt nodes, then it is safe to use such gpt to reset the board,
+ * - PCI is supported if enabled in the kernel configuration
+ * and if there is a PCI bus node defined in the device tree.
+ *
+ * Boards that are compatible with this generic platform support
+ * are listed in a 'board' table.
+ */
+
+#undef DEBUG
+#include <asm/time.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/mpc52xx.h>
+
+/*
+ * Setup the architecture
+ */
+static void __init mpc5200_simple_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+
+ /* Some mpc5200 & mpc5200b related configuration */
+ mpc5200_setup_xlb_arbiter();
+
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
+ mpc52xx_setup_pci();
+}
+
+/* list of the supported boards */
+static char *board[] __initdata = {
+ "promess,motionpro",
+ "schindler,cm5200",
+ "tqc,tqm5200",
+ NULL
+};
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+
+ return (board[i] != NULL);
+}
+
+define_machine(mpc5200_simple_platform) {
+ .name = "mpc5200-simple-platform",
+ .probe = mpc5200_simple_probe,
+ .setup_arch = mpc5200_simple_setup_arch,
+ .init = mpc52xx_declare_of_platform_devices,
+ .init_IRQ = mpc52xx_init_irq,
+ .get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply related
* Re: [PATCH 2/2] ps3fb: video memory size cleanups
From: Geert Uytterhoeven @ 2007-11-15 12:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0711151152290.19455@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2268 bytes --]
ps3fb: video memory size cleanups:
- Limit video memory size to avoid crossing a 256 MiB boundary in IOIF space.
- Pass the actual amount of video memory used to lv1_gpu_memory_allocate().
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
FIXME Booting with `ps3fb=49M' should work now. Except that on recent
kernels the system goes out of memory before you get there :-(
drivers/video/ps3fb.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -51,7 +51,6 @@
#define L1GPU_DISPLAY_SYNC_HSYNC 1
#define L1GPU_DISPLAY_SYNC_VSYNC 2
-#define DDR_SIZE (0) /* used no ddr */
#define GPU_CMD_BUF_SIZE (64 * 1024)
#define GPU_IOIF (0x0d000000UL)
#define GPU_ALIGN_UP(x) _ALIGN_UP((x), 64)
@@ -1060,6 +1059,7 @@ static int __devinit ps3fb_probe(struct
u64 xdr_lpar;
int status, res_index;
struct task_struct *task;
+ unsigned long max_ps3fb_size;
status = ps3_open_hv_device(dev);
if (status) {
@@ -1085,8 +1085,15 @@ static int __devinit ps3fb_probe(struct
ps3fb_set_sync(&dev->core);
+ max_ps3fb_size = _ALIGN_UP(GPU_IOIF, 256*1024*1024) - GPU_IOIF;
+ if (ps3fb_videomemory.size > max_ps3fb_size) {
+ dev_info(&dev->core, "Limiting ps3fb mem size to %lu bytes\n",
+ max_ps3fb_size);
+ ps3fb_videomemory.size = max_ps3fb_size;
+ }
+
/* get gpu context handle */
- status = lv1_gpu_memory_allocate(DDR_SIZE, 0, 0, 0, 0,
+ status = lv1_gpu_memory_allocate(ps3fb_videomemory.size, 0, 0, 0, 0,
&ps3fb.memory_handle, &ddr_lpar);
if (status) {
dev_err(&dev->core, "%s: lv1_gpu_memory_allocate failed: %d\n",
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* /sbin/init: error while loading shared libraries: libm.so.6:cannot open shared object file: No such file or directory [Scanned]
From: Lindner @ 2007-11-15 12:24 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a problem with booting the uRamdisk image from eldk 4.1 on an
TQM5200 (MPC5200 CPU) board.
I have taken the uRamdisk image from the "/eldk/ppc_6xx/images" folder
and copied it to the flash. After booting the following output came
after the Kernel boot:
Freeing unused kernel memory: 64k init
/sbin/init: error while loading shared libraries: libm.so.6: cannot open
shared object file: No such file or directory
Kernel panic: Attempted to kill init!
<0>Rebooting in 1 seconds..
An image from eldk 3.1.1 is working fine with the Kernel 2.4.25.
The files libm.so.6 and libm-2.3.5.so are available in the /lib folder.
Does anyone has an idea, what this could be?
Thanks,
Michael
^ permalink raw reply
* Re: /sbin/init: error while loading shared libraries: libm.so.6:cannot open shared object file: No such file or directory [Scanned]
From: S. Fricke @ 2007-11-15 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1195129440.10980.7.camel@linux-2drc.site>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hello,
> I have a problem with booting the uRamdisk image from eldk 4.1 on an
> TQM5200 (MPC5200 CPU) board.
> I have taken the uRamdisk image from the "/eldk/ppc_6xx/images" folder
> and copied it to the flash. After booting the following output came
> after the Kernel boot:
>
> Freeing unused kernel memory: 64k init
> /sbin/init: error while loading shared libraries: libm.so.6: cannot open
> shared object file: No such file or directory
> Kernel panic: Attempted to kill init!
> <0>Rebooting in 1 seconds..
>
>
> An image from eldk 3.1.1 is working fine with the Kernel 2.4.25.
> The files libm.so.6 and libm-2.3.5.so are available in the /lib folder.
>
> Does anyone has an idea, what this could be?
This is a problem of handling the eldk. Please contact the eldk-ml on [1].
[1] http://lists.denx.de/mailman/listinfo/eldk
Bye!
eS.eF.
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: silvio@jabber.ccc.de
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ps3: Prefix all ps3-specific kernel modules with `ps3-'
From: Geert Uytterhoeven @ 2007-11-15 12:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0711151152290.19455@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1492 bytes --]
ps3: Prefix ps3-specific kernel modules with `ps3-':
- vuart.ko -> ps3-vuart.ko
- sys-manager.ko -> ps3-sys-manager.ko
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
As the patch was too big for linuxppc-dev, here's an alternative using `mv'
drivers/ps3/Makefile | 4
5 files changed, 1975 insertions(+), 1975 deletions(-)
mv drivers/ps3/sys-manager.c drivers/ps3/ps3-sys-manager.c
mv drivers/ps3/vuart.c drivers/ps3/ps3-vuart.c
--- a/drivers/ps3/Makefile
+++ b/drivers/ps3/Makefile
@@ -1,6 +1,6 @@
-obj-$(CONFIG_PS3_VUART) += vuart.o
+obj-$(CONFIG_PS3_VUART) += ps3-vuart.o
obj-$(CONFIG_PS3_PS3AV) += ps3av_mod.o
ps3av_mod-objs += ps3av.o ps3av_cmd.o
obj-$(CONFIG_PPC_PS3) += sys-manager-core.o
-obj-$(CONFIG_PS3_SYS_MANAGER) += sys-manager.o
+obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o
obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* MPC5200B: Linux does not recognise the external PCI card
From: Juergen Beisert @ 2007-11-15 13:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
currently I'm trying to activate the PCI bus of my MPC5200B based card. U-Boot
outputs:
[...]
PCI: Bus Dev VenId DevId Class Int
00 18 1033 0035 0c03 00
00 18 1033 0035 0c03 00
00 18 1033 00e0 00e0 00
00 1a 1057 5809 0680 00
[...]
When I start Linux it outputs:
[...]
PCI: Probing PCI hardware
PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
mpc52xx_pci_fixup_resources() 1057:5809
[...]
and does not show the external card:
# lspci -v
00:1a.0 Bridge: Motorola Unknown device 5809
Flags: bus master, 66MHz, medium devsel, latency 248
Memory at a0000000 (32-bit, non-prefetchable) [size=256K]
Memory at <unassigned> (32-bit, prefetchable)
Any idea what could cause this behavior?
Could this be an oftree related issue? Or something hardware only related?
The external slot is of 3.3V only type, running at 33 1/3 MHz.
If it is an oftree issue, can someone point me to some kind of documentation,
what data I must provide in the
pci@0d00 {
....
}
section?
Juergen
^ permalink raw reply
* Kexec on powerpc
From: marco.stornelli @ 2007-11-15 13:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm using the latest kernel and I need the kexec support for 85xx
processor. When I use the menuconfig with ARCH=ppc and the 85xx and
e500 support, I have the kexec support, but when I use ARCH=powerpc I
haven't it, but I'm selecting the same processor!! Is it a bug in
kconfig? Somebody can explain to me why?
Thanks in advance.
Marco
^ permalink raw reply
* RE: MPC5200B: Linux does not recognise the external PCI card
From: Pedro Luis D. L. @ 2007-11-15 13:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711151430.05943.jbe@pengutronix.de>
> From: jbe@pengutronix.de
> To: linuxppc-embedded@ozlabs.org
> Date: Thu, 15 Nov 2007 14:30:05 +0100
> Subject: MPC5200B: Linux does not recognise the external PCI card
>=20
> Hi,
Hello,
> currently I'm trying to activate the PCI bus of my MPC5200B based card. U=
-Boot=20
> outputs:
>=20
> [...]
> PCI: Bus Dev VenId DevId Class Int
> 00 18 1033 0035 0c03 00
> 00 18 1033 0035 0c03 00
> 00 18 1033 00e0 00e0 00
> 00 1a 1057 5809 0680 00
> [...]
>=20
> When I start Linux it outputs:
>=20
> [...]
> PCI: Probing PCI hardware
> PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
> mpc52xx_pci_fixup_resources() 1057:5809
> [...]
>=20
> and does not show the external card:
Which card? Is its driver supported by the kernel? Is it enabled inside the=
kernel image?
Did you add the PCI bridge in platform configuration file? I suppose so if =
there is a PCI probing test.
I added an external ethernet device and had no problem to made it work with=
2.6.22 kernel.
Pedro.
> # lspci -v
> 00:1a.0 Bridge: Motorola Unknown device 5809
> Flags: bus master, 66MHz, medium devsel, latency 248
> Memory at a0000000 (32-bit, non-prefetchable) [size=3D256K]
> Memory at (32-bit, prefetchable)
>=20
> Any idea what could cause this behavior?
> Could this be an oftree related issue? Or something hardware only related=
?
> The external slot is of 3.3V only type, running at 33 1/3 MHz.
>=20
> If it is an oftree issue, can someone point me to some kind of documentat=
ion,=20
> what data I must provide in the
> pci@0d00 {
> ....
> }
> section?
>=20
> Juergen
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=
^ permalink raw reply
* Re: MPC5200B: Linux does not recognise the external PCI card
From: Juergen Beisert @ 2007-11-15 14:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BLU106-W38B9242918AC024D3BEBB6CA820@phx.gbl>
On Thursday 15 November 2007 14:49, Pedro Luis D. L. wrote:
> > [...]
> > PCI: Probing PCI hardware
> > PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
> > mpc52xx_pci_fixup_resources() 1057:5809
> > [...]
> >
> > and does not show the external card:
>
> Which card?
Its a NEC USB 2.0 card.
> Is its driver supported by the kernel?
I think so.
> Is it enabled inside the kernel image?
But until the card gets recognised it makes no sense to play with the driver.
> Did you add the PCI bridge in platform configuration file? I
> suppose so if there is a PCI probing test. I added an external ethernet
> device and had no problem to made it work with 2.6.22 kernel.
My kernel is a 2.6.23.1
Juergen
^ permalink raw reply
* RE: MPC5200B: Linux does not recognise the external PCI card
From: Pedro Luis D. L. @ 2007-11-15 14:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711151521.43047.jbe@pengutronix.de>
------------------------------------------------------------------ Todas mi=
s chorradas alemanas en: http://carcadiz.blogspot.com ---------------------=
---------------------------------------------
----------------------------------------
> From: jbe@pengutronix.de
> To: linuxppc-embedded@ozlabs.org
> Date: Thu, 15 Nov 2007 15:21:41 +0100
> CC: carcadiz@hotmail.com
> Subject: Re: MPC5200B: Linux does not recognise the external PCI card
>=20
> On Thursday 15 November 2007 14:49, Pedro Luis D. L. wrote:
>>> [...]
>>> PCI: Probing PCI hardware
>>> PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
>>> mpc52xx_pci_fixup_resources() 1057:5809
>>> [...]
>>>
>>> and does not show the external card:
>>
>> Which card?
>=20
> Its a NEC USB 2.0 card.
>=20
>> Is its driver supported by the kernel?
>=20
> I think so.
>=20
>> Is it enabled inside the kernel image?
>=20
> But until the card gets recognised it makes no sense to play with the dri=
ver.
Does it? It looks to me that the kernel detects an attached device to the P=
CI interface, but doesn't know wich one.
May that be the reason why it says "PCI: device 0000:00:18.0 has unknown he=
ader type 7f, ignoring."?
>> Did you add the PCI bridge in platform configuration file? I
>> suppose so if there is a PCI probing test. I added an external ethernet
>> device and had no problem to made it work with 2.6.22 kernel.
>=20
> My kernel is a 2.6.23.1
>=20
> Juergen
Pedro.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=
^ permalink raw reply
* Virtex TEMAC ping -s 10000 host, is it working?
From: alex_snippet @ 2007-11-15 15:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi All!
On Virtex 4FX board with TEMAC core, Linux ping working fine, but if s -
parameter set to big values it freezes for ever...
Colleagues please share your experience with ping -s 10000 host.
Do you know what parameters in core or in Linux kernel must be changed to
improve it.
My customer is too hypercritical, he likes to ping :(
I tried to increase LX/TX buffers in core, it increased dead line but there
is no desirable result.
--
View this message in context: http://www.nabble.com/Virtex-TEMAC-ping--s-10000-host%2C-is-it-working--tf4812989.html#a13770288
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* kernel update on mpc8248 muram definition?
From: Alan Bennett @ 2007-11-15 15:43 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5063 bytes --]
Hello;
While working on i2c support, I've decided to update to a new kernel. In
the process of doing this, I'm not sure I've properly configured the MURAM
node to my device tree (i.e. serial is broken again). Also, does this, in
any way, change the way I offset the early debug transmit descriptor
address?
I tried looking at your cpm tree on git.buserror.net, but it seems you've
taken it down?
-Alan
soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8248", "fsl,pq2-soc";
ranges = <00000000 e0000000 00053000>;
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = <e0000000 00053000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8248-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d000000>;
};
/* "Serial" port/SCC1 */
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
/* "Serial" port/SCC4 */
serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2B 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0CE00000>;
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
usb@11b60 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8248-usb",
"fsl,cpm2-usb";
reg = <11b60 18 8b00 100>;
interrupt-parent = <&PIC>;
interrupts = <b 8>;
fsl,cpm-command = <2e600000>;
};
i2c@11860 {
compatible = "fsl,mpc8248-i2c",
"fsl,cpm2-i2c",
"fsl,cpm-i2c";
reg = <11860 20 3c80 30>;
interrupts = <1>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <0010>;
};
};
[-- Attachment #2: Type: text/html, Size: 16181 bytes --]
^ permalink raw reply
* [PATCH] remove dead MAC_ADBKEYCODES
From: Stanislav Brabec @ 2007-11-15 15:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linuxppc-dev
It seems, that current kernel source code contains no traces of
MAC_ADBKEYCODES and no reference to keyboard_sends_linux_keycodes any
more.
Attached patch removes them from configuration files.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -582,20 +582,6 @@ config MAC_HID
depends on INPUT_ADBHID
default y
-config MAC_ADBKEYCODES
- bool "Support for ADB raw keycodes"
- depends on INPUT_ADBHID
- help
- This provides support for sending raw ADB keycodes to console
- devices. This is the default up to 2.4.0, but in future this may be
- phased out in favor of generic Linux keycodes. If you say Y here,
- you can dynamically switch via the
- /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
- sysctl and with the "keyboard_sends_linux_keycodes=" kernel
- argument.
-
- If unsure, say Y here.
-
config ADB_KEYBOARD
bool "Support for ADB keyboard (old driver)"
depends on MAC && !INPUT_ADBHID
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -678,7 +678,6 @@ CONFIG_LOGO_MAC_CLUT224=y
#
CONFIG_MAC_SCC=y
CONFIG_MAC_HID=y
-CONFIG_MAC_ADBKEYCODES=y
CONFIG_SERIAL_CONSOLE=y
#
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
^ permalink raw reply
* Re: 2.6.24-rc1 on PPC64: machine check exception
From: Vaidyanathan Srinivasan @ 2007-11-15 17:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc, lkml
In-Reply-To: <472F5C5E.4030607@linux.vnet.ibm.com>
>
>> http://patchwork.ozlabs.org/linuxppc/patch?id=14475
>
> Thanks for pointing me to this patch. I will try out and let you know if
> this fixed the problem.
Hi Anton,
This patch fixed the problem. I am able to run and profile ebizzy on 128-way
PPC64. However this fix is not included in 2.6.24-rc2 as well.
I will watch for inclusion of this fix in 2.6.24.
--Vaidy
^ permalink raw reply
* Latest paulus.git PCI broken on mpc8540?
From: Clemens Koller @ 2007-11-15 17:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi there!
I try to use the latest Linux-2.6.24-rc2-ge6a5c27f from paulus.git
for my mpc8540ads compatible board.
$ dmesg contains some nasty messages, which look like something is wrong.
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:12.0
PCI: Cannot allocate resource region 1 of device 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.0
PCI: Cannot allocate resource region 3 of device 0000:00:12.0
PCI: Cannot allocate resource region 4 of device 0000:00:12.0
PCI: Cannot allocate resource region 0 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000:00:14.0
However, the PCI devices just work fine - machine boots and:
$ lspci -vv
00:12.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85)
Subsystem: Promise Technology, Inc. Ultra133TX2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <-
Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 1000 [size=8]
Region 1: I/O ports at 1008 [size=4]
Region 2: I/O ports at 1010 [size=8]
Region 3: I/O ports at 100c [size=4]
Region 4: I/O ports at 1020 [size=16]
Region 5: Memory at 80000000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 000dc000 [disabled] [size=16K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pata_pdc2027x
00:14.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR--
Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 1080 [size=128]
Region 2: I/O ports at 1400 [size=256]
Region 3: Memory at 80004000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 80020000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 00080000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: sata_promise
Hmm...
I suspect a wrong kernel config or problems with the device tree
(I'm using an unchanged arch/powerpc/boot/dts/mpc8540ads.dts).
My .config is based on the mpc8540_ads_defconfig was attached:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071114/2567627a/attachment-0001.txt
Any ideas?
Thank you,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: kernel update on mpc8248 muram definition?
From: Scott Wood @ 2007-11-15 17:30 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711150743t440298cfsbce6f10b6fa39d73@mail.gmail.com>
Alan Bennett wrote:
> While working on i2c support, I've decided to update to a new kernel.
> In the process of doing this, I'm not sure I've properly configured the
> MURAM node to my device tree (i.e. serial is broken again).
You haven't -- you copied muram/data/reg from some other tree, rather
than from resource 2 of cpm/reg in your old tree.
> Also, does
> this, in any way, change the way I offset the early debug transmit
> descriptor address?
No.
> muram@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 10000>;
>
> data@0 {
> compatible = "fsl,cpm-muram-data";
> reg = <0 2000 9800 800>;
> };
> };
muram/data/reg should be <80 1f80 9800 800> for your board.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox