* [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
From: Paul Mackerras @ 2011-05-31 6:40 UTC (permalink / raw)
To: linuxppc-dev, kvm, kvm-ppc
The following series of patches enable KVM to exploit the hardware
hypervisor mode on 64-bit Power ISA Book3S machines. At present only
POWER7 is supported, but it would be easy to add other processors.
Running the KVM host in hypervisor mode means that the guest can use
both supervisor mode and user mode. That means that the guest can
execute supervisor-privilege instructions and access supervisor-
privilege registers. In addition the hardware directs most exceptions
to the guest. Thus we don't need to emulate any instructions in the
host. Generally, the only times we need to exit the guest are when it
does a hypercall or when an external interrupt or host timer
(decrementer) interrupt occurs.
The focus of this KVM implementation is to run guests that use the
PAPR (Power Architecture Platform Requirements) paravirtualization
interface, which is the interface supplied by PowerVM on IBM pSeries
machines. Currently the "pseries" machine type in qemu is only
supported by book3s_hv KVM, and book3s_hv KVM only supports the
"pseries" machine type. That will hopefully change in future.
These patches are against Linus' v3.0-rc1 tree.
Paul.
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Benjamin Herrenschmidt @ 2011-05-30 22:17 UTC (permalink / raw)
To: kevin diggs
Cc: Tabi Timur-B04825, Andrey Gusev, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BANLkTimLm1DYVWy2Cj-F9hLw3mNsqtk4iQ@mail.gmail.com>
On Mon, 2011-05-30 at 17:11 -0500, kevin diggs wrote:
> Hi,
>
> >
> > This is an SMP machine ? If not, does it work with a UP kernel ?
> >
> > Cheers,
> > Ben.
> >
> ??? Even if it is SMP, you can run non-SMP kernel on it, right?
Yes, I was asking whether the bug also occured with an UP kernel.
Cheers,
Ben.
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: kevin diggs @ 2011-05-30 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tabi Timur-B04825, Andrey Gusev, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1306705871.7481.594.camel@pasglop>
Hi,
>
> This is an SMP machine ? If not, does it work with a UP kernel ?
>
> Cheers,
> Ben.
>
??? Even if it is SMP, you can run non-SMP kernel on it, right?
kevin
^ permalink raw reply
* Re: [PATCH] 2.6.39 powerpc: Fix 32-bit SMP build
From: Benjamin Herrenschmidt @ 2011-05-30 21:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, stable
In-Reply-To: <20110530122621.GD2557@zod.rchland.ibm.com>
On Mon, 2011-05-30 at 08:26 -0400, Josh Boyer wrote:
> Backport upstream commit 6de06f313a65d0ec
>
> Commit fa3f82c8bb7acb ("powerpc/smp: soft-replugged CPUs must go back to
> start_secondary") introduced start_secondary_resume to head_32.S, however
> it uses a 64-bit instruction which is not valid on 32-bit platforms. Use
> 'stw' instead.
>
> CC: stable@kernel.org
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> index c5c24be..727f40a 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -896,7 +896,7 @@ _GLOBAL(start_secondary_resume)
> rlwinm r1,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
> addi r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
> li r3,0
> - std r3,0(r1) /* Zero the stack frame pointer */
> + stw r3,0(r1) /* Zero the stack frame pointer */
> bl start_secondary
> b .
> #endif /* CONFIG_SMP */
^ permalink raw reply
* PMAC_ZILOG serial driver locks up.
From: Rob Landley @ 2011-05-30 20:00 UTC (permalink / raw)
To: linuxppc-dev
The powerpc systems I emulate under qemu use the "mac99" board
emulation, which routes the serial console through a PMAC_ZILOG serial
chip.
It got screwed up by Alan Cox's refactoring of the tty layer in 2.6.28:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html
And then partially fixed here:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40477.html
However, if significant input and output traffic overlaps, the serial
port locks up. Here's a test for that. Grab this tarball:
http://landley.net/aboriginal/downloads/binaries/system-image-powerpc.tar.bz2
And do this:
echo -e " \necho hello world" | ./run-emulator.sh
That's echo a line of 20 spaces, a newline, and a command to see
if it makes it through to the comand prompt.
Data makes it out the serial console right up until init launches
(and interrupts are enabled), then it locks hard.
if you just ./run-emulator.sh directly and don't type anything until
you get a shell prompt, it works fine. It's the data crossing in
both directions at once that screws the driver up.
Trivially reproducible. I've tested back to 2.6.32 and it was doing
it back then. (2.6.31 was a build break.)
Rob
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
From: Anton Vorontsov @ 2011-05-30 16:57 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: a.zummo@towertech.it, rtc-linux@googlegroups.com,
p_gortmaker@yahoo.com, Jain Priyanka-B32167,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BANLkTi=H2rHSjTvRK5+SPhW26qCNUBMxbA@mail.gmail.com>
On Mon, May 30, 2011 at 02:29:58PM +0000, Tabi Timur-B04825 wrote:
> On Mon, May 30, 2011 at 3:24 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
> > The first place where this should be mentioned is the datasheet of the
> > pt-chip, so you might ask the producer to add this information (don't
> > expect much to happen, though).
>
> It's true that the data sheet does not mention that it's identical to
> the DS1307, but that's still no excuse for not noticing it and writing
> a whole driver for it. :-(
>
> > IIRC I asked you explicitly for the differences between the chips. If
> > there are none, you can use the driver directly, right? :)
>
> Yes. The device tree node for the PT7C4338 device should just say
>
> /* The board has a PT7C4338, which is compatible with the DS1307 */
> compatible = "dallas,ds1307";
While it seems to be 100% compatible, there could be chip-specific
bugs or some interesting features that are hidden behind "reserved"
bits and registers.
So I think device tree should not lie about the chip model. Doing
'compatible = "pericom,pt7c4338", "dallas,ds1307"' is perfectly fine.
Note that today the several compatible entries approach gives you
almost nothing, as you will need to add pt7c4338 entry into the driver
anyway.
I tried to improve this, i.e. make linux do OF-matching on the most
generic compatible entry (the last one):
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg21196.html
It was received coldly though:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22041.html
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg21273.html
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
From: Wolfram Sang @ 2011-05-30 14:50 UTC (permalink / raw)
To: rtc-linux
Cc: a.zummo@towertech.it, Jain Priyanka-B32167,
linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
p_gortmaker@yahoo.com
In-Reply-To: <BANLkTi=H2rHSjTvRK5+SPhW26qCNUBMxbA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
> > IIRC I asked you explicitly for the differences between the chips. If
> > there are none, you can use the driver directly, right? :)
>
> Yes. The device tree node for the PT7C4338 device should just say
>
> /* The board has a PT7C4338, which is compatible with the DS1307 */
> compatible = "dallas,ds1307";
>
> And that's it.
I'd also suggest to add a comment to the id_table in rtc-ds1307.c, so
the chip name can be grepped for.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
From: Tabi Timur-B04825 @ 2011-05-30 14:29 UTC (permalink / raw)
To: rtc-linux@googlegroups.com
Cc: a.zummo@towertech.it, Jain Priyanka-B32167,
linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
p_gortmaker@yahoo.com
In-Reply-To: <20110530082429.GA3409@pengutronix.de>
On Mon, May 30, 2011 at 3:24 AM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> The first place where this should be mentioned is the datasheet of the
> pt-chip, so you might ask the producer to add this information (don't
> expect much to happen, though).
It's true that the data sheet does not mention that it's identical to
the DS1307, but that's still no excuse for not noticing it and writing
a whole driver for it. :-(
> IIRC I asked you explicitly for the differences between the chips. If
> there are none, you can use the driver directly, right? :)
Yes. The device tree node for the PT7C4338 device should just say
/* The board has a PT7C4338, which is compatible with the DS1307 */
compatible =3D "dallas,ds1307";
And that's it.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] 2.6.39 powerpc: Fix 32-bit SMP build
From: Josh Boyer @ 2011-05-30 12:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: stable
Backport upstream commit 6de06f313a65d0ec
Commit fa3f82c8bb7acb ("powerpc/smp: soft-replugged CPUs must go back to
start_secondary") introduced start_secondary_resume to head_32.S, however
it uses a 64-bit instruction which is not valid on 32-bit platforms. Use
'stw' instead.
CC: stable@kernel.org
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index c5c24be..727f40a 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -896,7 +896,7 @@ _GLOBAL(start_secondary_resume)
rlwinm r1,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
addi r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
li r3,0
- std r3,0(r1) /* Zero the stack frame pointer */
+ stw r3,0(r1) /* Zero the stack frame pointer */
bl start_secondary
b .
#endif /* CONFIG_SMP */
^ permalink raw reply related
* Re: [PATCH] Add cpufreq driver for Momentum Maple boards
From: Dmitry Eremin-Solenikov @ 2011-05-30 11:57 UTC (permalink / raw)
To: cpufreq; +Cc: Dave Jones, Paul Mackerras, linuxppc-dev
In-Reply-To: <1305973726-28006-1-git-send-email-dbaryshkov@gmail.com>
Hello,
On 5/21/11, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
> Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
> kit and others). Driver is based on a cpufreq driver for 64-bit powermac
> boxes with all pmac-dependant features removed and simple cleanup
> applied.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/kernel/misc_64.S | 4 +-
> arch/powerpc/platforms/Kconfig | 8 +
> arch/powerpc/platforms/maple/Makefile | 1 +
> arch/powerpc/platforms/maple/cpufreq.c | 317
> ++++++++++++++++++++++++++++++++
> 4 files changed, 328 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/platforms/maple/cpufreq.c
What about this patch?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] powerpc/mpic: support compiling with DEBUG enabled
From: Dmitry Eremin-Solenikov @ 2011-05-30 11:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Support compilation of mpic.c with DEBUG defined, as now we have irq_desc and
not irq number.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/sysdev/mpic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3a8de5b..3f995dc 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -848,7 +848,7 @@ static void mpic_unmask_tm(struct irq_data *d)
struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = virq_to_hw(d->irq) - mpic->timer_vecs[0];
- DBG("%s: enable_tm: %d (tm %d)\n", mpic->name, irq, src);
+ DBG("%s: enable_tm: %d (tm %d)\n", mpic->name, d->irq, src);
mpic_tm_write(src, mpic_tm_read(src) & ~MPIC_VECPRI_MASK);
mpic_tm_read(src);
}
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
From: Wolfram Sang @ 2011-05-30 8:24 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: a.zummo@towertech.it, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, rtc-linux@googlegroups.com,
p_gortmaker@yahoo.com
In-Reply-To: <470DB7CE2CD0944E9436E7ADEFC02FE316DCB8@039-SN1MPN1-002.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
Hi, Priyanka,
> Yes, It is possible to directly use platform device 'ds1307' in device
> tree.
Great, thanks for testing.
> But I have one query of how to capture the information that pericom,
> pt7c4338 device is compatible with dallas, ds1307. Can it be done in
> somewhere in some document or some code. Actually for pt7c4338 device
Yes, it should definately be documented in the source.
> driver, I actually started by asking if there is any already existing
> rtc device driver which is compatible with pericom pt7c4338 device on
> mailing list and as there was no answer or help then, I actually ended
> up writing device driver for that
The first place where this should be mentioned is the datasheet of the
pt-chip, so you might ask the producer to add this information (don't
expect much to happen, though). For such generic devices, it is then
useful to look for similar register sets in existing drivers to find a
duplicate. Please don't forget that such lists are voluntary, there is
no guarantee that mails get replied to.
> and then on the suggestion using ds1307 device driver for this.
IIRC I asked you explicitly for the differences between the chips. If
there are none, you can use the driver directly, right? :)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [RFC][PATCH] Kexec support for PPC440x
From: Suzuki Poulose @ 2011-05-30 7:22 UTC (permalink / raw)
To: linux ppc dev; +Cc: Sebastian Andrzej Siewior, kexec@lists.infradead.org, lkml
KEXEC Support for ppc440X
The patch adds kexec support for PPC440x based boards. This work is based
on the KEXEC patches for FSL BookE.
The FSL BookE patch and the code flow could be found at the link below:
http://patchwork.ozlabs.org/patch/49359/
We invalidate all the TLB entries except the one this code is run from,
and create a 1:1 mapping for 0-2GiB in blocks of 256M. Later we jump to
the 1:1 mapping.
I have tested this patches on Ebony and Sequoia boards. It would be great
if somebody could test this on the other boards.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
arch/powerpc/Kconfig | 2
arch/powerpc/include/asm/kexec.h | 2
arch/powerpc/kernel/44x_kexec_mapping.S | 66 ++++++++++++++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 22 ++++++++++
4 files changed, 90 insertions(+), 2 deletions(-)
Index: powerpc/arch/powerpc/Kconfig
===================================================================
--- powerpc.orig/arch/powerpc/Kconfig
+++ powerpc/arch/powerpc/Kconfig
@@ -349,7 +349,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
- depends on (PPC_BOOK3S || FSL_BOOKE) && EXPERIMENTAL
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP && !47x)) && EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
Index: powerpc/arch/powerpc/include/asm/kexec.h
===================================================================
--- powerpc.orig/arch/powerpc/include/asm/kexec.h
+++ powerpc/arch/powerpc/include/asm/kexec.h
@@ -2,7 +2,7 @@
#define _ASM_POWERPC_KEXEC_H
#ifdef __KERNEL__
-#ifdef CONFIG_FSL_BOOKE
+#if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_44x)
/*
* On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2011 IBM
+ *
+ * Author : Suzuki K. Poulose <suzuki@in.ibm.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ *
+ * Code for setting up 1:1 mapping for PPC440x for KEXEC
+ *
+ * We cannot switch off the MMU on PPC44x.
+ * So we:
+ * 1) Invalidate all the mappings except the one we are
+ * running from.
+ * 2) Create a 1:1 mapping for 0-2GiB
+ *
+ * - Based on the kexec support code for FSL BookE
+ * - Based on the boot up code for ppc44x from head_44x.S
+ * - Doesn't support 47x yet.
+ * - Doesn't support SMP.
+ *
+ */
+ bl nxtins /* Find our address */
+nxtins: mflr r5 /* Make it accessible */
+ tlbsx r23,0,r5 /* Find entry we are in */
+ li r4,0 /* Start at TLB entry 0 */
+ li r3,0 /* Set PAGEID inval value */
+1: cmpw r23,r4 /* Is this our entry? */
+ beq skip /* If so, skip the inval */
+ tlbwe r3,r4,PPC44x_TLB_PAGEID /* If not, inval the entry */
+skip: addi r4,r4,1 /* Increment */
+ cmpwi r4,64 /* Are we done? */
+ bne 1b /* If not, repeat */
+ isync
+
+/*
+ * Setup 1:1 mapping for 0-2GiB in blocks of 256M.
+ * r23 is the index to the mapping of this code.
+ * Skip it.
+ */
+ /* attribute fields. rwx for SUPERVISOR mode */
+ li r5, 0
+ ori r5, r5, (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G)
+
+ li r11, 0 /* PageNumber */
+ li r6, 0 /* TLB Index */
+
+next_tlb:
+ rotlwi r3, r11, 28 /* Create EPN (bits 0-3) */
+ mr r4, r3 /* RPN = EPN */
+ ori r3, r3, PPC44x_TLB_VALID | PPC44x_TLB_256M /* SIZE = 256M, Valid */
+ cmpw r6, r23 /* Is this our TLB entry ? */
+ bne write_tlb
+ addi r6, r6, 1 /* Skip our entry */
+
+write_tlb:
+ tlbwe r3, r6, PPC44x_TLB_PAGEID /* PageID field : EPN, V, SIZE */
+ tlbwe r4, r6, PPC44x_TLB_XLAT /* Address translation : RPN */
+ tlbwe r5, r6, PPC44x_TLB_ATTRIB /* Attributes */
+
+ addi r11, r11, 1 /* Increment PN */
+ addi r6, r6, 1 /* Increment TLB Index */
+ cmpwi r11, 8 /* Are we done ? */
+ bne next_tlb
+ isync
+
Index: powerpc/arch/powerpc/kernel/misc_32.S
===================================================================
--- powerpc.orig/arch/powerpc/kernel/misc_32.S
+++ powerpc/arch/powerpc/kernel/misc_32.S
@@ -736,6 +736,28 @@ relocate_new_kernel:
mr r5, r31
li r0, 0
+#elif defined(CONFIG_44x) && !defined(CONFIG_47x)
+
+ mr r29, r3
+ mr r30, r4
+ mr r31, r5
+
+#include "44x_kexec_mapping.S"
+
+ mr r3, r29
+ mr r4, r30
+ mr r5, r31
+
+ li r0, 0
+
+ /* Jump back to the 1:1 address */
+ mr r8, r0
+ mtspr SPRN_SRR1, r8
+ addi r8, r4, 1f - relocate_new_kernel
+ mtspr SPRN_SRR0, r8
+ sync
+ rfi
+1:
#else
li r0, 0
^ permalink raw reply
* [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
From: Suzuki Poulose @ 2011-05-30 6:30 UTC (permalink / raw)
To: kexec@lists.infradead.org, Simon Horman
Cc: Sebastian Andrzej Siewior, lkml, linux ppc dev, Vivek Goyal
In-Reply-To: <4DCA285D.2080006@in.ibm.com>
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.
Changed the add_usable_mem_property() to accept FILE* fp instead of int fd,
as most of the other users of read_memory_region_limits() deals with FILE*.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
kexec/arch/ppc/crashdump-powerpc.c | 23 ------
kexec/arch/ppc/fs2dt.c | 31 ++------
kexec/arch/ppc/kexec-ppc.c | 136 ++++++++++++++++++++++++++-----------
kexec/arch/ppc/kexec-ppc.h | 6 +
4 files changed, 118 insertions(+), 78 deletions(-)
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===================================================================
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -26,6 +26,7 @@
#include "config.h"
+unsigned long dt_address_cells = 0, dt_size_cells = 0;
uint64_t rmo_top;
unsigned long long crash_base = 0, crash_size = 0;
unsigned long long initrd_base = 0, initrd_size = 0;
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = "/proc/device-tree/#address-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
+
+ file = "/proc/device-tree/#size-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
+
+ return 0;
+}
+
+#define MAXBYTES 128
+/*
+ * Reads the memory region info from the device-tree node pointed
+ * by @fp and fills the *start, *end with the boundaries of the region
+ */
+int read_memory_region_limits(FILE* fp, unsigned long long *start,
+ unsigned long long *end)
+{
+ char buf[MAXBYTES];
+ unsigned long *p;
+ unsigned long nbytes = dt_address_cells + dt_size_cells;
+
+ if (fread(buf, 1, MAXBYTES, fp) != nbytes) {
+ fprintf(stderr, "Error reading the memory region info\n");
+ return -1;
+ }
+
+ p = (unsigned long*)buf;
+ if (dt_address_cells == sizeof(unsigned long)) {
+ *start = p[0];
+ p++;
+ } else if (dt_address_cells == sizeof(unsigned long long)) {
+ *start = ((unsigned long long *)p)[0];
+ p = (unsigned long long *)p + 1;
+ } else {
+ fprintf(stderr,"Unsupported value for #address-cells : %ld\n",
+ dt_address_cells);
+ return -1;
+ }
+
+ if (dt_size_cells == sizeof(unsigned long))
+ *end = *start + p[0];
+ else if (dt_size_cells == sizeof(unsigned long long))
+ *end = *start + ((unsigned long long *)p)[0];
+ else {
+ fprintf(stderr,"Unsupported value for #size-cells : %ld\n",
+ dt_size_cells);
+ return -1;
+ }
+
+ return 0;
+}
+
void arch_reuse_initrd(void)
{
reuse_initrd = 1;
@@ -182,9 +269,6 @@ static int sort_base_ranges(void)
return 0;
}
-
-#define MAXBYTES 128
-
static int realloc_memory_ranges(void)
{
size_t memory_range_len;
@@ -248,6 +332,8 @@ static int get_base_ranges(void)
return -1;
}
while ((mentry = readdir(dmem)) != NULL) {
+ unsigned long long start, end;
+
if (strcmp(mentry->d_name, "reg"))
continue;
strcat(fname, "/reg");
@@ -257,8 +343,7 @@ static int get_base_ranges(void)
closedir(dir);
return -1;
}
- if ((n = fread(buf, 1, MAXBYTES, file)) < 0) {
- perror(fname);
+ if (read_memory_region_limits(file, &start, &end) != 0) {
fclose(file);
closedir(dmem);
closedir(dir);
@@ -271,24 +356,8 @@ static int get_base_ranges(void)
}
}
- if (n == sizeof(uint32_t) * 2) {
- base_memory_range[local_memory_ranges].start =
- ((uint32_t *)buf)[0];
- base_memory_range[local_memory_ranges].end =
- base_memory_range[local_memory_ranges].start +
- ((uint32_t *)buf)[1];
- }
- else if (n == sizeof(uint64_t) * 2) {
- base_memory_range[local_memory_ranges].start =
- ((uint64_t *)buf)[0];
- base_memory_range[local_memory_ranges].end =
- base_memory_range[local_memory_ranges].start +
- ((uint64_t *)buf)[1];
- }
- else {
- fprintf(stderr, "Mem node has invalid size: %d\n", n);
- return -1;
- }
+ base_memory_range[local_memory_ranges].start = start;
+ base_memory_range[local_memory_ranges].end = end;
base_memory_range[local_memory_ranges].type = RANGE_RAM;
local_memory_ranges++;
dbgprintf("%016llx-%016llx : %x\n",
@@ -577,20 +646,10 @@ static int get_devtree_details(unsigned
perror(fname);
goto error_opencdir;
}
- if ((n = fread(buf, 1, MAXBYTES, file)) < 0) {
- perror(fname);
- goto error_openfile;
- }
- if (n == sizeof(uint64_t)) {
- rmo_base = ((uint32_t *)buf)[0];
- rmo_top = rmo_base + ((uint32_t *)buf)[1];
- } else if (n == 16) {
- rmo_base = ((uint64_t *)buf)[0];
- rmo_top = rmo_base + ((uint64_t *)buf)[1];
- } else {
- fprintf(stderr, "Mem node has invalid size: %d\n", n);
+ if (read_memory_region_limits(file, &rmo_base, &rmo_top) != 0) {
goto error_openfile;
}
+
if (rmo_top > 0x30000000UL)
rmo_top = 0x30000000UL;
@@ -664,7 +723,6 @@ error_opendir:
return -1;
}
-
/* Setup a sorted list of memory ranges. */
static int setup_memory_ranges(unsigned long kexec_flags)
{
@@ -756,7 +814,6 @@ out:
return -1;
}
-
/* Return a list of valid memory ranges */
int get_memory_ranges_dt(struct memory_range **range, int *ranges,
unsigned long kexec_flags)
@@ -778,6 +835,11 @@ int get_memory_ranges_dt(struct memory_r
int get_memory_ranges(struct memory_range **range, int *ranges,
unsigned long kexec_flags)
{
+ int res = 0;
+
+ res = init_memory_region_info();
+ if (res != 0)
+ return res;
#ifdef WITH_GAMECUBE
return get_memory_ranges_gc(range, ranges, kexec_flags);
#else
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.h
===================================================================
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.h
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.h
@@ -69,6 +69,12 @@ extern unsigned long long initrd_base, i
extern unsigned long long ramdisk_base, ramdisk_size;
extern unsigned char reuse_initrd;
extern const char *ramdisk;
+
+/* Method to parse the memory/reg nodes in device-tree */
+extern unsigned long dt_address_cells, dt_size_cells;
+extern int init_memory_region_info(void);
+extern int read_memory_region_limits(FILE *fp, unsigned long long *start,
+ unsigned long long *end);
#define COMMAND_LINE_SIZE 512 /* from kernel */
/*fs2dt*/
void reserve(unsigned long long where, unsigned long long length);
Index: kexec-tools-2.0.4/kexec/arch/ppc/crashdump-powerpc.c
===================================================================
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/crashdump-powerpc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/crashdump-powerpc.c
@@ -130,9 +130,8 @@ static int get_crash_memory_ranges(struc
closedir(dir);
goto err;
}
- n = fread(buf, 1, MAXBYTES, file);
- if (n < 0) {
- perror(fname);
+ n = read_memory_region_limits(file, &start, &end);
+ if (n != 0) {
fclose(file);
closedir(dmem);
closedir(dir);
@@ -146,24 +145,6 @@ static int get_crash_memory_ranges(struc
goto err;
}
- /*
- * FIXME: This code fails on platforms that
- * have more than one memory range specified
- * in the device-tree's /memory/reg property.
- * or where the #address-cells and #size-cells
- * are not identical.
- *
- * We should interpret the /memory/reg property
- * based on the values of the #address-cells and
- * #size-cells properites.
- */
- if (n == (sizeof(unsigned long) * 2)) {
- start = ((unsigned long *)buf)[0];
- end = start + ((unsigned long *)buf)[1];
- } else {
- start = ((unsigned long long *)buf)[0];
- end = start + ((unsigned long long *)buf)[1];
- }
if (start == 0 && end >= (BACKUP_SRC_END + 1))
start = BACKUP_SRC_END + 1;
Index: kexec-tools-2.0.4/kexec/arch/ppc/fs2dt.c
===================================================================
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/fs2dt.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/fs2dt.c
@@ -122,7 +122,7 @@ static unsigned propnum(const char *name
return offset;
}
-static void add_usable_mem_property(int fd, int len)
+static void add_usable_mem_property(FILE* fp, int len)
{
char fname[MAXPATH], *bname;
unsigned long buf[2];
@@ -137,21 +137,11 @@ static void add_usable_mem_property(int
if (strncmp(bname, "/memory@", 8) && strcmp(bname, "/memory"))
return;
- if (len < 2 * sizeof(unsigned long))
- die("unrecoverable error: not enough data for mem property\n");
- len = 2 * sizeof(unsigned long);
-
- if (lseek(fd, 0, SEEK_SET) < 0)
+ if (fseek(fp, 0, SEEK_SET) < 0)
die("unrecoverable error: error seeking in \"%s\": %s\n",
pathname, strerror(errno));
- if (read(fd, buf, len) != len)
- die("unrecoverable error: error reading \"%s\": %s\n",
- pathname, strerror(errno));
-
- if (~0ULL - buf[0] < buf[1])
- die("unrecoverable error: mem property overflow\n");
- base = buf[0];
- end = base + buf[1];
+ if (read_memory_region_limits(fp, &base, &end) != 0)
+ die("unrecoverable error: error parsing memory/reg limits\n");
for (range = 0; range < usablemem_rgns.size; range++) {
loc_base = usablemem_rgns.ranges[range].start;
@@ -194,8 +184,9 @@ static void add_usable_mem_property(int
static void putprops(char *fn, struct dirent **nlist, int numlist)
{
struct dirent *dp;
- int i = 0, fd, len;
+ int i = 0, len;
struct stat statbuf;
+ FILE *fp;
for (i = 0; i < numlist; i++) {
dp = nlist[i];
@@ -243,12 +234,12 @@ static void putprops(char *fn, struct di
*dt++ = len;
*dt++ = propnum(fn);
- fd = open(pathname, O_RDONLY);
- if (fd == -1)
+ fp = fopen(pathname, "r");
+ if (fp == NULL)
die("unrecoverable error: could not open \"%s\": %s\n",
pathname, strerror(errno));
- if (read(fd, dt, len) != len)
+ if (fread(dt, 1, len, fp) != len)
die("unrecoverable error: could not read \"%s\": %s\n",
pathname, strerror(errno));
@@ -290,8 +281,8 @@ static void putprops(char *fn, struct di
dt += (len + 3)/4;
if (!strcmp(dp->d_name, "reg") && usablemem_rgns.size)
- add_usable_mem_property(fd, len);
- close(fd);
+ add_usable_mem_property(fp, len);
+ fclose(fp);
}
fn[0] = '\0';
^ permalink raw reply
* RE: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
From: Jain Priyanka-B32167 @ 2011-05-30 4:47 UTC (permalink / raw)
To: Wolfram Sang
Cc: a.zummo@towertech.it, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, rtc-linux@googlegroups.com,
p_gortmaker@yahoo.com
In-Reply-To: <20110526091020.GA2201@pengutronix.de>
> -----Original Message-----
> From: linuxppc-dev-bounces+priyanka.jain=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+priyanka.jain=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> Wolfram Sang
> Sent: Thursday, May 26, 2011 2:40 PM
> To: Jain Priyanka-B32167
> Cc: a.zummo@towertech.it; akpm@linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; rtc-linux@googlegroups.com; p_gortmaker@yahoo.com
> Subject: Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307
> driver
>=20
> On Thu, May 26, 2011 at 12:33:29PM +0530, Priyanka Jain wrote:
>=20
> > PT7C4338 chip is being manufactured by Pericom Technology Inc.
> > It is a serial real-time clock which provides:
> > 1)Low-power clock/calendar.
> > 2)Programmable square-wave output.
> > It has 56 bytes of nonvolatile RAM.
> > Its register set is same as that of rtc device: DS1307.
> >
> > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
>=20
> So it is identical to ds1307? Then why not name your platform_device
> simply 'ds1307'?
Yes, It is possible to directly use platform device 'ds1307' in device tree=
.=20
But I have one query of how to capture the information that pericom, pt7c43=
38 device is compatible with dallas, ds1307. Can it be done in somewhere in=
some document or some code. Actually for pt7c4338 device driver, I actuall=
y started by asking if there is any already existing rtc device driver whic=
h is compatible with pericom pt7c4338 device on mailing list and as there w=
as no answer or help then, I actually ended up writing device driver for th=
at and then on the suggestion using ds1307 device driver for this.
Thanks
Priyanka
>=20
> Regards,
>=20
> Wolfram
>=20
> --
> Pengutronix e.K. | Wolfram Sang
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
^ permalink raw reply
* Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.33-longterm tree
From: gregkh @ 2011-05-30 4:16 UTC (permalink / raw)
To: miltonm, andi, anton, benh, eric.dumazet, gregkh, linuxppc-dev,
npiggin, paulmck, tglx, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.33-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.33.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.33 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.33 longterm tree,
please let <stable@kernel.org> know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller <miltonm@bga.com>
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller <miltonm@bga.com>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in longterm-queue-2.6.33 which might be from miltonm@bga.com are
^ permalink raw reply
* Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.32-longterm tree
From: gregkh @ 2011-05-30 4:14 UTC (permalink / raw)
To: miltonm, andi, anton, benh, eric.dumazet, gregkh, linuxppc-dev,
npiggin, paulmck, tglx, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.32-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.32 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
please let <stable@kernel.org> know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller <miltonm@bga.com>
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller <miltonm@bga.com>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in longterm-queue-2.6.32 which might be from miltonm@bga.com are
^ permalink raw reply
* Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.39-stable tree
From: gregkh @ 2011-05-30 4:07 UTC (permalink / raw)
To: miltonm, andi, anton, benh, eric.dumazet, gregkh, linuxppc-dev,
npiggin, paulmck, tglx, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.39-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.39 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@kernel.org> know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller <miltonm@bga.com>
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller <miltonm@bga.com>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in stable-queue which might be from miltonm@bga.com are
^ permalink raw reply
* Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.38-stable tree
From: gregkh @ 2011-05-30 4:05 UTC (permalink / raw)
To: miltonm, andi, anton, benh, eric.dumazet, gregkh, linuxppc-dev,
npiggin, paulmck, tglx, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.38-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.38 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@kernel.org> know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller <miltonm@bga.com>
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller <miltonm@bga.com>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in stable-queue which might be from miltonm@bga.com are
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Benjamin Herrenschmidt @ 2011-05-29 21:51 UTC (permalink / raw)
To: Andrey Gusev
Cc: paulus@samba.org, Tabi Timur-B04825,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DE29B78.1070209@list.ru>
On Sun, 2011-05-29 at 23:16 +0400, Andrey Gusev wrote:
> 28.05.2011 22:09, Tabi Timur-B04825 пишет:
> > On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev<ronne@list.ru> wrote:
> >> Hi!
> >> A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with
> >> almost the same config boots without any problems.
> > Have you tried using git-bisect to isolate the commit that breaks?
> >
> Fortunately, the rc1 is booted. I made git bisect:
> I have errors on building bad kernels:
> arch/powerpc/platforms/powermac/smp.c: In function ‘smp_core99_cpu_notify’:
> arch/powerpc/platforms/powermac/smp.c:855:7: error:
> ‘pmac_tb_clock_chip_host’ undeclared (first use in this function)
> arch/powerpc/platforms/powermac/smp.c:855:7: note: each undeclared
> identifier is reported only once for each function it appears in
This is an SMP machine ? If not, does it work with a UP kernel ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-29 20:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Martin Schwidefsky,
Thomas Gleixner, linux-arm-kernel, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Tejun Heo, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1306345402.21578.100.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> But face it, you can argue until you're blue in the face,
That is not a technical argument though - and i considered and
answered every valid technical argument made by you and Thomas.
You were either not able to or not willing to counter them.
> [...] but both tglx and I will NAK any and all patches that extend
> perf/ftrace beyond the passive observing role.
The thing is, perf is *already* well beyond the 'passive observer'
role: we already generate lots of 'action' in response to events. We
generate notification signals, we write events - all of which can
(and does) modify program behavior.
So what's your point? There's no "passive observer" role really -
it's apparently just that you dislike this use of instrumentation
while you approve of other uses.
Thanks,
Ingo
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Andrey Gusev @ 2011-05-29 19:16 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BANLkTinZd32+5b=3DdYknBCtQJT0qiNKcg@mail.gmail.com>
28.05.2011 22:09, Tabi Timur-B04825 пишет:
> On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev<ronne@list.ru> wrote:
>> Hi!
>> A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with
>> almost the same config boots without any problems.
> Have you tried using git-bisect to isolate the commit that breaks?
>
Fortunately, the rc1 is booted. I made git bisect:
andrey@power-debian:~/trash/build/kernel/git$ git bisect log
# bad: [a6360dd37e1a144ed11e6548371bade559a1e4df] Linux 2.6.39-rc3
# good: [0ce790e7d736cedc563e1fb4e998babf5a4dbc3d] Linux 2.6.39-rc1
git bisect start 'v2.6.39-rc3' 'v2.6.39-rc1'
# bad: [d14f5b810b49c7dbd1a01be1c6d3641d46090080] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad d14f5b810b49c7dbd1a01be1c6d3641d46090080
# good: [84daeb09ef2b11cb0b29e100766e38e206c8bc47] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good 84daeb09ef2b11cb0b29e100766e38e206c8bc47
# bad: [fb9a7d76da108d120efb2258ea83b18dbbb2ecdd] Merge branch
'core-fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad fb9a7d76da108d120efb2258ea83b18dbbb2ecdd
# bad: [ccd00d1091fa7fff151127f26f6900be2ac8cc10] Merge branch 'merge'
of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
git bisect bad ccd00d1091fa7fff151127f26f6900be2ac8cc10
# good: [d72944457bb7d5c4be43aa1b741cb93c69484c20] powerpc/smp: Add a
smp_ops->bringup_up() done callback
git bisect good d72944457bb7d5c4be43aa1b741cb93c69484c20
# good: [afdef69c7ff7d0bf59e3cafc187aefb12878dbe3] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6
git bisect good afdef69c7ff7d0bf59e3cafc187aefb12878dbe3
# bad: [c56e58537d504706954a06570b4034c04e5b7500] powerpc/smp: Create
idle threads on demand and properly reset them
git bisect bad c56e58537d504706954a06570b4034c04e5b7500
# bad: [105765f451d3ff007bb4ae3761e825686d9615db] powerpc/smp: Don't
expose per-cpu "cpu_state" array
git bisect bad 105765f451d3ff007bb4ae3761e825686d9615db
# bad: [734796f12351f9a0f38c47b981414f82d852f222] powerpc/pmac/smp: Fix
CPU hotplug crashes on some machines
git bisect bad 734796f12351f9a0f38c47b981414f82d852f222
I have errors on building bad kernels:
arch/powerpc/platforms/powermac/smp.c: In function ‘smp_core99_cpu_notify’:
arch/powerpc/platforms/powermac/smp.c:855:7: error:
‘pmac_tb_clock_chip_host’ undeclared (first use in this function)
arch/powerpc/platforms/powermac/smp.c:855:7: note: each undeclared
identifier is reported only once for each function it appears in
Andrey
^ permalink raw reply
* Re: Mapping an executable page
From: Tabi Timur-B04825 @ 2011-05-29 14:53 UTC (permalink / raw)
To: Thomas De Schampheleire; +Cc: linuxppc-dev
In-Reply-To: <BANLkTikd3ZtNRcz=ZWSsDL9OoeV0Wndy1g@mail.gmail.com>
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire
<patrickdepinguin+linuxppc@gmail.com> wrote:
> Although I realize that what I need to achieve is unconventional, what
> is the correct way of mapping a certain address range into memory, and
> be able to execute from it?
Have you tried looking at the actual TLB entry for this page to see if
it's correct? Also, you might need to do some kind of instruction
cache flushing before you jump to that page.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Andrey Gusev @ 2011-05-29 7:36 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BANLkTinZd32+5b=3DdYknBCtQJT0qiNKcg@mail.gmail.com>
28.05.2011 22:09, Tabi Timur-B04825 пишет:
> On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev<ronne@list.ru> wrote:
>> Hi!
>> A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with
>> almost the same config boots without any problems.
> Have you tried using git-bisect to isolate the commit that breaks?
>
I didn't. It takes very long time. If nobody have ideas I will.
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Tabi Timur-B04825 @ 2011-05-28 18:09 UTC (permalink / raw)
To: Andrey Gusev; +Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DE0AA62.4070909@list.ru>
On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev <ronne@list.ru> wrote:
> Hi!
> A kernel 2.6.39 doesn't boot on my POWER MAC G4. =9AA kernel 2.6.38.6 wit=
h
> almost the same config boots without any problems.
Have you tried using git-bisect to isolate the commit that breaks?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox