On Wed, Jan 07, 2015 at 04:12:47PM +1100, Anton Blanchard wrote:
> Hi Alan,
>
> > Right. This is really an rs6000 backend bug. We describe one of the
> > indirect calls that go wrong here as
> >
> > (call_insn 108 107 109 13 (parallel [
> > (set (reg:DI 3 3)
> > (cal
On PowerNV platform, the OPAL interrupts are exported by firmware
through device-node property (/ibm,opal::opal-interrupts). Under
some extreme circumstances (e.g. simulator), we don't have this
property found from the device tree. For that case, we shouldn't
allocate the interrupt map. Otherwise,
As commit 50ba08f3 ("of/fdt: Don't clear initial_boot_params
if fdt_check_header() fails") does, the device-tree pointer
"initial_boot_params" is initialized by early_init_dt_verify(),
which is called by early_init_devtree(). So we needn't explicitly
initialize that again in early_init_devtree().
When calling to early_setup(), we picks "boot_paca" up for the
master CPU and initialize that with initialise_paca(). At the
point, SLB shadow buffer isn't populated yet. Updating the SLB
shadow buffer should corrupt what we had in physical address 0
where the trap instruction is usually stored.
S
On 01/07/2015 01:46 PM, Aneesh Kumar K.V wrote:
> Mahesh J Salgaonkar writes:
>
>> From: Mahesh Salgaonkar
>>
>> commit id 9975f5e added new config variable CONFIG_KVM_BOOK3S_HV_POSSIBLE
>> that helps to select the relevant code in the kernel when HV and PR
>> bits are built as separate modules.
In commit a3e5b356b3ab "powerpc: Don't use local named register variable
in current_thread_info" Anton changed the way we did current_thread_info()
to accommodate LLVM, and it was not meant to have any effect elsewhere.
Unfortunately it has exposed a gcc bug, where r1 gets copied into
another regi
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, January 08, 2015 9:13 AM
> To: Medve Emilian-EMMEDVE1
> Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
>
> On Wed, 2015-
On Wed, 2015-01-07 at 09:08 +0100, Alessio Igor Bogani wrote:
> Hi Michael,
>
> On 5 December 2014 at 10:42, Michael Ellerman wrote:
> > On Fri, 2014-05-12 at 08:17:42 UTC, Alessio Igor Bogani wrote:
> >> Signed-off-by: Alessio Igor Bogani
> >> ---
> >> arch/powerpc/configs/mpc85xx_defconfig |
On Wed, Jan 7, 2015 at 4:58 PM, Rusty Russell wrote:
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> void bpf_jit_binary_free(struct bpf_binary_header *hdr)
> {
> - module_free(NULL, hdr);
> + module_memfree(hdr);
> }
...
> -void __weak module_free(struct module *mod, void *mo
From: Cody P Schafer
CC: Haren Myneni
CC: Cody P Schafer
Acked-by: Jiri Olsa
Signed-off-by: Cody P Schafer
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
From: Cody P Schafer
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where the single 'cpu' parameter is
insufficient. For example, P
From: Cody P Schafer
This causes `perf list pmu` to show parameters for parameterized events
like:
pmu/event_name,param1=?,param2=?/ [Kernel PMU event]
An example:
hv_24x7/HPM_TLBIE__PHYS_CORE,core=?/ [Kernel PMU event]
CC: Haren Myneni
CC: Cody P Schafer
Acked-by: Jiri Olsa
Signed-off
Description of "event parameters" from the documentation patch:
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where
From: Cody P Schafer
Enable event specification like:
pmu/event_name,param1=0x1,param2=0x4/
Assuming that
/sys/bus/event_source/devices/pmu/events/event_name
Contains something like
param2=?,bar=1,param1=?
CC: Haren Myneni
CC: Cody P Schafer
Acked-by: Jiri Olsa
Si
On Wed, 2015-01-07 at 13:44 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 01/07/2015 12:05 PM, Scott Wood wrote:
> > On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote:
> > +- interrupts
> > + Usage: optional
> > + Value type:
> > +
Nothing needs the module pointer any more, and the next patch will
call it from RCU, where the module itself might no longer exist.
Removing the arg is the safest approach.
This just codifies the use of the module_alloc/module_free pattern
which ftrace and bpf use.
Signed-off-by: Rusty Russell
C
On Wed, Jan 07, 2015 at 03:40:10PM +0100, Benjamin Herrenschmidt wrote:
> One way to work around the performance loss for you would be to add some
> DT property to indicate to the guest that the read isn't necessary.
Or KVM could use a virtual interrupt controller better suited to its
needs.
Seg
Jiri Olsa [jo...@redhat.com] wrote:
| On Sun, Dec 21, 2014 at 11:49:25PM -0800, Sukadev Bhattiprolu wrote:
| > From: Cody P Schafer
| >
| > This causes `perf list pmu` to show parameters for parameterized events
| > like:
| >
| > pmu/event_name,param1=?,param2=?/ [Kernel PMU event]
| >
| > An
Hello Scott,
On 01/07/2015 12:05 PM, Scott Wood wrote:
> On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote:
> +- interrupts
> + Usage: optional
> + Value type:
> + Definition: Event interrupt of external MDIO controller.
> + 1 Gb/s MD
On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote:
> > > > +- interrupts
> > > > + Usage: optional
> > > > + Value type:
> > > > + Definition: Event interrupt of external MDIO controller.
> > > > + 1 Gb/s MDIO and 10 Gb/s MDIO has o
On Wed, 2015-01-07 at 16:12 +1100, Anton Blanchard wrote:
> Thanks for looking into this. Does that mean we were just getting lucky
> with the previous version:
>
> static inline struct thread_info *current_thread_info(void)
> {
> register unsigned long sp asm("r1");
>
> return (s
On Wed, 2015-01-07 at 15:44 +0100, Benjamin Herrenschmidt wrote:
> On Mon, 2015-01-05 at 12:10 -0600, Scott Wood wrote:
> > It would have been nice if a code comment explained why it was doing the
> > readback... I don't see any particular need to wait for EOI completion
> > here (unlike when mask
On Mon, 2015-01-05 at 12:10 -0600, Scott Wood wrote:
> It would have been nice if a code comment explained why it was doing the
> readback... I don't see any particular need to wait for EOI completion
> here (unlike when masking).
The EOI is what causes the MPIC to drop it's EE output to the CPU,
On 01/07/2015 05:35 AM, Anton Blanchard wrote:
> Commit 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
> converted uses of CONFIG_JUMP_LABEL to HAVE_JUMP_LABEL in
> some assembly files.
>
> HAVE_JUMP_LABEL is defined in linux/jump_label.h, so we need to
> include this or we always get the
On Mon, 2015-01-05 at 18:46 +0100, Andreas Mohr wrote:
> Hi,
>
> > I was curious why the mpic_cpu_read(MPIC_INFO(CPU_WHOAMI)) was there in
> > the first place and if it's still needed. If it's still required, I
> > guess a better approach is to eliminate the call only if the kernel is
> > running
On Mon, 2015-01-05 at 16:14 +0200, Purcareata Bogdan wrote:
> Hello,
>
> While doing some performance testing of a KVM guest on a PPC platform, I
> noticed that there's a read of the CPU_WHOAMI register after each MPIC
> EOI [1]. This has been present since the initial implementation of the
> M
On Wed, Jan 07, 2015 at 10:35:56AM +, Anton Blanchard wrote:
> Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
> Since these are kernel only headers, we don't need #ifdef __KERNEL__
> so can simplify things a bit.
>
> If an architecture wants to use jump labels in assembly, it
>
Commit 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
converted uses of CONFIG_JUMP_LABEL to HAVE_JUMP_LABEL in
some assembly files.
HAVE_JUMP_LABEL is defined in linux/jump_label.h, so we need to
include this or we always get the non jump label fallback code.
Fixes: 1bc9e47aa8e4 ("powe
To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
so we select a fallback version if the toolchain does not support
them.
Modify linux/jump_label.h so it can be included by assembly files.
We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
Signed-off-by: Anton Blanchard
--
Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
Since these are kernel only headers, we don't need #ifdef __KERNEL__
so can simplify things a bit.
If an architecture wants to use jump labels in assembly, it
will still need to define a macro to create the __jump_table
entries (see AR
Hi Steve,
> Have you tested this on other archs? Because just looking at x86, it
> doesn't seem that asm/jump_label.h can handle being called in
> assembly.
Since no one is including linux/jump_label.h in assembly yet, nothing
should break. We could however add __ASSEMBLY__ protection to all the
This is a note to let you know that I have just added a patch titled
powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode
to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=sho
Hi!
"ppc64_cpu --smt=off" produces multiple error on the latest upstream kernel
(sha1 bdec419):
NMI watchdog: BUG: soft lockup - CPU#20 stuck for 23s! [swapper/20:0]
or
INFO: rcu_sched detected stalls on CPUs/tasks: { 2 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 2
4 25 26 27 28 29 30 31} (
Mahesh J Salgaonkar writes:
> From: Mahesh Salgaonkar
>
> commit id 9975f5e added new config variable CONFIG_KVM_BOOK3S_HV_POSSIBLE
> that helps to select the relevant code in the kernel when HV and PR
> bits are built as separate modules. As part of that commit, all the
> instances of #ifdef CO
Hi Michael,
On 5 December 2014 at 10:42, Michael Ellerman wrote:
> On Fri, 2014-05-12 at 08:17:42 UTC, Alessio Igor Bogani wrote:
>> Signed-off-by: Alessio Igor Bogani
>> ---
>> arch/powerpc/configs/mpc85xx_defconfig | 57
>> +++---
>> 1 file changed, 12 insertions(
35 matches
Mail list logo
