* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Preeti U Murthy @ 2014-05-10 15:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <1399695993.4481.47.camel@pasglop>
On 05/10/2014 09:56 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2014-05-09 at 15:22 +0530, Preeti U Murthy wrote:
>> in __timer_interrupt() outside the _else_ loop? This will ensure that no
>> matter what, before exiting timer interrupt handler we check for pending
>> irq work.
>
> We still need to make sure that set_next_event() doesn't move the
> dec beyond the next tick if there is a pending timer... maybe we
Sorry, but didn't get this. s/if there is pending timer/if there is
pending irq work ?
> can fix it like this:
We can call set_next_event() from events like hrtimer_cancel() or
hrtimer_forward() as well. In that case we don't come to
decrementer_set_next_event() from __timer_interrupt(). Then, if we race
with irq work, we *do not do* a set_dec(1) ( I am referring to the patch
below ), we might never set the decrementer to fire immediately right?
Or does this scenario never arise?
Regards
Preeti U Murthy
>
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
>
> /* Don't adjust the decrementer if some irq work is pending */
> if (!test_irq_work_pending())
> set_dec(evt);
>
> return 0;
> }
>
> Along with a single occurrence of:
>
> if (test_irq_work_pending())
> set_dec(1);
>
> At the end of __timer_interrupt(), outside if the current else {}
> case, this should work, don't you think ?
>
> What about this completely untested patch ?
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 122a580..ba7e83b 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -503,12 +503,13 @@ void __timer_interrupt(void)
> now = *next_tb - now;
> if (now <= DECREMENTER_MAX)
> set_dec((int)now);
> - /* We may have raced with new irq work */
> - if (test_irq_work_pending())
> - set_dec(1);
> __get_cpu_var(irq_stat).timer_irqs_others++;
> }
>
> + /* We may have raced with new irq work */
> + if (test_irq_work_pending())
> + set_dec(1);
> +
> #ifdef CONFIG_PPC64
> /* collect purr register values often, for accurate calculations */
> if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
> @@ -813,15 +814,11 @@ static void __init clocksource_init(void)
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> - /* Don't adjust the decrementer if some irq work is pending */
> - if (test_irq_work_pending())
> - return 0;
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
> - set_dec(evt);
>
> - /* We may have raced with new irq work */
> - if (test_irq_work_pending())
> - set_dec(1);
> + /* Don't adjust the decrementer if some irq work is pending */
> + if (!test_irq_work_pending())
> + set_dec(evt);
>
> return 0;
> }
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/pm: add api to get suspend state which is STANDBY or MEM
From: Li Yang @ 2014-05-10 12:35 UTC (permalink / raw)
To: Scott Wood
Cc: Zhao Chenhui, linux-pm@vger.kernel.org, Rafael J. Wysocki,
Dongsheng Wang, 正雄 金, linuxppc-dev
In-Reply-To: <1399655386.15726.438.camel@snotra.buserror.net>
On Sat, May 10, 2014 at 1:09 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Fri, 2014-05-09 at 17:33 +0800, Li Yang wrote:
>> On Wed, Apr 30, 2014 at 6:47 AM, Scott Wood <scottwood@freescale.com> wrote:
>> > On Mon, 2014-04-28 at 13:53 +0800, Leo Li wrote:
>> >> On Sat, Apr 26, 2014 at 5:45 AM, Scott Wood <scottwood@freescale.com> wrote:
>> >> > On Thu, 2014-04-24 at 14:11 +0800, Dongsheng Wang wrote:
>> >> >> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>> >> >>
>> >> >> Add set_pm_suspend_state & pm_suspend_state functions to set/get
>> >> >> suspend state. When system going to sleep or deep sleep, devices
>> >> >> can get the system suspend state(STANDBY/MEM) through pm_suspend_state
>> >> >> function and to handle different situations.
>> >> >>
>> >> >> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>> >> >> ---
>> >> >> *v2*
>> >> >> Move pm api from fsl platform to powerpc general framework.
>> >> >
>> >> > What is powerpc-specific about this?
>> >>
>> >> Generally I agree with you. But I had the discussion about this topic
>> >> a while ago with the PM maintainer. He suggestion to go with the
>> >> platform way.
>> >>
>> >> https://lkml.org/lkml/2013/8/16/505
>> >
>> > If what he meant was whether you could do what this patch does, then you
>> > can answer him with, "No, because it got nacked as not being platform or
>> > arch specific." Oh, and you're still using .valid as the hook to set
>> > the platform state, which is awful -- I think .begin is what you want to
>> > use.
>>
>> I'm not saying the current patch is good for upstream. Actually I did
>> say that the patch need to be updated for upstream purpose.
>
> I don't follow -- this thread is an upstream submission.
Thought you were suggesting to change the generic PM interface for
this as discussed internally. So I was just providing the information
about previous discussion. Nothing more.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Paul Mackerras @ 2014-05-10 6:33 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20140509220845.GY8754@linux.vnet.ibm.com>
On Fri, May 09, 2014 at 03:08:45PM -0700, Paul E. McKenney wrote:
> On Fri, May 09, 2014 at 11:50:05PM +0200, Gabriel Paubert wrote:
> > On Fri, May 09, 2014 at 06:41:13AM -0700, Paul E. McKenney wrote:
> > > On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
> > > > I am seeing an issue where a CPU running perf eventually hangs.
> > > > Traces show timer interrupts happening every 4 seconds even
> > > > when a userspace task is running on the CPU.
> > >
> > > Is this by chance every 4.2 seconds? The reason I ask is that
> > > Paul Clarke and I are seeing an interrupt every 4.2 seconds when
> > > he runs NO_HZ_FULL, and are trying to get rid of it. ;-)
> >
> > Hmmm, it's close to 2^32 nanoseconds, isnt't it suspiscious?
>
> Now that you mention it... ;-)
>
> So you are telling me that we are not succeeding in completely turning
> off the decrementer interrupt?
There is no way to turn off the decrementer interrupt without turning
off external (device) interrupts.
On IBM Power CPUs since POWER6, the decrementer runs at 512MHz. If
you set the decrementer to 0x7fffffff it will interrupt in 4.194
seconds, so that would be what you're seeing. The only way to avoid
the interrupt becoming pending is to keep on setting it to a large
value before it gets to -1.
If an interrupt every 4.2 seconds is a problem in some applications,
then we need to talk to the Power architects.
Regards,
Paul.
^ permalink raw reply
* device tree, fedora 20 install
From: Anatoly Pugachev @ 2014-05-10 6:28 UTC (permalink / raw)
To: linuxppc-dev
Hello!
There's a regression somewhere in kernel, I'm unable to boot
installation kernel version 3.11.10-301.fc20.ppc64 of fedora 20 on IBM
JS22 (type 7998) blade. But my previous attempt with kernel
3.9.5-301.fc19.ppc64 was able to boot.
I have the following output with 3.11.10-301.fc20.ppc64 kernel:
Booting `Install Fedora 20 (64-bit kernel)'
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 3.11.10-301.fc20.ppc64
(mockbuild@ppc-builder7.qa.fedoraproject.org) (gcc version 4.8.2
20131017 (Red Hat 4.8.2-1) (GCC) ) #1 SMP Tue Dec 10 00:35:15 MST 2013
Detected machine type: 0000000000000101
Max number of cores passed to firmware: 512 (NR_CPUS = 1024)
Calling ibm,client-architecture-
support... done
command line: BOOT_IMAGE=/ppc/ppc64/vmlinuz ro
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000006e80000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
found display : /pci@800000020000202/display@1, opening... done
instantiating rtas at 0x0000000006eb0000... done
Querying for OPAL presence... not there.
boot cpu hw idx 0
starting cpu hw idx 2... done
starting cpu hw idx 4... done
starting cpu hw idx 6... done
copying OF device tree...
Building dt strings...
Building dt structure...
No memory for flatten_device_tree (no room)
EXIT called ok
0 >
while with 3.9.5-301.fc19.ppc64 it pass DT stage:
Welcome to the 64-bit Fedora 19 installer!
Hit <TAB> for boot options.
Welcome to yaboot version 1.3.17 (Red Hat 1.3.17-6.fc19)
Enter "help" to get some basic usage information
boot: linux
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 03980000, size: 9872 Kbytes
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 3.9.5-301.fc19.ppc64
(mockbuild@ppc-builder3.qa.fedoraproject.org) (gcc version 4.8.1
20130603 (Red Hat 4.8.1-1)
(GCC) ) #1 SMP Tue Jun 11 15:07:48 MST 2013
Detected machine type: 0000000000000101
Max number of cores passed to firmware: 512 (NR_CPUS = 1024)
Calling ibm,client-architecture-support... done
command line: ro
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000004330000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
found display : /pci@800000020000202/display@1, opening... done
instantiating rtas at 0x0000000006db0000... done
Querying for OPAL presence... not there.
boot cpu hw idx 0
starting cpu hw idx 2... done
starting cpu hw idx 4... done
starting cpu hw idx 6... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004440000 -> 0x000000000444182e
Device tree struct 0x0000000004450000 -> 0x0000000004470000
Calling quiesce...
returning from prom_init
[ 0.000000] Using pSeries machine description
[ 0.000000] Using 1TB segments
[ 0.000000] Found initrd at 0xc000000003980000:0xc000000004324000
[ 0.000000] bootconsole [udbg0] enabled
[ 0.000000] Partition configured for 8 cpus.
(and so on...)
Can someone help me with this issue? Thanks.
^ permalink raw reply
* [PATCH] printk/of_serial: fix serial console cessation part way through boot.
From: Stephen Chivers @ 2014-05-10 5:37 UTC (permalink / raw)
To: geert, jslaby, gregkh
Cc: devicetree, linux-serial, linux-kernel, rob+dt, schivers,
grant.likely, linuxppc-dev, cproctor
Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.
There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.
This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.
The sequence is:
bootconsole [udbg0] enabled
....
serial8250/16550 driver initialises and registers its UARTS,
one of these is the serial console.
console [ttyS0] enabled
....
of_serial probes "platform" devices, registering them as it goes.
One of these is the serial console.
console [ttyS0] disabled.
The disabling of the serial console is due to:
a. unregister_console in printk not clearing the
CONS_ENABLED bit in the console flags,
even though it has announced that the console is disabled; and
b. of_platform_serial_probe in of_serial not setting the port type
before it registers with serial8250_register_8250_port.
This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.
Signed-off-by: Stephen Chivers <schivers@csc.com>
Tested-by: Stephen Chivers <schivers@csc.com>
===
The above failure was identified in Linux-3.15-rc2.
Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.
The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.
---
drivers/tty/serial/of_serial.c | 1 +
kernel/printk/printk.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 9924660..27981e2 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -173,6 +173,7 @@ static int of_platform_serial_probe(struct platform_device *ofdev)
{
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
+ port.type = port_type;
port8250.port = port;
if (port.fifosize)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 7228258..221229c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2413,6 +2413,7 @@ int unregister_console(struct console *console)
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
+ console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;
^ permalink raw reply related
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Benjamin Herrenschmidt @ 2014-05-10 4:26 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <536CA561.8010803@linux.vnet.ibm.com>
On Fri, 2014-05-09 at 15:22 +0530, Preeti U Murthy wrote:
> in __timer_interrupt() outside the _else_ loop? This will ensure that no
> matter what, before exiting timer interrupt handler we check for pending
> irq work.
We still need to make sure that set_next_event() doesn't move the
dec beyond the next tick if there is a pending timer... maybe we
can fix it like this:
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
__get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
/* Don't adjust the decrementer if some irq work is pending */
if (!test_irq_work_pending())
set_dec(evt);
return 0;
}
Along with a single occurrence of:
if (test_irq_work_pending())
set_dec(1);
At the end of __timer_interrupt(), outside if the current else {}
case, this should work, don't you think ?
What about this completely untested patch ?
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 122a580..ba7e83b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -503,12 +503,13 @@ void __timer_interrupt(void)
now = *next_tb - now;
if (now <= DECREMENTER_MAX)
set_dec((int)now);
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
- set_dec(1);
__get_cpu_var(irq_stat).timer_irqs_others++;
}
+ /* We may have raced with new irq work */
+ if (test_irq_work_pending())
+ set_dec(1);
+
#ifdef CONFIG_PPC64
/* collect purr register values often, for accurate calculations */
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
@@ -813,15 +814,11 @@ static void __init clocksource_init(void)
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
- /* Don't adjust the decrementer if some irq work is pending */
- if (test_irq_work_pending())
- return 0;
__get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
- set_dec(evt);
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
- set_dec(1);
+ /* Don't adjust the decrementer if some irq work is pending */
+ if (!test_irq_work_pending())
+ set_dec(evt);
return 0;
}
^ permalink raw reply related
* [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info
From: Sukadev Bhattiprolu @ 2014-05-10 2:46 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Michael Ellerman, Anton Blanchard, linux-kernel, Ulrich.Weigand,
Maynard Johnson, linuxppc-dev
[PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info
When saving the callchain on Power, the kernel conservatively saves excess
entries in the callchain. A few of these entries are needed in some cases
but not others.
Eg: the value in the link register (LR) is needed only when it holds the
return address of a function. At other times it must be ignored.
If the unnecessary entries are not ignored, we end up with duplicate arcs
in the call-graphs.
Use DWARF debug information to ignore the unnecessary entries.
Callgraph before the patch:
14.67% 2234 sprintft libc-2.18.so [.] __random
|
--- __random
|
|--61.12%-- __random
| |
| |--97.15%-- rand
| | do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| |
| --2.85%-- do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--38.88%-- rand
|
|--94.01%-- rand
| do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--5.99%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
Callgraph after the patch:
14.67% 2234 sprintft libc-2.18.so [.] __random
|
--- __random
|
|--95.93%-- rand
| do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--4.07%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
TODO: For split-debug info objects like glibc, we can only determine
the call-frame-address only when both .eh_frame and .debug_info
sections are available. We should be able to determin the CFA
even without the .eh_frame section.
Thanks to Ulrich Weigand for help with DWARF debug information.
Fix suggested by Anton Blanchard.
Reported-by: Maynard Johnson <maynard@us.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
tools/perf/arch/powerpc/Makefile | 1 +
tools/perf/arch/powerpc/util/adjust-callchain.c | 278 ++++++++++++++++++++++++
tools/perf/config/Makefile | 5 +
tools/perf/util/callchain.h | 12 +
tools/perf/util/machine.c | 16 +-
5 files changed, 310 insertions(+), 2 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/adjust-callchain.c
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 744e629..512cc8d 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -3,3 +3,4 @@ PERF_HAVE_DWARF_REGS := 1
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
endif
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/adjust-callchain.o
diff --git a/tools/perf/arch/powerpc/util/adjust-callchain.c b/tools/perf/arch/powerpc/util/adjust-callchain.c
new file mode 100644
index 0000000..31b1f95
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/adjust-callchain.c
@@ -0,0 +1,278 @@
+/*
+ * Use DWARF Debug information to skip unnecessary callchain entries.
+ *
+ * Copyright (C) 2014 Sukadev Bhattiprolu, IBM Corporation.
+ * Copyright (C) 2014 Ulrich Weigand, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <inttypes.h>
+#include <dwarf.h>
+#include <elfutils/libdwfl.h>
+
+#include "util/thread.h"
+#include "util/callchain.h"
+
+/*
+ * When saving the callchain on Power, the kernel conservatively saves
+ * excess entries in the callchain. A few of these entries are needed
+ * in some cases but not others. If the unnecessary entries are not
+ * ignored, we end up with duplicate arcs in the call-graphs. Use
+ * DWARF debug information to skip over any unnecessary callchain
+ * entries.
+ *
+ * See function header for arch_adjust_callchain() below for more details.
+ *
+ * The libdwfl code in this file is based on code from elfutils
+ * (libdwfl/argp-std.c, libdwfl/tests/addrcfi.c, etc).
+ */
+static char *debuginfo_path;
+
+static const Dwfl_Callbacks offline_callbacks = {
+ .debuginfo_path = &debuginfo_path,
+ .find_debuginfo = dwfl_standard_find_debuginfo,
+ .section_address = dwfl_offline_section_address,
+};
+
+
+/*
+ * Use the DWARF expression for the Call-frame-address and determine
+ * if return address is in LR and if a new frame was allocated.
+ */
+static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
+{
+ Dwarf_Op ops_mem[2];
+ Dwarf_Op dummy;
+ Dwarf_Op *ops = &dummy;
+ size_t nops;
+ int result;
+
+ result = dwarf_frame_register(frame, ra_regno, ops_mem, &ops, &nops);
+ if (result < 0) {
+ pr_debug("dwarf_frame_register() %s\n", dwarf_errmsg(-1));
+ return -1;
+ }
+
+ /*
+ * Check if return address is on the stack.
+ */
+ if (nops != 0 || ops != NULL)
+ return 0;
+
+ /*
+ * Return address is in LR. Check if a frame was allocated
+ * but not-yet used.
+ */
+ result = dwarf_frame_cfa(frame, &ops, &nops);
+ if (result < 0) {
+ pr_debug("dwarf_frame_cfa() returns %d, %s\n", result,
+ dwarf_errmsg(-1));
+ return -1;
+ }
+
+ /*
+ * If call frame address is in r1, no new frame was allocated.
+ */
+ if (nops == 1 && ops[0].atom == DW_OP_bregx && ops[0].number == 1 &&
+ ops[0].number2 == 0)
+ return 1;
+
+ /*
+ * A new frame was allocated but has not yet been used.
+ */
+ return 2;
+}
+
+/*
+ * Get the DWARF frame from the .eh_frame section.
+ */
+static Dwarf_Frame *get_eh_frame(Dwfl_Module *mod, Dwarf_Addr pc)
+{
+ int result;
+ Dwarf_Addr bias;
+ Dwarf_CFI *cfi;
+ Dwarf_Frame *frame;
+
+ cfi = dwfl_module_eh_cfi(mod, &bias); // CHECK
+ if (!cfi) {
+ pr_debug("%s(): no CFI - %s\n", __func__, dwfl_errmsg(-1));
+ return NULL;
+ }
+
+ result = dwarf_cfi_addrframe(cfi, pc, &frame);
+ if (result) {
+ pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
+ return NULL;
+ }
+
+ return frame;
+}
+
+/*
+ * Get the DWARF frame from the .debug_frame section.
+ */
+static Dwarf_Frame *get_dwarf_frame(Dwfl_Module *mod, Dwarf_Addr pc)
+{
+ Dwarf_CFI *cfi;
+ Dwarf_Addr bias;
+ Dwarf_Frame *frame;
+ int result;
+
+ cfi = dwfl_module_dwarf_cfi(mod, &bias);
+ if (!cfi) {
+ pr_debug("%s(): no CFI - %s\n", __func__, dwfl_errmsg(-1));
+ return NULL;
+ }
+
+ result = dwarf_cfi_addrframe(cfi, pc, &frame);
+ if (result) {
+ pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
+ return NULL;
+ }
+
+ return frame;
+}
+
+/*
+ * Return:
+ * 0 if return address for the program counter @pc is on stack
+ * 1 if return address is in LR and no new stack frame was allocated
+ * 2 if return address is in LR and a new frame was allocated (but not
+ * yet used)
+ * -1 in case of errors
+ */
+static int check_return_addr(const char *exec_file, Dwarf_Addr pc)
+{
+ Dwfl *dwfl;
+ Dwfl_Module *mod;
+ Dwarf_Frame *frame;
+ int ra_regno;
+ Dwarf_Addr start = pc;
+ Dwarf_Addr end = pc;
+ bool signalp;
+
+ pr_debug("Testing: %s, @0x%llx\n", exec_file, (unsigned long long)pc);
+
+ dwfl = dwfl_begin(&offline_callbacks);
+ if (!dwfl) {
+ pr_debug("dwfl_begin() failed: %s\n", dwarf_errmsg(-1));
+ return -1;
+ }
+
+ if (dwfl_report_offline(dwfl, "", exec_file, -1) == NULL) {
+ pr_debug("dwfl_report_offline() failed %s\n", dwarf_errmsg(-1));
+ return -1;
+ }
+
+ mod = dwfl_addrmodule(dwfl, pc);
+ if (!mod) {
+ pr_debug("dwfl_addrmodule() failed, %s\n", dwarf_errmsg(-1));
+ return -1;
+ }
+
+ /*
+ * To work with split debug info files (eg: glibc), check both
+ * .eh_frame and .debug_frame sections of the ELF header.
+ */
+ frame = get_eh_frame(mod, pc);
+ if (!frame) {
+ frame = get_dwarf_frame(mod, pc);
+ if (!frame)
+ return -1;
+ }
+
+ ra_regno = dwarf_frame_info (frame, &start, &end, &signalp);
+ if (ra_regno < 0) {
+ pr_debug("Return address register unavailable: %s\n",
+ dwarf_errmsg(-1));
+ return -1;
+ }
+
+ return check_return_reg(ra_regno, frame);
+}
+
+/*
+ * The callchain saved by the kernel always includes the link register (LR).
+ *
+ * 0: PERF_CONTEXT_USER
+ * 1: Program counter (Next instruction pointer)
+ * 2: LR value
+ * 3: Caller's caller
+ * 4: ...
+ *
+ * The value in LR is only needed when it holds a return address. If the
+ * return address is on the stack, we should ignore the LR value.
+ *
+ * Further, when the return address is in the LR, if a new frame was just
+ * allocated but the LR was not saved into it, then the LR contains the
+ * caller, slot 4: contains the caller's caller and the contents of slot 3:
+ * (chain->ips[3]) is undefined and must be ignored.
+ *
+ * Use DWARF debug information to determine if any entries need to be skipped.
+ *
+ * Return:
+ * index: of callchain entry that needs to be ignored (if any)
+ * -1 if no entry needs to be ignored or in case of errors
+ *
+ * TODO:
+ * Rather than returning an index into the callchain and have the
+ * caller skip that entry, we could modify the callchain in-place
+ * by putting a PERF_CONTEXT_IGNORE marker in the affected entry.
+ *
+ * But @chain points to read-only mmap, so the caller needs to
+ * duplicate the callchain to modify in-place - something like:
+ *
+ * new_callchain = arch_duplicate_callchain()
+ * arch_adjust_callchain(new_callchain)
+ * arch_free_callchain(new_callchain)
+ *
+ * Since we only expect to adjust <= 1 entry for now, just return
+ * the index.
+ */
+int arch_adjust_callchain(struct machine *machine, struct thread *thread,
+ struct ip_callchain *chain)
+{
+ struct addr_location al;
+ struct dso *dso = NULL;
+ int rc;
+ u64 ip;
+ u64 skip_slot = -1;
+
+ if (chain->nr < 3)
+ return skip_slot;
+
+ ip = chain->ips[2];
+
+ thread__find_addr_location(thread, machine, PERF_RECORD_MISC_USER,
+ MAP__FUNCTION, ip, &al);
+
+ if (al.map)
+ dso = al.map->dso;
+
+ if (!dso) {
+ pr_debug("%" PRIx64 " dso is NULL\n", ip);
+ return skip_slot;
+ }
+
+ rc = check_return_addr(dso->long_name, ip);
+
+ pr_debug("DSO %s, nr %" PRIx64 ", ip 0x%" PRIx64 "rc %d\n",
+ dso->long_name, chain->nr, ip, rc);
+
+ if (rc == 0) {
+ /*
+ * Return address on stack. Ignore LR value in callchain
+ */
+ skip_slot = 2;
+ } else if (rc == 2) {
+ /*
+ * New frame allocated but return address still in LR.
+ * Ignore the caller's caller entry in callchain.
+ */
+ skip_slot = 3;
+ }
+ return skip_slot;
+}
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 5a3c452..7e93877 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -29,11 +29,16 @@ ifeq ($(ARCH),x86)
endif
NO_PERF_REGS := 0
endif
+
ifeq ($(ARCH),arm)
NO_PERF_REGS := 0
LIBUNWIND_LIBS = -lunwind -lunwind-arm
endif
+ifeq ($(ARCH),powerpc)
+ CFLAGS += -DHAVE_ADJUST_CALLCHAIN
+endif
+
ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
else
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 8ad97e9..81ecb90 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -157,4 +157,16 @@ int sample__resolve_callchain(struct perf_sample *sample, struct symbol **parent
int hist_entry__append_callchain(struct hist_entry *he, struct perf_sample *sample);
extern const char record_callchain_help[];
+
+#ifdef HAVE_ADJUST_CALLCHAIN
+extern int arch_adjust_callchain(struct machine *machine,
+ struct thread *thread, struct ip_callchain *chain);
+#else
+static inline int arch_adjust_callchain(struct machine *machine,
+ struct thread *thread, struct ip_callchain *chain)
+{
+ return -1;
+}
+#endif
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index a53cd0b..dce3bf0 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1271,6 +1271,7 @@ static int machine__resolve_callchain_sample(struct machine *machine,
int chain_nr = min(max_stack, (int)chain->nr);
int i;
int err;
+ int skip_slot;
callchain_cursor_reset(&callchain_cursor);
@@ -1279,14 +1280,25 @@ static int machine__resolve_callchain_sample(struct machine *machine,
return 0;
}
+ /*
+ * Based on DWARF debug information, some architectures skip
+ * some of the callchain entries saved by the kernel.
+ */
+ skip_slot = arch_adjust_callchain(machine, thread, chain);
+
for (i = 0; i < chain_nr; i++) {
u64 ip;
struct addr_location al;
- if (callchain_param.order == ORDER_CALLEE)
+ if (callchain_param.order == ORDER_CALLEE) {
+ if (i == skip_slot)
+ continue;
ip = chain->ips[i];
- else
+ } else {
+ if ((int)(chain->nr - i - 1) == skip_slot)
+ continue;
ip = chain->ips[chain->nr - i - 1];
+ }
if (ip >= PERF_CONTEXT_MAX) {
switch (ip) {
--
1.8.4.2
^ permalink raw reply related
* [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Guenter Roeck @ 2014-05-10 0:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, linux-kernel, Guenter Roeck
Commit 4e243b7 (powerpc: Fix "attempt to move .org backwards" error) fixes the
allyesconfig build by moving machine_check_common to a different location.
While this fixes most of the errors, both allmodconfig and allyesconfig still
fail as follows.
arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards
Fix by moving machine_check_common after the offending address.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
This fixes the build error, but unfortunately I don't have a system to test
the resulting image.
arch/powerpc/kernel/exceptions-64s.S | 49 ++++++++++++++++++------------------
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 3afd391..25398be 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1138,31 +1138,6 @@ unrecov_user_slb:
#endif /* __DISABLED__ */
-
- /*
- * Machine check is different because we use a different
- * save area: PACA_EXMC instead of PACA_EXGEN.
- */
- .align 7
- .globl machine_check_common
-machine_check_common:
-
- mfspr r10,SPRN_DAR
- std r10,PACA_EXGEN+EX_DAR(r13)
- mfspr r10,SPRN_DSISR
- stw r10,PACA_EXGEN+EX_DSISR(r13)
- EXCEPTION_PROLOG_COMMON(0x200, PACA_EXMC)
- FINISH_NAP
- DISABLE_INTS
- ld r3,PACA_EXGEN+EX_DAR(r13)
- lwz r4,PACA_EXGEN+EX_DSISR(r13)
- std r3,_DAR(r1)
- std r4,_DSISR(r1)
- bl .save_nvgprs
- addi r3,r1,STACK_FRAME_OVERHEAD
- bl .machine_check_exception
- b .ret_from_except
-
.align 7
.globl alignment_common
alignment_common:
@@ -1328,6 +1303,30 @@ fwnmi_data_area:
initial_stab:
.space 4096
+ /*
+ * Machine check is different because we use a different
+ * save area: PACA_EXMC instead of PACA_EXGEN.
+ */
+ .align 7
+ .globl machine_check_common
+machine_check_common:
+
+ mfspr r10,SPRN_DAR
+ std r10,PACA_EXGEN+EX_DAR(r13)
+ mfspr r10,SPRN_DSISR
+ stw r10,PACA_EXGEN+EX_DSISR(r13)
+ EXCEPTION_PROLOG_COMMON(0x200, PACA_EXMC)
+ FINISH_NAP
+ DISABLE_INTS
+ ld r3,PACA_EXGEN+EX_DAR(r13)
+ lwz r4,PACA_EXGEN+EX_DSISR(r13)
+ std r3,_DAR(r1)
+ std r4,_DSISR(r1)
+ bl .save_nvgprs
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .machine_check_exception
+ b .ret_from_except
+
#ifdef CONFIG_PPC_POWERNV
_GLOBAL(opal_mc_secondary_handler)
HMT_MEDIUM_PPR_DISCARD
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Gabriel Paubert @ 2014-05-09 21:50 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <20140509134113.GP8754@linux.vnet.ibm.com>
On Fri, May 09, 2014 at 06:41:13AM -0700, Paul E. McKenney wrote:
> On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
> > I am seeing an issue where a CPU running perf eventually hangs.
> > Traces show timer interrupts happening every 4 seconds even
> > when a userspace task is running on the CPU.
>
> Is this by chance every 4.2 seconds? The reason I ask is that
> Paul Clarke and I are seeing an interrupt every 4.2 seconds when
> he runs NO_HZ_FULL, and are trying to get rid of it. ;-)
Hmmm, it's close to 2^32 nanoseconds, isnt't it suspiscious?
Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Paul E. McKenney @ 2014-05-09 22:08 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <20140509215005.GA28239@visitor2.iram.es>
On Fri, May 09, 2014 at 11:50:05PM +0200, Gabriel Paubert wrote:
> On Fri, May 09, 2014 at 06:41:13AM -0700, Paul E. McKenney wrote:
> > On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
> > > I am seeing an issue where a CPU running perf eventually hangs.
> > > Traces show timer interrupts happening every 4 seconds even
> > > when a userspace task is running on the CPU.
> >
> > Is this by chance every 4.2 seconds? The reason I ask is that
> > Paul Clarke and I are seeing an interrupt every 4.2 seconds when
> > he runs NO_HZ_FULL, and are trying to get rid of it. ;-)
>
> Hmmm, it's close to 2^32 nanoseconds, isnt't it suspiscious?
Now that you mention it... ;-)
So you are telling me that we are not succeeding in completely turning
off the decrementer interrupt?
Thanx, Paul
^ permalink raw reply
* linux-next: add scottwood/linux.git
From: Scott Wood @ 2014-05-09 21:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linuxppc-dev
In-Reply-To: <1395709794.12479.411.camel@snotra.buserror.net>
On Mon, 2014-03-24 at 20:09 -0500, Scott Wood wrote:
> On Mon, 2014-03-24 at 10:33 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-03-24 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote:
> > > > The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac:
> > > >
> > > > powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100)
> > > >
> > > > are available in the git repository at:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
> > > >
> > > > for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14:
> > > >
> > > > fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500)
> > >
> > > Stephen just informed me that your tree wasn't in -next ... Kumar's
> > > still is.
> > >
> > > Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer
> > > in -next on its own.
>
> Stephen, what's the process for adding a tree?
ping
-Scott
>
> I suppose we should update MAINTAINERS while we're at it.
>
> > Oh and where is my little summary to put in the merge commit ?
> >
> > I made one up for this time around.
>
> Oops, forgot again. Now I've added something to the script I use to
> generate pull requests, to give me a reminder.
>
> -Scott
>
^ permalink raw reply
* Re: [v6,3/5] powerpc/book3e: support kgdb for kernel space
From: Scott Wood @ 2014-05-09 19:36 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1382520685-11609-4-git-send-email-tiejun.chen@windriver.com>
On Wed, Oct 23, 2013 at 05:31:23PM +0800, Tiejun Chen wrote:
> Currently we need to skip this for supporting KGDB.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index a55cf62..0b750c6 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -597,11 +597,13 @@ kernel_dbg_exc:
> rfdi
>
> /* Normal debug exception */
> +1: andi. r14,r11,MSR_PR; /* check for userspace again */
> +#ifndef CONFIG_KGDB
> /* XXX We only handle coming from userspace for now since we can't
> * quite save properly an interrupted kernel state yet
> */
> -1: andi. r14,r11,MSR_PR; /* check for userspace again */
> beq kernel_dbg_exc; /* if from kernel mode */
> +#endif
Now that we have support for properly saving state on special level
exceptions, that should be used here. With the above patch, what happens
if e.g. a debug exception fires during a TLB miss, and the kgdb handler
takes its own TLB miss accessing the serial port?
-Scott
^ permalink raw reply
* Re: [PATCHv2] powerpc/85xx: Add OCA4080 board support
From: Scott Wood @ 2014-05-09 19:24 UTC (permalink / raw)
To: Martijn de Gouw; +Cc: stef.van.os, Martijn de Gouw, linuxppc-dev
In-Reply-To: <1397584306-8706-1-git-send-email-martijn.de.gouw@prodrive-technologies.com>
On Tue, Apr 15, 2014 at 07:51:46PM +0200, Martijn de Gouw wrote:
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
> index fbd871e..f3685047 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -55,8 +55,6 @@ void __init corenet_gen_setup_arch(void)
> mpc85xx_smp_init();
>
> swiotlb_detect_4g();
> -
> - pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
Valentin's patch kept this line but removed "from Freescale
Semiconductor"; I'll leave it like that when applying.
-Scott
^ permalink raw reply
* Re: [PATCH 1/1] booke/watchdog: refine and clean up the codes
From: Guenter Roeck @ 2014-05-09 17:44 UTC (permalink / raw)
To: Yuantian.Tang; +Cc: scottwood, wim, linuxppc-dev, linux-watchdog
In-Reply-To: <1399514666-2572-1-git-send-email-Yuantian.Tang@freescale.com>
On Thu, May 08, 2014 at 10:04:26AM +0800, Yuantian.Tang@freescale.com wrote:
> From: Tang Yuantian <yuantian.tang@freescale.com>
>
> Basically, this patch does the following:
> 1. Move the codes of parsing boot parameters from setup-common.c
> to driver. In this way, code reader can know directly that
> there are boot parameters that can change the timeout.
> 2. Make boot parameter 'booke_wdt_period' effective.
> currently, when driver is loaded, default timeout is always
> being used in stead of booke_wdt_period.
> 3. Wrap up the watchdog timeout in device struct and clean up
> unnecessary codes.
>
> Signed-off-by: Tang Yuantian <yuantian.tang@freescale.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/pm: add api to get suspend state which is STANDBY or MEM
From: Scott Wood @ 2014-05-09 17:09 UTC (permalink / raw)
To: Li Yang
Cc: Zhao Chenhui, linux-pm@vger.kernel.org, Rafael J. Wysocki,
Dongsheng Wang, 正雄 金, linuxppc-dev
In-Reply-To: <CADRPPNRukfr92m4hSTar_N4iNYJ8fRPMnyOokzc9tCEDLg_BVw@mail.gmail.com>
On Fri, 2014-05-09 at 17:33 +0800, Li Yang wrote:
> On Wed, Apr 30, 2014 at 6:47 AM, Scott Wood <scottwood@freescale.com> wrote:
> > On Mon, 2014-04-28 at 13:53 +0800, Leo Li wrote:
> >> On Sat, Apr 26, 2014 at 5:45 AM, Scott Wood <scottwood@freescale.com> wrote:
> >> > On Thu, 2014-04-24 at 14:11 +0800, Dongsheng Wang wrote:
> >> >> From: Wang Dongsheng <dongsheng.wang@freescale.com>
> >> >>
> >> >> Add set_pm_suspend_state & pm_suspend_state functions to set/get
> >> >> suspend state. When system going to sleep or deep sleep, devices
> >> >> can get the system suspend state(STANDBY/MEM) through pm_suspend_state
> >> >> function and to handle different situations.
> >> >>
> >> >> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> >> >> ---
> >> >> *v2*
> >> >> Move pm api from fsl platform to powerpc general framework.
> >> >
> >> > What is powerpc-specific about this?
> >>
> >> Generally I agree with you. But I had the discussion about this topic
> >> a while ago with the PM maintainer. He suggestion to go with the
> >> platform way.
> >>
> >> https://lkml.org/lkml/2013/8/16/505
> >
> > If what he meant was whether you could do what this patch does, then you
> > can answer him with, "No, because it got nacked as not being platform or
> > arch specific." Oh, and you're still using .valid as the hook to set
> > the platform state, which is awful -- I think .begin is what you want to
> > use.
>
> I'm not saying the current patch is good for upstream. Actually I did
> say that the patch need to be updated for upstream purpose.
I don't follow -- this thread is an upstream submission.
> > Now, a more legitimate objection to putting it in generic code might be
> > that "standby" and "mem" are loosely defined and the knowledge of how a
> > driver should react to each is platform specific -- but your patch
> > doesn't address that. You still have the driver itself interpret what
> > "standby" and "mem" mean.
> >
>
> Yup, we will address it in next batch.
Thanks.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Paul E. McKenney @ 2014-05-09 13:41 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20140509174712.55fe72d0@kryten>
On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
> I am seeing an issue where a CPU running perf eventually hangs.
> Traces show timer interrupts happening every 4 seconds even
> when a userspace task is running on the CPU.
Is this by chance every 4.2 seconds? The reason I ask is that
Paul Clarke and I are seeing an interrupt every 4.2 seconds when
he runs NO_HZ_FULL, and are trying to get rid of it. ;-)
Thanx, Paul
> /proc/timer_list
> also shows pending hrtimers have not run in over an hour,
> including the scheduler.
>
> Looking closer, decrementers_next_tb is getting set to
> 0xffffffffffffffff, and at that point we will never take
> a timer interrupt again.
>
> In __timer_interrupt() we set decrementers_next_tb to
> 0xffffffffffffffff and rely on ->event_handler to update it:
>
> *next_tb = ~(u64)0;
> if (evt->event_handler)
> evt->event_handler(evt);
>
> In this case ->event_handler is hrtimer_interrupt. This will eventually
> call back through the clockevents code with the next event to be
> programmed:
>
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> /* Don't adjust the decrementer if some irq work is pending */
> if (test_irq_work_pending())
> return 0;
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
>
> If irq work came in between these two points, we will return
> before updating decrementers_next_tb and we never process a timer
> interrupt again.
>
> This looks to have been introduced by 0215f7d8c53f (powerpc: Fix races
> with irq_work). Fix it by removing the early exit and relying on
> code later on in the function to force an early decrementer:
>
> /* We may have raced with new irq work */
> if (test_irq_work_pending())
> set_dec(1);
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: stable@vger.kernel.org # 3.14+
> ---
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 122a580..4f0b676 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -813,9 +888,6 @@ static void __init clocksource_init(void)
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> - /* Don't adjust the decrementer if some irq work is pending */
> - if (test_irq_work_pending())
> - return 0;
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
> set_dec(evt);
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Preeti U Murthy @ 2014-05-09 9:52 UTC (permalink / raw)
To: Anton Blanchard, benh; +Cc: paulmck, paulus, linuxppc-dev
In-Reply-To: <20140509174712.55fe72d0@kryten>
Hi Anton,
On 05/09/2014 01:17 PM, Anton Blanchard wrote:
> I am seeing an issue where a CPU running perf eventually hangs.
> Traces show timer interrupts happening every 4 seconds even
> when a userspace task is running on the CPU. /proc/timer_list
> also shows pending hrtimers have not run in over an hour,
> including the scheduler.
>
> Looking closer, decrementers_next_tb is getting set to
> 0xffffffffffffffff, and at that point we will never take
> a timer interrupt again.
>
> In __timer_interrupt() we set decrementers_next_tb to
> 0xffffffffffffffff and rely on ->event_handler to update it:
>
> *next_tb = ~(u64)0;
> if (evt->event_handler)
> evt->event_handler(evt);
>
> In this case ->event_handler is hrtimer_interrupt. This will eventually
> call back through the clockevents code with the next event to be
> programmed:
>
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> /* Don't adjust the decrementer if some irq work is pending */
> if (test_irq_work_pending())
> return 0;
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
>
> If irq work came in between these two points, we will return
> before updating decrementers_next_tb and we never process a timer
> interrupt again.
>
> This looks to have been introduced by 0215f7d8c53f (powerpc: Fix races
> with irq_work). Fix it by removing the early exit and relying on
> code later on in the function to force an early decrementer:
>
> /* We may have raced with new irq work */
> if (test_irq_work_pending())
> set_dec(1);
>
There is another scenario we are missing. Its not necessary that on a
timer interrupt the event handler will call back through the
set_next_event().
If there are no pending timers then the event handler will not bother
programming the tick device and simply return.IOW, set_next_event() will
not be called. In that case we will miss taking care of pending irq work
altogether.
__timer_interrupt() -> event_handler -> next_time = KTIME_MAX ->
__timer_interrupt().
In __timer_interrupt() we do not check for pending irq anywhere after
the call to the event handler and we hence miss servicing irqs in the
above scenario.
How about you also move the check:
if (test_irq_pending())
set_dec(1)
in __timer_interrupt() outside the _else_ loop? This will ensure that no
matter what, before exiting timer interrupt handler we check for pending
irq work.
Regards
Preeti U Murthy
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: stable@vger.kernel.org # 3.14+
> ---
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 122a580..4f0b676 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -813,9 +888,6 @@ static void __init clocksource_init(void)
> static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> - /* Don't adjust the decrementer if some irq work is pending */
> - if (test_irq_work_pending())
> - return 0;
> __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
> set_dec(evt);
How about if you move the test_irq_work_pending
Why do we have test_irq_work_pending() later in the function
decrementer_set_next_event()?
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/pm: add api to get suspend state which is STANDBY or MEM
From: Li Yang @ 2014-05-09 9:33 UTC (permalink / raw)
To: Scott Wood
Cc: Zhao Chenhui, linux-pm@vger.kernel.org, Rafael J. Wysocki,
Dongsheng Wang, 正雄 金, linuxppc-dev
In-Reply-To: <1398811632.24575.98.camel@snotra.buserror.net>
On Wed, Apr 30, 2014 at 6:47 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, 2014-04-28 at 13:53 +0800, Leo Li wrote:
>> On Sat, Apr 26, 2014 at 5:45 AM, Scott Wood <scottwood@freescale.com> wrote:
>> > On Thu, 2014-04-24 at 14:11 +0800, Dongsheng Wang wrote:
>> >> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>> >>
>> >> Add set_pm_suspend_state & pm_suspend_state functions to set/get
>> >> suspend state. When system going to sleep or deep sleep, devices
>> >> can get the system suspend state(STANDBY/MEM) through pm_suspend_state
>> >> function and to handle different situations.
>> >>
>> >> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>> >> ---
>> >> *v2*
>> >> Move pm api from fsl platform to powerpc general framework.
>> >
>> > What is powerpc-specific about this?
>>
>> Generally I agree with you. But I had the discussion about this topic
>> a while ago with the PM maintainer. He suggestion to go with the
>> platform way.
>>
>> https://lkml.org/lkml/2013/8/16/505
>
> If what he meant was whether you could do what this patch does, then you
> can answer him with, "No, because it got nacked as not being platform or
> arch specific." Oh, and you're still using .valid as the hook to set
> the platform state, which is awful -- I think .begin is what you want to
> use.
I'm not saying the current patch is good for upstream. Actually I did
say that the patch need to be updated for upstream purpose. I only
meant that we discussed about having the mem/standby passed by generic
kernel/power interface as you suggested internally and got an negative
feedback.
>
> If we did it in powerpc code, then what would we do on ARM? Copy the
> code? No.
If you are saying that this shouldn't be done in arch/powerpc Yes.
We have determined to use drivers/platform folder for the re-used code
with ARM. Platform power management code will be moved there.
>
> Now, a more legitimate objection to putting it in generic code might be
> that "standby" and "mem" are loosely defined and the knowledge of how a
> driver should react to each is platform specific -- but your patch
> doesn't address that. You still have the driver itself interpret what
> "standby" and "mem" mean.
>
Yup, we will address it in next batch.
- Leo
^ permalink raw reply
* RE: powerpc/mpc85xx: Add BSC9132 QDS Support
From: Harninder Rai @ 2014-05-09 8:55 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, prabhakar@freescale.com,
Ruchika Gupta
In-Reply-To: <20140503003113.GB20757@home.buserror.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Saturday, May 03, 2014 6:01 AM
> To: Rai Harninder-B01044
> Cc: linuxppc-dev@lists.ozlabs.org; Gupta Ruchika-R66431
> Subject: Re: powerpc/mpc85xx: Add BSC9132 QDS Support
>=20
> On Tue, Mar 18, 2014 at 01:05:02PM +0530, harninder rai wrote:
> > +&ifc {
> > + #address-cells =3D <2>;
> > + #size-cells =3D <1>;
> > + compatible =3D "fsl,ifc", "simple-bus";
> > + /* FIXME: Test whether interrupts are split */
> > + interrupts =3D <16 2 0 0 20 2 0 0>;
> > +};
>=20
> Have you done this test yet?
Checked with Prabhakar and he says that on 9132, the IFC interrupts are spl=
it
B4/T4 (and variants), C29x etc onwards are when the interrupts got merged i=
nto single interrupt
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH 1/1] booke/watchdog: refine and clean up the codes
From: Leo Li @ 2014-05-09 8:31 UTC (permalink / raw)
To: Yuantian.Tang; +Cc: Scott Wood, wim, linuxppc-dev, linux-watchdog
In-Reply-To: <1399514666-2572-1-git-send-email-Yuantian.Tang@freescale.com>
On Thu, May 8, 2014 at 10:04 AM, <Yuantian.Tang@freescale.com> wrote:
> From: Tang Yuantian <yuantian.tang@freescale.com>
>
> Basically, this patch does the following:
> 1. Move the codes of parsing boot parameters from setup-common.c
> to driver. In this way, code reader can know directly that
> there are boot parameters that can change the timeout.
> 2. Make boot parameter 'booke_wdt_period' effective.
> currently, when driver is loaded, default timeout is always
> being used in stead of booke_wdt_period.
> 3. Wrap up the watchdog timeout in device struct and clean up
> unnecessary codes.
>
> Signed-off-by: Tang Yuantian <yuantian.tang@freescale.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Li Yang <leoli@freescale.com>
^ permalink raw reply
* Re: [RFT PATCH -next ] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-05-09 8:06 UTC (permalink / raw)
To: ananth
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, akataria, Tony Luck, Kevin Hao,
Linus Torvalds, rdunlap, Tony Luck, dl9pf, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20140508061658.GA2384@in.ibm.com>
(2014/05/08 15:16), Ananth N Mavinakayanahalli wrote:
> On Thu, May 08, 2014 at 02:40:00PM +0900, Masami Hiramatsu wrote:
>> (2014/05/08 13:47), Ananth N Mavinakayanahalli wrote:
>>> On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
>>>
>>> ...
>>>
>>>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>>>> +/*
>>>> + * On PPC64 ABIv1 the function pointer actually points to the
>>>> + * function's descriptor. The first entry in the descriptor is the
>>>> + * address of the function text.
>>>> + */
>>>> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
>>>> +#else
>>>> +#define constant_function_entry(fn) ((unsigned long)(fn))
>>>> +#endif
>>>> +
>>>> #endif /* __ASSEMBLY__ */
>>>
>>> Hi Masami,
>>>
>>> You could just use ppc_function_entry() instead.
>>
>> No, I think ppc_function_entry() has two problems (on the latest -next kernel)
>>
>> At first, that is an inlined functions which is not applied in build time.
>> Since the NOKPROBE_SYMBOL() is used outside of any functions as like as
>> EXPORT_SYMBOL(), we can only use preprocessed macros.
>> Next, on PPC64 ABI*v2*, ppc_function_entry() returns local function entry,
>> which seems global function entry + 2 insns. I'm not sure about implementation
>> of the kallsyms on PPC64 ABIv2, but I guess we need global function entry
>> for kallsyms.
>
> ABIv2 does away with function descriptors and Anton fixed up that
> routine to handle the change (the +2 is an artefact of that).
Hmm, do you mean that the address +2 is the actual entry point?
I'd like to know which address is same as the address shown in /proc/kallsyms.
>> BTW, could you test this patch on the latest -next tree on PPC64 if possible?
>
> I'll test it, but it may take a bit.
Thanks for your help!
>
> Ananth
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* RE: powerpc/mpc85xx: Add BSC9132 QDS Support
From: Harninder Rai @ 2014-05-09 7:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org, Ruchika Gupta
In-Reply-To: <20140503002309.GA20757@home.buserror.net>
> > + };
> > +
> > + nand@1,0 {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > + compatible =3D "fsl,ifc-nand";
> > + reg =3D <0x1 0x0 0x4000>;
> > +
> > + partition@0 {
> > + /* This location must not be altered */
> > + /* 3MB for u-boot Bootloader Image */
> > + reg =3D <0x0 0x00300000>;
> > + label =3D "NAND U-Boot Image";
> > + read-only;
> > + };
> > +
> > + partition@300000 {
> > + /* 1MB for DTB Image */
> > + reg =3D <0x00300000 0x00100000>;
> > + label =3D "NAND DTB Image";
> > + };
> > +
> > + partition@400000 {
> > + /* 8MB for Linux Kernel Image */
> > + reg =3D <0x00400000 0x00800000>;
> > + label =3D "NAND Linux Kernel Image";
> > + };
> > +
> > + partition@c00000 {
> > + /* Rest space for Root file System Image */
> > + reg =3D <0x00c00000 0x07400000>;
> > + label =3D "NAND RFS Image";
> > + };
> > + };
> > +};
>=20
> Please keep partition definitions out of the dts file, as has been recent=
ly
> requested of other boards. You can use U-Boot to create the partition no=
des
> based on the mtdparts variable, or you can use the Linux mtdparts command=
line
> option.
Ok. Will remove these in V2 of patch
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH RFC v2 00/10] EEH Support for VFIO PCI devices on PowerKVM guest
From: Gavin Shan @ 2014-05-09 7:54 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, agraf, kvm-ppc, alex.williamson, qiudayu, linuxppc-dev
In-Reply-To: <1399621782-23281-1-git-send-email-gwshan@linux.vnet.ibm.com>
On Fri, May 09, 2014 at 05:49:32PM +1000, Gavin Shan wrote:
Sorry for having missed cc'ing Alex Graf. Amending it.
>The series of patches intends to support EEH for PCI devices, which are
>passed through to PowerKVM based guest via VFIO. The implementation is
>straightforward based on the issues or problems we have to resolve to
>support EEH for PowerKVM based guest.
>
>- Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
> If QEMU can't handle it, the request will be sent to host via newly introduced
> VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel.
>
>- The error injection infrastructure need support request from the userland
> utility "errinjct" and PowerKVM based guest. The userland utility "errinjct"
> works on pSeries platform well with dedicated syscall, which helps invoking
> RTAS service to fulfil error injection in kernel. From the perspective, it's
> reasonable to extend the syscall to support PowerNV platform so that OPAL call
> can be invoked in host kernel for injecting errors. The data transported
> between userland and kerenl is still following "struct rtas_args" for both
> cases of PowerNV (OPAL) and pSeries (RTAS).
>
>The series of patches requires corresponding firmware changes from Mike Qiu to
>support error injection and QEMU changes to support EEH for guest. QEMU patchset
>will be sent separately.
>
>Change log
>==========
>v1 -> v2:
> * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl.
> The mechanism KVM in-kernel handling is dropped.
> * Error injection is reimplemented based syscall, instead of KVM in-kerenl
> handling. The logic for error injection token management is moved to
> QEMU. The error injection request is routed to QEMU and then possiblly
> to host kernel.
>
>Testing on P7
>=============
>
>- Emulex adapter
>
>Testing on P8
>=============
>
>- Need more testing after design is finalized.
>
>-----
>
>Gavin Shan (10):
> drivers/vfio: Introduce CONFIG_VFIO_EEH
> powerpc/eeh: Info to trace passed devices
> powerpc/eeh: Search EEH device by guest address
> powerpc/eeh: Search EEH PE by guest address
> drivers/vfio: New IOCTL command VFIO_EEH_INFO
> powerpc/eeh: Avoid event on passed PE
> powerpc/powernv: Sync OPAL header file with firmware
> powerpc: Extend syscall ppc_rtas()
> powerpc/powernv: Implement ppc_call_opal()
> powerpc/powernv: Error injection infrastructure
>
>arch/powerpc/include/asm/eeh.h | 52 +++++++++++++
>arch/powerpc/include/asm/opal.h | 74 +++++++++++++++++-
>arch/powerpc/include/asm/rtas.h | 10 ++-
>arch/powerpc/include/asm/syscalls.h | 2 +-
>arch/powerpc/include/asm/systbl.h | 2 +-
>arch/powerpc/include/uapi/asm/unistd.h | 2 +-
>arch/powerpc/kernel/eeh.c | 8 ++
>arch/powerpc/kernel/eeh_pe.c | 80 +++++++++++++++++++
>arch/powerpc/kernel/rtas.c | 57 +++-----------
>arch/powerpc/kernel/syscalls.c | 50 ++++++++++++
>arch/powerpc/platforms/powernv/Makefile | 3 +-
>arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +-
>arch/powerpc/platforms/powernv/eeh-vfio.c | 584 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>arch/powerpc/platforms/powernv/errinject.c | 222 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
>arch/powerpc/platforms/powernv/opal.c | 93 ++++++++++++++++++++++
>drivers/vfio/Kconfig | 6 ++
>drivers/vfio/vfio_iommu_spapr_tce.c | 12 +++
>include/uapi/linux/vfio.h | 61 +++++++++++++++
>kernel/sys_ni.c | 2 +-
>20 files changed, 1271 insertions(+), 53 deletions(-)
>create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
>create mode 100644 arch/powerpc/platforms/powernv/errinject.c
>
>Thanks,
>Gavin
^ permalink raw reply
* [PATCH 09/10] powerpc/powernv: Implement ppc_call_opal()
From: Gavin Shan @ 2014-05-09 7:49 UTC (permalink / raw)
To: linuxppc-dev, kvm-ppc; +Cc: aik, alex.williamson, qiudayu, Gavin Shan
In-Reply-To: <1399621782-23281-1-git-send-email-gwshan@linux.vnet.ibm.com>
If we're running PowerNV platform, ppc_firmware() will be directed
to ppc_call_opal() where we can call to OPAL API accordingly. In
ppc_call_opal(), the input argument are parsed out and call to
appropriate OPAL API to handle that. Each request passed to the
function is identified with token. As we get to the function either
from host owned application (e.g. errinjct) or VM, we always have
the first parameter (so-called "virtual") to differentiate the
cases.
The patch implements above logic and OPAL call handler dynamica
registeration mechanism so that the handlers could be distributed.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 3 +-
arch/powerpc/platforms/powernv/opal.c | 90 ++++++++++++++++++++++++++++++++++-
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ca55d9c..7c4ffd0 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -997,7 +997,8 @@ extern void opal_lpc_init(void);
struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
-
+int opal_call_handler_register(bool virt, int token,
+ int (*fn)(struct rtas_args *));
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index ad33c2b..c84823c 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -38,6 +38,13 @@ struct opal {
u64 size;
} opal;
+struct opal_call_handler {
+ bool virt;
+ int token;
+ int (*fn)(struct rtas_args *args);
+ struct list_head list;
+};
+
struct mcheck_recoverable_range {
u64 start_addr;
u64 end_addr;
@@ -47,6 +54,10 @@ struct mcheck_recoverable_range {
static struct mcheck_recoverable_range *mc_recoverable_range;
static int mc_recoverable_range_len;
+/* OPAL call handler */
+static LIST_HEAD(opal_call_handler_list);
+static DEFINE_SPINLOCK(opal_call_lock);
+
struct device_node *opal_node;
static DEFINE_SPINLOCK(opal_write_lock);
extern u64 opal_mc_secondary_handler[];
@@ -703,8 +714,83 @@ void opal_free_sg_list(struct opal_sg_list *sg)
}
}
-/* Extend it later */
-int ppc_call_opal(struct rtas_args *args)
+int opal_call_handler_register(bool virt, int token,
+ int (*fn)(struct rtas_args *))
{
+ struct opal_call_handler *h, *handler;
+
+ if (!token || !fn) {
+ pr_warn("%s: Invalid parameters\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ handler = kzalloc(sizeof(*handler), GFP_KERNEL);
+ if (!handler) {
+ pr_warn("%s: Out of memory\n",
+ __func__);
+ return -ENOMEM;
+ }
+ handler->token = token;
+ handler->virt = virt;
+ handler->fn = fn;
+ INIT_LIST_HEAD(&handler->list);
+
+ spin_lock(&opal_call_lock);
+ list_for_each_entry(h, &opal_call_handler_list, list) {
+ if (h->token == token &&
+ h->virt == virt) {
+ spin_unlock(&opal_call_lock);
+ pr_warn("%s: Handler existing (%s, %x)\n",
+ __func__, virt ? "T" : "F", token);
+ kfree(handler);
+ return -EEXIST;
+ }
+ }
+
+ list_add_tail(&handler->list, &opal_call_handler_list);
+ spin_unlock(&opal_call_lock);
+
return 0;
}
+
+/*
+ * It's usually invoked from syscall ppc_firmware() by host
+ * owned application or VM. The information carried in the
+ * input arguments is different. So we always have the first
+ * argument to differentiate it.
+ *
+ * Also, we have to extend 32-bits address to 64-bits. So
+ * for each address sensitive field, it will require 8
+ * bytes.
+ */
+int ppc_call_opal(struct rtas_args *args)
+{
+ bool virt, found;
+ int token;
+ struct opal_call_handler *h;
+
+ /* We should have "virt" at least */
+ if (args->nargs < 1)
+ return -EINVAL;
+ virt = !!args->args[0];
+ token = args->token;
+
+ /* Do we have handler ? */
+ found = false;
+ spin_lock(&opal_call_lock);
+ list_for_each_entry(h, &opal_call_handler_list, list) {
+ if (h->token == token &&
+ h->virt == virt) {
+ found = true;
+ break;
+ }
+ }
+ spin_unlock(&opal_call_lock);
+
+ /* Call to handler */
+ if (!found)
+ return -ERANGE;
+
+ return h->fn(args);
+}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 10/10] powerpc/powernv: Error injection infrastructure
From: Gavin Shan @ 2014-05-09 7:49 UTC (permalink / raw)
To: linuxppc-dev, kvm-ppc; +Cc: aik, alex.williamson, qiudayu, Gavin Shan
In-Reply-To: <1399621782-23281-1-git-send-email-gwshan@linux.vnet.ibm.com>
The patch intends to implemdent the error injection infrastructure
for PowerNV platform. The predetermined handlers will be called
according to the type of injected error (e.g. OpalErrinjctTypeIoaBusError).
For now, we just support PCI error injection. We need support
injecting other types of errors in future.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 6 +
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/errinject.c | 224 +++++++++++++++++++++++++++++
3 files changed, 231 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/errinject.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7c4ffd0..7bf86ba 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -794,6 +794,12 @@ typedef struct oppanel_line {
uint64_t line_len;
} oppanel_line_t;
+enum OpalCallToken{
+ OPAL_CALL_TOKEN_MIN = 0,
+ OPAL_CALL_TOKEN_ERRINJCT,
+ OPAL_CALL_TOKEN_MAX
+};
+
/* /sys/firmware/opal */
extern struct kobject *opal_kobj;
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 2b15a03..5ae8257 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y += setup.o opal-takeover.o opal-wrappers.o opal.o opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
-obj-y += opal-msglog.o
+obj-y += opal-msglog.o errinject.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/errinject.c b/arch/powerpc/platforms/powernv/errinject.c
new file mode 100644
index 0000000..aa892d4
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/errinject.c
@@ -0,0 +1,224 @@
+/*
+ * The file intends to support error injection requests from host OS
+ * owned utility (e.g. errinjct) or VM. We need parse the information
+ * passed from user space and call to appropriate OPAL API accordingly.
+ *
+ * Copyright Benjamin Herrenschmidt & Gavin Shan, IBM Corporation 2014.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/msi.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+
+#include <asm/eeh.h>
+#include <asm/eeh_event.h>
+#include <asm/io.h>
+#include <asm/iommu.h>
+#include <asm/msi_bitmap.h>
+#include <asm/opal.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc-pci.h>
+#include <asm/rtas.h>
+#include <asm/tce.h>
+#include <asm/uaccess.h>
+
+#include "powernv.h"
+#include "pci.h"
+
+static int powernv_errinjct_ioa(struct rtas_args *args)
+{
+ return -ENXIO;
+}
+
+static int powernv_errinjct_ioa64(struct rtas_args *args)
+{
+ return -ENXIO;
+}
+
+#ifdef CONFIG_VFIO_EEH
+static int powernv_errinjct_ioa_virt(struct rtas_args *args)
+{
+ uint32_t addr, mask, cfg_addr;
+ uint32_t buid_hi, buid_lo, op;
+ uint64_t buf_addr = ((uint64_t)(args->args[3])) << 32 |
+ args->args[4];
+ void __user *buf = (void __user *)buf_addr;
+ struct eeh_vfio_pci_addr vfio_addr;
+ struct pnv_phb *phb;
+ struct eeh_pe *pe;
+ struct OpalErrinjct ej;
+
+ /* Extract parameters */
+ if (get_user(addr, (uint32_t __user *)buf) ||
+ get_user(mask, (uint32_t __user *)(buf + 4)) ||
+ get_user(cfg_addr, (uint32_t __user *)(buf + 8)) ||
+ get_user(buid_hi, (uint32_t __user *)(buf + 12)) ||
+ get_user(buid_lo, (uint32_t __user *)(buf + 16)) ||
+ get_user(op, (uint32_t __user *)(buf + 20)))
+ return -EFAULT;
+
+ /* Check opcode */
+ if (op < OpalEjtIoaLoadMemAddr ||
+ op > OpalEjtIoaDmaWriteMemTarget)
+ return -EINVAL;
+
+ /* Find PE */
+ vfio_addr.buid = ((((uint64_t)buid_hi) << 32) | buid_lo);
+ vfio_addr.pe_addr = cfg_addr;
+ pe = eeh_vfio_pe_get(&vfio_addr);
+ if (!pe)
+ return -ENODEV;
+ phb = pe->phb->private_data;
+
+ /* OPAL call */
+ ej.type = OpalErrinjctTypeIoaBusError;
+ ej.ioa.addr = addr;
+ ej.ioa.mask = mask;
+ ej.ioa.phb_id = phb->opal_id;
+ ej.ioa.pe = pe->addr;
+ ej.ioa.function = op;
+ if (opal_err_injct(&ej) != OPAL_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int powernv_errinjct_ioa64_virt(struct rtas_args *args)
+{
+ uint32_t addr_hi, addr_lo, mask_hi, mask_lo;
+ uint32_t cfg_addr, buid_hi, buid_lo, op;
+ uint64_t buf_addr = ((uint64_t)(args->args[3])) << 32 |
+ args->args[4];
+ void __user *buf = (void __user *)buf_addr;
+ struct eeh_vfio_pci_addr vfio_addr;
+ struct pnv_phb *phb;
+ struct eeh_pe *pe;
+ struct OpalErrinjct ej;
+
+ /* Extract parameters */
+ if (get_user(addr_hi, (uint32_t __user *)buf) ||
+ get_user(addr_lo, (uint32_t __user *)(buf + 4)) ||
+ get_user(mask_hi, (uint32_t __user *)(buf + 8)) ||
+ get_user(mask_lo, (uint32_t __user *)(buf + 12)) ||
+ get_user(cfg_addr, (uint32_t __user *)(buf + 16)) ||
+ get_user(buid_hi, (uint32_t __user *)(buf + 20)) ||
+ get_user(buid_lo, (uint32_t __user *)(buf + 24)) ||
+ get_user(op, (uint32_t __user *)(buf + 28)))
+ return -EFAULT;
+
+ /* Check opcode */
+ if (op < OpalEjtIoaLoadMemAddr ||
+ op > OpalEjtIoaDmaWriteMemTarget)
+ return -EINVAL;
+
+ /* Find PE */
+ vfio_addr.buid = ((((uint64_t)buid_hi) << 32) | buid_lo);
+ vfio_addr.pe_addr = (cfg_addr >> 8) & 0xffff;
+ pe = eeh_vfio_pe_get(&vfio_addr);
+ if (!pe)
+ return -ENODEV;
+ phb = pe->phb->private_data;
+
+ /* OPAL call */
+ ej.type = OpalErrinjctTypeIoaBusError64;
+ ej.ioa.addr = (((uint64_t)addr_hi) << 32) | addr_lo;
+ ej.ioa.mask = (((uint64_t)mask_hi) << 32) | mask_lo;
+ ej.ioa.phb_id = phb->opal_id;
+ ej.ioa.pe = pe->addr;
+ ej.ioa.function = op;
+ if (opal_err_injct(&ej) != OPAL_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+#endif /* CONFIG_VFIO_EEH */
+
+struct errinjct_handler {
+ bool virt;
+ int token;
+ int (*fn)(struct rtas_args *arg);
+};
+
+static struct errinjct_handler handlers[] = {
+#ifdef CONFIG_EEH
+ { false,
+ OpalErrinjctTypeIoaBusError,
+ powernv_errinjct_ioa
+ },
+ { false,
+ OpalErrinjctTypeIoaBusError64,
+ powernv_errinjct_ioa64
+ },
+#endif
+#ifdef CONFIG_VFIO_EEH
+ { true,
+ OpalErrinjctTypeIoaBusError,
+ powernv_errinjct_ioa_virt
+ },
+ { true,
+ OpalErrinjctTypeIoaBusError64,
+ powernv_errinjct_ioa64_virt
+ },
+#endif
+};
+
+static int powernv_errinjct(struct rtas_args *args)
+{
+ struct errinjct_handler *h;
+ int token, ej_token, i;
+ bool virt;
+
+ /* Sanity check */
+ if (args->nargs != 5 || args->nret != 1)
+ return -EINVAL;
+
+ token = args->token;
+ virt = !!args->args[0];
+ if (!virt || token != OPAL_CALL_TOKEN_ERRINJCT)
+ return -EINVAL;
+
+ /* Call into specific handler */
+ ej_token = args->args[1];
+ for (i = 0; i < ARRAY_SIZE(handlers); i++) {
+ h = &handlers[i];
+ if (h->virt == virt &&
+ h->token == ej_token &&
+ h->fn)
+ return h->fn(args);
+ }
+
+ return -ENXIO;
+}
+
+static int __init powernv_errinjct_init(void)
+{
+ int ret;
+
+ ret = opal_call_handler_register(false, OPAL_CALL_TOKEN_ERRINJCT,
+ powernv_errinjct);
+ if (ret) {
+ pr_warn("%s: Cannot register errinjct handler\n",
+ __func__);
+ return ret;
+ }
+
+ ret = opal_call_handler_register(true, OPAL_CALL_TOKEN_ERRINJCT,
+ powernv_errinjct);
+ if (ret) {
+ pr_warn("%s: Cannot register errinjct virtual handler\n",
+ __func__);
+ return ret;
+ }
+
+ return 0;
+}
+
+module_init(powernv_errinjct_init);
--
1.8.3.2
^ permalink raw reply related
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