[PATCH 2/2] powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

Current vDSO64 implementation does not have support for coarse clocks (CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_COARSE), for which it falls back to system call, increasing the response time, vDSO implementation reduces the cycle time. Below is a benchmark of the difference in execution time with and

[PATCH 1/2] powerpc/vdso64: Coarse timer support preparatory patch

Reorganize code to make it easy to introduce CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE timer support. Signed-off-by: Santosh Sivaraj --- arch/powerpc/kernel/vdso64/gettimeofday.S | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[linux-next][DLPAR CPU][Oops] Bad kernel stack pointer

Hi, Dynamic CPU remove operation resulted in Kernel Panic on today's next-20170915 kernel. Machine Type: Power 7 PowerVM LPAR Kernel : 4.13.0-next-20170915 config : attached test: DLPAR CPU remove dmesg logs: -- cpu 37 (hwid 37) Ready to die... cpu 38 (hwid 38) Ready to die... cpu 39

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > If it's expected, why don't we kill the WARN_ON_ONCE()? I get it all > the time running xfstests as well. Dave insisted on it to decourage users/applications from mixing mmap and direct I/O. In many ways a tracepoint might be the

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 05:39:47PM +0200, Christoph Hellwig wrote: > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > > If it's expected, why don't we kill the WARN_ON_ONCE()? I get it all > > the time running xfstests as well. > > Dave insisted on it to decourage users/applications

[linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

Hi, A warning is triggered from: file fs/iomap.c in function iomap_dio_rw if (ret) goto out_free_dio; ret = invalidate_inode_pages2_range(mapping, start >> PAGE_SHIFT, end >> PAGE_SHIFT); >> WARN_ON_ONCE(ret); ret = 0; inode_dio_begin(inode); Machine

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On 09/18/2017 09:27 AM, Christoph Hellwig wrote: > On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: >> Hi, >> >> A warning is triggered from: >> >> file fs/iomap.c in function iomap_dio_rw >> >> if (ret) >> goto out_free_dio; >> >> ret =

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On 09/18/2017 09:43 AM, Al Viro wrote: > On Mon, Sep 18, 2017 at 05:39:47PM +0200, Christoph Hellwig wrote: >> On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: >>> If it's expected, why don't we kill the WARN_ON_ONCE()? I get it all >>> the time running xfstests as well. >> >> Dave

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: > Hi, > > A warning is triggered from: > > file fs/iomap.c in function iomap_dio_rw > > if (ret) > goto out_free_dio; > > ret = invalidate_inode_pages2_range(mapping, > start >> PAGE_SHIFT, end >>

[PATCH] powerpc: make irq_chip const, __initdata and __initconst

Make ehv_pic_irq_chip, mpic_ipi_chip and mpic_tm_chip const as they are used only as a copy operation. This usage is during init, so make them __initconst too. Make mpic_ipi_chip __initdata as it is only modified during the init phase and there is no reference of it anywhere after init.

Re: [PATCH] Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"

On 16.09.2017 22:12, Jan H. Schönherr wrote: > This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563. > > The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also, > there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where larger > gsi values make sense. > > As the commit was

[PATCH] powerpc/xmon: Add option to show uptime information

It might be useful to quickly get the uptime of a running system on xmon, without needing to grab data from memory and doing math on struct addresses. For example, it'd be useful to check for how long after a crash a system is on xmon shell or if some test was started after the first test crashed

Re: [linux-next][DLPAR CPU][Oops] Bad kernel stack pointer

On Mon, Sep 18, 2017 at 5:08 AM, Abdul Haleem wrote: > Hi, > > Dynamic CPU remove operation resulted in Kernel Panic on today's > next-20170915 kernel. > > Machine Type: Power 7 PowerVM LPAR > Kernel : 4.13.0-next-20170915 I assume this is not something new to 9/15

[PATCH] qe/ic: make qe_ic_irq_chip const and __initconst

Make this const as it is used only as a copy operation. This usage is inside an __init function, so make it __initconst too. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- Cross-compiled for powerpc. drivers/soc/fsl/qe/qe_ic.c | 2 +- 1 file changed, 1

[PATCH v1 2/3] pseries: Override pci_bus_match_virtfn_driver

For Powervm SR-IOV (Pseries) enablement we dont want to match the virtual function's device drivers since firmware plans to load the device node in the device tree dynamically when Novalink assigns the VF to a partition. Signed-off-by: Bryant G. Ly Signed-off-by:

[PATCH 2/2] powerpc/hotplug: Ensure nodes initialized for hotplug

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU, it may occur that the new resources are to be inserted into nodes that were not used for memory resources at bootup. Many different configurations of PowerPC resources may need to be supported depending upon the environment.

[PATCH v1 1/3] powerpc/kernel: Split up pci_bus_add_device

When enabling SR-IOV one might want to have their own version of starting device drivers for the VFs. This patch allows for SR-IOV callers to use pci_bus_add_virtfn_device instead of generic pci_bus_add_device. When enabling SR-IOV in PSeries architecture the dynamic VFs created within the

[PATCH v1 3/3] powerpc/kernel: Separate SR-IOV Calls

SR-IOV can now be enabled in PowerNV platforms and Pseries platforms. Therefore, the appropriate calls were moved to machine dependent code instead of definition at compile time. Signed-off-by: Bryant G. Ly Signed-off-by: Juan J. Alvarez ---

[PATCH 0/2] powerpc/nodes/hotplug: Fix problem with memoryless nodes

powerpc/nodes: Ensure enough nodes avail for operations. On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be

[PATCH 1/2] powerpc/nodes: Ensure enough nodes avail for operations

powerpc/nodes: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. This patch

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote: > Hello > > RFC > > On some arches C function pointers are indirect and point to > a function descriptor, which contains the actual pointer to the code. > This mostly doesn't matter, except for cases when

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

* Luck, Tony : > On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote: > > Hello > > > > RFC > > > > On some arches C function pointers are indirect and point to > > a function descriptor, which contains the actual pointer to the code. > > This

[PATCH v1 0/3] Prepartion for SR-IOV PowerVM Enablement

This patch series is to prepare for enabling SR-IOV on pseries. It separates the calls to be machine dependent and does not change any current functionality. Bryant G. Ly (3): powerpc/kernel: Split up pci_bus_add_device pseries: Override pci_bus_match_virtfn_driver powerpc/kernel: Separate

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On 9/15/2017 5:49 PM, Catalin Marinas wrote: > On Thu, Sep 14, 2017 at 07:07:50PM +, Roy Pledge wrote: >> On 9/14/2017 10:00 AM, Catalin Marinas wrote: >>> On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: @@ -123,23 +122,34 @@ static int bman_portal_probe(struct platform_device

[v5 02/12] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations

Use the shared-memory-pool mechanism for free buffer proxy record area allocation. Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/bman_ccsr.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c

[v5 10/12] soc/fsl/qbman: different register offsets on ARM

From: Madalin Bucur Signed-off-by: Madalin Bucur Signed-off-by: Claudiu Manoil Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/bman.c | 22 ++ drivers/soc/fsl/qbman/qman.c | 38

[v5 00/12] soc/fsl/qbman: Enable QBMan on ARM Platforms

This patch series enables DPAA1 QBMan devices for ARM and ARM64 architectures. This allows the LS1043A and LS1046A to use QBMan functionality which allows access to ethernet and cyptographic devices for example. Changes since v4: - Introduce a common function for QBMan private memory

[v5 06/12] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

From: Claudiu Manoil Not relevant and arch dependent. Overkill for PPC. Signed-off-by: Claudiu Manoil Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/dpaa_sys.h | 4 1 file changed, 4 deletions(-) diff --git

linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:541: bad condition ?

Hello there, linux-4.14-rc1/arch/powerpc/perf/hv-24x7.c:543]: (warning) Identical condition 's1 s1) return -1; Suggest code rework. Regards David Binderman

[v5 03/12] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations

Use the shared-memory-pool mechanism for frame queue descriptor and packed frame descriptor record area allocations. Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/qman_ccsr.c | 93 ++- drivers/soc/fsl/qbman/qman_priv.h | 2 -

[v5 11/12] soc/fsl/qbman: Add missing headers on ARM

From: Claudiu Manoil Unlike PPC builds, ARM builds need following headers explicitly: +#include for ioread32be() +#includefor udelay() Signed-off-by: Claudiu Manoil Signed-off-by: Roy Pledge ---

[v5 05/12] soc/fsl/qbman: Drop set/clear_bits usage

From: Madalin Bucur Replace PPC specific set/clear_bits API with standard bit twiddling so driver is portalable outside PPC. Signed-off-by: Madalin Bucur Signed-off-by: Claudiu Manoil Signed-off-by: Roy Pledge

[v5 09/12] soc/fsl/qbman: add QMAN_REV32

From: Madalin Bucur Add revision 3.2 of the QBMan block. This is the version for LS1043A and LS1046A SoCs. Signed-off-by: Madalin Bucur Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++

[v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

Updates the QMan and BMan device tree bindings for reserved memory nodes. This makes the reserved memory allocation compatible with the shared-dma-pool usage. Signed-off-by: Roy Pledge --- Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-

[v5 08/12] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

Rework portal mapping for PPC and ARM. The PPC devices require a cacheable coherent mapping while ARM will work with a non-cachable/write combine mapping. This also eliminates the need for manual cache flushes on ARM. This also fixes the code so sparse checking is clean. Signed-off-by: Roy Pledge

[v5 12/12] soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM

From: Madalin Bucur Signed-off-by: Madalin Bucur Signed-off-by: Claudiu Manoil [Stuart: changed to use ARCH_LAYERSCAPE] Signed-off-by: Stuart Yoder Signed-off-by: Roy Pledge ---

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 05:00:58PM -0500, Eric Sandeen wrote: > On 9/18/17 4:31 PM, Dave Chinner wrote: > > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > >> On 09/18/2017 09:27 AM, Christoph Hellwig wrote: > >>> On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: >

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 05:00:58PM -0500, Eric Sandeen wrote: > On 9/18/17 4:31 PM, Dave Chinner wrote: > > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > >> On 09/18/2017 09:27 AM, Christoph Hellwig wrote: > >>> On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: >

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > On 09/18/2017 09:27 AM, Christoph Hellwig wrote: > > On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: > >> Hi, > >> > >> A warning is triggered from: > >> > >> file fs/iomap.c in function iomap_dio_rw > >> > >> if (ret)

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On Mon, Sep 18, 2017 at 09:51:29AM -0600, Jens Axboe wrote: > On 09/18/2017 09:43 AM, Al Viro wrote: > > On Mon, Sep 18, 2017 at 05:39:47PM +0200, Christoph Hellwig wrote: > >> On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: > >>> If it's expected, why don't we kill the WARN_ON_ONCE()?

Re: [PATCH v2] net/ethernet/freescale: fix warning for ucc_geth

From: Valentin Longchamp Date: Fri, 15 Sep 2017 07:58:47 +0200 > uf_info.regs is resource_size_t i.e. phys_addr_t that can be either u32 > or u64 according to CONFIG_PHYS_ADDR_T_64BIT. > > The printk format is thus adaptet to u64 and the regs value cast to u64 >

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On 9/18/17 4:31 PM, Dave Chinner wrote: > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: >> On 09/18/2017 09:27 AM, Christoph Hellwig wrote: >>> On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: Hi, A warning is triggered from: file fs/iomap.c in

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

On 15.09.2017 10:59, David Gibson wrote: > On Fri, Sep 15, 2017 at 07:52:49AM +0200, Greg Kurz wrote: >> Dang! The mail relay at OVH has blacklisted Paul's address :-\ >> >> : host smtp.samba.org[144.76.82.148] said: 550-blacklisted >> at >> zen.spamhaus.org 550

Re: [PATCH] Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"

"Jan H. Schönherr" writes: > This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563. > > The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also, > there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where larger > gsi values make sense. > > As the commit

Re: [PATCH v3 00/20] Speculative page faults

Despite the unprovable lockdep warning raised by Sergey, I didn't get any feedback on this series. Is there a chance to get it moved upstream ? Thanks, Laurent. On 08/09/2017 20:06, Laurent Dufour wrote: > This is a port on kernel 4.13 of the work done by Peter Zijlstra to > handle page fault

Re: [PATCH] Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"

On 18/09/2017 08:44, Michael Ellerman wrote: > "Jan H. Schönherr" writes: > >> This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563. >> >> The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also, >> there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where

[PATCH 0/5] More NMI IPI enablement work

Hi, Here is the NMI IPI enablement for powernv, which requires supported firmware and hardware: https://lists.ozlabs.org/pipermail/skiboot/2017-September/009111.html And some preceeding patches that fix issues I ran into when testing it. Thanks, Nick Nicholas Piggin (5): powerpc/watchdog:

[PATCH 1/5] powerpc/watchdog: do not panic from locked CPU's IPI handler

The SMP watchdog will detect locked CPUs and IPI them to print a backtrace and registers. If panic on hard lockup is enabled, do not panic from this handler, because that can cause recursion into the IPI layer during the panic. The caller already panics in this case. Signed-off-by: Nicholas

[PATCH 2/5] powerpc/watchdog: do not backtrace locked CPUs twice if allcpus backtrace is enabled

If sysctl_hardlockup_all_cpu_backtrace is enabled, there is no need to IPI stuck CPUs for backtrace before trigger_allbutself_cpu_backtrace(), which does the same thing again. Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/watchdog.c | 19 +++ 1 file

[PATCH 4/5] powerpc/xmon: avoid tripping SMP hardlockup watchdog

The SMP hardlockup watchdog cross-checks other CPUs for lockups, which causes xmon headaches because it's assuming interrupts hard disabled means no watchdog troubles. Try to improve that by calling touch_nmi_watchdog() in obvious places where secondaries are spinning. Also annotate these spin

[PATCH 3/5] powerpc/watchdog: do not trigger SMP crash from touch_nmi_watchdog

In xmon, touch_nmi_watchdog() is not expected to be checking that other CPUs have not touched the watchdog, so the code will just call touch_nmi_watchdog() once before re-enabling hard interrupts. Just update our CPU's state, and ignore apparently stuck SMP threads. Arguably touch_nmi_watchdog

[PATCH 5/5] powerpc/powernv: implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET

This allows MSR[EE]=0 lockups to be detected on an OPAL (bare metal) system similarly to the hcall NMI IPI on pseries guests, when the platform/firmware supports it. This is an example of CPU10 spinning with interrupts hard disabled: Watchdog CPU:32 detected Hard LOCKUP other CPUS:10 Watchdog

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/18/17 20:39), Helge Deller wrote: [..] > > A few new warnings when building on ia64: > > > > arch/ia64/kernel/module.c:931: warning: passing argument 1 of > > 'dereference_function_descriptor' makes pointer from integer without a cast > > arch/ia64/kernel/module.c:931: warning: return

[v5 01/12] soc/fsl/qbman: Add common routine for QBMan private allocations

The QBMan device uses several memory regions to manage frame queues and buffers. Add a common routine for extracting and initializing these reserved memory areas. Signed-off-by: Roy Pledge --- drivers/soc/fsl/qbman/Makefile | 2 +- drivers/soc/fsl/qbman/dpaa_sys.c | 78

[v5 07/12] soc/fsl/qbman: Fix ARM32 typo

From: Valentin Rothberg The Kconfig symbol for 32bit ARM is 'ARM', not 'ARM32'. Signed-off-by: Valentin Rothberg Signed-off-by: Claudiu Manoil Signed-off-by: Roy Pledge ---

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/18/17 10:44), Luck, Tony wrote: [..] > > A few new warnings when building on ia64: > > arch/ia64/kernel/module.c:931: warning: passing argument 1 of > 'dereference_function_descriptor' makes pointer from integer without a cast > arch/ia64/kernel/module.c:931: warning: return makes