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 interru
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 w
On Tue, 10 Apr 2018 09:42:29 +0200 (CEST)
Thomas Gleixner 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
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
On Tue, 10 Apr 2018, Nicholas Piggin wrote:
> On Tue, 10 Apr 2018 09:42:29 +0200 (CEST)
> Thomas Gleixner 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
Jon, Andrew,
How do you suggest to continue with this?
On Sun, Apr 01, 2018 at 09:38:58AM +0300, Mike Rapoport wrote:
> (added akpm)
>
> On Thu, Mar 29, 2018 at 03:46:07PM -0600, Jonathan Corbet wrote:
> > On Wed, 21 Mar 2018 21:22:16 +0200
> > Mike Rapoport wrote:
> >
> > > These patches conv
This is the start of an effort to tidy up and standardise all the
delays. Existing loops have a range of delay/sleep periods from 1ms
to 20ms, and some have no delay. They all loop forever except rtc,
which times out after 10 retries, and that uses 10ms delays. So use
10ms as our standard delay. Th
The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or
OPAL_BUSY_EVENT from firmware, which causes large scheduling
latencies, up to 50 seconds have been observed here when RTC stops
responding (BMC reboot can do it).
Fix this by converting it to the standard form OPAL_BUSY loop that
slee
This is a couple of important fixes broken out of the series
"first step of standardising OPAL_BUSY handling", that prevents
the kernel from locking up if the NVRAM or RTC hardware does not
respond.
Another one, the console driver, has a similar problem that has
also been hit in testing, but that
The OPAL NVRAM driver does not sleep in case it gets OPAL_BUSY or
OPAL_BUSY_EVENT from firmware, which causes large scheduling
latencies, and various lockup errors to trigger (again, BMC reboot
can cause it).
Fix this by converting it to the standard form OPAL_BUSY loop that
sleeps.
Fixes: 628daa
Hi Nicholas,
I would greatly appreciate a changelog and at least the cover letter
because it is difficult to grasp how this relates to the previous
patches you sent to the RTC mailing list.
On 10/04/2018 21:49:32+1000, Nicholas Piggin wrote:
> The OPAL RTC driver does not sleep in case it gets O
This series adds powerpc:tlbie tracepoints for radix partition
scoped invalidations. After I started getting some traces on a
32 vCPU radix guest it showed a problem with partition scoped
faults/invalidates, so I had a try at fixing it. This seems to
stable be on radix so far (haven't tested hash y
Implent local TLB flush for entire LPID, for hash and radix, and
a global TLB flush for a partition scoped page in an LPID, for
radix.
These will be used by KVM in subsequent patches.
Signed-off-by: Nicholas Piggin
---
.../include/asm/book3s/64/tlbflush-hash.h | 2 +
.../include/asm/book3s
This has the advantage of consolidating TLB flush code in fewer
places, and it also implements powerpc:tlbie trace events.
1GB pages should be handled without further modification.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 26 +++---
1 file
The existing flush uses the radix value for sets, and uses R=0
tlbiel instructions. This can't be quite right, but I'm not entirely
sure if this is the right way to fix it.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_hv_builtin.c | 14 +-
1 file changed, 5 insertions(+
Move this flushing out of assembly and have it use Linux TLB
flush implementations introduced earlier. This allows powerpc:tlbie
trace events to be used.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_hv.c| 21 +++-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 43 +--
KVM with an SMP radix guest can get into storms of page faults and
tlbies due to the partition scopd page tables being invalidated and
TLB flushed if they were found to race with another page fault that
set them up.
This tends to cause vCPUs to pile up if several hit common addresses,
then page fa
On Tue, 10 Apr 2018 14:07:28 +0200
Alexandre Belloni wrote:
> Hi Nicholas,
>
> I would greatly appreciate a changelog and at least the cover letter
> because it is difficult to grasp how this relates to the previous
> patches you sent to the RTC mailing list.
Yes good point. Basically this cha
From: Mahesh Salgaonkar
The second kernel, during early boot after the crash, reserves rest of
the memory above boot memory size to make sure it does not touch any of the
dump memory area. It uses memblock_reserve() that reserves the specified
memory region irrespective of memory holes present wi
FADump capture kernel boots in restricted memory environment preserving
the context of previous kernel to save vmcore. Supporting hugepages in
such environment makes things unnecessarily complicated, as hugepages
need memory set aside for them. This means most of the capture kernel's
memory is used
On 09/04/2018 22:08, David Rientjes wrote:
> 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
Hi Nicolin,
On Sun, Apr 8, 2018 at 8:57 PM, 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
The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.
The first patch of this series is replacing __HAVE_ARCH_PTE_SPECIAL by
CONFIG_ARCH_HAS_PTE_SPECIAL defined into the Kconfig files
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/mm/m
Currently the PTE special supports is turned on in per architecture header
files. Most of the time, it is defined in arch/*/include/asm/pgtable.h
depending or not on some other per architecture static definition.
This patch introduce a new configuration variable to manage this directly
in the Kcon
On 10/04/18 16:25, Laurent Dufour wrote:
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 23 ++-
1 file changed, 10 inse
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
> arch/powerpc/include/asm/pte-common.h | 3 ---
> arch/riscv/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
You forgot to delete __HAVE_ARCH_PTE_SPE
On 03/04/2018 02:11, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> This change is inspired by the Peter's proposal patch [1] which was
>> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in
>> that particular case, and it is introducing major perfo
On 03/04/2018 01:57, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> When dealing with speculative page fault handler, we may race with VMA
>> being split or merged. In this case the vma->vm_start and vm->vm_end
>> fields may not match the address the page fault is occurrin
On 10/04/2018 18:09, Matthew Wilcox wrote:
> On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
>> arch/powerpc/include/asm/pte-common.h | 3 ---
>> arch/riscv/Kconfig | 1 +
>> arch/s390/Kconfig
On 10/04/2018 17:58, Robin Murphy wrote:
> On 10/04/18 16:25, Laurent Dufour wrote:
>> Remove the additional define HAVE_PTE_SPECIAL and rely directly on
>> CONFIG_ARCH_HAS_PTE_SPECIAL.
>>
>> There is no functional change introduced by this patch
>>
>> Signed-off-by: Laurent Dufour
>> ---
>> m
On 04/09/2018 11:51 PM, Michael Ellerman wrote:
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.
Indeed :) No worrie
On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote:
> The disabling informational messages on the PCI subsystem should be deleted
> since they do not represent any real value for the system logs.
>
> These messages are either not presented, or presented for all PCI devices
On Tue, Apr 10, 2018 at 02:36:31PM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote:
> > The disabling informational messages on the PCI subsystem should be deleted
> > since they do not represent any real value for the system logs.
> >
> > T
On Wed, Mar 28, 2018 at 8:31 PM, Ran Wang wrote:
> Enable Power Management feature on device tree, including MPC8536,
> MPC8544, MPC8548, MPC8572, P1010, P1020, P1021, P1022, P2020, P2041,
> P3041, T104X, T1024.
There are no device tree bindings documented for the properties and
compatible string
Bjorn,
On 04/10/2018 04:55 PM, Bjorn Helgaas wrote:
On Tue, Apr 10, 2018 at 02:36:31PM -0500, Bjorn Helgaas wrote:
On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote:
The disabling informational messages on the PCI subsystem should be deleted
since they do not represent
On Tue, 10 Apr 2018 09:09:32 PDT (-0700), wi...@infradead.org wrote:
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
arch/powerpc/include/asm/pte-common.h | 3 ---
arch/riscv/Kconfig | 1 +
arch/s390/Kconfig
On Tue, 10 Apr 2018, Laurent Dufour wrote:
> > On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
> >> arch/powerpc/include/asm/pte-common.h | 3 ---
> >> arch/riscv/Kconfig | 1 +
> >> arch/s390/Kconfig
The "name" field of struct vnic_login_client_data is a char array of
undefined length. This should be written as "char name[]" so the compiler
can make better decisions about the field (for example, not assuming
it's a single character). This was noticed while trying to tighten the
CONFIG_FORTIFY_S
On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote:
>
> + /*
> +* Do we need to flush the TLB for the LPAR? (see TLB comment above)
> + * On POWER9, individual threads can come in here, but the
> + * TLB is shared between the 4 threads in a core, hence
> +
On Wed, 11 Apr 2018 11:32:12 +1000
Benjamin Herrenschmidt wrote:
> On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote:
> >
> > + /*
> > +* Do we need to flush the TLB for the LPAR? (see TLB comment above)
> > + * On POWER9, individual threads can come in here, but th
On boot we save the configuration space of PCIe bridges. We do this so
when we get an EEH event and everything gets reset that we can restore
them.
Unfortunately we save this state before we've enabled the MMIO space
on the bridges. Hence if we have to reset the bridge when we come back
MMIO is no
On 06/04/18 15:24, Balbir Singh wrote:
> This patch adds support for flushing potentially dirty
> cache lines when memory is hot-plugged/hot-un-plugged.
> The support is currently limited to 64 bit systems.
>
> The bug was exposed when mappings for a device were
> actually hot-unplugged and plugg
On 06/04/18 15:24, Balbir Singh wrote:
> Don't do this via custom code, instead now that we have support
> in the arch hotplug/hotunplug code, rely on those routines
> to do the right thing.
>
> Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory
> tracing")
> because t
When setting up a CPU, we "push" (activate) a pool VP for it.
However it's an error to do so if it already has an active
pool VP.
This happens when doing soft CPU hotplug on powernv since we
don't tear down the CPU on unplug. The HW flags the error which
gets captured by the diagnostics.
Fix thi
It's identical to xive_teardown_cpu() so just use the latter
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/xive.h| 1 -
arch/powerpc/platforms/powernv/setup.c | 2 +-
arch/powerpc/platforms/pseries/kexec.c | 2 +-
arch/powerpc/sysdev/xive/common.c | 22 --
Those overly verbose statement in the setup of the pool VP
aren't particularly useful (esp. considering we don't actually
use the pool, we configure it bcs HW requires it only). So
remove them which improves the code readability.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/sysdev/xive
On Wed, 2018-04-11 at 15:17 +1000, Benjamin Herrenschmidt wrote:
> When setting up a CPU, we "push" (activate) a pool VP for it.
>
> However it's an error to do so if it already has an active
> pool VP.
>
> This happens when doing soft CPU hotplug on powernv since we
> don't tear down the CPU on
The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are
used to allocate/free contexts to allow address translation and shootdown
by the NPU on a particular GPU. Context initialisation is implicitly safe
as it is protected by the requirement mmap_sem be held in write mode,
however
There is a single npu context per set of callback parameters. Callers
should be prevented from overwriting existing callback values so instead
return an error if different parameters are passed.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/powernv.h | 2 +-
arch/powerpc/pla
Also, unselect FSL_PMC which is for older platfroms instead.
Signed-off-by: Ran Wang
---
Changes in v2:
- no change
arch/powerpc/Kconfig |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd..ed60c83 100644
--- a/
51 matches
Mail list logo