* [PATCH v2 14/14] powerpc/8xx: Move SW perf counters in first 32kb of memory
From: Christophe Leroy @ 2018-05-16 10:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
aneesh.kumar
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <cover.1526464250.git.christophe.leroy@c-s.fr>
In order to simplify time critical exceptions handling 8xx
specific SW perf counters, this patch moves the counters into
the begining of memory. This is possible because .text is readable
and the counters are never modified outside of the handlers.
By doing this, we avoid having to set a second register with
the upper part of the address of the counters.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/head_8xx.S | 75 +++++++++++++++++++-----------------------
1 file changed, 34 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index f65bd6fd1572..765fc4970c9c 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -106,6 +106,23 @@ turn_on_mmu:
mtspr SPRN_SRR0,r0
rfi /* enables MMU */
+
+#ifdef CONFIG_PERF_EVENTS
+ .align 4
+
+ .globl itlb_miss_counter
+itlb_miss_counter:
+ .space 4
+
+ .globl dtlb_miss_counter
+dtlb_miss_counter:
+ .space 4
+
+ .globl instruction_counter
+instruction_counter:
+ .space 4
+#endif
+
/*
* Exception entry code. This code runs with address translation
* turned off, i.e. using physical addresses.
@@ -368,25 +385,20 @@ _ENTRY(ITLBMiss_cmp)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
/* Restore registers */
-_ENTRY(itlb_miss_exit_1)
- mfspr r10, SPRN_SPRG_SCRATCH0
#if defined(ITLB_MISS_KERNEL) || defined(CONFIG_SWAP)
mfspr r11, SPRN_SPRG_SCRATCH1
#endif
+_ENTRY(itlb_miss_exit_1)
+ mfspr r10, SPRN_SPRG_SCRATCH0
rfi
#ifdef CONFIG_PERF_EVENTS
_ENTRY(itlb_miss_perf)
-#if !defined(ITLB_MISS_KERNEL) && !defined(CONFIG_SWAP)
- mtspr SPRN_SPRG_SCRATCH1, r11
-#endif
- lis r10, (itlb_miss_counter - PAGE_OFFSET)@ha
- lwz r11, (itlb_miss_counter - PAGE_OFFSET)@l(r10)
- addi r11, r11, 1
- stw r11, (itlb_miss_counter - PAGE_OFFSET)@l(r10)
-#endif
+ lwz r10, (itlb_miss_counter - PAGE_OFFSET)@l(0)
+ addi r10, r10, 1
+ stw r10, (itlb_miss_counter - PAGE_OFFSET)@l(0)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
+#endif
#ifndef CONFIG_PIN_TLB_TEXT
ITLBMissLinear:
@@ -399,9 +411,9 @@ ITLBMissLinear:
_PAGE_PRESENT
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
+ mfspr r11, SPRN_SPRG_SCRATCH1
_ENTRY(itlb_miss_exit_2)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
#endif
@@ -465,20 +477,18 @@ _ENTRY(DTLBMiss_jmp)
/* Restore registers */
mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG_SCRATCH1
_ENTRY(dtlb_miss_exit_1)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
#ifdef CONFIG_PERF_EVENTS
_ENTRY(dtlb_miss_perf)
- lis r10, (dtlb_miss_counter - PAGE_OFFSET)@ha
- lwz r11, (dtlb_miss_counter - PAGE_OFFSET)@l(r10)
- addi r11, r11, 1
- stw r11, (dtlb_miss_counter - PAGE_OFFSET)@l(r10)
-#endif
+ lwz r10, (dtlb_miss_counter - PAGE_OFFSET)@l(0)
+ addi r10, r10, 1
+ stw r10, (dtlb_miss_counter - PAGE_OFFSET)@l(0)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
+#endif
DTLBMissIMMR:
mtcr r11
@@ -493,9 +503,9 @@ DTLBMissIMMR:
li r11, RPN_PATTERN
mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG_SCRATCH1
_ENTRY(dtlb_miss_exit_2)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
DTLBMissLinear:
@@ -510,9 +520,9 @@ DTLBMissLinear:
li r11, RPN_PATTERN
mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG_SCRATCH1
_ENTRY(dtlb_miss_exit_3)
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
@@ -598,16 +608,13 @@ DataBreakpoint:
. = 0x1d00
InstructionBreakpoint:
mtspr SPRN_SPRG_SCRATCH0, r10
- mtspr SPRN_SPRG_SCRATCH1, r11
- lis r10, (instruction_counter - PAGE_OFFSET)@ha
- lwz r11, (instruction_counter - PAGE_OFFSET)@l(r10)
- addi r11, r11, -1
- stw r11, (instruction_counter - PAGE_OFFSET)@l(r10)
+ lwz r10, (instruction_counter - PAGE_OFFSET)@l(0)
+ addi r10, r10, -1
+ stw r10, (instruction_counter - PAGE_OFFSET)@l(0)
lis r10, 0xffff
ori r10, r10, 0x01
mtspr SPRN_COUNTA, r10
mfspr r10, SPRN_SPRG_SCRATCH0
- mfspr r11, SPRN_SPRG_SCRATCH1
rfi
#else
EXCEPTION(0x1d00, Trap_1d, unknown_exception, EXC_XFER_EE)
@@ -966,17 +973,3 @@ swapper_pg_dir:
*/
abatron_pteptrs:
.space 8
-
-#ifdef CONFIG_PERF_EVENTS
- .globl itlb_miss_counter
-itlb_miss_counter:
- .space 4
-
- .globl dtlb_miss_counter
-dtlb_miss_counter:
- .space 4
-
- .globl instruction_counter
-instruction_counter:
- .space 4
-#endif
--
2.13.3
^ permalink raw reply related
* Re: [PATCH 05/17] powerpc: move io mapping functions into ioremap.c
From: Christophe LEROY @ 2018-05-16 10:13 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
aneesh.kumar
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <87y3gqrarj.fsf@concordia.ellerman.id.au>
Le 11/05/2018 à 08:01, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
[...]
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/mm.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/init.h>
>> +#include <linux/highmem.h>
>> +#include <linux/memblock.h>
>> +#include <linux/slab.h>
>> +
>> +#include <asm/pgtable.h>
>> +#include <asm/pgalloc.h>
>> +#include <asm/fixmap.h>
>> +#include <asm/io.h>
>> +#include <asm/setup.h>
>> +#include <asm/sections.h>
>
> I needed:
>
> +#include <asm/machdep.h>
Oops, yes it was added in the following patch. Ok I move it one patch back.
Thanks
Christophe
>
> To fix:
>
> ../arch/powerpc/mm/ioremap.c: In function ‘ioremap_wc’:
> ../arch/powerpc/mm/ioremap.c:290:6: error: ‘ppc_md’ undeclared (first use in this function)
> if (ppc_md.ioremap)
> ^~~~~~
>
> cheers
>
^ permalink raw reply
* Re: [PATCH 00/17] Implement use of HW assistance on TLB table walk on 8xx
From: Christophe LEROY @ 2018-05-16 10:17 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
aneesh.kumar
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <87sh6yr8l2.fsf@concordia.ellerman.id.au>
Le 11/05/2018 à 08:48, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> The purpose of this serie is to implement hardware assistance for TLB table walk
>> on the 8xx.
>>
>> First part is to make L1 entries and L2 entries independant.
>> For that, we need to alter ioremap functions in order to handle GUARD attribute
>> at the PGD/PMD level.
>>
>> Last part is to try and reuse PTE fragment implemented on PPC64 in order to
>> not waste 16k Pages for page tables as only 4k are used. For the time being,
>> it doesn't work, but I include it in the serie anyway in order to get feedback.
>>
>> Tested successfully on 8xx up to the one before the last.
>>
>> Didn't have time to do compilation test on other configs, I send it anyway
>> before leaving for one week vacation in order to get feedback.
>
> I replied to a few patches, here's some other build errors:
>
>
> arch/powerpc/mm/ioremap.c:135:15: error: '_PAGE_GUARDED' undeclared (first use in this function):
> pseries_defconfig/powerpc
>
> arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: error: 'PKMAP_BASE' undeclared (first use in this function):
> pmac32_defconfig/powerpc-5.3
>
> include/linux/mm.h:533:41: error: 'PKMAP_BASE' undeclared (first use in this function):
> pmac32_defconfig/powerpc
>
> ERROR: "ioremap_bot" [net/netfilter/nf_conntrack.ko] undefined!:
> linkstation_defconfig/powerpc
>
> ERROR: "ioremap_bot" [fs/xfs/xfs.ko] undefined!:
> linkstation_defconfig/powerpc
>
> arch/powerpc/include/asm/nohash/32/pgtable.h:80:20: error: 'PKMAP_BASE' undeclared (first use in this function):
> corenet32_smp_defconfig/powerpc-5.3
>
> arch/powerpc/include/asm/nohash/32/pgalloc.h:64:43: error: '_PMD_GUARDED' undeclared (first use in this function):
> ppc40x_defconfig/powerpc-5.3
>
> ERROR: "ioremap_bot" [net/packet/af_packet.ko] undefined!:
> storcenter_defconfig/powerpc
>
> ERROR: "ioremap_bot" [drivers/usb/core/usbcore.ko] undefined!:
> ppc44x_defconfig/powerpc
>
Thanks for testing. I have now fixed all of them in v2.
For PKMAP_BASE, I had to move it from asm/highmem.h into the
book3s/32/pgtable.h and nohash/32/pgtable.h because including
asm/highmem.h in the pgtable.h files was introducing circular dependency.
Christophe
^ permalink raw reply
* [PATCH] cpuidle/powernv : init all present cpus for deep states
From: Akshay Adiga @ 2018-05-16 12:02 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: npiggin, mpe, ego, Akshay Adiga
Init all present cpus for deep states instead of "all possible" cpus.
Init fails if the possible cpu is gaurded. Resulting in making only
non-deep states available for cpuidle/hotplug.
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 1f12ab1..1c5d067 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -79,7 +79,7 @@ static int pnv_save_sprs_for_deep_states(void)
uint64_t msr_val = MSR_IDLE;
uint64_t psscr_val = pnv_deepest_stop_psscr_val;
- for_each_possible_cpu(cpu) {
+ for_each_present_cpu(cpu) {
uint64_t pir = get_hard_smp_processor_id(cpu);
uint64_t hsprg0_val = (uint64_t)paca_ptrs[cpu];
@@ -814,7 +814,7 @@ static int __init pnv_init_idle_states(void)
int cpu;
pr_info("powernv: idle: Saving PACA pointers of all CPUs in their thread sibling PACA\n");
- for_each_possible_cpu(cpu) {
+ for_each_present_cpu(cpu) {
int base_cpu = cpu_first_thread_sibling(cpu);
int idx = cpu_thread_in_core(cpu);
int i;
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v2] powerpc/powernv: Add queue mechanism for early messages
From: Michael Ellerman @ 2018-05-16 13:35 UTC (permalink / raw)
To: Deb McLemore, linuxppc-dev; +Cc: Deb McLemore, jk
In-Reply-To: <1511989553-16198-1-git-send-email-debmc@linux.vnet.ibm.com>
Deb McLemore <debmc@linux.vnet.ibm.com> writes:
> Problem being solved is when issuing a BMC soft poweroff during IPL,
> the poweroff was being lost so the machine would not poweroff.
>
> Opal messages were being received before the opal-power code
> registered its notifiers.
>
> Alternatives discussed (option #3 was chosen):
>
> 1 - Have opal_message_init() explicitly call opal_power_control_init()
> before it dequeues any OPAL messages (i.e. before we register the
> opal-msg IRQ handler).
>
> 2 - Introduce concept of critical message types and when we register
> handlers we track which message types have a registered handler,
> then defer the opal-msg IRQ registration until we have a handler
> registered for all the critical types.
>
> 3 - Buffering messages, if we receive a message and do not yet
> have a handler for that type, store the message and replay when
> a handler for that type is registered.
>
> Signed-off-by: Deb McLemore <debmc@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/opal.c | 83 ++++++++++++++++++++++++++++++++---
> 1 file changed, 78 insertions(+), 5 deletions(-)
Hi Deb,
Sorry for the delay (!) on this one.
A couple more comments ...
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index 65c79ec..46d7604 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -238,14 +288,25 @@ machine_early_initcall(powernv, opal_register_exception_handlers);
> int opal_message_notifier_register(enum opal_msg_type msg_type,
> struct notifier_block *nb)
> {
> + int ret;
> +
> if (!nb || msg_type >= OPAL_MSG_TYPE_MAX) {
> pr_warning("%s: Invalid arguments, msg_type:%d\n",
> __func__, msg_type);
> return -EINVAL;
> }
We still want to take the msg_list_lock around the registration, ie.
from here to the end of the function.
> - return atomic_notifier_chain_register(
> - &opal_msg_notifier_head[msg_type], nb);
> + ret = atomic_notifier_chain_register(
> + &opal_msg_notifier_head[msg_type], nb);
> +
> + if (ret)
> + return ret;
Otherwise a message that arrives here will be delivered before any
queued messages, which might be a problem.
> +
> + /* Replay any queued messages that came in */
> + /* prior to the notifier chain registration */
> + dequeue_replay_msg(msg_type);
> +
> + return 0;
> }
> EXPORT_SYMBOL_GPL(opal_message_notifier_register);
>
> @@ -259,9 +320,21 @@ EXPORT_SYMBOL_GPL(opal_message_notifier_unregister);
>
> static void opal_message_do_notify(uint32_t msg_type, void *msg)
> {
> - /* notify subscribers */
> - atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type],
> - msg_type, msg);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&msg_list_lock, flags);
> +
> + if (opal_msg_notifier_head[msg_type].head != NULL) {
> + /* notify subscribers */
> + atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type],
> + msg_type, msg);
> + } else {
> + /* Queue up the msg since no notifiers have */
> + /* registered yet for this msg_type */
> + queue_replay_msg(msg);
> + }
> +
> + spin_unlock_irqrestore(&msg_list_lock, flags);
I don't think it's actually likely to be a problem, but it would be nice
if we didn't have to hold the lock while calling the notifier in the
general case.
I think we can do that with eg:
bool queued = false;
spin_lock_irqsave(&msg_list_lock, flags);
if (opal_msg_notifier_head[msg_type].head == NULL) {
/*
* Queue up the msg since no notifiers have registered
* yet for this msg_type.
*/
queue_replay_msg(msg);
queued = true;
}
spin_unlock_irqrestore(&msg_list_lock, flags);
if (queued)
return;
/* notify subscribers */
atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type], msg_type, msg);
cheers
^ permalink raw reply
* Re: [V1, 01/11] powerpc/mm/book3s64: Move book3s64 code to pgtable-book3s64
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180416112724.9677-3-aneesh.kumar@linux.ibm.com>
On Mon, 2018-04-16 at 11:27:14 UTC, "Aneesh Kumar K.V" wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Only code movement and avoid #ifdef.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/59879d542a8e880391863d82cddf38
cheers
^ permalink raw reply
* Re: [2/5] powerpc/lib: Fix feature fixup test of external branch
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aik, paulus
In-Reply-To: <20180416143905.2716-2-mpe@ellerman.id.au>
On Mon, 2018-04-16 at 14:39:02 UTC, Michael Ellerman wrote:
> The expected case for this test was wrong, the source of the alternate
> code sequence is:
>
> FTR_SECTION_ELSE
> 2: or 2,2,2
> PPC_LCMPI r3,1
> beq 3f
> blt 2b
> b 3f
> b 1b
> ALT_FTR_SECTION_END(0, 1)
> 3: or 1,1,1
> or 2,2,2
> 4: or 3,3,3
>
> So when it's patched the '3' label should still be on the 'or 1,1,1',
> and the 4 label is irrelevant and can be removed.
>
> Fixes: 362e7701fd18 ("powerpc: Add self-tests of the feature fixup code")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Patches 2-5 applied to powerpc next.
https://git.kernel.org/powerpc/c/32810d91325ec76b8ef4df463f8a0e
cheers
^ permalink raw reply
* Re: [v2] powerpc: platform: cell: spufs: Change return type to vm_fault_t
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Souptick Joarder, willy, jk, arnd, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20180420173239.GA24560@jordon-HP-15-Notebook-PC>
On Fri, 2018-04-20 at 17:32:39 UTC, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
>
> We are fixing a minor bug, that the error from vm_insert_
> pfn() was being ignored and the effect of this is likely
> to be only felt in OOM situations.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e807f02c5c364c5a7315b50efdbc10
cheers
^ permalink raw reply
* Re: [1/3] powerpc/prom: Drop support for old FDT versions
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180509134229.26278-1-mpe@ellerman.id.au>
On Wed, 2018-05-09 at 13:42:27 UTC, Michael Ellerman wrote:
> In commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use
> libfdt") (Apr 2014), the generic flat device tree code dropped support
> for flat device tree's older than version 0x10 (16).
>
> We still have code in our CPU scanning to cope with flat device tree
> versions earlier than 2, which can now never trigger, so drop it.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/89c190627257a38d5e4d7cb3e5382f
cheers
^ permalink raw reply
* Re: powerpc/powernv: Fix memtrace build when NUMA=n
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: rashmica.g, anton
In-Reply-To: <20180510130913.23931-1-mpe@ellerman.id.au>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Thu, 2018-05-10 at 13:09:13 UTC, Michael Ellerman wrote:
> Currently memtrace doesn't build if NUMA=n:
>
> In function ‘memtrace_alloc_node’:
> arch/powerpc/platforms/powernv/memtrace.c:134:6:
> error: the address of ‘contig_page_data’ will always evaluate as ‘true’
> if (!NODE_DATA(nid) || !node_spanned_pages(nid))
> ^
>
> This is because for NUMA=n NODE_DATA(nid) points to an always
> allocated structure, contig_page_data.
>
> But even in the NUMA=y case memtrace_alloc_node() is only called for
> online nodes, and we should always have a NODE_DATA() allocated for an
> online node. So remove the (hopefully) overly paranoid check, which
> also means we can build when NUMA=n.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/8ccb442dec0ab53eefb5a607e405f7
cheers
^ permalink raw reply
* Re: macintosh/windfarm: fix spelling mistake: "ttarged" -> "ttarget"
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Colin King, Benjamin Herrenschmidt, linuxppc-dev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180510155439.16582-1-colin.king@canonical.com>
On Thu, 2018-05-10 at 15:54:39 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in debug messages of a structure
> field name
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/942cc40ae4354fee1e97137346434a
cheers
^ permalink raw reply
* Re: selftests/powerpc: fix exec benchmark
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180512033525.18762-1-npiggin@gmail.com>
On Sat, 2018-05-12 at 03:35:24 UTC, Nicholas Piggin wrote:
> The exec_target binary could segfault calling _exit(2) because r13
> is not set up properly (and libc looks at that when performing a
> syscall). Call SYS_exit using syscall(2) which doesn't seem to
> have this problem.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c906d2c74e0bb9059fbf43e21f8a96
cheers
^ permalink raw reply
* Re: [kernel, v3] powerpc/ioda: Use ibm, supported-tce-sizes for IOMMU page size mask
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson
In-Reply-To: <20180514093922.27179-1-aik@ozlabs.ru>
On Mon, 2018-05-14 at 09:39:22 UTC, Alexey Kardashevskiy wrote:
> At the moment we assume that IODA2 and newer PHBs can always do 4K/64K/16M
> IOMMU pages, however this is not the case for POWER9 and now skiboot
> advertises the supported sizes via the device so we use that instead
> of hard coding the mask.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7ef73cd39b4e2829ee88c06f938bc7
cheers
^ permalink raw reply
* [PATCH v4 0/4] powerpc patches for new Kconfig language
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
This series of patches improves th powerpc kbuild system. The
motivation was to to be compatible with the new Kconfig scripting
language that Yamada-san has proposed here:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/?h=kconfig-shell-v3
I have tested on top of that tree and powerpc now builds there.
I think patches 1-3 are improvements to the build system even before
kconfig-shell, so they could be merged ahead of it in the powerpc
tree.
Patch 4 takes advatage of a new feature of the kconfig-shell work to
improve powerpc kconfig, so that should instead be merged with the
kbuild tree with an ack from powerpc, after patches 1-3 are merged.
v4 just brings some build fixes to patch 3 (including a change from
patch 4 that belonged in patch 3), and improvemets to changelogs.
Thanks,
Nick
Nicholas Piggin (4):
powerpc/kbuild: set default generic machine type for 32-bit compile
powerpc/kbuild: remove CROSS32 defines from top level powerpc Makefile
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
powerpc/kbuild: move -mprofile-kernel check to Kconfig
arch/powerpc/Kconfig | 16 +------
arch/powerpc/Makefile | 45 ++++++++-----------
arch/powerpc/boot/Makefile | 16 ++++---
arch/powerpc/kernel/vdso32/Makefile | 15 +++++--
.../tools/gcc-check-mprofile-kernel.sh | 12 +++--
scripts/recordmcount.pl | 18 +++++++-
6 files changed, 67 insertions(+), 55 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v4 1/4] powerpc/kbuild: set default generic machine type for 32-bit compile
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
Some 64-bit toolchains uses the wrong ISA variant for compiling 32-bit
kernels, even with -m32. Debian's powerpc64le is one such case, and
that is because it is built with --with-cpu=power8.
So when cross compiling a 32-bit kernel with a 64-bit toolchain, set
-mcpu=powerpc initially, which is the generic 32-bit powerpc machine
type and scheduling model. CPU and platform code can override this
with subsequent -mcpu flags if necessary.
This is not done for 32-bit toolchains otherwise it would override
their defaults, which are presumably set appropriately for the
environment (moreso than a 64-bit cross compiler).
This fixes a lot of build failures due to incompatible assembly when
compiling 32-bit kernel with th Debian powerpc64le 64-bit toolchain.
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/Makefile | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 95813df90801..15ca4bafad82 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -24,9 +24,20 @@ ifeq ($(HAS_BIARCH),y)
ifeq ($(CROSS32_COMPILE),)
CROSS32CC := $(CC) -m32
KBUILD_ARFLAGS += --target=elf32-powerpc
+
+ifdef CONFIG_PPC32
+# These options will be overridden by any -mcpu option that the CPU
+# or platform code sets later on the command line, but they are needed
+# to set a sane 32-bit cpu target for the 64-bit cross compiler which
+# may default to the wrong ISA.
+KBUILD_CFLAGS += -mcpu=powerpc
+KBUILD_AFLAGS += -mcpu=powerpc
+endif
+
endif
endif
+
export CROSS32CC CROSS32AR
ifeq ($(CROSS_COMPILE),)
--
2.17.0
^ permalink raw reply related
* [PATCH v4 2/4] powerpc/kbuild: remove CROSS32 defines from top level powerpc Makefile
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
Switch VDSO32 build over to use CROSS32_COMPILE directly, and have
it pass in -m32 after the standard c_flags. This allows endianness
overrides to be removed and the endian and bitness flags moved into
standard flags variables.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/Makefile | 10 ----------
arch/powerpc/boot/Makefile | 16 +++++++++++-----
arch/powerpc/kernel/vdso32/Makefile | 15 +++++++++++----
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 15ca4bafad82..167b26a0780c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -17,14 +17,8 @@ HAS_BIARCH := $(call cc-option-yn, -m32)
# Set default 32 bits cross compilers for vdso and boot wrapper
CROSS32_COMPILE ?=
-CROSS32CC := $(CROSS32_COMPILE)gcc
-CROSS32AR := $(CROSS32_COMPILE)ar
-
ifeq ($(HAS_BIARCH),y)
ifeq ($(CROSS32_COMPILE),)
-CROSS32CC := $(CC) -m32
-KBUILD_ARFLAGS += --target=elf32-powerpc
-
ifdef CONFIG_PPC32
# These options will be overridden by any -mcpu option that the CPU
# or platform code sets later on the command line, but they are needed
@@ -33,13 +27,9 @@ ifdef CONFIG_PPC32
KBUILD_CFLAGS += -mcpu=powerpc
KBUILD_AFLAGS += -mcpu=powerpc
endif
-
endif
endif
-
-export CROSS32CC CROSS32AR
-
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
else
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 26d5d2a5b8e9..49767e06202c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,19 +23,23 @@ all: $(obj)/zImage
compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
+ifdef CROSS32_COMPILE
+ BOOTCC := $(CROSS32_COMPILE)gcc
+ BOOTAR := $(CROSS32_COMPILE)ar
+else
+ BOOTCC := $(CC)
+ BOOTAR := $(AR)
+endif
+
BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -Os -msoft-float -pipe \
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-D$(compress-y)
-BOOTCC := $(CC)
ifdef CONFIG_PPC64_BOOT_WRAPPER
BOOTCFLAGS += -m64
else
BOOTCFLAGS += -m32
-ifdef CROSS32_COMPILE
- BOOTCC := $(CROSS32_COMPILE)gcc
-endif
endif
BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
@@ -49,6 +53,8 @@ endif
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+BOOTARFLAGS := -cr$(KBUILD_ARFLAGS)
+
ifdef CONFIG_DEBUG_INFO
BOOTCFLAGS += -g
endif
@@ -202,7 +208,7 @@ quiet_cmd_bootas = BOOTAS $@
cmd_bootas = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
quiet_cmd_bootar = BOOTAR $@
- cmd_bootar = $(CROSS32AR) -cr$(KBUILD_ARFLAGS) $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
+ cmd_bootar = $(BOOTAR) $(BOOTARFLAGS) $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
$(obj-libfdt): $(obj)/%.o: $(srctree)/scripts/dtc/libfdt/%.c FORCE
$(call if_changed_dep,bootcc)
diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
index b8c434d1d459..50112d4473bb 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -8,8 +8,15 @@ obj-vdso32 = sigtramp.o gettimeofday.o datapage.o cacheflush.o note.o \
# Build rules
-ifeq ($(CONFIG_PPC32),y)
-CROSS32CC := $(CC)
+ifdef CROSS32_COMPILE
+ VDSOCC := $(CROSS32_COMPILE)gcc
+else
+ VDSOCC := $(CC)
+endif
+
+CC32FLAGS :=
+ifdef CONFIG_PPC64
+CC32FLAGS += -m32
endif
targets := $(obj-vdso32) vdso32.so vdso32.so.dbg
@@ -45,9 +52,9 @@ $(obj-vdso32): %.o: %.S FORCE
# actual build commands
quiet_cmd_vdso32ld = VDSO32L $@
- cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^)
+ cmd_vdso32ld = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^)
quiet_cmd_vdso32as = VDSO32A $@
- cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
+ cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) -c -o $@ $<
# install commands for the unstripped file
quiet_cmd_vdso_install = INSTALL $@
--
2.17.0
^ permalink raw reply related
* [PATCH v4 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
The powerpc toolchain can compile combinations of 32/64 bit and
big/little endian, so it's convenient to consider, e.g.,
`CC -m64 -mbig-endian`
To be the C compiler for the purpose of invoking it to build target
artifacts. So overriding the the CC variable to include these flags
works for this purpose.
Unfortunately that is not compatible with the way the proposed new
Kconfig macro language implementation, which gets confused by the
the $(CC) environment variable changing.
After previous patches in this series, these flags can be carefully
passed in using the usual kbuild flags variables instead.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Since v3:
- Added 32/64 flags to recordmcount.pl invocation of the toolchain,
similarly to BE/LE. This fixes problems with toolchain default
target bitness != kernel target bitness. I kept Steven's ack
because it's much the same powerpc specific change, okay?
- Added a similar fix for mismatched toolchain default endianness
or bitness to the gcc-check-mprofile-kernel.sh script. This was
pulled in from patch 4 and improved (added comment and endianness
flags).
arch/powerpc/Makefile | 16 +++++++++-------
.../powerpc/tools/gcc-check-mprofile-kernel.sh | 12 ++++++++----
scripts/recordmcount.pl | 18 +++++++++++++++++-
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 167b26a0780c..6faf1d6ad9dd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -75,13 +75,15 @@ endif
endif
ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
-override LD += -EL
+KBUILD_CFLAGS += -mlittle-endian
+LDFLAGS += -EL
LDEMULATION := lppc
GNUTARGET := powerpcle
MULTIPLEWORD := -mno-multiple
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
else
-override LD += -EB
+KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
+LDFLAGS += -EB
LDEMULATION := ppc
GNUTARGET := powerpc
MULTIPLEWORD := -mmultiple
@@ -94,19 +96,19 @@ aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
endif
-cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
-cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
ifneq ($(cc-name),clang)
cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align
endif
+cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
+cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
ifeq ($(HAS_BIARCH),y)
-override AS += -a$(BITS)
-override LD += -m elf$(BITS)$(LDEMULATION)
-override CC += -m$(BITS)
+KBUILD_CFLAGS += -m$(BITS)
+KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
+LDFLAGS += -m elf$(BITS)$(LDEMULATION)
KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
endif
diff --git a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
index 061f8035bdbe..a7dd0e5d9f98 100755
--- a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
+++ b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
@@ -7,17 +7,21 @@ set -o pipefail
# To debug, uncomment the following line
# set -x
+# -mprofile-kernel is only supported on 64le, so this should not be invoked
+# for other targets. Therefore we can pass in -m64 and -mlittle-endian
+# explicitly, to take care of toolchains defaulting to other targets.
+
# Test whether the compile option -mprofile-kernel exists and generates
# profiling code (ie. a call to _mcount()).
echo "int func() { return 0; }" | \
- $* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
- grep -q "_mcount"
+ $* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+ 2> /dev/null | grep -q "_mcount"
# Test whether the notrace attribute correctly suppresses calls to _mcount().
echo -e "#include <linux/compiler.h>\nnotrace int func() { return 0; }" | \
- $* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
- grep -q "_mcount" && \
+ $* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+ 2> /dev/null | grep -q "_mcount" && \
exit 1
echo "OK"
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 191eb949d52c..fe06e77c15eb 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -266,13 +266,29 @@ if ($arch eq "x86_64") {
$objcopy .= " -O elf32-sh-linux";
} elsif ($arch eq "powerpc") {
+ my $ldemulation;
+
$local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)";
# See comment in the sparc64 section for why we use '\w'.
$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?\\w*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$";
+ if ($endian eq "big") {
+ $cc .= " -mbig-endian ";
+ $ld .= " -EB ";
+ $ldemulation = "ppc"
+ } else {
+ $cc .= " -mlittle-endian ";
+ $ld .= " -EL ";
+ $ldemulation = "lppc"
+ }
if ($bits == 64) {
- $type = ".quad";
+ $type = ".quad";
+ $cc .= " -m64 ";
+ $ld .= " -m elf64".$ldemulation." ";
+ } else {
+ $cc .= " -m32 ";
+ $ld .= " -m elf32".$ldemulation." ";
}
} elsif ($arch eq "arm") {
--
2.17.0
^ permalink raw reply related
* [PATCH v4 4/4] powerpc/kbuild: move -mprofile-kernel check to Kconfig
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
This eliminates the workaround that requires disabling
-mprofile-kernel by default in Kconfig.
[ Note: this depends on https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kconfig-shell-v3 ]
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Since v3:
- Moved a stray hunk back to patch 3 where it belongs.
arch/powerpc/Kconfig | 16 +---------------
arch/powerpc/Makefile | 14 ++------------
2 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 512fcc177c87..af527f894f9b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -460,23 +460,9 @@ config LD_HEAD_STUB_CATCH
If unsure, say "N".
-config DISABLE_MPROFILE_KERNEL
- bool "Disable use of mprofile-kernel for kernel tracing"
- depends on PPC64 && CPU_LITTLE_ENDIAN
- default y
- help
- Selecting this options disables use of the mprofile-kernel ABI for
- kernel tracing. That will cause options such as live patching
- (CONFIG_LIVEPATCH) which depend on CONFIG_DYNAMIC_FTRACE_WITH_REGS to
- be disabled also.
-
- If you have a toolchain which supports mprofile-kernel, then you can
- disable this. Otherwise leave it enabled. If you're not sure, say
- "Y".
-
config MPROFILE_KERNEL
depends on PPC64 && CPU_LITTLE_ENDIAN
- def_bool !DISABLE_MPROFILE_KERNEL
+ def_bool $(success $(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)
config IOMMU_HELPER
def_bool PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6faf1d6ad9dd..8f7a64fe7370 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -161,18 +161,8 @@ CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
endif
ifdef CONFIG_MPROFILE_KERNEL
- ifeq ($(shell $(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__),OK)
- CC_FLAGS_FTRACE := -pg -mprofile-kernel
- KBUILD_CPPFLAGS += -DCC_USING_MPROFILE_KERNEL
- else
- # If the user asked for mprofile-kernel but the toolchain doesn't
- # support it, emit a warning and deliberately break the build later
- # with mprofile-kernel-not-supported. We would prefer to make this an
- # error right here, but then the user would never be able to run
- # oldconfig to change their configuration.
- $(warning Compiler does not support mprofile-kernel, set CONFIG_DISABLE_MPROFILE_KERNEL)
- CC_FLAGS_FTRACE := -mprofile-kernel-not-supported
- endif
+ CC_FLAGS_FTRACE := -pg -mprofile-kernel
+ KBUILD_CPPFLAGS += -DCC_USING_MPROFILE_KERNEL
endif
CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
--
2.17.0
^ permalink raw reply related
* Re: administrivia: mails containing HTML attachments
From: Stewart Smith @ 2018-05-16 14:46 UTC (permalink / raw)
To: Stephen Rothwell, ppc-dev
In-Reply-To: <20180516144829.2dbefb0b@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> I have decided that any email sent to the linuxppc-dev mailing list
> that contains an HTML attachment (or is just an HTML email) will be
> rejected. The vast majority of such mail are spam (and I have to spend
> time dropping them manually at the moment) and, I presume, anyone on
> this list is capable of sending no HTML email.
certainly one way to get those pesky IBM Verse users off. To be fair,
Documentation/process/email-clients.rst also warns them appropriately.
I fully support ditching HTML mail.
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH 1/7] cxlflash: Yield to active send threads
From: Matthew R. Ochs @ 2018-05-16 15:09 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065486-38860-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:04:46PM -0500, Uma Krishnan wrote:
> The following Oops may be encountered if the device is reset, i.e. EEH
> recovery, while there is heavy I/O traffic:
>
> 59:mon> t
> [c000200db64bb680] c008000009264c40 cxlflash_queuecommand+0x3b8/0x500
> [cxlflash]
> [c000200db64bb770] c00000000090d3b0 scsi_dispatch_cmd+0x130/0x2f0
> [c000200db64bb7f0] c00000000090fdd8 scsi_request_fn+0x3c8/0x8d0
> [c000200db64bb900] c00000000067f528 __blk_run_queue+0x68/0xb0
> [c000200db64bb930] c00000000067ab80 __elv_add_request+0x140/0x3c0
> [c000200db64bb9b0] c00000000068daac blk_execute_rq_nowait+0xec/0x1a0
> [c000200db64bba00] c00000000068dbb0 blk_execute_rq+0x50/0xe0
> [c000200db64bba50] c0000000006b2040 sg_io+0x1f0/0x520
> [c000200db64bbaf0] c0000000006b2e94 scsi_cmd_ioctl+0x534/0x610
> [c000200db64bbc20] c000000000926208 sd_ioctl+0x118/0x280
> [c000200db64bbcc0] c00000000069f7ac blkdev_ioctl+0x7fc/0xe30
> [c000200db64bbd20] c000000000439204 block_ioctl+0x84/0xa0
> [c000200db64bbd40] c0000000003f8514 do_vfs_ioctl+0xd4/0xa00
> [c000200db64bbde0] c0000000003f8f04 SyS_ioctl+0xc4/0x130
> [c000200db64bbe30] c00000000000b184 system_call+0x58/0x6c
>
> When there is no room to send the I/O request, the cached room is refreshed
> by reading the memory mapped command room value from the AFU. The AFU
> register mapping is refreshed during a reset, creating a race condition
> that can lead to the Oops above.
>
> During a device reset, the AFU should not be unmapped until all the active
> send threads quiesce. An atomic counter, cmds_active, is currently used to
> track internal AFU commands and quiesce during reset. This same counter can
> also be used for the active send threads.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] cpuidle/powernv : init all present cpus for deep states
From: Stewart Smith @ 2018-05-16 15:22 UTC (permalink / raw)
To: Akshay Adiga, linux-kernel, linuxppc-dev; +Cc: Akshay Adiga, npiggin, ego
In-Reply-To: <1526472134-23757-1-git-send-email-akshay.adiga@linux.vnet.ibm.com>
Akshay Adiga <akshay.adiga@linux.vnet.ibm.com> writes:
> Init all present cpus for deep states instead of "all possible" cpus.
> Init fails if the possible cpu is gaurded. Resulting in making only
> non-deep states available for cpuidle/hotplug.
Should this also head to stable? It means that for single threaded
workloads, if you guard out a CPU core you'll not get WoF, which means
that performance goes down when you wouldn't expect it to. Right?
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH 2/7] cxlflash: Limit the debug logs in the IO path
From: Matthew R. Ochs @ 2018-05-16 15:53 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065508-38897-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:08PM -0500, Uma Krishnan wrote:
> The kernel log can get filled with debug messages from send_cmd_ioarrin()
> when dynamic debug is enabled for the cxlflash module and there is a lot
> of legacy I/O traffic.
>
> While these messages are necessary to debug issues that involve command
> tracking, the abundance of data can overwrite other useful data in the
> log. The best option available is to limit the messages that should
> serve most of the common use cases.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services
From: Matthew R. Ochs @ 2018-05-16 15:54 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:22PM -0500, Uma Krishnan wrote:
> When a superpipe process that makes use of virtual LUNs is terminated or
> killed abruptly, there is a possibility that the cxlflash driver could
> hang and deprive other operations on the adapter.
>
> The release fop registered to be invoked on a context close, detaches
> every LUN associated with the context. The underlying service to detach
> the LUN assumes it has been called with the read semaphore held, and
> releases the semaphore before any operation that could be time consuming.
>
> When invoked without holding the read semaphore, an opportunity is created
> for the semaphore's count to become negative when it is temporarily
> released during one of these potential lengthy operations. This negative
> count results in subsequent acquisition attempts taking forever, leading
> to the hang.
>
> To support the current design point of holding the semaphore on the
> ioctl() paths, the release fop should acquire it before invoking any
> ioctl services.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 5/7] cxlflash: Add include guards to backend.h
From: Matthew R. Ochs @ 2018-05-16 15:58 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065551-39005-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:51PM -0500, Uma Krishnan wrote:
> The new header file, backend.h, that was recently added is missing
> the include guards. This commit adds the guards.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 6/7] cxlflash: Abstract hardware dependent assignments
From: Matthew R. Ochs @ 2018-05-16 15:59 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065565-39041-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:06:05PM -0500, Uma Krishnan wrote:
> As a staging cleanup to support transport specific builds of the cxlflash
> module, relocate device dependent assignments to header files. This will
> avoid littering the core driver with conditional compilation logic.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ 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