Re: [PATCH v2] watchdog: core: make sure the watchdog worker always works

On 12/08/2017 02:18 AM, Christophe Leroy wrote: When running a command like 'chrt -f 50 dd if=/dev/zero of=/dev/null', the watchdog_worker fails to service the HW watchdog and the HW watchdog fires long before the watchdog soft timeout. At the moment, the watchdog_worker is invoked as a delayed

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

On Tue, Dec 12, 2017 at 11:29 PM, Ravi Bangoria wrote: > It may very well happen that branch instructions recorded by > bhrb entries already get unmapped before they get processed by > the kernel. Hence, trying to dereference such memory location > will endup in

Re: [PATCH 2/2] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Thu, 14 Dec 2017 23:16:26 +1100 Balbir Singh wrote: > On Thu, Dec 14, 2017 at 12:51 PM, Nicholas Piggin wrote: > >> I can't call smp_send_nmi_ipi due to the nmi_ipi_busy_count and > >> I'm worried about calling a stale nmi_ipi_function via the > >>

[RFC PATCH for 4.16 08/21] powerpc: Wire up restartable sequences system call

From: Boqun Feng Wire up the rseq system call on powerpc. This provides an ABI improving the speed of a user-space getcpu operation on powerpc by skipping the getcpu system call on the fast path, as well as improving the speed of user-space operations on per-cpu data

[RFC PATCH for 4.16 07/21] powerpc: Add support for restartable sequences

From: Boqun Feng Call the rseq_handle_notify_resume() function on return to userspace if TIF_NOTIFY_RESUME thread flag is set. Increment the event counter and perform fixup on the pre-signal when a signal is delivered on top of a restartable sequence critical section.

[PATCH] powerpc: dts: Remove leading 0x and 0s from bindings notation

Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following

[RFC PATCH for 4.16 12/21] powerpc: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: Boqun Feng CC: Peter Zijlstra CC: "Paul E.

Re: [PATCH 2/2] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Thu, Dec 14, 2017 at 12:51 PM, Nicholas Piggin wrote: > On Thu, 14 Dec 2017 11:12:13 +1100 > Balbir Singh wrote: > >> On Wed, 13 Dec 2017 20:51:01 +1000 >> Nicholas Piggin wrote: >> >> > This is looking pretty nice now... >> > >> >

[PATCH v3 3/3] powernv/kdump: Fix cases where the kdump kernel can get HMI's

Certain HMI's such as malfunction error propagate through all threads/core on the system. If a thread was offline prior to us crashing the system and jumping to the kdump kernel, bad things happen when it wakes up due to an HMI in the kdump kernel. There are several possible ways to solve this

Re: [PATCH v3 3/3] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Fri, Dec 15, 2017 at 2:10 PM, Nicholas Piggin wrote: > On Fri, 15 Dec 2017 12:27:40 +1100 > Balbir Singh wrote: > >> Certain HMI's such as malfunction error propagate through >> all threads/core on the system. If a thread was offline >> prior to us

Re: [PATCH v3 3/3] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Fri, 15 Dec 2017 14:34:03 +1100 Balbir Singh wrote: > On Fri, Dec 15, 2017 at 2:10 PM, Nicholas Piggin wrote: > > On Fri, 15 Dec 2017 12:27:40 +1100 > > Balbir Singh wrote: > > But then you still need an explicit kdump check

[PATCH v3 2/3] powerpc/powernv: Identify scom driven system reset

In irq_set_pending_from_srr1() we were missing 0x2 as system reset identified from SRR1 caused by back to back system resets or when interrupts are caused by SCOM when the thread is not in power saving mode. This helps us get to NMI handling in both the case where NMI is caused when in

Re: [PATCH v3 2/3] powerpc/powernv: Identify scom driven system reset

On Fri, 15 Dec 2017 12:27:39 +1100 Balbir Singh wrote: > In irq_set_pending_from_srr1() we were missing 0x2 as system > reset identified from SRR1 caused by back to back system > resets or when interrupts are caused by SCOM when the thread > is not in power saving mode. >

Re: [PATCH v3 2/3] powerpc/powernv: Identify scom driven system reset

On Fri, 15 Dec 2017 13:54:18 +1100 Balbir Singh wrote: > On Fri, Dec 15, 2017 at 1:44 PM, Nicholas Piggin wrote: > > On Fri, 15 Dec 2017 12:27:39 +1100 > > Balbir Singh wrote: > > > >> In irq_set_pending_from_srr1() we were

Re: [PATCH v3 3/3] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Fri, 15 Dec 2017 12:27:40 +1100 Balbir Singh wrote: > Certain HMI's such as malfunction error propagate through > all threads/core on the system. If a thread was offline > prior to us crashing the system and jumping to the kdump > kernel, bad things happen when it wakes

Re: [PATCH v3 2/3] powerpc/powernv: Identify scom driven system reset

On Fri, Dec 15, 2017 at 1:44 PM, Nicholas Piggin wrote: > On Fri, 15 Dec 2017 12:27:39 +1100 > Balbir Singh wrote: > >> In irq_set_pending_from_srr1() we were missing 0x2 as system >> reset identified from SRR1 caused by back to back system >> resets or

Re: [PATCH 2/2] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Fri, Dec 15, 2017 at 12:32 AM, Nicholas Piggin wrote: > On Thu, 14 Dec 2017 23:16:26 +1100 > Balbir Singh wrote: > >> On Thu, Dec 14, 2017 at 12:51 PM, Nicholas Piggin wrote: > > >> >> I can't call smp_send_nmi_ipi due to the

[PATCH v3 1/3] powerpc/crash: Remove the test for cpu_online in the IPI callback

Our check was extra cautious, we've audited crash_send_ipi and it sends an IPI only to online CPU's. Removal of this check should have not functional impact on crash kdump. Signed-off-by: Balbir Singh --- arch/powerpc/kernel/crash.c | 3 --- 1 file changed, 3 deletions(-)