* Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL
From: Christoph Hellwig @ 2018-04-09 17:57 UTC (permalink / raw)
To: Laurent Dufour
Cc: linux-kernel, linux-mm, linuxppc-dev, x86, linux-doc,
linux-snps-arc, linux-arm-kernel, linux-riscv, linux-s390,
linux-sh, sparclinux, Jerome Glisse, mhocko, aneesh.kumar, akpm,
mpe, benh, paulus, Jonathan Corbet, Catalin Marinas, Will Deacon,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Vineet Gupta, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens
In-Reply-To: <1523282229-20731-3-git-send-email-ldufour@linux.vnet.ibm.com>
> -#ifdef __HAVE_ARCH_PTE_SPECIAL
> +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
> # define HAVE_PTE_SPECIAL 1
> #else
> # define HAVE_PTE_SPECIAL 0
I'd say kill this odd indirection and just use the
CONFIG_ARCH_HAS_PTE_SPECIAL symbol directly.
^ permalink raw reply
* Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL
From: David Rientjes @ 2018-04-09 20:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Laurent Dufour, linux-kernel, linux-mm, linuxppc-dev, x86,
linux-doc, linux-snps-arc, linux-arm-kernel, linux-riscv,
linux-s390, linux-sh, sparclinux, Jerome Glisse, mhocko,
aneesh.kumar, akpm, mpe, benh, paulus, Jonathan Corbet,
Catalin Marinas, Will Deacon, Yoshinori Sato, Rich Felker,
David S . Miller, Thomas Gleixner, Ingo Molnar, Vineet Gupta,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens
In-Reply-To: <20180409175757.GA12938@infradead.org>
On Mon, 9 Apr 2018, Christoph Hellwig wrote:
> > -#ifdef __HAVE_ARCH_PTE_SPECIAL
> > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
> > # define HAVE_PTE_SPECIAL 1
> > #else
> > # define HAVE_PTE_SPECIAL 0
>
> I'd say kill this odd indirection and just use the
> CONFIG_ARCH_HAS_PTE_SPECIAL symbol directly.
>
>
Agree, and I think it would be easier to audit/review if patches 1 and 3
were folded together to see the relationship between the newly added
selects and what #define's it is replacing. Otherwise, looks good!
^ permalink raw reply
* Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA
From: Rob Herring @ 2018-04-09 20:52 UTC (permalink / raw)
To: Oliver O'Halloran
Cc: linux-kernel@vger.kernel.org, Stephen Rothwell, linux-nvdimm,
devicetree, sparclinux, linuxppc-dev
In-Reply-To: <20180409074604.17671-1-oohall@gmail.com>
On Mon, Apr 9, 2018 at 2:46 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
> Some OF platforms (pseries and some SPARC systems) has their own
> implementations of NUMA affinity detection rather than using the generic
> OF_NUMA driver, which mainly exists for arm64. For other platforms one
> of two fallbacks provided by the base OF driver are used depending on
> CONFIG_NUMA.
>
> In the CONFIG_NUMA=n case the fallback is an inline function in of.h.
> In the =y case the fallback is a real function which is defined as a
> weak symbol so that it may be overwritten by the architecture if desired.
>
> The problem with this arrangement is that the real implementations all
> export of_node_to_nid(). Unfortunately it's not possible to export the
> fallback since it would clash with the non-weak version. As a result
> we get build failures when:
>
> a) CONFIG_NUMA=y && CONFIG_OF=y, and
> b) The platform doesn't implement of_node_to_nid(), and
> c) A module uses of_node_to_nid()
>
> Given b) will be true for most platforms this is fairly easy to hit
> and has been observed on ia64 and x86.
How specifically do we hit this? The only module I see using
of_node_to_nid in mainline is Cell EDAC driver.
> This patch remedies the problem by introducing the ARCH_HAS_OWN_OF_NUMA
> Kconfig option which is selected if an architecture provides an
> implementation of of_node_to_nid(). If a platform does not use it's own,
> or the generic OF_NUMA, then always use the inline fallback in of.h so
> we don't need to futz around with exports.
I'm more inclined to figure out how to remove the export and provide a
non DT specific function if drivers need to know this.
Rob
^ permalink raw reply
* Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA
From: Dan Williams @ 2018-04-09 21:05 UTC (permalink / raw)
To: Rob Herring
Cc: Oliver O'Halloran, Stephen Rothwell, Device Tree,
linux-nvdimm, linux-kernel@vger.kernel.org, sparclinux,
linuxppc-dev
In-Reply-To: <CAL_Jsq+ho2QhmNmPZMDJcfSxposJd=jYDvjhXH8cMAtVFP7n4A@mail.gmail.com>
On Mon, Apr 9, 2018 at 1:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Apr 9, 2018 at 2:46 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>> Some OF platforms (pseries and some SPARC systems) has their own
>> implementations of NUMA affinity detection rather than using the generic
>> OF_NUMA driver, which mainly exists for arm64. For other platforms one
>> of two fallbacks provided by the base OF driver are used depending on
>> CONFIG_NUMA.
>>
>> In the CONFIG_NUMA=n case the fallback is an inline function in of.h.
>> In the =y case the fallback is a real function which is defined as a
>> weak symbol so that it may be overwritten by the architecture if desired.
>>
>> The problem with this arrangement is that the real implementations all
>> export of_node_to_nid(). Unfortunately it's not possible to export the
>> fallback since it would clash with the non-weak version. As a result
>> we get build failures when:
>>
>> a) CONFIG_NUMA=y && CONFIG_OF=y, and
>> b) The platform doesn't implement of_node_to_nid(), and
>> c) A module uses of_node_to_nid()
>>
>> Given b) will be true for most platforms this is fairly easy to hit
>> and has been observed on ia64 and x86.
>
> How specifically do we hit this? The only module I see using
> of_node_to_nid in mainline is Cell EDAC driver.
The of_pmem driver is using it currently pending for a 4.17 pull
request. Stephen hit the compile failure in -next.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mm: Flush cache on memory hot(un)plug
From: Reza Arbab @ 2018-04-09 21:14 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, rashmica.g
In-Reply-To: <20180406052424.29841-1-bsingharora@gmail.com>
On Fri, Apr 06, 2018 at 03:24:23PM +1000, Balbir Singh wrote:
>This patch adds support for flushing potentially dirty
>cache lines when memory is hot-plugged/hot-un-plugged.
Acked-by: Reza Arbab <arbab@linux.ibm.com>
--
Reza Arbab
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio
From: Marek Vasut @ 2018-04-09 21:43 UTC (permalink / raw)
To: Nicolin Chen, broonie
Cc: linux-kernel, linuxppc-dev, alsa-devel, tiwai, perex, lgirdwood,
fabio.estevam
In-Reply-To: <1523231855-7854-1-git-send-email-nicoleotsuka@gmail.com>
On 04/09/2018 01:57 AM, Nicolin Chen wrote:
> When the desired ratio is less than 256, the savesub (tolerance)
> in the calculation would become 0. This will then fail the loop-
> search immediately without reporting any errors.
>
> But if the ratio is smaller enough, there is no need to calculate
> the tolerance because PM divisor alone is enough to get the ratio.
>
> So a simple fix could be just to set PM directly instead of going
> into the loop-search.
>
> Reported-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> Cc: Marek Vasut <marex@denx.de>
On i.MX6Q with TI PCM1808
Tested-by: Marek Vasut <marex@denx.de>
> ---
> sound/soc/fsl/fsl_esai.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 40a7004..da8fd98 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -144,6 +144,13 @@ static int fsl_esai_divisor_cal(struct snd_soc_dai *dai, bool tx, u32 ratio,
>
> psr = ratio <= 256 * maxfp ? ESAI_xCCR_xPSR_BYPASS : ESAI_xCCR_xPSR_DIV8;
>
> + /* Do not loop-search if PM (1 ~ 256) alone can serve the ratio */
> + if (ratio <= 256) {
> + pm = ratio;
> + fp = 1;
> + goto out;
> + }
> +
> /* Set the max fluctuation -- 0.1% of the max devisor */
> savesub = (psr ? 1 : 8) * 256 * maxfp / 1000;
>
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA
From: Rob Herring @ 2018-04-10 1:02 UTC (permalink / raw)
To: Dan Williams
Cc: Oliver O'Halloran, Stephen Rothwell, Device Tree,
linux-nvdimm, linux-kernel@vger.kernel.org, sparclinux,
linuxppc-dev
In-Reply-To: <CAPcyv4iCkc7ZSB7Sjk-O7iBWvvTzhTmdccucC4uN6GEu5Bjotw@mail.gmail.com>
On Mon, Apr 9, 2018 at 4:05 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, Apr 9, 2018 at 1:52 PM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, Apr 9, 2018 at 2:46 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>>> Some OF platforms (pseries and some SPARC systems) has their own
>>> implementations of NUMA affinity detection rather than using the generic
>>> OF_NUMA driver, which mainly exists for arm64. For other platforms one
>>> of two fallbacks provided by the base OF driver are used depending on
>>> CONFIG_NUMA.
>>>
>>> In the CONFIG_NUMA=n case the fallback is an inline function in of.h.
>>> In the =y case the fallback is a real function which is defined as a
>>> weak symbol so that it may be overwritten by the architecture if desired.
>>>
>>> The problem with this arrangement is that the real implementations all
>>> export of_node_to_nid(). Unfortunately it's not possible to export the
>>> fallback since it would clash with the non-weak version. As a result
>>> we get build failures when:
>>>
>>> a) CONFIG_NUMA=y && CONFIG_OF=y, and
>>> b) The platform doesn't implement of_node_to_nid(), and
>>> c) A module uses of_node_to_nid()
>>>
>>> Given b) will be true for most platforms this is fairly easy to hit
>>> and has been observed on ia64 and x86.
>>
>> How specifically do we hit this? The only module I see using
>> of_node_to_nid in mainline is Cell EDAC driver.
>
> The of_pmem driver is using it currently pending for a 4.17 pull
> request. Stephen hit the compile failure in -next.
You mean the stuff reviewed last week in the middle of the merge
window? Sounds like 4.18 material to me.
Rob
^ permalink raw reply
* [PATCH] powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic
From: Michael Ellerman @ 2018-04-10 1:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ard.biesheuvel
If you build the kernel with CONFIG_RELOCATABLE=n, then install the
modules, rebuild the kernel with CONFIG_RELOCATABLE=y and leave the
old modules installed, we crash something like:
Unable to handle kernel paging request for data at address 0xd000000018d66cef
Faulting instruction address: 0xc0000000021ddd08
Oops: Kernel access of bad area, sig: 11 [#1]
Modules linked in: x_tables autofs4
CPU: 2 PID: 1 Comm: systemd Not tainted 4.16.0-rc6-gcc_ubuntu_le-g99fec39 #1
...
NIP check_version.isra.22+0x118/0x170
Call Trace:
__ksymtab_xt_unregister_table+0x58/0xfffffffffffffcb8 [x_tables] (unreliable)
resolve_symbol+0xb4/0x150
load_module+0x10e8/0x29a0
SyS_finit_module+0x110/0x140
system_call+0x58/0x6c
This happens because since commit 71810db27c1c ("modversions: treat
symbol CRCs as 32 bit quantities"), a relocatable kernel encodes and
handles symbol CRCs differently from a non-relocatable kernel.
Although it's possible we could try and detect this situation and
handle it, it's much more robust to simply make the state of
CONFIG_RELOCATABLE part of the module vermagic.
Fixes: 71810db27c1c ("modversions: treat symbol CRCs as 32 bit quantities")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/module.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
index 7e28442827f1..4f6573934792 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -15,9 +15,19 @@
#ifdef CC_USING_MPROFILE_KERNEL
-#define MODULE_ARCH_VERMAGIC "mprofile-kernel"
+#define MODULE_ARCH_VERMAGIC_FTRACE "mprofile-kernel "
+#else
+#define MODULE_ARCH_VERMAGIC_FTRACE ""
#endif
+#ifdef CONFIG_RELOCATABLE
+#define MODULE_ARCH_VERMAGIC_RELOCATABLE "relocatable "
+#else
+#define MODULE_ARCH_VERMAGIC_RELOCATABLE ""
+#endif
+
+#define MODULE_ARCH_VERMAGIC MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE
+
#ifndef __powerpc64__
/*
* Thanks to Paul M for explaining this.
--
2.14.1
^ permalink raw reply related
* Occasionally losing the tick_sched_timer
From: Nicholas Piggin @ 2018-04-10 2:16 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Linux Kernel Mailing List, Alexey Kardashevskiy, linuxppc-dev,
kvm-ppc
We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no
more timers scheduled, despite hard and soft lockup watchdogs should have
their heart beat timers and probably many others.
The reproducer we have is running a KVM workload. The lockup is in the
host kernel, quite rare but we may be able to slowly test things.
I have a sysrq+q snippet. CPU3 is the stuck one, you can see its tick has
stopped for a long time and no hrtimer active. Included CPU4 for what the
other CPUs look like.
Thomas do you have any ideas on what we might look for, or if we can add
some BUG_ON()s to catch this at its source?
- CPU3 is sitting in its cpuidle loop (polling idle with all other idle
states disabled).
- `taskset -c 3 ls` basically revived the CPU and got timers running again.
- May not be a new bug because we have just in the past few releases
enabled the hard lockup detector by default
- KVM is being used. This switches various registers like timebase and
decrementer. Possibly that's involved, but we can't say the bug does
not happen without KVM.
cpu: 3
clock 0:
.base: 00000000df30f5ab
.index: 0
.resolution: 1 nsecs
.get_time:
ktime_get
.offset: 0 nsecs
active timers:
clock 1:
.base: 00000000520cc304
.index: 1
.resolution: 1 nsecs
.get_time:
ktime_get_real
.offset: 1523263049759155857 nsecs
active timers:
clock 2:
.base: 00000000706e6277
.index: 2
.resolution: 1 nsecs
.get_time:
ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 3:
.base: 00000000e2ae2811
.index: 3
.resolution: 1 nsecs
.get_time:
ktime_get_clocktai
.offset: 1523263049759155857 nsecs
active timers:
clock 4:
.base: 00000000c93e2f8e
.index: 4
.resolution: 1 nsecs
.get_time:
ktime_get
.offset: 0 nsecs
active timers:
clock 5:
.base: 000000007b726c6a
.index: 5
.resolution: 1 nsecs
.get_time:
ktime_get_real
.offset: 1523263049759155857 nsecs
active timers:
clock 6:
.base: 00000000f17c2d4f
.index: 6
.resolution: 1 nsecs
.get_time:
ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 7:
.base: 000000006c57ef89
.index: 7
.resolution: 1 nsecs
.get_time:
ktime_get_clocktai
.offset: 1523263049759155857 nsecs
active timers:
.expires_next : 9223372036854775807 nsecs
.hres_active : 1
.nr_events : 1446533
.nr_retries : 1434
.nr_hangs : 0
.max_hang_time : 0
.nohz_mode : 2
.last_tick : 17763120000000 nsecs
.tick_stopped : 1
.idle_jiffies : 4296713609
.idle_calls : 2573133
.idle_sleeps : 1957794
.idle_entrytime : 17763129999625 nsecs
.idle_waketime : 59550238131639 nsecs
.idle_exittime : 17763110009176 nsecs
.idle_sleeptime : 17504617295679 nsecs
.iowait_sleeptime: 719978688 nsecs
.last_jiffies : 4296713608
.next_timer : 17763130000000
.idle_expires : 17763130000000 nsecs
jiffies: 4300892324
cpu: 4
clock 0:
.base: 0000000007d8226b
.index: 0
.resolution: 1 nsecs
.get_time:
ktime_get
.offset: 0 nsecs
active timers:
#0:
<00000000a73e543a>
,
tick_sched_timer
, S:01
# expires at 59552950000000-59552950000000 nsecs [in 2685654802 to 2685654802 nsecs]
#1:
<000000009b4a3b88>
,
hrtimer_wakeup
, S:01
# expires at 59602585423025-59602642458243 nsecs [in 52321077827 to 52378113045 nsecs]
clock 1:
.base: 00000000d2ae50c4
.index: 1
.resolution: 1 nsecs
.get_time:
ktime_get_real
.offset: 1523263049759155857 nsecs
active timers:
clock 2:
.base: 000000001a80e123
.index: 2
.resolution: 1 nsecs
.get_time:
ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 3:
.base: 000000005c97ab69
.index: 3
.resolution: 1 nsecs
.get_time:
ktime_get_clocktai
.offset: 1523263049759155857 nsecs
active timers:
clock 4:
.base: 0000000075ac8f03
.index: 4
.resolution: 1 nsecs
.get_time:
ktime_get
.offset: 0 nsecs
active timers:
clock 5:
.base: 00000000db06f6ce
.index: 5
.resolution: 1 nsecs
.get_time:
ktime_get_real
.offset: 1523263049759155857 nsecs
active timers:
clock 6:
.base: 00000000fa63fbce
.index: 6
.resolution: 1 nsecs
.get_time:
ktime_get_boottime
.offset: 0 nsecs
active timers:
clock 7:
.base: 0000000041de439c
.index: 7
.resolution: 1 nsecs
.get_time:
ktime_get_clocktai
.offset: 1523263049759155857 nsecs
active timers:
.expires_next : 59552950000000 nsecs
.hres_active : 1
.nr_events : 294282
.nr_retries : 16138
.nr_hangs : 0
.max_hang_time : 0
.nohz_mode : 2
.last_tick : 59545620000000 nsecs
.tick_stopped : 1
.idle_jiffies : 4300891859
.idle_calls : 553259
.idle_sleeps : 536396
.idle_entrytime : 59547990019145 nsecs
.idle_waketime : 59547990000281 nsecs
.idle_exittime : 59545550189113 nsecs
.idle_sleeptime : 59355272715835 nsecs
.iowait_sleeptime: 846852479 nsecs
.last_jiffies : 4300892096
.next_timer : 59552950000000
.idle_expires : 59552950000000 nsecs
jiffies: 4300892324
^ permalink raw reply
* Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA
From: Dan Williams @ 2018-04-10 2:29 UTC (permalink / raw)
To: Rob Herring
Cc: Oliver O'Halloran, Stephen Rothwell, Device Tree,
linux-nvdimm, linux-kernel@vger.kernel.org, sparclinux,
linuxppc-dev
In-Reply-To: <CAL_JsqJY-sh+KBVAja=epesGdd=OKJzooeLTpZZD0Z++ZxqzfA@mail.gmail.com>
On Mon, Apr 9, 2018 at 6:02 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Apr 9, 2018 at 4:05 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> On Mon, Apr 9, 2018 at 1:52 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Mon, Apr 9, 2018 at 2:46 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>>>> Some OF platforms (pseries and some SPARC systems) has their own
>>>> implementations of NUMA affinity detection rather than using the generic
>>>> OF_NUMA driver, which mainly exists for arm64. For other platforms one
>>>> of two fallbacks provided by the base OF driver are used depending on
>>>> CONFIG_NUMA.
>>>>
>>>> In the CONFIG_NUMA=n case the fallback is an inline function in of.h.
>>>> In the =y case the fallback is a real function which is defined as a
>>>> weak symbol so that it may be overwritten by the architecture if desired.
>>>>
>>>> The problem with this arrangement is that the real implementations all
>>>> export of_node_to_nid(). Unfortunately it's not possible to export the
>>>> fallback since it would clash with the non-weak version. As a result
>>>> we get build failures when:
>>>>
>>>> a) CONFIG_NUMA=y && CONFIG_OF=y, and
>>>> b) The platform doesn't implement of_node_to_nid(), and
>>>> c) A module uses of_node_to_nid()
>>>>
>>>> Given b) will be true for most platforms this is fairly easy to hit
>>>> and has been observed on ia64 and x86.
>>>
>>> How specifically do we hit this? The only module I see using
>>> of_node_to_nid in mainline is Cell EDAC driver.
>>
>> The of_pmem driver is using it currently pending for a 4.17 pull
>> request. Stephen hit the compile failure in -next.
>
> You mean the stuff reviewed last week in the middle of the merge
> window? Sounds like 4.18 material to me.
It was originally posted for 4.16. The reposting and review came in
late this cycle, but outside of a critical issue I'd rather not delay
it again. The build error issue is resolved by not allowing modular
builds of this driver for now.
>
> Rob
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Fix section mismatch warnings for early boot symbols
From: Michael Ellerman @ 2018-04-10 2:51 UTC (permalink / raw)
To: Mauricio Faria de Oliveira, linux-kernel, jeyu
Cc: jeyu, akpm, npiggin, linuxppc-dev
In-Reply-To: <1522943439-26235-1-git-send-email-mauricfo@linux.vnet.ibm.com>
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> writes:
> Some of the boot code located at the start of kernel text is "init"
> class, in that it only runs at boot time, however marking it as normal
> init code is problematic because that puts it into a different section
> located at the very end of kernel text.
>
> e.g., in case the TOC is not set up, we may not be able to tolerate a
> branch trampoline to reach the init function.
>
> Credits: code and message are based on 2016 patch by Nicholas Piggin,
> and slightly modified so not to rename the powerpc code/symbol names.
>
> Subject: [PATCH] powerpc/64: quieten section mismatch warnings
> From: Nicholas Piggin <npiggin at gmail.com>
> Date: Fri Dec 23 00:14:19 AEDT 2016
>
> This resolves the following section mismatch warnings:
>
> WARNING: vmlinux.o(.text+0x2fa8): Section mismatch in reference from the variable __boot_from_prom to the function .init.text:prom_init()
> The function __boot_from_prom() references
> the function __init prom_init().
> This is often because __boot_from_prom lacks a __init
> annotation or the annotation of prom_init is wrong.
>
> WARNING: vmlinux.o(.text+0x3238): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:early_setup()
> The function start_here_multiplatform() references
> the function __init early_setup().
> This is often because start_here_multiplatform lacks a __init
> annotation or the annotation of early_setup is wrong.
>
> WARNING: vmlinux.o(.text+0x326c): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel()
> The function start_here_common() references
> the function __init start_kernel().
> This is often because start_here_common lacks a __init
> annotation or the annotation of start_kernel is wrong.
Thanks for picking this one up.
I hate to be a pain ... but before we merge this and proliferate these
names, I'd like to change the names of some of these early asm
functions. They're terribly named due to historical reasons.
I haven't actually thought of good names yet though :)
I'll try and come up with some and post a patch doing the renames.
cheers
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
From: Michael Ellerman @ 2018-04-10 3:21 UTC (permalink / raw)
To: Nicholas Piggin, Balbir Singh
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC
In-Reply-To: <20180408234150.36d766f6@roar.ozlabs.ibm.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> On Sun, 8 Apr 2018 20:17:47 +1000
> Balbir Singh <bsingharora@gmail.com> wrote:
>
>> On Fri, Apr 6, 2018 at 3:56 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>> > This crashes with a "Bad real address for load" attempting to load
>> > from the vmalloc region in realmode (faulting address is in DAR).
>> >
>> > Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
>> > LE SMP NR_CPUS=2048 NUMA PowerNV
>> > CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994
>> > NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
>> > REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994)
>> > MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
>> > CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
>> > NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
>> > LR [c0000000000c2430] do_tlbies+0x230/0x2f0
>> >
>> > I suspect the reason is the per-cpu data is not in the linear chunk.
>> > This could be restored if that was able to be fixed, but for now,
>> > just remove the tracepoints.
>>
>> Could you share the stack trace as well? I've not observed this in my testing.
>
> I can't seem to find it, I can try reproduce tomorrow. It was coming
> from h_remove hcall from the guest. It's 176 logical CPUs.
>
>> May be I don't have as many cpus. I presume your talking about the per cpu
>> data offsets for per cpu trace data?
>
> It looked like it was dereferencing virtually mapped per-cpu data, yes.
> Probably the perf_events deref.
Naveen has posted a series to (hopefully) fix this, which just missed
the merge window:
https://patchwork.ozlabs.org/patch/894757/
cheers
^ permalink raw reply
* Re: [PATCH v2 9/9] powerpc/powernv: opal-kmsg standardise OPAL_BUSY handling
From: Russell Currey @ 2018-04-10 5:01 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180409052431.26405-10-npiggin@gmail.com>
On Mon, 2018-04-09 at 15:24 +1000, Nicholas Piggin wrote:
> OPAL_CONSOLE_FLUSH is documented as being able to return OPAL_BUSY,
> so implement the standard OPAL_BUSY handling for it.
>
> Cc: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/powernv: opal-kmsg use flush fallback from console code
From: Russell Currey @ 2018-04-10 5:01 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180409054056.27292-2-npiggin@gmail.com>
On Mon, 2018-04-09 at 15:40 +1000, Nicholas Piggin wrote:
> Use the more refined and tested event polling loop from
> opal_put_chars
> as the fallback console flush in the opal-kmsg path. This loop is
> used
> by the console driver today, whereas the opal-kmsg fallback is not
> likely to have been used for years.
>
> Use WARN_ONCE rather than a printk when the fallback is invoked to
> prepare for moving the console flush into a common function.
>
> Cc: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/powernv: Implement and use opal_flush_console
From: Russell Currey @ 2018-04-10 5:02 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180409054056.27292-3-npiggin@gmail.com>
On Mon, 2018-04-09 at 15:40 +1000, Nicholas Piggin wrote:
> A new console flushing firmware API was introduced to replace event
> polling loops, and implemented in opal-kmsg with affddff69c55e
> ("powerpc/powernv: Add a kmsg_dumper that flushes console output on
> panic"), to flush the console in the panic path.
>
> The OPAL console driver has other situations where interrupts are off
> and it needs to flush the console synchronously. These still use a
> polling loop.
>
> So move the opal-kmsg flush code to opal_flush_console, and use the
> new function in opal-kmsg and opal_put_chars.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
From: Naveen N. Rao @ 2018-04-10 5:55 UTC (permalink / raw)
To: Balbir Singh, Michael Ellerman, Nicholas Piggin
Cc: open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <87in8zbvbk.fsf@concordia.ellerman.id.au>
Michael Ellerman wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>=20
>> On Sun, 8 Apr 2018 20:17:47 +1000
>> Balbir Singh <bsingharora@gmail.com> wrote:
>>
>>> On Fri, Apr 6, 2018 at 3:56 AM, Nicholas Piggin <npiggin@gmail.com> wro=
te:
>>> > This crashes with a "Bad real address for load" attempting to load
>>> > from the vmalloc region in realmode (faulting address is in DAR).
>>> >
>>> > Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
>>> > LE SMP NR_CPUS=3D2048 NUMA PowerNV
>>> > CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g4=
3d1859f0994
>>> > NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
>>> > REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d=
1859f0994)
>>> > MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 0000000=
0
>>> > CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE:=
3
>>> > NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
>>> > LR [c0000000000c2430] do_tlbies+0x230/0x2f0
>>> >
>>> > I suspect the reason is the per-cpu data is not in the linear chunk.
>>> > This could be restored if that was able to be fixed, but for now,
>>> > just remove the tracepoints. =20
>>>=20
>>> Could you share the stack trace as well? I've not observed this in my t=
esting.
>>
>> I can't seem to find it, I can try reproduce tomorrow. It was coming
>> from h_remove hcall from the guest. It's 176 logical CPUs.
>>
>>> May be I don't have as many cpus. I presume your talking about the per =
cpu
>>> data offsets for per cpu trace data?
>>
>> It looked like it was dereferencing virtually mapped per-cpu data, yes.
>> Probably the perf_events deref.
>=20
> Naveen has posted a series to (hopefully) fix this, which just missed
> the merge window:
>=20
> https://patchwork.ozlabs.org/patch/894757/
I'm afraid that won't actually help here :(
That series is specific to the function tracer, while this is using=20
static tracepoints.
We could convert trace_tlbie() to a TRACE_EVENT_CONDITION() and guard it=20
within a check for paca->ftrace_enabled, but that would only be useful=20
if the below callsites can ever be hit outside of KVM guest mode.
- Naveen
=
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
From: Nicholas Piggin @ 2018-04-10 6:10 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Balbir Singh, Michael Ellerman,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <1523338519.27phm7a0v6.naveen@linux.ibm.com>
On Tue, 10 Apr 2018 11:25:02 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> Michael Ellerman wrote:
> > Nicholas Piggin <npiggin@gmail.com> writes:
> >
> >> On Sun, 8 Apr 2018 20:17:47 +1000
> >> Balbir Singh <bsingharora@gmail.com> wrote:
> >>
> >>> On Fri, Apr 6, 2018 at 3:56 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
> >>> > This crashes with a "Bad real address for load" attempting to load
> >>> > from the vmalloc region in realmode (faulting address is in DAR).
> >>> >
> >>> > Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
> >>> > LE SMP NR_CPUS=2048 NUMA PowerNV
> >>> > CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994
> >>> > NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
> >>> > REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994)
> >>> > MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
> >>> > CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
> >>> > NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
> >>> > LR [c0000000000c2430] do_tlbies+0x230/0x2f0
> >>> >
> >>> > I suspect the reason is the per-cpu data is not in the linear chunk.
> >>> > This could be restored if that was able to be fixed, but for now,
> >>> > just remove the tracepoints.
> >>>
> >>> Could you share the stack trace as well? I've not observed this in my testing.
> >>
> >> I can't seem to find it, I can try reproduce tomorrow. It was coming
> >> from h_remove hcall from the guest. It's 176 logical CPUs.
> >>
> >>> May be I don't have as many cpus. I presume your talking about the per cpu
> >>> data offsets for per cpu trace data?
> >>
> >> It looked like it was dereferencing virtually mapped per-cpu data, yes.
> >> Probably the perf_events deref.
> >
> > Naveen has posted a series to (hopefully) fix this, which just missed
> > the merge window:
> >
> > https://patchwork.ozlabs.org/patch/894757/
>
> I'm afraid that won't actually help here :(
> That series is specific to the function tracer, while this is using
> static tracepoints.
>
> We could convert trace_tlbie() to a TRACE_EVENT_CONDITION() and guard it
> within a check for paca->ftrace_enabled, but that would only be useful
> if the below callsites can ever be hit outside of KVM guest mode.
Right, removing the trace points is the right thing to do here.
Doing tracing in real mode would be a whole effort itself, I'd expect.
Or disabling realmode handling of HPT hcalls if trace points are
active.
Thanks,
Nick
^ permalink raw reply
* [PATCH] powerpc/64: optimises from64to32()
From: Christophe Leroy @ 2018-04-10 6:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev
The current implementation of from64to32() gives a poor result:
0000000000000270 <.from64to32>:
270: 38 00 ff ff li r0,-1
274: 78 69 00 22 rldicl r9,r3,32,32
278: 78 00 00 20 clrldi r0,r0,32
27c: 7c 60 00 38 and r0,r3,r0
280: 7c 09 02 14 add r0,r9,r0
284: 78 09 00 22 rldicl r9,r0,32,32
288: 7c 00 4a 14 add r0,r0,r9
28c: 78 03 00 20 clrldi r3,r0,32
290: 4e 80 00 20 blr
This patch modifies from64to32() to operate in the same
spirit as csum_fold()
It swaps the two 32-bit halves of sum then it adds it with the
unswapped sum. If there is a carry from adding the two 32-bit halves,
it will carry from the lower half into the upper half, giving us the
correct sum in the upper half.
The resulting code is:
0000000000000260 <.from64to32>:
260: 78 60 00 02 rotldi r0,r3,32
264: 7c 60 1a 14 add r3,r0,r3
268: 78 63 00 22 rldicl r3,r3,32,32
26c: 4e 80 00 20 blr
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/checksum.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/checksum.h b/arch/powerpc/include/asm/checksum.h
index 4e63787dc3be..54065caa40b3 100644
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -12,6 +12,7 @@
#ifdef CONFIG_GENERIC_CSUM
#include <asm-generic/checksum.h>
#else
+#include <linux/bitops.h>
/*
* Computes the checksum of a memory block at src, length len,
* and adds in "sum" (32-bit), while copying the block to dst.
@@ -55,11 +56,7 @@ static inline __sum16 csum_fold(__wsum sum)
static inline u32 from64to32(u64 x)
{
- /* add up 32-bit and 32-bit for 32+c bit */
- x = (x & 0xffffffff) + (x >> 32);
- /* add up carry.. */
- x = (x & 0xffffffff) + (x >> 32);
- return (u32)x;
+ return (x + ror64(x, 32)) >> 32;
}
static inline __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr, __u32 len,
--
2.13.3
^ permalink raw reply related
* [PATCH] Revert "powerpc/64: Fix checksum folding in csum_add()"
From: Christophe Leroy @ 2018-04-10 6:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev, Shile Zhang
This reverts commit 6ad966d7303b70165228dba1ee8da1a05c10eefe.
That commit was pointless, because csum_add() sums two 32 bits
values, so the sum is 0x1fffffffe at the maximum.
And then when adding upper part (1) and lower part (0xfffffffe),
the result is 0xffffffff which doesn't carry.
Any lower value will not carry either.
And behind the fact that this commit is useless, it also kills the
whole purpose of having an arch specific inline csum_add()
because the resulting code gets even worse than what is obtained
with the generic implementation of csum_add()
0000000000000240 <.csum_add>:
240: 38 00 ff ff li r0,-1
244: 7c 84 1a 14 add r4,r4,r3
248: 78 00 00 20 clrldi r0,r0,32
24c: 78 89 00 22 rldicl r9,r4,32,32
250: 7c 80 00 38 and r0,r4,r0
254: 7c 09 02 14 add r0,r9,r0
258: 78 09 00 22 rldicl r9,r0,32,32
25c: 7c 00 4a 14 add r0,r0,r9
260: 78 03 00 20 clrldi r3,r0,32
264: 4e 80 00 20 blr
In comparison, the generic implementation of csum_add() gives:
0000000000000290 <.csum_add>:
290: 7c 63 22 14 add r3,r3,r4
294: 7f 83 20 40 cmplw cr7,r3,r4
298: 7c 10 10 26 mfocrf r0,1
29c: 54 00 ef fe rlwinm r0,r0,29,31,31
2a0: 7c 60 1a 14 add r3,r0,r3
2a4: 78 63 00 20 clrldi r3,r3,32
2a8: 4e 80 00 20 blr
And the reverted implementation for PPC64 gives:
0000000000000240 <.csum_add>:
240: 7c 84 1a 14 add r4,r4,r3
244: 78 80 00 22 rldicl r0,r4,32,32
248: 7c 80 22 14 add r4,r0,r4
24c: 78 83 00 20 clrldi r3,r4,32
250: 4e 80 00 20 blr
Fixes: 6ad966d7303b7 ("powerpc/64: Fix checksum folding in csum_add()")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/checksum.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/checksum.h b/arch/powerpc/include/asm/checksum.h
index 842124b199b5..4e63787dc3be 100644
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -112,7 +112,7 @@ static inline __wsum csum_add(__wsum csum, __wsum addend)
#ifdef __powerpc64__
res += (__force u64)addend;
- return (__force __wsum) from64to32(res);
+ return (__force __wsum)((u32)res + (res >> 32));
#else
asm("addc %0,%0,%1;"
"addze %0,%0;"
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v9 21/24] perf tools: Add support for the SPF perf event
From: David Rientjes @ 2018-04-10 6:47 UTC (permalink / raw)
To: Andi Kleen
Cc: Laurent Dufour, paulmck, peterz, akpm, kirill, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180327034936.GO13724@tassilo.jf.intel.com>
On Mon, 26 Mar 2018, Andi Kleen wrote:
> > Aside: should there be a new spec_flt field for struct task_struct that
> > complements maj_flt and min_flt and be exported through /proc/pid/stat?
>
> No. task_struct is already too bloated. If you need per process tracking
> you can always get it through trace points.
>
Hi Andi,
We have
count_vm_event(PGFAULT);
count_memcg_event_mm(vma->vm_mm, PGFAULT);
in handle_mm_fault() but not counterpart for spf. I think it would be
helpful to be able to determine how much faulting can be done
speculatively if there is no per-process tracking without tracing.
^ permalink raw reply
* [PATCH] powerpc/powernv/opal: Use standard interrupts property when available
From: Benjamin Herrenschmidt @ 2018-04-10 7:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stewart Smith
For (bad) historical reasons, OPAL used to create a non-standard pair of
properties "opal-interrupts" and "opal-interrupts-names" for representing
the list of interrupts it wants Linux to request on its behalf.
Among other issues, the opal-interrupts doesn't have a way to carry the
type of interrupts, and they were assumed to be all level sensitive.
This is wrong on some recent systems where some of them are edge sensitive
causing warnings in the XIVE code and possible misbehaviours if they need
to be retriggered (typically the NPU2 TCE error interrupts).
This makes Linux switch to using the standard "interrupts" and
"interrupt-names" properties instead when they are available, using standard
of_irq helpers, which can carry all the desired type information.
Newer versions of OPAL will generate those properties in addition to the
legacy ones.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
index 9d1b8c0aaf93..46785eaf625d 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -23,6 +23,7 @@
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/irq_work.h>
+#include <linux/of_irq.h>
#include <asm/machdep.h>
#include <asm/opal.h>
@@ -39,8 +40,8 @@ struct opal_event_irqchip {
};
static struct opal_event_irqchip opal_event_irqchip;
-static unsigned int opal_irq_count;
-static unsigned int *opal_irqs;
+static int opal_irq_count;
+static struct resource *opal_irqs;
static void opal_handle_irq_work(struct irq_work *work);
static u64 last_outstanding_events;
@@ -174,24 +175,21 @@ void opal_event_shutdown(void)
/* First free interrupts, which will also mask them */
for (i = 0; i < opal_irq_count; i++) {
- if (!opal_irqs[i])
+ if (!opal_irqs || !opal_irqs[i].start)
continue;
if (in_interrupt())
- disable_irq_nosync(opal_irqs[i]);
+ disable_irq_nosync(opal_irqs[i].start);
else
- free_irq(opal_irqs[i], NULL);
-
- opal_irqs[i] = 0;
+ free_irq(opal_irqs[i].start, NULL);
}
}
int __init opal_event_init(void)
{
struct device_node *dn, *opal_node;
- const char **names;
- u32 *irqs;
- int i, rc;
+ bool old_style = false;
+ int i, rc = 0;
opal_node = of_find_node_by_path("/ibm,opal");
if (!opal_node) {
@@ -216,67 +214,91 @@ int __init opal_event_init(void)
goto out;
}
- /* Get opal-interrupts property and names if present */
- rc = of_property_count_u32_elems(opal_node, "opal-interrupts");
- if (rc < 0)
- goto out;
+ /* Look for new-style (standard) "interrupts" property */
+ opal_irq_count = of_irq_count(opal_node);
- opal_irq_count = rc;
- pr_debug("Found %d interrupts reserved for OPAL\n", opal_irq_count);
+ /* Absent ? Look for the old one */
+ if (opal_irq_count < 1) {
+ /* Get opal-interrupts property and names if present */
+ rc = of_property_count_u32_elems(opal_node, "opal-interrupts");
+ if (rc > 0)
+ opal_irq_count = rc;
+ old_style = true;
+ }
- irqs = kcalloc(opal_irq_count, sizeof(*irqs), GFP_KERNEL);
- names = kcalloc(opal_irq_count, sizeof(*names), GFP_KERNEL);
- opal_irqs = kcalloc(opal_irq_count, sizeof(*opal_irqs), GFP_KERNEL);
+ /* No interrupts ? Bail out */
+ if (!opal_irq_count)
+ goto out;
- if (WARN_ON(!irqs || !names || !opal_irqs))
- goto out_free;
+ pr_debug("OPAL: Found %d interrupts reserved for OPAL using %s scheme\n",
+ opal_irq_count, old_style ? "old" : "new");
- rc = of_property_read_u32_array(opal_node, "opal-interrupts",
- irqs, opal_irq_count);
- if (rc < 0) {
- pr_err("Error %d reading opal-interrupts array\n", rc);
- goto out_free;
+ /* Allocate an IRQ resources array */
+ opal_irqs = kcalloc(opal_irq_count, sizeof(struct resource), GFP_KERNEL);
+ if (WARN_ON(!opal_irqs)) {
+ rc = -ENOMEM;
+ goto out;
}
- /* It's not an error for the names to be missing */
- of_property_read_string_array(opal_node, "opal-interrupts-names",
- names, opal_irq_count);
+ /* Build the resources array */
+ if (old_style) {
+ /* Old style "opal-interrupts" property */
+ for (i = 0; i < opal_irq_count; i++) {
+ struct resource *r = &opal_irqs[i];
+ const char *name = NULL;
+ u32 hw_irq;
+ int virq;
+
+ rc = of_property_read_u32_index(opal_node, "opal-interrupts",
+ i, &hw_irq);
+ if (WARN_ON(rc < 0)) {
+ opal_irq_count = i;
+ break;
+ }
+ of_property_read_string_index(opal_node, "opal-interrupts-names",
+ i, &name);
+ virq = irq_create_mapping(NULL, hw_irq);
+ if (!virq) {
+ pr_warn("Failed to map OPAL irq 0x%x\n", hw_irq);
+ continue;
+ }
+ r->start = r->end = virq;
+ r->flags = IORESOURCE_IRQ | IRQ_TYPE_LEVEL_LOW;
+ r->name = name;
+ }
+ } else {
+ /* new style standard "interrupts" property */
+ rc = of_irq_to_resource_table(opal_node, opal_irqs, opal_irq_count);
+ if (WARN_ON(rc < 0)) {
+ opal_irq_count = 0;
+ kfree(opal_irqs);
+ goto out;
+ }
+ if (WARN_ON(rc < opal_irq_count))
+ opal_irq_count = rc;
+ }
/* Install interrupt handlers */
for (i = 0; i < opal_irq_count; i++) {
- unsigned int virq;
- char *name;
+ struct resource *r = &opal_irqs[i];
+ const char *name;
- /* Get hardware and virtual IRQ */
- virq = irq_create_mapping(NULL, irqs[i]);
- if (!virq) {
- pr_warn("Failed to map irq 0x%x\n", irqs[i]);
- continue;
- }
-
- if (names[i] && strlen(names[i]))
- name = kasprintf(GFP_KERNEL, "opal-%s", names[i]);
+ /* Prefix name */
+ if (r->name)
+ name = kasprintf(GFP_KERNEL, "opal-%s", r->name);
else
name = kasprintf(GFP_KERNEL, "opal");
/* Install interrupt handler */
- rc = request_irq(virq, opal_interrupt, IRQF_TRIGGER_LOW,
+ rc = request_irq(r->start, opal_interrupt, r->flags & IRQD_TRIGGER_MASK,
name, NULL);
if (rc) {
- irq_dispose_mapping(virq);
- pr_warn("Error %d requesting irq %d (0x%x)\n",
- rc, virq, irqs[i]);
+ pr_warn("Error %d requesting OPAL irq %d\n", rc, (int)r->start);
continue;
}
-
- /* Cache IRQ */
- opal_irqs[i] = virq;
}
-
-out_free:
- kfree(irqs);
- kfree(names);
-out:
+ rc = 0;
+ out:
of_node_put(opal_node);
return rc;
}
^ permalink raw reply related
* Re: Occasionally losing the tick_sched_timer
From: Thomas Gleixner @ 2018-04-10 7:42 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Linux Kernel Mailing List, Alexey Kardashevskiy, linuxppc-dev,
kvm-ppc, Frederic Weisbecker
In-Reply-To: <20180410121618.4fffffcc@roar.ozlabs.ibm.com>
Nick,
On Tue, 10 Apr 2018, Nicholas Piggin wrote:
> We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no
> more timers scheduled, despite hard and soft lockup watchdogs should have
> their heart beat timers and probably many others.
>
> The reproducer we have is running a KVM workload. The lockup is in the
> host kernel, quite rare but we may be able to slowly test things.
>
> I have a sysrq+q snippet. CPU3 is the stuck one, you can see its tick has
> stopped for a long time and no hrtimer active. Included CPU4 for what the
> other CPUs look like.
>
> Thomas do you have any ideas on what we might look for, or if we can add
> some BUG_ON()s to catch this at its source?
Not really. Tracing might be a more efficient tool that random BUG_ONs.
> - CPU3 is sitting in its cpuidle loop (polling idle with all other idle
> states disabled).
>
> - `taskset -c 3 ls` basically revived the CPU and got timers running again.
Which is not surprising because that kicks the CPU out of idle and starts
the tick timer again.
Does this restart the watchdog timers as well?
> cpu: 3
> clock 0:
> .base: 00000000df30f5ab
> .index: 0
> .resolution: 1 nsecs
> .get_time: ktime_get
> .offset: 0 nsecs
> active timers:
So in theory the soft lockup watchdog hrtimer should be queued here.
> .expires_next : 9223372036854775807 nsecs
> .hres_active : 1
> .nr_events : 1446533
> .nr_retries : 1434
> .nr_hangs : 0
> .max_hang_time : 0
> .nohz_mode : 2
> .last_tick : 17763120000000 nsecs
> .tick_stopped : 1
> .idle_jiffies : 4296713609
> .idle_calls : 2573133
> .idle_sleeps : 1957794
> .idle_waketime : 59550238131639 nsecs
> .idle_sleeptime : 17504617295679 nsecs
> .iowait_sleeptime: 719978688 nsecs
> .last_jiffies : 4296713608
So this was the last time when the CPU came out of idle:
> .idle_exittime : 17763110009176 nsecs
Here it went back into idle:
> .idle_entrytime : 17763129999625 nsecs
And this was the next timer wheel timer due for expiry:
> .next_timer : 17763130000000
> .idle_expires : 17763130000000 nsecs
which makes no sense whatsoever, but this might be stale information. Can't
tell.
> cpu: 4
> clock 0:
> .base: 0000000007d8226b
> .index: 0
> .resolution: 1 nsecs
> .get_time: ktime_get
> .offset: 0 nsecs
> active timers: #0: <00000000a73e543a>, tick_sched_timer, S:01
> # expires at 59552950000000-59552950000000 nsecs [in 2685654802 to 2685654802 nsecs]
The tick timer is scheduled because the next timer wheel timer is due at
59552950000000, which might be the hard watchdog timer
> #1: <000000009b4a3b88>, hrtimer_wakeup, S:01
> # expires at 59602585423025-59602642458243 nsecs [in 52321077827 to 52378113045 nsecs]
That might be the soft lockup hrtimer.
I'd try to gather more information about the chain of events via tracing
and stop the tracer once the lockup detector hits.
Thanks,
tglx
^ permalink raw reply
* Re: Occasionally losing the tick_sched_timer
From: Nicholas Piggin @ 2018-04-10 8:26 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Linux Kernel Mailing List, Alexey Kardashevskiy, linuxppc-dev,
kvm-ppc, Frederic Weisbecker
In-Reply-To: <alpine.DEB.2.21.1804100923430.2058@nanos.tec.linutronix.de>
On Tue, 10 Apr 2018 09:42:29 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> Nick,
>
> On Tue, 10 Apr 2018, Nicholas Piggin wrote:
> > We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no
> > more timers scheduled, despite hard and soft lockup watchdogs should have
> > their heart beat timers and probably many others.
> >
> > The reproducer we have is running a KVM workload. The lockup is in the
> > host kernel, quite rare but we may be able to slowly test things.
> >
> > I have a sysrq+q snippet. CPU3 is the stuck one, you can see its tick has
> > stopped for a long time and no hrtimer active. Included CPU4 for what the
> > other CPUs look like.
> >
> > Thomas do you have any ideas on what we might look for, or if we can add
> > some BUG_ON()s to catch this at its source?
>
> Not really. Tracing might be a more efficient tool that random BUG_ONs.
Sure, we could try that. Any suggestions? timer events?
>
> > - CPU3 is sitting in its cpuidle loop (polling idle with all other idle
> > states disabled).
> >
> > - `taskset -c 3 ls` basically revived the CPU and got timers running again.
>
> Which is not surprising because that kicks the CPU out of idle and starts
> the tick timer again.
Yep.
> Does this restart the watchdog timers as well?
I think so, but now you ask I'm not 100% sure we directly observed it.
We can check that next time it locks up.
> > cpu: 3
> > clock 0:
> > .base: 00000000df30f5ab
> > .index: 0
> > .resolution: 1 nsecs
> > .get_time: ktime_get
> > .offset: 0 nsecs
> > active timers:
>
> So in theory the soft lockup watchdog hrtimer should be queued here.
>
> > .expires_next : 9223372036854775807 nsecs
> > .hres_active : 1
> > .nr_events : 1446533
> > .nr_retries : 1434
> > .nr_hangs : 0
> > .max_hang_time : 0
> > .nohz_mode : 2
> > .last_tick : 17763120000000 nsecs
> > .tick_stopped : 1
> > .idle_jiffies : 4296713609
> > .idle_calls : 2573133
> > .idle_sleeps : 1957794
>
> > .idle_waketime : 59550238131639 nsecs
> > .idle_sleeptime : 17504617295679 nsecs
> > .iowait_sleeptime: 719978688 nsecs
> > .last_jiffies : 4296713608
>
> So this was the last time when the CPU came out of idle:
>
> > .idle_exittime : 17763110009176 nsecs
>
> Here it went back into idle:
>
> > .idle_entrytime : 17763129999625 nsecs
>
> And this was the next timer wheel timer due for expiry:
>
> > .next_timer : 17763130000000
> > .idle_expires : 17763130000000 nsecs
>
> which makes no sense whatsoever, but this might be stale information. Can't
> tell.
Wouldn't we expect to see that if there is a timer that was missed
somehow because the tick_sched_timer was not set?
>
> > cpu: 4
> > clock 0:
> > .base: 0000000007d8226b
> > .index: 0
> > .resolution: 1 nsecs
> > .get_time: ktime_get
> > .offset: 0 nsecs
> > active timers: #0: <00000000a73e543a>, tick_sched_timer, S:01
> > # expires at 59552950000000-59552950000000 nsecs [in 2685654802 to 2685654802 nsecs]
>
> The tick timer is scheduled because the next timer wheel timer is due at
> 59552950000000, which might be the hard watchdog timer
>
> > #1: <000000009b4a3b88>, hrtimer_wakeup, S:01
> > # expires at 59602585423025-59602642458243 nsecs [in 52321077827 to 52378113045 nsecs]
>
> That might be the soft lockup hrtimer.
>
> I'd try to gather more information about the chain of events via tracing
> and stop the tracer once the lockup detector hits.
Okay will do, thanks for taking a look.
Thanks,
Nick
^ permalink raw reply
* [PATCH] powerpc/8xx: Build fix with Hugetlbfs enabled
From: Aneesh Kumar K.V @ 2018-04-10 8:51 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V, Christophe LEROY
8xx use slice code when hugetlbfs is enabled. We missed a header include on
8xx which resulted in the below build failure.
config: mpc885_ads_defconfig + CONFIG_HUGETLBFS
CC arch/powerpc/mm/slice.o
arch/powerpc/mm/slice.c: In function 'slice_get_unmapped_area':
arch/powerpc/mm/slice.c:655:2: error: implicit declaration of function 'need_extra_context' [-Werror=implicit-function-declaration]
arch/powerpc/mm/slice.c:656:3: error: implicit declaration of function 'alloc_extended_context' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/mm/slice.o] Error 1
make: *** [arch/powerpc/mm] Error 2
on PPC64 the mmu_context.h was included via linux/pkeys.h
CC: Christophe LEROY <christophe.leroy@c-s.fr>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/slice.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 9cd87d11fe4e..205fe557ca10 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -35,6 +35,7 @@
#include <asm/mmu.h>
#include <asm/copro.h>
#include <asm/hugetlb.h>
+#include <asm/mmu_context.h>
static DEFINE_SPINLOCK(slice_convert_lock);
--
2.14.3
^ permalink raw reply related
* Re: Occasionally losing the tick_sched_timer
From: Thomas Gleixner @ 2018-04-10 9:07 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Linux Kernel Mailing List, Alexey Kardashevskiy, linuxppc-dev,
kvm-ppc, Frederic Weisbecker
In-Reply-To: <20180410182651.727b5ae7@roar.ozlabs.ibm.com>
On Tue, 10 Apr 2018, Nicholas Piggin wrote:
> On Tue, 10 Apr 2018 09:42:29 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> > > Thomas do you have any ideas on what we might look for, or if we can add
> > > some BUG_ON()s to catch this at its source?
> >
> > Not really. Tracing might be a more efficient tool that random BUG_ONs.
>
> Sure, we could try that. Any suggestions? timer events?
timer, hrtimer and the tick-sched stuff should be a good start. And make
sure to freeze the trace once you hit the fault case. tracing_off() is your
friend.
Thanks,
tglx
^ 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