: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/mobility.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/mobility.c
b/arch/powerpc/platforms/pseries/mobili
eries: Partition migration in the kernel")
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/cacheinfo.c | 21 +
arch/powerpc/kernel/cacheinfo.h | 4
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cachein
Tyrel Datwyler writes:
> On 06/06/2019 10:04 PM, Nathan Lynch wrote:
>> During post-migration device tree updates, we can oops in
>> pseries_update_drconf_memory if the source device tree has an
>> ibm,dynamic-memory-v2 property and the destination has a
>> ibm,d
Michael Ellerman writes:
> Nathan Lynch writes:
>
>> During post-migration device tree updates, we can oops in
>> pseries_update_drconf_memory if the source device tree has an
>> ibm,dynamic-memory-v2 property and the destination has a
>> ibm,dynamic_memory (v1) pr
t's really an add in this
scenario. So make sure the old property object is there before
dereferencing it.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/ar
Tyrel Datwyler writes:
> On 05/20/2019 08:01 AM, Nathan Lynch wrote:
>> Kernel implementation details aside, how do you change the cpu-node
>> relationship at runtime without breaking NUMA-aware applications? Is
>> this not a fundamental issue to address be
GFP_ATOMIC for both allocations.
Ultimately it probably would be better to avoid or reduce allocations
in this path if possible.
Signed-off-by: Nathan Lynch
---
Found by inspection, built but not runtime-tested.
arch/powerpc/platforms/pseries/dlpar.c | 8
1 file changed, 4 insertions(+), 4
; cc_workarea *ccwa)
>
> name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
> prop->name = kstrdup(name, GFP_KERNEL);
> + if (!prop->name) {
> + dlpar_free_cc_property(prop);
> + return NULL;
> + }
Acked-by: Nathan Lynch
Tyrel Datwyler writes:
> On 05/16/2019 12:17 PM, Nathan Lynch wrote:
>> Tyrel Datwyler writes:
>>> The current dlpar_cpu_readd() takes in a cpu_id and uses that to look up
>>> the cpus device_node so that we can get at the ibm,my-drc-index
>>>
Tyrel Datwyler writes:
> The current dlpar_cpu_readd() takes in a cpu_id and uses that to look up
> the cpus device_node so that we can get at the ibm,my-drc-index
> property. The only user of cpu readd is an OF notifier call back. This
> call back already has a reference to the device_node and
ed to save and restore the previous mask
> value.
>
> We don't need to save and restore the earlier mask value if
> CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not enabled. So, remove the field
> from the structure as well.
Makes sense.
Acked-by: Nathan Lynch
"Naveen N. Rao" writes:
> Introduce macros to encode the DTL enable mask fields and use those
> instead of hardcoding numbers.
This is a good cleanup on its own.
Acked-by: Nathan Lynch
Hi Juliet,
Juliet Kim writes:
> Fix extending start/stop topology update scope during LPM
> Commit 65b9fdadfc4d ("powerpc/pseries/mobility: Extend start/stop
> topology update scope") made the change to the duration that
> topology updates are suppressed during LPM to allow the complete
>
Hi Thiago,
Thiago Jung Bauermann writes:
> Nathan Lynch writes:
>> Thiago Jung Bauermann writes:
>>> + while (true) {
>>> cpu_status = smp_query_cpu_stopped(pcpu);
>>> if (cpu_status == QCSS_STOPPED ||
&g
Thiago Jung Bauermann writes:
> This can be a problem because if the busy loop finishes too early, then the
> kernel may offline another CPU before the previous one finished dying,
> which would lead to two concurrent calls to rtas-stop-self, which is
> prohibited by the PAPR.
>
> Since the
Michal Suchánek writes:
> On Thu, 18 Apr 2019 13:56:56 -0500
> Nathan Lynch wrote:
>
> Hello,
>
>> Changing cpu <-> node relationships at runtime, as the pseries
>> platform code attempts to do for LPM, PRRN, and VPHN is essentially
>> unsuppo
-by: Nathan Lynch
---
arch/powerpc/mm/numa.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 48c9a97eb2c3..71af382ce1d5 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -908,16 +908,22 @@ static int
nments are disabled.
[1] E.g. see the discussion here:
https://lore.kernel.org/lkml/20180831115350.gc8...@linux.vnet.ibm.com/T/#u
Nathan Lynch (2):
powerpc/numa: improve control of topology updates
powerpc/numa: document topology_updates_enabled, disable by default
arch/powerpc/mm/numa.
s
incoherent.
Check the topology_updates_enabled flag in
start/stop_topology_update() so that callers of those APIs need not be
aware of whether reassignments are enabled. This allows the
administrative decision on reassignments to remain in force across
migrations and suspensions.
Signed-off-by: Nathan Lync
.
Akpm, can you take this?
FWIW:
Acked-by: Nathan Lynch nathan_ly...@mentor.com
This patch allows me to avoid adding a bunch of empty hooks to arch/arm
when adding VDSO support:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/268045.html
Hi Steve,
On Tue, 2011-06-14 at 12:58 -0400, Steve Best wrote:
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index e72dcf6..e1aab6b 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -283,4 +283,15 @@ config PPC_EARLY_DEBUG_CPM_ADDR
On Fri, 2011-03-25 at 09:23 +, David Laight wrote:
We also have the related fubar (on x64/amd64) of the
kernel generating stack traces for processes that are
sleeping uninterruptibly for long periods.
Turn off CONFIG_DETECT_HUNG_TASK?
___
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
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
Subrata Modak subr...@linux.vnet.ibm.com writes:
On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
Hi Subrata,
On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak
subr...@linux.vnet.ibm.com wrote:
/* Find the TBI PHY. If it's not there, we don't support SGMII */
- ph =
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
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
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
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
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
. 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
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
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
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
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
The per_cpu__ prefix on DECLARE_PER_CPU'd variables is going away;
rename cache_dir to cache_dir_pcpu.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/kernel/cacheinfo.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
Not sure which route this should go, I assume
Benjamin Herrenschmidt wrote:
I don't know quite the detail of the new cpumask stuff ... It could be
as simple as passing a pointer instead of the value in the
cpumask_scnprintf call though...
Actually, I'll do more tests and if that ends up being the only needed
change, I'll push your
Benjamin Herrenschmidt wrote:
On Wed, 2009-01-07 at 03:46 -0600, Nathan Lynch wrote:
Benjamin Herrenschmidt wrote:
I don't know quite the detail of the new cpumask stuff ... It could be
as simple as passing a pointer instead of the value in the
cpumask_scnprintf call though
is better, and the
functions are much shorter and less complex.
Nathan Lynch wrote:
The current code for providing processor cache information in sysfs
has the following deficiencies:
- several complex functions that are hard to understand
- implicit recursion (cache_desc_release - kobject_put
Hi,
Michael Ellerman wrote:
The non-zero return from the prepare callback is returned by sys_kexec_load()
to userspace, indicating that kexec is not supported on the machine.
...
@@ -638,6 +639,13 @@ static int __init iseries_probe(void)
return 1;
}
+#ifdef CONFIG_KEXEC
+static
it would have
roughly doubled the size of sysfs.c, which is already kind of messy.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/kernel/Makefile|2 +-
arch/powerpc/kernel/cacheinfo.c | 837 +++
arch/powerpc/kernel/cacheinfo.h |8 +
arch
and that the first error
message complains about its alignment). This allows the system to
boot.
Signed-off-by: Nathan Lynch n...@pobox.com
---
drivers/net/ehea/ehea_qmr.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
By the way, there are several other kzalloc(PAGE_SIZE) call sites
Benjamin Herrenschmidt wrote:
On Wed, 2008-12-10 at 18:46 -0600, Nathan Lynch wrote:
+ /* OF on pmac has nodes instead of properties named l2-cache
+* beneath CPU nodes.
+*/
+ if (!strcmp(np-type, cpu))
+ for_each_child_of_node(np, child
Benjamin Herrenschmidt wrote:
Don't 970MP have a shared L2 tho ?
The 970MP UM describes 1MB L2 per core, and the device tree on the
quad G5 reflects that... might be interesting to know what it looks
like on IBM JS21 for comparison's sake, but I think we're okay.
Tony Breeds wrote:
ibm_configure_kernel_dump, is passed as the token to rtas_call() but I
cannot see where it is initialised. Set it to something sane?
Yes, please.
Acked-by: Nathan Lynch n...@pobox.com
Would be good to know whether the dump area registration and dump
retrieval are working
Benjamin Herrenschmidt wrote:
On Wed, 2008-12-10 at 18:46 -0600, Nathan Lynch wrote:
+ /* OF on pmac has nodes instead of properties named l2-cache
+* beneath CPU nodes.
+*/
+ if (!strcmp(np-type, cpu))
+ for_each_child_of_node(np, child
information on failure.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm/rtas.h |1 +
arch/powerpc/kernel/rtas.c| 26 ++
arch/powerpc/platforms/pseries/xics.c | 15 ---
3 files changed, 39 insertions(+), 3 deletions
smp_hw_index isn't used on 64-bit, so move it from smp.c to
setup_32.c.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_32.c |2 ++
arch/powerpc/kernel/smp.c |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32
The hard_smp_processor_id functions are the appropriate interfaces for
managing physical CPU ids.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/smp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powermac
Using the common code means that more complete cache information will
provided in sysfs on platforms that don't use the l2-cache property
convention.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/sysfs.c |7 +--
1 files changed, 1 insertions(+), 6 deletions
We have more than one piece of code that looks up cache nodes manually
using the l2-cache property. Add a common helper routine which does
this and handles ePAPR's next-level-cache property as well as
powermac.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/include/asm/prom.h
The smp code uses cache information to populate cpu_core_map; change
it to use common code for cache lookup.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b
Stephen Rothwell wrote:
On Wed, 10 Dec 2008 18:46:05 -0600 Nathan Lynch [EMAIL PROTECTED] wrote:
@@ -418,13 +416,7 @@ static struct device_node *cpu_to_l2cache(int cpu)
if (np == NULL)
return NULL;
- php = of_get_property(np, l2-cache, NULL);
- if (php == NULL
The smp code uses cache information to populate cpu_core_map; change
it to use common code for cache lookup.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
v2: Fix refcount imbalance, thanks to sfr
Benjamin Herrenschmidt wrote:
On Fri, 2008-12-05 at 06:08 -0500, Josh Boyer wrote:
Shouldn't there also be a next-level-cache property added to the cpu
node that references this?
It would be nice indeed, it would allow the kernel to expose the cache
info in sysfs
Currently the kernel
Kumar Gala wrote:
On Dec 2, 2008, at 11:31 PM, Nathan Lynch wrote:
Kumar Gala wrote:
WARNING: vmlinux.o(.text+0x2aa): Section mismatch in reference from
the variable __secondary_start to the function
.devinit.text:start_secondary()
The function __secondary_start() references
Benjamin Herrenschmidt wrote:
On Mon, 2008-12-01 at 15:30 -0600, Nathan Lynch wrote:
cpu_callin_map is used during secondary CPU bootstrap to notify the
waiting CPU that the new CPU is coming up. __cpu_up clears
cpu_callin_map[cpu] and then polls the same location, waiting
Benjamin Herrenschmidt wrote:
On Tue, 2008-12-02 at 20:16 -0600, Nathan Lynch wrote:
Apart from barriers (or lack thereof), the fact that __cpu_up gives up
after a more-or-less arbitrary period seems... well, arbitrary. If we
get to Processor X is stuck then something is seriously wrong
Kumar Gala wrote:
WARNING: vmlinux.o(.text+0x2aa): Section mismatch in reference from the
variable __secondary_start to the function .devinit.text:start_secondary()
The function __secondary_start() references
the function __devinit start_secondary().
start_secondary gets called by
Hi,
I think there may be a plausible issue here. If not, maybe I'll get
an education :)
cpu_callin_map is used during secondary CPU bootstrap to notify the
waiting CPU that the new CPU is coming up. __cpu_up clears
cpu_callin_map[cpu] and then polls the same location, waiting for
Hi, I have some questions about this patch.
Sebastien Dugue wrote:
Currently, pseries_cpu_die() calls msleep() while polling RTAS for
the status of the dying cpu.
However if the cpu that is going down also happens to be the one doing
the tick then we're hosed as the tick_do_timer_cpu
Milton Miller wrote:
attr_smt_snooze_delay is defined for CONFIG_PPC64, so protect the attribute
removal with the same condition.
/data/home/miltonm/next.git/arch/powerpc/kernel/sysfs.c: In function
‘unregister_cpu_online’:
/data/home/miltonm/next.git/arch/powerpc/kernel/sysfs.c:722:
Dave Hansen wrote:
I was handed off a bug report about a blade not booting with a, um
newer kernel.
If you're unable to provide basic information such as the kernel
version then perhaps this isn't the best forum for discussing this. :)
I'm thinking that we need to at least fix
so.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/sysfs.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 56d172d..12058db 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch
Benjamin Herrenschmidt wrote:
On Fri, 2008-08-08 at 10:58 +0200, Segher Boessenkool wrote:
I don't know yet for sure what happens, but a quick look at the commit
seems to show that the driver synchronously spin-waits for up to 2.5ms
That's what the comment says, but the code says 2.5
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
/core_id:0
cpu0/topology/thread_siblings:0003
cpu0/topology/thread_siblings_list:0-1
cpu0/topology/core_siblings:000f
cpu0/topology/core_siblings_list:0-3
Nathan Lynch (6):
kill useless SMT code in prom_hold_cpus
register_cpu_online should be __cpuinit
Update cpu_sibling_maps dynamically
It is called only in cpu online paths.
(caught by CONFIG_DEBUG_SECTION_MISMATCH=y)
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/sysfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
Implement the notion of core siblings for powerpc. This makes
/sys/devices/system/cpu/cpu*/topology/core_siblings present sensible
values, indicating online CPUs which share an L2 cache.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp.c | 71
that of x86, and is
arguably more useful.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c | 24
arch/powerpc/kernel/setup_64.c |3 ---
arch/powerpc/kernel/smp.c | 32 +---
3 files
those attributes for
which it is able to determine values; attributes for values which
cannot be determined are not created at all.
[1] arch/x86/kernel/cpu/intel_cacheinfo.c
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/sysfs.c | 308
Existing Open Firmware practice is to report each processor core as a
separate node in the device tree. Report the value of the reg OF
property corresponding to a logical CPU's device node as the core_id
attribute in /sys/devices/system/cpu/cpu*/topology/core_id.
Signed-off-by: Nathan Lynch
Jon Smirl wrote:
I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
How does it fail?
@@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
long offset, unsigned int pvr)
} else
*t = *s;
Commit 9115d13453dee22473a1e8cacc90a8d64a9c4bc9 (powerpc: Enable
AT_BASE_PLATFORM aux vector) broke boot on 32-bit powerpc systems; we
have to use PTRRELOC to initialize powerpc_base_platform this early in
boot.
Bug reported by Jon Smirl.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED
This works too.
Thanks Jon, sorry about that.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
arch/powerpc/kernel/vio.c:1034: warning: function declaration isn’t a prototype
arch/powerpc/kernel/vio.c:1035: warning: function declaration isn’t a prototype
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/vio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions
I'm seeing warnings from the lockdep code itself in recent kernels on
a Power6 blade (v2.6.26 and benh's -next branch).
Something to do with powerpc's lazy interrupt-disabling, perhaps?
A couple of stack traces below, the first is from benh's tree, the
second is from 2.6.26. The lockdep
Nathan Lynch wrote:
A couple of stack traces below, the first is from benh's tree, the
second is from 2.6.26. The lockdep self-tests all pass at boot.
Sorry, should have pointed out the code that is warning more
specifically.
RTAS daemon started
RTAS: event: 295, Type: Dump Notification
Benjamin Herrenschmidt wrote:
On Thu, 2008-07-24 at 14:23 -0500, Nathan Lynch wrote:
I'm seeing warnings from the lockdep code itself in recent kernels on
a Power6 blade (v2.6.26 and benh's -next branch).
Something to do with powerpc's lazy interrupt-disabling, perhaps?
A couple
at boot, update the
maps at cpu online/offline time.
Note: while this is a bug fix, it is also a behavior change -- the
thread_siblings attribute now reflects only online siblings, whereas
it would display offline siblings before. The new behavior matches
that of x86.
Signed-off-by: Nathan Lynch
that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Andrew Morton wrote:
OK.
But it conflicts directly with the already-queued
execve-filename-document-and-export-via-auxiliary-vector.patch (which
various potential reviewers
Sean MacLennan wrote:
On Sun, 20 Jul 2008 11:28:36 -0700
Mike Mason [EMAIL PROTECTED] wrote:
This patch changes the EEH_MAX_FAILS action from panic to printing an
error message. Panicking under under this condition is too harsh.
Although performance will be affected and the device may
Mike Mason wrote:
This patch changes the EEH_MAX_FAILS action from panic to printing
an error message. Panicking under under this condition is too
harsh. Although performance will be affected and the device may not
recover, the system is still running, which at the very least,
should allow
John Reiser wrote:
Andrew Morton wrote:
On Thu, 17 Jul 2008 17:19:32 -0500
Nathan Lynch [EMAIL PROTECTED] wrote:
[snip]
A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
[snip]
OK.
But it conflicts directly with the already-queued
execve-filename
Andrew Morton wrote:
On Tue, 2008-07-15 at 18:58 -0500, Nathan Lynch wrote:
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d48ff5f..834c2c4 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,10 @@ static int padzero(unsigned long elf_bss)
#define
Linus Torvalds wrote:
On Thu, 17 Jul 2008, Benjamin Herrenschmidt wrote:
Should I seek somebody's ack before merging a patch like the one below ?
I'm a bit reluctant to merge via the powerpc.git tree some changes to
generic files without at least an ack from somebody else :-)
that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Added comment explaining ELF_BASE_PLATFORM.
fs/binfmt_elf.c| 28
include/linux/auxvec.h |5 -
2 files changed, 32 insertions(+), 1
Arnd Bergmann wrote:
Implement save_stack_trace_tsk on powerpc, so that we can run with
latencytop.
So I tried latencytop with linux-next and got the following oops, but
I didn't really look into it yet.
Unable to handle kernel paging request for data at address 0x0008
Faulting instruction
Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
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
, 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
,
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
701 - 800 of 884 matches
Mail list logo
