On Sun, 1 Apr 2018 15:50:36 +1000
Nicholas Piggin wrote:
> flush_thread will call set_breakpoint via set_debug_reg_defaults,
> and cause POWER8 and above CPUs without the DAWR feature to try
> to write to DAWR.
DABR
>
> Cc: Michael Neuling
> Signed-off-by: Nic
I'm rebasing and resending this series because the hard
lockup messages are being seen in the field.
Since last time, one of the patches was merged, and patches
were split and reordered a bit. No major changes.
This still hasn't been tested with the FSP firmware update.
Thanks,
Nick
Nicholas Pi
Use the NMI IPI rather than smp_call_function for smp_send_stop.
Have stopped CPUs hard disable interrupts rather than just soft
disable.
This function is used in crash/panic/shutdown paths to bring other
CPUs down as quickly and reliably as possible, and minimizing their
potential to cause troubl
The hard lockup watchdog can fire under local_irq_disable
on platforms with irq soft masking.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/smp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index db88660b
Currently powernv reboot and shutdown requests just leave secondaries
to do their own things. This is undesirable because they can trigger
any number of watchdogs while waiting for reboot, but also we don't
know what else they might be doing -- they might be causing trouble,
trampling memory, etc.
On Tue, Mar 27, 2018 at 11:21:17AM +0100, Will Deacon wrote:
> On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast
> > IPI.
> > If CPU is in extended quiescent state (idle task or nohz_full userspace),
> > this
>
On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote:
> On Tue, Mar 27, 2018 at 11:21:17AM +0100, Will Deacon wrote:
> > On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> > > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast
> > > IPI.
> > > If CPU is in ex
The first patch in this series added a weakly-defined generic
implementation, which is functionally identical to the
architecture-specific one removed here.
Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).
Signed-off-by: Shea Levy
---
arch/pow
Hi Michael,
Michael Ellerman writes:
> Shea Levy writes:
>
>> Joe Perches writes:
>>
>>> On Wed, 2018-03-28 at 16:36 -0400, Shea Levy wrote:
Signed-off-by: Shea Levy
>>>
>>> Most people seem to want some form of commit message
>>> and not just your sign-off.
>>>
>>
>> Ah, if the subject
Hi Ingo,
Ingo Molnar writes:
> * Shea Levy wrote:
>
>> Now only those architectures that have custom initrd free requirements
>> need to define free_initrd_mem.
>>
>> Signed-off-by: Shea Levy
>
> Please put the Kconfig symbol name this patch introduces both into the title,
> so
> that peopl
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. This reserved
memory is used for saving the contents of old crashed kernel's memory before
fadump capture kernel uses old kernel's memory area to boot. However, This
res
From: Mahesh Salgaonkar
Currently the metadata region that holds crash info structure and ELF core
header is placed towards the end of reserved memory area. This patch places
it at the beginning of the reserved memory area.
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/include/asm/fadump.h
From: Mahesh Salgaonkar
Metadata region that holds fadump header and ELF header is now placed at
the start of reserved memory area. Update the documentation accordingly
Signed-off-by: Mahesh Salgaonkar
---
Documentation/powerpc/firmware-assisted-dump.txt | 31 +-
1 file c
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is in
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
From: Mahesh Salgaonkar
fadump fails to register when there are holes in reserved memory area.
This can happen if user has hot-removed a memory that falls in the fadump
reserved memory area. Throw a meaningful error message to the user in
such case.
Signed-off-by: Mahesh Salgaonkar
---
arch/po
From: Mahesh Salgaonkar
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. But this memory area is currently not
protected from hot-remove operations. Hence, fadump ser
From: Mahesh Salgaonkar
otherwise the fadump registration in new kexec-ed kernel complains that
fadump is already registered. This makes new kernel to continue using
fadump registered by previous kernel which may lead to invalid vmcore
generation. Hence this patch fixes this issue by un-registeri
* Shea Levy wrote:
> > Please also put it into Documentation/features/.
>
> I switched this patch series (the latest revision v6 was just posted) to
> using weak symbols instead of Kconfig. Does it still warrant documentation?
Probably not.
Thanks,
Ingo
19 matches
Mail list logo
