* Re: [PATCH] [POWERPC] vdso: Fixes for cache line sizes
From: Benjamin Herrenschmidt @ 2007-11-14 20:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: dwmw2, paulus, linuxppc-dev
In-Reply-To: <20071114192405.GA1637@lixom.net>
On Wed, 2007-11-14 at 13:24 -0600, Olof Johansson wrote:
> [POWERPC] vdso: Fixes for cache line sizes
>
> Current VDSO implementation is hardcoded to 128 byte cachelines, which
> only works on IBM's 64-bit processors.
>
> Convert it to get the line sizes out of vdso_data instead, similar to
> how the ppc64 in-kernel cache flush does it.
Please call the fields "block size" not "line size". There are subtle
differences and per architecture, it should really be block size.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> ---
> Paul, this is needed to make for example the IBM jvm run on pa6t. Please
> include as bugfix for 2.6.24.
Heh, they use the vdso for flushes ? I didn't know that !
Ben.
^ permalink raw reply
* [PATCH v2] pci hotplug: fix rpaphp directory naming
From: Linas Vepstas @ 2007-11-14 20:31 UTC (permalink / raw)
To: Greg KH
Cc: rick.jones2, pcihpd-discuss, Alex Chiang, Matthew Wilcox, gregkh,
linux-kernel, linuxppc-dev, linux-acpi, Kristen Carlson Accardi,
linux-pci, strosake, lenb
In-Reply-To: <20071114032607.GA22438@kroah.com>
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
------
On Tue, Nov 13, 2007 at 07:26:07PM -0800, Greg KH wrote:
> We need a signed-off-by: to be able to apply this...
Whoops. See above. Same patch as list time, no changes.
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> > /sys/bus/pci/slots
> > /sys/bus/pci/slots/control
> > /sys/bus/pci/slots/control/remove_slot
> > /sys/bus/pci/slots/control/add_slot
> > /sys/bus/pci/slots/0001:00:02.0
> > /sys/bus/pci/slots/0001:00:02.0/phy_location
>
> Ugh. Almost two years ago, paulus promised me he was going to fix the
> slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
> This is one of the hateful things about the current design -- hotplug
> drivers do too much. Instead of being just the interface between the
> Linux PCI code and the hardware, they create sysfs directories, add
> files,
> and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
> We have four different schemes currently for naming in slots/,
> 1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
> 2. domain:bus:dev:fn. Used by fakephp.
> 3a. domain:bus:dev. Used by rpaphp and sgihp.
> 3b. Except that rpaphp uses phy_location to present the information
> that
> should be in the name and sgihp uses path.
>
> ... I've forgotten what cpci uses. And yenta doesn't use it.
>
> How is anyone supposed to write sane managability tools in the
> presence
> of such anarchy?
>
> > ~ # cat /sys/bus/pci/slots/0000:00:02.2/phy_location
> > U787A.001.DNZ00Z5-P1-C2
>
> Right. This should look like:
>
> # cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
> 0000:00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h | 1
drivers/pci/hotplug/rpaphp_pci.c | 14 -----------
drivers/pci/hotplug/rpaphp_slot.c | 47 +++++++++++++++++++-------------------
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 17:52:10.000000000 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *bridge;
-
- bridge = bus->self;
- if (bridge)
- strcpy(slot->name, pci_name(bridge));
- else
- sprintf(slot->name, "%04x:%02x:00.0", pci_domain_nr(bus),
- bus->number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
slot->pci_devs = &bus->devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13 18:05:13.000000000 -0600
@@ -33,23 +33,31 @@
#include <asm/rtas.h>
#include "rpaphp.h"
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot->private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot->location;
- retval = sprintf (buf, "%s\n", value);
+ bus = slot->bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus->self)
+ retval = sprintf(buf, pci_name(bus->self));
+ else
+ retval = sprintf(buf, "%04x:%02x:00.0",
+ pci_domain_nr(bus), bus->number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = "phy_location", .mode = S_IFREG | S_IRUGO},
- .show = location_read_file,
+static struct hotplug_slot_attribute php_attr_address = {
+ .attr = {.name = "address", .mode = S_IFREG | S_IRUGO},
+ .show = address_read_file,
};
/* free up the memory used by a slot */
@@ -64,7 +72,6 @@ void dealloc_slot_struct(struct slot *sl
kfree(slot->hotplug_slot->info);
kfree(slot->hotplug_slot->name);
kfree(slot->hotplug_slot);
- kfree(slot->location);
kfree(slot);
}
@@ -83,16 +90,13 @@ struct slot *alloc_slot_struct(struct de
GFP_KERNEL);
if (!slot->hotplug_slot->info)
goto error_hpslot;
- slot->hotplug_slot->name = kmalloc(BUS_ID_SIZE + 1, GFP_KERNEL);
+ slot->hotplug_slot->name = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
if (!slot->hotplug_slot->name)
goto error_info;
- slot->location = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
- if (!slot->location)
- goto error_name;
slot->name = slot->hotplug_slot->name;
+ strcpy(slot->name, drc_name);
slot->dn = dn;
slot->index = drc_index;
- strcpy(slot->location, drc_name);
slot->power_domain = power_domain;
slot->hotplug_slot->private = slot;
slot->hotplug_slot->ops = &rpaphp_hotplug_slot_ops;
@@ -100,8 +104,6 @@ struct slot *alloc_slot_struct(struct de
return (slot);
-error_name:
- kfree(slot->hotplug_slot->name);
error_info:
kfree(slot->hotplug_slot->info);
error_hpslot:
@@ -133,8 +135,8 @@ int rpaphp_deregister_slot(struct slot *
list_del(&slot->rpaphp_slot_list);
- /* remove "phy_location" file */
- sysfs_remove_file(&php_slot->kobj, &php_attr_location.attr);
+ /* remove "address" file */
+ sysfs_remove_file(&php_slot->kobj, &php_attr_address.attr);
retval = pci_hp_deregister(php_slot);
if (retval)
@@ -166,8 +168,8 @@ int rpaphp_register_slot(struct slot *sl
return retval;
}
- /* create "phy_location" file */
- retval = sysfs_create_file(&php_slot->kobj, &php_attr_location.attr);
+ /* create "address" file */
+ retval = sysfs_create_file(&php_slot->kobj, &php_attr_address.attr);
if (retval) {
err("sysfs_create_file failed with error %d\n", retval);
goto sysfs_fail;
@@ -175,8 +177,7 @@ int rpaphp_register_slot(struct slot *sl
/* add slot to our internal list */
list_add(&slot->rpaphp_slot_list, &rpaphp_slot_head);
- info("Slot [%s](PCI location=%s) registered\n", slot->name,
- slot->location);
+ info("Slot [%s] registered\n", slot->name);
return 0;
sysfs_fail:
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13 18:06:16.000000000 -0600
@@ -74,7 +74,6 @@ struct slot {
u32 type;
u32 power_domain;
char *name;
- char *location;
struct device_node *dn;
struct pci_bus *bus;
struct list_head *pci_devs;
^ permalink raw reply
* [REPOST] script to build all defconfigs
From: Olof Johansson @ 2007-11-14 20:32 UTC (permalink / raw)
To: linuxppc-dev
I've been asked to post the script again, might as well update with the
latest version.
See below. I normally use this as:
$ CROSS_COMPILE= ARCH=powerpc TARGET="vmlinux modules" buildall
modules won't build on some of the embedded platforms though, so you'll
have to weed out those build errors by hand, or do:
$ CROSS_COMPILE= ARCH=powerpc TARGET=vmlinux buildall
---
#!/bin/bash
#export CC="ccache gcc"
echo -n cleaning:
make $O -ks mrproper
echo " done"
for config in arch/$ARCH/configs/* allnoconfig allmodconfig allyesconfig ; do
CONFIG=`basename $config`
echo -n $ARCH.$CONFIG: ;
yes "" | make $O $CONFIG >buildall.log 2>&1
if time make $O $TARGET -ksj 5 >>buildall.log 2>&1 ; then
mv buildall.log $ARCH.$CONFIG.log.passed
echo " passed"
else
mv buildall.log $ARCH.$CONFIG.log.failed
echo " failed"
fi
done
^ permalink raw reply
* [PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
From: Olof Johansson @ 2007-11-14 21:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: dwmw2, paulus, linuxppc-dev
In-Reply-To: <1195072102.28865.41.camel@pasglop>
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cache blocks,
which are only used on IBM's 64-bit processors.
Convert it to get the blocks sizes out of vdso_data instead, similar
to how the ppc64 in-kernel cache flush does it.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Paul, this is needed to make for example the IBM jvm run on pa6t. Please
include as bugfix for 2.6.24.
On Thu, Nov 15, 2007 at 07:28:22AM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-11-14 at 13:24 -0600, Olof Johansson wrote:
> > [POWERPC] vdso: Fixes for cache line sizes
> >
> > Current VDSO implementation is hardcoded to 128 byte cachelines, which
> > only works on IBM's 64-bit processors.
> >
> > Convert it to get the line sizes out of vdso_data instead, similar to
> > how the ppc64 in-kernel cache flush does it.
>
> Please call the fields "block size" not "line size". There are subtle
> differences and per architecture, it should really be block size.
Alright. I've added block sizes since I'm not sure whether the old
systemcfg data is actually line or block sizes, and I guess it's something
we need to stay compatible with. See separate new patch.
Also, ppc64_caches only has line sizes, so fill it with that for now. I'll
submit a separate patch to complete ppc64_caches with block sizes,
but that's a cleanup not a bug fix (i.e. target for that would be 2.6.25).
> > Paul, this is needed to make for example the IBM jvm run on pa6t. Please
> > include as bugfix for 2.6.24.
>
> Heh, they use the vdso for flushes ? I didn't know that !
Me neither, and the fact that the vdso was hardcoded for 128 had
completely passed me by.
-Olof
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 2c8e756..d67bcd8 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -284,6 +284,10 @@ int main(void)
DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32));
DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec));
DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec));
+ DEFINE(CFG_ICACHE_BLOCKSZ, offsetof(struct vdso_data, icache_block_size));
+ DEFINE(CFG_DCACHE_BLOCKSZ, offsetof(struct vdso_data, dcache_block_size));
+ DEFINE(CFG_ICACHE_LOGBLOCKSZ, offsetof(struct vdso_data, icache_log_block_size));
+ DEFINE(CFG_DCACHE_LOGBLOCKSZ, offsetof(struct vdso_data, dcache_log_block_size));
#ifdef CONFIG_PPC64
DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64));
DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec));
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 2322ba5..3702df7 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -699,11 +699,22 @@ static int __init vdso_init(void)
vdso_data->icache_size = ppc64_caches.isize;
vdso_data->icache_line_size = ppc64_caches.iline_size;
+ /* XXXOJN: Blocks should be added to ppc64_caches and used instead */
+ vdso_data->dcache_block_size = ppc64_caches.dline_size;
+ vdso_data->icache_block_size = ppc64_caches.iline_size;
+ vdso_data->dcache_log_block_size = ppc64_caches.log_dline_size;
+ vdso_data->icache_log_block_size = ppc64_caches.log_iline_size;
+
/*
* Calculate the size of the 64 bits vDSO
*/
vdso64_pages = (&vdso64_end - &vdso64_start) >> PAGE_SHIFT;
DBG("vdso64_kbase: %p, 0x%x pages\n", vdso64_kbase, vdso64_pages);
+#else
+ vdso_data->dcache_block_size = L1_CACHE_BYTES;
+ vdso_data->dcache_log_block_size = L1_CACHE_SHIFT;
+ vdso_data->icache_block_size = L1_CACHE_BYTES;
+ vdso_data->icache_log_block_size = L1_CACHE_SHIFT;
#endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S
index 9cb3199..99a76f7 100644
--- a/arch/powerpc/kernel/vdso32/cacheflush.S
+++ b/arch/powerpc/kernel/vdso32/cacheflush.S
@@ -23,29 +23,44 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl __get_datapage@local
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
- crclr cr0*4+so
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S
index 66a36d3..6ed5916 100644
--- a/arch/powerpc/kernel/vdso64/cacheflush.S
+++ b/arch/powerpc/kernel/vdso64/cacheflush.S
@@ -23,29 +23,44 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl V_LOCAL_FUNC(__get_datapage)
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
- crclr cr0*4+so
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/include/asm-powerpc/vdso_datapage.h b/include/asm-powerpc/vdso_datapage.h
index 8a94f0e..f013932 100644
--- a/include/asm-powerpc/vdso_datapage.h
+++ b/include/asm-powerpc/vdso_datapage.h
@@ -77,6 +77,10 @@ struct vdso_data {
/* those additional ones don't have to be located anywhere
* special as they were not part of the original systemcfg
*/
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
@@ -99,6 +103,10 @@ struct vdso_data {
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
};
#endif /* CONFIG_PPC64 */
^ permalink raw reply related
* Re: 85xx Device tree problems: e0024520:02 not found
From: Clemens Koller @ 2007-11-14 21:33 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <473B5940.2090306@anagramm.de>
Hi, Robert!
Just one more short note...
My good - vs. - bad dmesg output:
good 2.6.21-rc5-git:
> Gianfar MII Bus: probed
> eth0: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> eth2: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> eth2: Running with NAPI enabled
> eth2: 256/256 RX/TX BD ring size
> Marvell 88E1101: Registered new driver
> Marvell 88E1111: Registered new driver
> Marvell 88E1145: Registered new driver
(I've wiped out my MAC)
bad 2.6.24-rc2-git:
< Gianfar MII Bus: probed
< eth0: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
< eth0: Running with NAPI enabled
< eth0: 256/256 RX/TX BD ring size
< eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
< eth1: Running with NAPI enabled
< eth1: 256/256 RX/TX BD ring size
< eth2: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
< eth2: Running with NAPI enabled
< eth2: 256/256 RX/TX BD ring size
The MACs are all 00 here.
The PHY drivers don't get registered.
(What happened to CONFIG_NETDEV_1000 in the newer kernels?)
How is your mileage?
Next round... tomorrow,
regards,
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 locks up after calling kernel_execve()
From: Paul Mackerras @ 2007-11-14 21:54 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071114093939.297890@gmx.net>
Gerhard Pircher writes:
> Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
Wow.
> masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
> prefetch engines (I don't care about the performance loss).
> I couldn't find any other code that sets the M bit, except for huge TLB
> page support, but isn't that only for PPC64?
No it's not just for ppc64. We had a patch that went in some time ago
to ensure that the M bit was set on various 32-bit platforms because
otherwise we got data corruption (due to a small cache in the
northbridge not being kept coherent with the processor cache).
Look for CPU_FTR_NEED_COHERENT in include/asm-powerpc/cputable.h and
arch/powerpc/mm/*.
Paul.
^ permalink raw reply
* Re: 85xx Device tree problems: e0024520:02 not found
From: robert lazarski @ 2007-11-14 22:00 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <473B699C.5040700@anagramm.de>
On Nov 14, 2007 4:33 PM, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hi, Robert!
>
> Just one more short note...
> My good - vs. - bad dmesg output:
>
> good 2.6.21-rc5-git:
> > Gianfar MII Bus: probed
> > eth0: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> > eth0: Running with NAPI enabled
> > eth0: 256/256 RX/TX BD ring size
> > eth1: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> > eth1: Running with NAPI enabled
> > eth1: 256/256 RX/TX BD ring size
> > eth2: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd
> > eth2: Running with NAPI enabled
> > eth2: 256/256 RX/TX BD ring size
> > Marvell 88E1101: Registered new driver
> > Marvell 88E1111: Registered new driver
> > Marvell 88E1145: Registered new driver
> (I've wiped out my MAC)
>
> bad 2.6.24-rc2-git:
> < Gianfar MII Bus: probed
> < eth0: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
> < eth0: Running with NAPI enabled
> < eth0: 256/256 RX/TX BD ring size
> < eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
> < eth1: Running with NAPI enabled
> < eth1: 256/256 RX/TX BD ring size
> < eth2: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
> < eth2: Running with NAPI enabled
> < eth2: 256/256 RX/TX BD ring size
>
> The MACs are all 00 here.
> The PHY drivers don't get registered.
> (What happened to CONFIG_NETDEV_1000 in the newer kernels?)
>
> How is your mileage?
> Next round... tomorrow,
>
> regards,
>
> Clemens Koller
Hmm, I'm getting my mac addresses, the same ones I set in u-boot:
=> bootm 1000000 - c00000
## Booting image at 01000000 ...
Image Name: Linux-2.6.24-rc2-ge6a5c27f-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1278631 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x3FF9DD50 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF90
bd address = 0x3FF9DFB0
memstart = 0x00000000
memsize = 0x40000000
flashstart = 0xF8000000
flashsize = 0x08000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xE0000000
bootflags = 0xE4013F80
intfreq = 888.888 MHz
busfreq = 355.555 MHz
ethaddr = 00:E0:0C:00:00:FD
eth1addr = 00:E0:0C:00:01:FD
eth2addr = 00:E0:0C:00:02:FD
eth3addr = 00:E0:0C:00:03:FD
IP addr = 10.101.43.142
baudrate = 115200 bps
Skipping initrd
Booting using the fdt at 0xc00000
No initrd
## device tree at 0x00C00000 ... 0x00C01B6C (len=7021=0x1B6D)
Loading Device Tree to 007fc000, end 007fdb6c ... OK
## Transferring control to Linux (at address 00000000) ...
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:00:fd
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:01:fd
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
eth2: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:02:fd
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
eth3: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:03:fd
eth3: Running with NAPI enabled
eth3: 256/256 RX/TX BD ring size
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
e0024520:02 not found
eth2: Could not attach to PHY
IP-Config: Failed to open eth2
IP-Config: Device `eth2' not found.
Tomorrow's a holiday here in Brazil, will catch up with you Friday,
Robert
^ permalink raw reply
* Re: [PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Stephen Rothwell @ 2007-11-14 23:21 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071114102115.31052.67271.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
Hi Marian,
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.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix fs_enet module build
From: David Miller @ 2007-11-14 23:51 UTC (permalink / raw)
To: jochen; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded, akpm
In-Reply-To: <473AE325.8070901@scram.de>
From: Jochen Friedrich <jochen@scram.de>
Date: Wed, 14 Nov 2007 12:59:33 +0100
> I know it's ugly, however, module building is completely
> broken right now and I just want to provide a quick and
> ugly fix until both that ppc->powerpc transition and the
> new binding transition are over. Noone wants to touch the
> old stuff any more as it's a pita and it's already scheduled
> for removal in a couple of months.
Fair enough, I'll apply the patch.
Thanks for the explanation.
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jerry Van Baren @ 2007-11-15 1:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9e4733910711131732i5ec5d226r4037e42399c38f59@mail.gmail.com>
Jon Smirl wrote:
> On 11/13/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>> That's why Dominic wants to get OpenOCD running on the PowerPC. All we
>>> need is the programming documentation for controlling the CPU via the
>>> debug hardware.
>> Note that this is basically different for every CPU around.
>
> I'd like to get it for the MPC5200 because of the project I am working
> on, an open source audio device. It would be nice if there was a cheap
> hardware debugger available for hackers to use on it. Maybe one of the
> Freescale developers will see this and send me the right docs.
>
> Is it radically different? Dominic has been able to support every ARM
> 7/9 chip he can get his hands on without too much trouble once the
> core support was written. I don't think he has ARM 11 working yet.
>
>>> Obviously this documentation exist, all of the commercial vendors had
>>> to have it to develop their debuggers. Maybe it is already out there
>>> and we just don't know where to look.
>> Ben.
DISCLAIMER: Extrapolating grossly from almost no knowledge!
My understanding is that the Freescale PPC debugger interface is based
on the JTAG interface using a proprietary command set. Basically, if
you do their magic BDM (JTAG extension) command, you get into an
internal scan chain that allows you to read/write the processor
internals (registers).
The problems are many...
* The documentation is only available under NDA, a problem for open
source debuggers.
* The scan chain is different on every processor, and may be different
on different revisions of the same processor.
* If you mess up with JTAG, you will probably burn up the CPU. Very
literally. I've seen it done. Twice. (Thankfully not my screwup, and
it wasn't a PPC so it deserved to die. ;-) The internal scan chain is
probably safer, but YMMV.
gvb
^ permalink raw reply
* RE: printk/console_init - baud rate setting
From: Siva Prasad @ 2007-11-15 2:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <610b1b49ca582c7a2277e8d6dea2be31@kernel.crashing.org>
Thanks Segher.
It was because of the BASE_BAUD value. We are working at 600MHz, not
18.432. After that change, it worked fine.
Thanks
Siva
-----Original Message-----
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
Sent: Wednesday, November 14, 2007 3:00 PM
To: Siva Prasad
Subject: Re: printk/console_init - baud rate setting
> Thanks for your response Segher.
> I already have the command line "console=3DttyS0, 115200". Now, how to
> make sure that 115200 setting is calculated properly for the use by
> driver.
>
> In other words, can you kind enough to please let me know how 115200
is
> supported by the driver, based on the clock frequency.
That is solely the driver's own responsibility, you'll have to look
at the source code. 8250 typically just assumes 18.432MHz.
Segher
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-15 2:34 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <473BA278.2000402@gmail.com>
On 11/14/07, Jerry Van Baren <gvb.linuxppc.dev@gmail.com> wrote:
> Jon Smirl wrote:
> > On 11/13/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >>> That's why Dominic wants to get OpenOCD running on the PowerPC. All we
> >>> need is the programming documentation for controlling the CPU via the
> >>> debug hardware.
> >> Note that this is basically different for every CPU around.
> >
> > I'd like to get it for the MPC5200 because of the project I am working
> > on, an open source audio device. It would be nice if there was a cheap
> > hardware debugger available for hackers to use on it. Maybe one of the
> > Freescale developers will see this and send me the right docs.
> >
> > Is it radically different? Dominic has been able to support every ARM
> > 7/9 chip he can get his hands on without too much trouble once the
> > core support was written. I don't think he has ARM 11 working yet.
> >
> >>> Obviously this documentation exist, all of the commercial vendors had
> >>> to have it to develop their debuggers. Maybe it is already out there
> >>> and we just don't know where to look.
> >> Ben.
>
> DISCLAIMER: Extrapolating grossly from almost no knowledge!
>
> My understanding is that the Freescale PPC debugger interface is based
> on the JTAG interface using a proprietary command set. Basically, if
> you do their magic BDM (JTAG extension) command, you get into an
> internal scan chain that allows you to read/write the processor
> internals (registers).
>
> The problems are many...
> * The documentation is only available under NDA, a problem for open
> source debuggers.
This is what we need. I would like it specifically for the mpc5200.
But we want to use it in OpenOCD so NDA won't work.
> * The scan chain is different on every processor, and may be different
> on different revisions of the same processor.
Hopefully the doc will cover this.
> * If you mess up with JTAG, you will probably burn up the CPU. Very
> literally. I've seen it done. Twice. (Thankfully not my screwup, and
> it wasn't a PPC so it deserved to die. ;-) The internal scan chain is
> probably safer, but YMMV.
Dominic is way experienced implementing JTAG for ARM CPUs. He has done
several dozen interfaces. ARM doesn't have any problems releasing
their debugging info.
I've also lined up a mpc5200 development board vendor who wants a
cheap mpc5200 JTAG too and is willing to supply him with target
hardware.
JTAG hardware would be something similar to this:
http://www.amontec.com/jtagkey-tiny.shtml
So $30-40 for hardware with free OpenOCD software and you have JTAG
for the mpc5200.
This puts it in the range of classroom use.
The few embedded classes I've been around lately are being taught on
ARM hardware because it is so cheap. Development boards and the JTAG
can be had for under $100.
For example check out this store, it carries hundreds of ARM products
and almost no PowerPC ones.
http://microcontrollershop.com
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Do not depend on MAX_ORDER when grouping pages by mobility
From: Stephen Rothwell @ 2007-11-15 3:17 UTC (permalink / raw)
To: Mel Gorman; +Cc: ppc-dev
In-Reply-To: <20071114181044.GB773@skynet.ie>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
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.
So
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> iSeries boot test and
hugetlb tests on PPC64
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: about uImage-DENX-v2.6.14 config
From: Stefan Roese @ 2007-11-15 6:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: info, zhangwei zhang, linuxppc-embedded
In-Reply-To: <4b7912400711140706i3c96456bua42dc01c6cb5467b@mail.gmail.com>
On Wednesday 14 November 2007, zhangwei zhang wrote:
> Hello, I have a problem when using linux-2.6.14(download from
> ftp.denx.de) for RTAI on ppc440EP.
RTAI on PPC? I thought RTAI was dead for anything other than X86.
And 2.6.14 is quite old. I suggest you use a newer binary version or compile a
the image from the current kernel source.
> I use the ELDK4.1 and when boot the
> uImage I compiled , I always have the problem as following:
>
> ## Booting image at 00500000 ...
> Image Name: Linux-2.6.14
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1155686 Bytes = 1.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> then it stopped . I am afraid that maybe the problem comes from the
> config. I have ever use the uImage-DENX-v2.6.14 you offered in
> ftp.denx.de/pub/linux/amcc/image/yosemite/ and it works. So can you
> send me a config file for 2.6.14 to me? Thank you.
Please don't stick with 2.6.14. Download the current kernel:
http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=summary
and there you will find the .config for the Yosemite
(arch/ppc/configs/yosemite_defconfig).
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-15 8:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18235.28312.88899.861687@cargo.ozlabs.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 15 Nov 2007 08:54:32 +1100
> Von: Paul Mackerras <paulus@samba.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: benh@kernel.crashing.org, linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> No it's not just for ppc64. We had a patch that went in some time ago
> to ensure that the M bit was set on various 32-bit platforms because
> otherwise we got data corruption (due to a small cache in the
> northbridge not being kept coherent with the processor cache).
Ah, I thought this was due to a CPU errata, where L2 cache prefetching
causes data corruption with the coherent bit set to 0.
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Problem with uboot on lite5200
From: Leo Hendrawan @ 2007-11-15 9:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
Hi all,
i am newbee in Linux PPC. i have problem with my lite5200 board. previously
it has been installed with uboot. but now i dont receive any message from
uboot in the serial line (serial line is ok with 115200 bps - tested).
how can i re-flash the uboot inside the MPC5200? i use bdi2000, compiled the
new uboot version 1.1.6 but didnt find out anyway to flash it inside the
controller.
thanks for the hint,
[-- Attachment #2: Type: text/html, Size: 438 bytes --]
^ permalink raw reply
* [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
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