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 for non-sreset wakeups
> > because the platform may not implement
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 crashing the system and jumping to the kdump
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 up due to an HMI
> in t
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 missing 0x2 as system
> >> reset identified from SRR1 caused by back
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 nmi_ipi_busy_count and
>> >> I'm worried about calling a stale nmi_
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 when interrupts are caused by SCOM when the
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.
>
> This helps us get to
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 pro
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 power-savin
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(-)
diff --git a/arch/powe
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 com
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arc
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.
Signed-off-by: Boqun Feng
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 compared to using load-reser
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
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
> >> system_reset_exception path, if we are OK
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 a crash. Ex,
>
> Unable to hand
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...
>> >
>> > On Wed, 13 Dec 2017 19:08:28 +1100
>> > Balbir Singh wrote:
18 matches
Mail list logo