Haren Myneni writes:
>
> NX can set 3rd bit in CR register for XER[SO] (Summation overflow)
> which is not used for paste return value. So. mask this bit to get
> proper return status.
This sounds like a bug fix, but I can't tell from the change log.
What happens if we don't merge this patc
On 04/26/2018 07:10 PM, Nicholas Piggin wrote:
> On Thu, 26 Apr 2018 18:35:10 +0530
> Mahesh Jagannath Salgaonkar wrote:
>
>> On 04/26/2018 06:28 PM, Nicholas Piggin wrote:
>>> On Thu, 26 Apr 2018 17:12:03 +0530
>>> Mahesh J Salgaonkar wrote:
>>>
From: Mahesh Salgaonkar
otherw
From: Mahesh Salgaonkar
Unregister fadump on kexec down path 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 p
laurentiu.tu...@nxp.com writes:
> From: Laurentiu Tudor
>
> Add missing "altivec unavailable" interrupt injection helper
> thus fixing the linker error below:
>
> arch/powerpc/kvm/emulate_loadstore.o: In function
> `kvmppc_check_altivec_disabled':
> arch/powerpc/kvm/emulate_loadstore.c: undefined
Hi Simon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
smp_send_stop can lock up the IPI path for any subsequent calls,
because the receiving CPUs spin in their handler function. This
started becoming a problem with the addition of an smp_send_stop
call in the reboot path, because panics can reboot after doing
their own smp_send_stop.
The NMI IPI vari
On Thu, 2018-03-22 at 23:10 -0300, Mauro S. M. Rodrigues wrote:
> Due to recent refactoring in EEH in:
> commit b9fde58db7e5 ("powerpc/powernv: Rework EEH initialization on
> powernv")
> a misleading message was seen in the kernel message buffer:
>
> [0.108431] EEH: PowerNV platform initialize
Bindings are supposed to be organized by device class/function. Move a
couple of powerpc 4xx bindings to the correct binding directory.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring
---
.../devicetree/bindings/{powerpc/4xx/ndfc.txt => mtd/ibm,ndfc.txt}| 0
.../devicetree/b
Michal Hocko a écrit :
On Thu 26-04-18 15:28:46, Christophe LEROY wrote:
Le 26/04/2018 à 15:11, Michal Hocko a écrit :
> On Thu 26-04-18 08:10:30, Christophe LEROY wrote:
> >
> >
> > Le 25/04/2018 à 21:57, David Rientjes a écrit :
> > > On Tue, 24 Apr 2018, christophe leroy wrote:
> > >
> >
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Thu 26-04-18 15:28:46, Christophe LEROY wrote:
>
>
> Le 26/04/2018 à 15:11, Michal Hocko a écrit :
> > On Thu 26-04-18 08:10:30, Christophe LEROY wrote:
> > >
> > >
> > > Le 25/04/2018 à 21:57, David Rientjes a écrit :
> > > > On Tue, 24 Apr 2018, christophe leroy wrote:
> > > >
> > > > > H
On 04/24/2018 04:35 PM, Michael Bringmann wrote:
> See below.
>
> On 04/24/2018 12:17 PM, Nathan Fontenot wrote:
>> On 02/26/2018 02:53 PM, Michael Bringmann wrote:
>>> postmigration/memory: Now apply changes to the associativity of memory
>>> blocks described by the 'ibm,dynamic-memory-v2' proper
On 04/24/2018 04:33 PM, Michael Bringmann wrote:
> See comments below:
>
> On 04/24/2018 11:56 AM, Nathan Fontenot wrote:
>> On 02/26/2018 02:52 PM, Michael Bringmann wrote:
>>> hotplug/mobility: Recognize more changes to the associativity of
>>> memory blocks described by the 'ibm,dynamic-memory'
Hello,
On Tue, 24 Apr 2018 14:15:55 +1000
Michael Ellerman wrote:
> From: Michal Suchanek
>
> Based on the RFI patching. This is required to be able to disable the
> speculation barrier.
why do you not patch the nospec barrier which is included as part of
the RFI flush code?
I think when deb
Hello,
On Tue, 24 Apr 2018 14:15:57 +1000
Michael Ellerman wrote:
> From: Michal Suchanek
>
> Check what firmware told us and enable/disable the barrier_nospec as
> appropriate.
>
> We err on the side of enabling the barrier, as it's no-op on older
> systems, see the comment for more detail.
From: Zi Yan
pmd swap soft dirty support is added, too.
Signed-off-by: Zi Yan
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Aneesh Kumar K.V"
Cc: Ram Pai
Cc: Balbir Singh
Cc: Naoya Horiguchi
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
---
arch/powe
From: Zi Yan
Remove CONFIG_ARCH_ENABLE_THP_MIGRATION. thp migration is enabled along
with transparent hugepage and can be toggled via
/sys/kernel/mm/transparent_hugepage/enable_thp_migration.
Signed-off-by: Zi Yan
Cc: linux...@kvack.org
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
C
From: Zi Yan
Hi all,
THP migration is only enabled on x86_64 with a special
ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for
all architectures that uses transparent hugepage, so that special macro can
be dropped. Instead, THP migration is enabled/disabled via
/sys/kernel/
On Thu, 26 Apr 2018 18:35:10 +0530
Mahesh Jagannath Salgaonkar wrote:
> On 04/26/2018 06:28 PM, Nicholas Piggin wrote:
> > On Thu, 26 Apr 2018 17:12:03 +0530
> > Mahesh J Salgaonkar wrote:
> >
> >> From: Mahesh Salgaonkar
> >>
> >> otherwise the fadump registration in new kexec-ed kernel com
Le 26/04/2018 à 15:11, Michal Hocko a écrit :
On Thu 26-04-18 08:10:30, Christophe LEROY wrote:
Le 25/04/2018 à 21:57, David Rientjes a écrit :
On Tue, 24 Apr 2018, christophe leroy wrote:
Hi
Allthough there is still about one forth of memory available (7976kB
among 32MB), oom-killer is
On Thu 26-04-18 08:10:30, Christophe LEROY wrote:
>
>
> Le 25/04/2018 à 21:57, David Rientjes a écrit :
> > On Tue, 24 Apr 2018, christophe leroy wrote:
> >
> > > Hi
> > >
> > > Allthough there is still about one forth of memory available (7976kB
> > > among 32MB), oom-killer is invoked and mak
On 04/26/2018 06:28 PM, Nicholas Piggin wrote:
> On Thu, 26 Apr 2018 17:12:03 +0530
> Mahesh J Salgaonkar wrote:
>
>> 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
>>
On Thu, 26 Apr 2018 17:12:03 +0530
Mahesh J Salgaonkar wrote:
> 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 in
On Thu, 26 Apr 2018 20:30:37 +1000
Michael Ellerman wrote:
> Nicholas Piggin writes:
> > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
> > over the handler function call, which causes later smp_send_nmi_ipi()
> > callers to spin until the call is finished.
> >
> > The smp
From: Laurentiu Tudor
Add missing "altivec unavailable" interrupt injection helper
thus fixing the linker error below:
arch/powerpc/kvm/emulate_loadstore.o: In function
`kvmppc_check_altivec_disabled':
arch/powerpc/kvm/emulate_loadstore.c: undefined reference to
`.kvmppc_core_queue_vec_unavail
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. Now that fadump uses CMA for reserved
area, this memory area is now not protected from hot-re
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
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
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
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
Le 16/05/2017 à 11:23, Aneesh Kumar K.V a écrit :
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/Kconfig.cputype | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 8017542d..8acc4f27
Nicholas Piggin writes:
> The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
> over the handler function call, which causes later smp_send_nmi_ipi()
> callers to spin until the call is finished.
>
> The smp_send_stop function never returns, so the busy count is never
> decremete
On Thu, 2018-04-26 at 10:19:02 UTC, Michael Ellerman wrote:
> From: Nicholas Piggin
>
> The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
> over the handler function call, which causes later smp_send_nmi_ipi()
> callers to spin until the call is finished.
>
> The stop_this_cp
On Tue, 2018-04-10 at 11:49:32 UTC, Nicholas Piggin wrote:
> 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).
>
>
From: Nicholas Piggin
The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
over the handler function call, which causes later smp_send_nmi_ipi()
callers to spin until the call is finished.
The stop_this_cpu() function never returns, so the busy count is never
decremeted, which c
Nicholas Piggin writes:
> On Wed, 25 Apr 2018 13:15:34 +1000
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>>
>> > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count
>> > over the handler function call, which causes later smp_send_nmi_ipi()
>> > callers to spin until t
On 25/04/18 07:12, Sukadev Bhattiprolu wrote:
Yes. Like with PIDR, was trying to assign TIDR initially to all threads.
But since only a subset of threads need/use TIDR, we can assign the
value later (when set_thread_tidr() is called). So we should be able to
use task_pid_nr() then.
OK. Alastair
37 matches
Mail list logo
