[PATCH] powerpc/8xx: Build fix with Hugetlbfs enabled

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':

Re: Occasionally losing the tick_sched_timer

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

[PATCH 0/3] Fix RTC and NVRAM OPAL_BUSY loops

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

[PATCH 3/3] powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops

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:

Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

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

Re: [PATCH 00/32] docs/vm: convert to ReST format

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: > >

[PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

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

[PATCH 1/3] powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops

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.

[RFC PATCH 1/5] powerpc/64s/mm: Implement LPID based TLB flushes to be used by KVM

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 +

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

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

[PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

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

[RFC PATCH 5/5] KVM: PPC: Book3S HV: Radix do not clear partition scoped page table when page fault races with other vCPUs.

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

[RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

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 +++-

Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

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.

[PATCH v2 1/2] powerpc/fadump: exclude memory holes while reserving memory in second kernel

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

[RFC PATCH 0/5] KVM TLB flushing improvements

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

[RFC PATCH 3/5] KVM: PPC: Book3S HV: kvmhv_p9_set_lpcr use Linux flush function

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

[PATCH v2 2/2] powerpc/fadump: Do not use hugepages when fadump is active

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

[PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

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

Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio

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

[PATCH v2 0/2] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

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

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

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

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

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

[RFC PATCH 2/5] KVM: PPC: Book3S HV: kvmppc_radix_tlbie_page use Linux flush function

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

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

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

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

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

Re: [PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

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

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

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

Re: [PATCH 5/5] powerpc:dts:pm: add power management node

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

Re: [PATCH v3] powerpc/64: Fix section mismatch warnings for early boot symbols

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

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

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. > > > >

Re: [PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

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

[PATCH] ibmvnic: Define vnic_login_client_data name field as unsized array

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

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

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

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

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

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

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

Re: Occasionally losing the tick_sched_timer

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

[PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

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

[PATCH 3/3] powerpc/xive: Remove xive_kexec_teardown_cpu()

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 +-

[PATCH 2/3] powerpc/xive: Remove now useless pr_debug statements

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

Re: [PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

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

[PATCH] powerpc/powernv/opal: Use standard interrupts property when available

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

Re: Occasionally losing the tick_sched_timer

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

[PATCH] powerpc/64: optimises from64to32()

The current implementation of from64to32() gives a poor result: 0270 <.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

[PATCH] Revert "powerpc/64: Fix checksum folding in csum_add()"

This reverts commit 6ad966d7303b70165228dba1ee8da1a05c10eefe. That commit was pointless, because csum_add() sums two 32 bits values, so the sum is 0x1fffe at the maximum. And then when adding upper part (1) and lower part (0xfffe), the result is 0x which doesn't carry. Any lower

Re: [PATCH v9 21/24] perf tools: Add support for the SPF perf event

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

Re: [PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode

On Tue, 10 Apr 2018 11:25:02 +0530 "Naveen N. Rao" wrote: > Michael Ellerman wrote: > > Nicholas Piggin writes: > > > >> On Sun, 8 Apr 2018 20:17:47 +1000 > >> Balbir Singh wrote: > >> > >>> On Fri, Apr 6, 2018 at

Re: [RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

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 > +

Re: [RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

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

[PATCH] powerpc/eeh: Fix enabling bridge MMIO windows

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

Re: [PATCH 1/2] powerpc/mm: Flush cache on memory hot(un)plug

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

Re: [PATCH 2/2] powerpc/mm/memtrace: Let the arch hotunplug code flush cache

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