On Thu, 2009-10-29 at 14:08 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2009-10-28 at 15:53 -0500, Nathan Fontenot wrote:
+ struct device_node *dn;
+ struct device_node *first_dn = NULL;
+ struct device_node *last_dn = NULL;
+ struct property *property;
+ struct property
This series is a first attempt at enabling checkpoint/restart for
powerpc. It is based on Oren Laadan's v13 checkpoint/restart series:
http://lkml.org/lkml/2009/1/27/227
Nathan Lynch (3):
powerpc: bare minimum checkpoint/restart implementation
powerpc: wire up checkpoint and restart
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm/systbl.h |2 ++
arch/powerpc/include/asm/unistd.h |4 +++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index 803def2..cdb60b4
Signed-off-by: Nathan Lynch n...@pobox.com
---
checkpoint/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/checkpoint/Kconfig b/checkpoint/Kconfig
index ffaa635..00036aa 100644
--- a/checkpoint/Kconfig
+++ b/checkpoint/Kconfig
@@ -1,7 +1,7 @@
config
and external checkpoint of simple (single thread, one open
file) 32- and 64-bit processes on a ppc64 kernel
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Untested:
* ppc32 (but it builds)
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for the next
Brian King wrote:
While testing partition migration with heavy CPU load using
shared processors, it was observed that sometimes the migration
would never complete and would appear to hang. Currently, the
migration code assumes that if H_SUCCESS is returned from the H_JOIN
then the migration
Oren Laadan wrote:
Nathan Lynch wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
+ pr_debug(%s: unexpected thread_hdr contents: 0x%lx\n,
+ __func__, (unsigned long)thread_hdr-unimplemented);
Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix
. Split this into validate
(debugreg_valid) and update (debugreg_update) functions, and make
them available for use outside of the ptrace code.
Also ptrace_set_debugreg has extern linkage, but no users outside of
ptrace.c. Make it static.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc
On Tue, 17 Feb 2009 01:03:55 -0600
Nathan Lynch n...@pobox.com wrote:
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt
On Tue, 24 Feb 2009 13:58:26 -0600
Serge E. Hallyn se...@us.ibm.com wrote:
Quoting Nathan Lynch (n...@pobox.com):
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice
Oren Laadan or...@cs.columbia.edu wrote:
Nathan Lynch wrote:
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks
Michael Ellerman mich...@ellerman.id.au wrote:
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally
Tony Breeds t...@bakeyournoodle.com wrote:
On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote:
I think I had some reason for doing it this way, but I'm drawing a
blank right now.
In the meantime, can someone post the warnings that gcc emits for
cacheinfo.c, as well
Wu Fengguang fengguang...@intel.com writes:
On Wed, Apr 29, 2009 at 05:32:44AM +0800, Andrew Morton wrote:
On Tue, 28 Apr 2009 09:09:12 +0800
Wu Fengguang fengguang...@intel.com wrote:
+/*
+ * Kernel flags are exported faithfully to Linus and his fellow hackers.
+ * Otherwise some
Rune Torgersen wrote:
Kumar Gala wrote:
Can you git-bisect to narrow this down further.
Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
and up.
Is there an somewhat esy way in git to apply the differences from master
branch to our board branch to a branch created by
Scott Wood wrote:
On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
Unable to handle kernel paging request for data at address 0x48024000
Faulting instruction address: 0xc000f0a0
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Does it happen
Rune Torgersen wrote:
Hi
I get the following kernel core while a user program I have is dumping
core.
Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on
a 8280)
When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11
and dumps core.
On 2.6.24, I ghet
Doug Maxey wrote:
A small set of fixups for checkpatch.
Based on upstream pull from a few hours ago.
Er, ehea doesn't even build right now[1], maybe that could get fixed
first? :-)
[1] http://lkml.org/lkml/2008/1/28/337
___
Linuxppc-dev mailing
Christoph Hellwig wrote:
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
I just did a git pull of Josh's tree, and
arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
glossing over the linuxppc-dev emails, so forgive me if this already
came up.
I
Sean MacLennan wrote:
Christoph Hellwig wrote:
On Thu, Feb 07, 2008 at 12:49:34AM -0600, Nathan Lynch wrote:
Christoph Hellwig wrote:
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
I just did a git pull of Josh's tree, and
arch/powerpc/kernel/asm
Josh Boyer wrote:
On Sat, 23 Feb 2008 15:58:23 -0600
Josh Boyer [EMAIL PROTECTED] wrote:
IEEE 1275 defined a standard status property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property
Maynard Johnson wrote:
static long lib_addr;
module_param(lib_addr, long, 0);
Should be unsigned long?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Nathan Lynch wrote:
Maynard Johnson wrote:
static long lib_addr;
module_param(lib_addr, long, 0);
Should be unsigned long?
ulong, rather, but that doesn't fix it.
In any case, lib_addr is a user virtual address; doesn't the kernel
need to do get_user_pages
Badari Pulavarty wrote:
+static struct notifier_block pseries_smp_nb = {
Rename this to pseries_mem_nb?
+ .notifier_call = pseries_memory_notifier,
+};
+
+static int __init pseries_memory_hotplug_init(void)
+{
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+
Badari Pulavarty wrote:
Hi Paul,
Here are the hotplug memory remove updates for 2.6.25-rc2-mm1.
How have these been tested? Have you initiated a memory remove
operation from the HMC? That's the only way to catch some bugs...
___
Linuxppc-dev
Josh Boyer wrote:
On Mon, 3 Mar 2008 13:09:25 -0600
Scott Wood [EMAIL PROTECTED] wrote:
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
On Mon, 3 Mar 2008 04:43:42 +0100
Arnd Bergmann [EMAIL PROTECTED] wrote:
I wonder whether we should move the check for used-by-rtas
Michael Ellerman wrote:
On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
Hotplug memory notifier for ppc64. This gets invoked by writing
the device-node that needs to be removed to /proc/ppc64/ofdt.
We need to adjust the sections and remove sysfs entries by
calling
. There should not be any behavioral
change -- fixup_maple_ide() calls machine_is(maple) but the body of
the function is ifdef'd out.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc
Please consider the following mostly-trivial patches for 2.6.26.
arch/powerpc/configs/maple_defconfig | 133 --
arch/powerpc/platforms/maple/pci.c | 47
arch/powerpc/platforms/maple/setup.c |2 +-
3 files changed, 129 insertions(+), 53
This function has been a no-op for about 18 months; it's there in
the history should anyone need to resurrect it.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/pci.c | 47
1 files changed, 0 insertions(+), 47 deletions
Some machines supported by the maple platform have an Obsidian
controller which can't be used without enabling CONFIG_IPR and the
options on which it depends.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/configs/maple_defconfig | 133 --
1 files
A couple of places are duplicating the function of
of_device_is_available; convert them to use it.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
This depends on Josh Boyer's patch [OF] Add of_device_is_available
function:
http://patchwork.ozlabs.org/linuxppc/patch?id=17100
arch/powerpc
Benjamin Herrenschmidt wrote:
On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
Currently HEA requires 4K pages for IO resources. Just set the pages
size to
IO to 4K.
Well, that's too bad. Why penalize all
Tony Breeds wrote:
+#if defined(CONFIG_PPC_PSERIES) defined(CONFIG_PPC_64K_PAGES)
+static int __init scan_dt_for_ehea(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ if (depth != 0)
+ return 0;
+
+ if
leak of ent-data on failed create_proc_entry()
* simplify control flow
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
(not urgent, please consider for 2.6.26)
arch/powerpc/platforms/pseries/scanlog.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff
Jens Osterkamp wrote:
Handling of the proc_dir_entry-count has being changed in 2.6.24-rc5.
Do you know which commit caused the change?
After this change the default value for pde-count is 1 and not 0 as it
was in earlier kernels. Therefore, if we want to check wether our procfs
file is
Nathan Lynch wrote:
One could argue that the real problem is using the proc_dir_entry's
reference count to enforce exclusive open.
I think this is better... the way these files are used is lame, but
this should preserve the existing behavior. I haven't yet tested
this, can you?
diff --git
Paul Mackerras wrote:
Nathan Lynch writes:
I think this is better... the way these files are used is lame, but
this should preserve the existing behavior. I haven't yet tested
this, can you?
Looks OK -- can I have a proper patch description and a signed-off-by
line for this please
Roel Kluin wrote:
replace logical by bit and for ISA_SPACE_MASK
I think Paul has picked this up now:
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/054103.html
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Hello-
2.6.23-rc1 breaks the build for 64-bit powerpc for me (using
maple_defconfig):
LD vmlinux.o
powerpc64-unknown-linux-gnu-ld: dynreloc miscount for
kernel/built-in.o, section .opd
powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
This is on a
Hi Sam-
Sam Ravnborg wrote:
On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote:
2.6.23-rc1 breaks the build for 64-bit powerpc for me (using
maple_defconfig):
LD vmlinux.o
powerpc64-unknown-linux-gnu-ld: dynreloc miscount for
kernel/built-in.o, section .opd
Linas Vepstas wrote:
--- linux-2.6.22-git2.orig/include/asm-powerpc/nvram.h2007-07-08
18:32:17.0 -0500
+++ linux-2.6.22-git2/include/asm-powerpc/nvram.h 2007-08-08
13:34:27.0 -0500
@@ -62,14 +62,19 @@ struct nvram_partition {
unsigned int index;
};
-
Linas Vepstas wrote:
We don't need to look up the rtas event token once per
cpu per second. This avoids some misc string ops and
rtas calls and provides some minor performance improvement.
It does not avoid any calls to RTAS. (rtas_token merely looks up
properties under the /rtas node.)
Linas Vepstas wrote:
On Wed, Aug 08, 2007 at 04:57:14PM -0500, Nathan Lynch wrote:
Linas Vepstas wrote:
+
+#ifdef CONFIG_PPC_PSERIES
+extern int pSeries_nvram_init(void);
+extern int nvram_write_error_log(char * buff, int length,
+ unsigned int
Benjamin Herrenschmidt wrote:
On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
Remove the gratuitous reads from u3_agp_write_config,
u3_ht_write_config, and u4_pcie_write_config.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED
David Gibson wrote:
On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
The maple pci configuration space write methods read the written
location immediately after the write is performed, presumably in order
to flush the write. However, configuration space writes
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/rtas_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index a5de621..21f14e5 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/celleb/pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c
b/arch/powerpc/platforms/celleb/pci.c
index e9ac19c..de8038b 100644
--- a/arch/powerpc/platforms
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/celleb/scc_epci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c
b/arch/powerpc/platforms/celleb/scc_epci.c
index c4b0110..7506acc 100644
--- a/arch
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/pci.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c
b/arch/powerpc/platforms/maple/pci.c
index 2542403..6247f94 100644
--- a/arch/powerpc
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/pasemi/pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c
b/arch/powerpc/platforms/pasemi/pci.c
index ab1f5f6..882b571 100644
--- a/arch/powerpc/platforms
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/pci.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c
b/arch/powerpc/platforms/powermac/pci.c
index 92586db..69d67ff 100644
--- a/arch
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/pci_32.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 04a3109..0e2bee4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/efika.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index 4be6e7a..4263158 100644
--- a/arch/powerpc/platforms
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/chrp/pci.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pci.c
b/arch/powerpc/platforms/chrp/pci.c
index 28d1647..0c6dba9 100644
--- a/arch/powerpc/platforms
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/sysdev/tsi108_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 90db8a7..cf0bfbd 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
Segher Boessenkool wrote:
It might be worth checking that there isn't a particular reason for
these. Just because posting writes are forbidden doesn't mean a
particular bridge won't screw it up...
Well, I had already checked with Ben, who wrote the code, and my
understanding is that the
, and u4_pcie_write_config.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/pci.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c
b/arch/powerpc/platforms/powermac/pci.c
index 92586db..bf1f5d1
Hi Joachim-
Joachim Fenkes wrote:
Nathan Lynch [EMAIL PROTECTED] wrote on 29.08.2007 20:12:32:
Will anything break?
Nope. Userspace programs should not depend on ibmebus' way of naming the
devices; especially since some overly long loc_codes tended to be
truncated and thus rendered
Hi,
Joachim Fenkes wrote:
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
Linas Vepstas wrote:
I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
for whatever reason, a spinlock locked up. The bizarre thing
was that the rest of system locked up as well: an ssh terminal,
and also an hvc console.
Breaking into the debugger showed 4 cpus, 1 of which
Medve Emilian-EMMEDVE1 wrote:
I have module with 36K relocation entries (I know, I know, how could
that be...) and the count_relocs() function takes ~17 seconds to crunch
through the relocation table from the .rela.text section. I don't think
I can reduce the number of entries in the
(cc'ing linuxppc-dev, see
http://www.mail-archive.com/[EMAIL PROTECTED]/msg221770.html
for original post and .config)
Elimar Riesebieter wrote:
On Wed, 24 Oct 2007 the mental interface of
Elimar Riesebieter told:
[...]
The kernel is loaded from firmware but freezes at the moment to load
Hi,
Roel Kluin wrote:
I think this is how it should be done, but
please review: it was not tested.
--
Balance alloc/free and ioremap/iounmap
It would be more helpful if your changelog identified the objects
which could be leaked. More comments below.
-static int __devinit
Nathan Lynch wrote:
Medve Emilian-EMMEDVE1 wrote:
I have module with 36K relocation entries (I know, I know, how could
that be...) and the count_relocs() function takes ~17 seconds to crunch
through the relocation table from the .rela.text section. I don't think
I can reduce the number
(very rfc for now, no sign-off, needs more testing)
There are a couple of bugs in the rtas_ibm_suspend_me() and
rtas_percpu_suspend_me() functions:
1. rtas_ibm_suspend_me() uses on_each_cpu() to invoke
rtas_percpu_suspend_me() via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, data, 1, 0))
...
Medve Emilian wrote:
Would it be possible to do the sort in place (without the extra
buffer)? I mean would that upset any other part of the kernel?
I suspect so. Sounds like you've got the good testcase, maybe you
should try it and see. :)
___
Nathan Lynch wrote:
(very rfc for now, no sign-off, needs more testing)
There are a couple of bugs in the rtas_ibm_suspend_me() and
rtas_percpu_suspend_me() functions:
1. rtas_ibm_suspend_me() uses on_each_cpu() to invoke
rtas_percpu_suspend_me() via IPI:
if (on_each_cpu
.)
This is fixed by calling H_PROD for each online cpu using
get_hard_smp_processor_id(cpu) for the argument.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/rtas.c | 94 +---
1 files changed, 53 insertions(+), 41 deletions(-)
Changes since v1
prod_processor() is unused, and that's a good thing, since it does not
supply the required proc id parameter to H_PROD.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/plpar_wrappers.h |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git
.)
This is fixed by calling H_PROD for each online cpu using
get_hard_smp_processor_id(cpu) for the argument.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Paul Mackerras wrote:
On a uniprocessor configuration, with this patch I get:
CC arch/powerpc/kernel/rtas.o
/home/paulus/kernel/powerpc
Nathan Lynch wrote:
3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt
disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN
with it on; the local_irq_disable() in on_each_cpu() is not
sufficient.
Fix this by explicitly saving the MSR and clearing the EE bit
The powerpc implementations of syscall_get_error and
syscall_set_return_value should use CCR0:S0 (0x1000) for testing
and setting syscall error status. Fortunately these APIs don't seem
to be used at the moment.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm
Segher Boessenkool wrote:
The PowerPC binding defines an l2-cache property for this (it
points from CPU node to L2 cache node, from L2 cache node to L3
cache node, from L3 cache node to L4 cache node, etc.)
So looking at the PPC binding its not terrible clear about l3-cache
being a valid
Hannes Hering wrote:
On Wednesday 28 May 2008 18:44:05 Nathan Lynch wrote:
Hannes Hering wrote:
The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG.
Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---
diff --git a/drivers/net/Kconfig b/drivers/net
: Add dependency to Kconfig
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c |3 +--
include/linux/memory_hotplug.h | 16
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f67e118
Now that walk_memory_resource() is available regardless of
MEMORY_HOTPLUG's setting, this dependency is not needed.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
drivers/net/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net
Nathan Lynch wrote:
The ehea driver was recently changed[1] to use walk_memory_resource() to
detect the system's memory layout. However, walk_memory_resource() is
available only when memory hotplug is enabled. So CONFIG_EHEA was
made to depend on MEMORY_HOTPLUG [2], but it is inappropriate
Hi, mainly a couple of coding style things, but one minor bug (I
think).
[EMAIL PROTECTED] wrote:
From: Sonny Rao [EMAIL PROTECTED]
+static int bsr_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ unsigned long size = vma-vm_end - vma-vm_start;
+ struct bsr_dev *dev =
nr_cores), but I'm not
seeing this improvement with 2.6.26-rc kernels for some reason I am
still trying to track down.
Nathan Lynch (3):
sched: support arch override of sched_group cpu power
add cpu_power to machdep_calls, override SD_SIBLING_INIT
adjust cpu power for secondary threads
the
SD_ASYM_CPU_POWER flag, which will cause ppc_md.cpu_power() to be
invoked (via arch_cpu_power()) during sched domain initialization.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c |7 +++
include/asm-powerpc/machdep.h |2 ++
include/asm-powerpc
Add a new sched domain flag, SD_ASYM_CPU_POWER, which signifies that
the architecture may override the cpu power for a cpu via a hook in
init_sched_groups_power(). Add a dummy definition of arch_cpu_power()
which conforms with the existing behavior.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED
threads'
cpu power. Allow this percentage to be overriden on the kernel
command line via sec_thread_power_scale=.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/setup.c | 37
include/asm-powerpc/cputable.h |3 +-
2
Ingo Molnar wrote:
* Nathan Lynch [EMAIL PROTECTED] wrote:
So it would be nice to have the scheduler slightly prefer primary
threads on POWER6 machines. These patches, which allow the
architecture to override the scheduler's CPU power calculation, are
one possible approach, but I'm
Breno Leitao wrote:
Nathan Lynch wrote:
There is an interesting quality of POWER6 cores, which each have 2
hardware threads: assuming one thread on the core is idle, the primary
thread is a little faster than the secondary thread. To illustrate:
I found this feature interesting
Beginning with Power6, there is a set of 32 PMU events which is
compatible across POWER processor lines. PPC_FEATURE_PMU_COMPAT
indicates support for this subset.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/cputable.c |4 ++--
include/asm-powerpc/cputable.h |1
has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Next patch implements ELF/AT_BASE_PLATFORM for powerpc.
fs/binfmt_elf.c | 23 +++
1 files changed, 23 insertions(+), 0
Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Note: I wasn't sure how to pick the index value for AT_BASE_PLATFORM;
I simply searched
Mikael Pettersson wrote:
Nathan Lynch writes:
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value
Roland McGrath wrote:
Well, we use strings to represent the platforms already (ie, the actual
CPU microarchitecture). Fitting those into bits would be annoying, it
Then use dsocaps.
makes sense to have AT_BASE_PLATFORM to be the base variant of
AT_PLATFORM.
I understand why you
Kumar Gala wrote:
On Jul 3, 2008, at 6:20 PM, Nathan Lynch wrote:
Beginning with Power6, there is a set of 32 PMU events which is
compatible across POWER processor lines. PPC_FEATURE_PMU_COMPAT
indicates support for this subset.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch
Benjamin Herrenschmidt wrote:
On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
left there (keeping it to 32), but 3 is not 0. If not that, why not use
dsocaps? That is, some magic in the vDSO, which glibc
,
then the performance tool can surface just those events to the user
of the tool.
PPC_FEATURE_PSERIES_PMU_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Changes since v1:
- make name
I think this code that counts SMT threads and compares against NR_CPUS
is an artifact of pre-powerpc-merge ppc64. We care about starting
only primary threads in the OF client code.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom_init.c | 39
, then the performance tool can
surface just those events to the user of the tool.
PPC_FEATURE_PSERIES_PERFMON_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Changes since v2
that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
fs/binfmt_elf.c| 23 +++
include/linux/auxvec.h |5 -
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs
Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/cputable.c | 11 +++
include/asm-powerpc/cputable.h |2
Background:
Some IBM POWER-based systems have the ability to run in a
compatibility mode which mostly appears to the OS as a different
processor from the actual hardware. This feature of the platform is
useful for live partition migration and for backwards compatibility
with old kernels on new
1 - 100 of 884 matches
Mail list logo
