Hi Michael,
On Wednesday, December 09, 2015 11:17:12 AM Michael Ellerman wrote:
> Hi Wen,
>
> Thanks for the patch.
>
> On Tue, 2015-12-08 at 15:30 +0800, wen...@powercore.com.cn wrote:
> > I found that there are unimplemented OPAL message types "OPAL_MSG_EPOW"
> > and
> > "OPAL_MSG_DPO" in Powe
Two DSCR tests have a hack in them:
/*
* XXX: Force a context switch out so that DSCR
* current value is copied into the thread struct
* which is required for the child to inherit the
* changed value.
*/
sleep(1);
We should not be worki
Hi Michael,
On Wednesday, December 09, 2015 11:17:12 AM Michael Ellerman wrote:
> Hi Wen,
>
> Thanks for the patch.
>
> On Tue, 2015-12-08 at 15:30 +0800, wen...@powercore.com.cn wrote:
> > I found that there are unimplemented OPAL message types "OPAL_MSG_EPOW"
> > and
> > "OPAL_MSG_DPO" in Powe
If kmemdup fails, We need kfree *buff* first then return -ENOMEM.
Otherwise there is a memory leak.
Signed-off-by: Pan Xinhui
---
arch/powerpc/kernel/nvram_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
in
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
>
> From: Scott Wood
> Date: Tue, 8 Dec 2015 16:44:38 -0600
>
> > On Tue, 2015-12-08 at 14:18 -0600, Andy Fleming wrote:
> >> On Thu, Dec 3, 2015 at 1:19 AM, wrote:
> >> > From: Igal Liberman
> >> >
> >> > This pat
> Currently we copy the whole mm_context_t to the paca but only access a
> few bits of it. This is wasteful of space paca and also takes quite
> some time in the hot path of context switching.
>
> This patch pulls in only the required bits from the mm_context_t to
> the paca and on context switch
This patch set generalizes the already existing solution for
printing NMI messages. The main idea comes from Peter Zijlstra.
Changes against v2:
+ fixed compilation problems reported by 0-day build robot
+ MN10300 and Xtensa architectures will get handled separately
+ dropped the patch th
printk() takes some locks and could not be used a safe way in NMI
context.
The chance of a deadlock is real especially when printing
stacks from all CPUs. This particular problem has been addressed
on x86 by the commit a9edc8809328 ("x86/nmi: Perform a safe NMI stack
trace on all CPUs").
This pat
NMIs could happen at any time. This patch makes sure that the safe
printk() in NMI will schedule IRQ work only when the related
structs are initialized.
All pending messages are flushed when the IRQ work is being
initialized.
Signed-off-by: Petr Mladek
---
kernel/printk/nmi.c | 13 -
We could not resize the temporary buffer in NMI context. Let's warn
if a message is lost.
This is rather theoretical. printk() should not be used in NMI.
The only sensible use is when we want to print backtrace from all
CPUs. The current buffer should be enough for this purpose.
Signed-off-by: Pe
Testing has shown that the backtrace sometimes does not fit
into the 4kB temporary buffer that is used in NMI context.
The warnings are gone when I double the temporary buffer size.
This patch doubles the buffer size and makes it configurable.
Note that this problem existed even in the x86-specif
[Re: [PATCH] sbc8641: drop bogus PHY IRQ entries from DTS file] On 09/12/2015
(Wed 04:07) Andrew Lunn wrote:
> On Tue, Dec 08, 2015 at 05:44:02PM -0500, Paul Gortmaker wrote:
> > This file was originally cloned off of the MPC8641D-HPCN reference
> > platform, which actually had a PHY IRQ line con
On 12/09/2015 04:00 AM, xinhui wrote:
>
> If kmemdup fails, We need kfree *buff* first then return -ENOMEM.
> Otherwise there is a memory leak.
>
> Signed-off-by: Pan Xinhui
Reviewed-by: Nathan Fontenot
> ---
> arch/powerpc/kernel/nvram_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
> > Originally the interrupt is used for detecting the link has gone
> > down. That would of also been bogus before. Have you tried this? If
>
> Haven't tried it, but chances are you are right.
>
> > that is also broken, maybe you need to add a fixes: tag so that it
> > gets back ported?
>
> No
On Wed, 2015-12-09 at 04:10 -0600, Bucur Madalin-Cristian-B32716 wrote:
> > -Original Message-
> > From: David Miller [mailto:da...@davemloft.net]
> >
> > From: Scott Wood
> > Date: Tue, 8 Dec 2015 16:44:38 -0600
> >
> > > On Tue, 2015-12-08 at 14:18 -0600, Andy Fleming wrote:
> > > > On
The functionality of context tracking has been implemented by PPC64 and
HAVE_CONTEXT_TRACKING was selected by pseries by default.
Actually, it is applicale to all PPC64 platforms, so select it in PPC64
generic Kconfig.
NO_HZ_FULL depends on it, with this change NO_HZ_FULL could be enabled
for all
I just realised I sent my reply to Denis not the list - apologies. This
info goes for v2 as well.
> Could you explain why it's useful, and what it's useful for. Moreover,
> it's POWER8 feature, right?
I'm not sure whether you're asking about the script or HMIs. Explaining
HMIs helps make
On Wed, 9 Dec 2015 14:21:02 +0100 Petr Mladek wrote:
> printk() takes some locks and could not be used a safe way in NMI
> context.
>
> The chance of a deadlock is real especially when printing
> stacks from all CPUs. This particular problem has been addressed
> on x86 by the commit a9edc880932
Originally the mpc85xx-pci-edac driver bound directly to the PCI
controller node.
Commit 905e75c46dba5f30 ("powerpc/fsl-pci: Unify pci/pcie
initialization code") turned the PCI controller code into a platform
device. Since we can't have two drivers binding to the same device,
the edac code was ch
Originally the mpc85xx-pci-edac driver bound directly to the PCI
controller node.
Commit 905e75c46dba5f30 ("powerpc/fsl-pci: Unify pci/pcie
initialization code") turned the PCI controller code into a platform
device. Since we can't have two drivers binding to the same device,
the edac code was ch
On 2015/12/9 23:21, Nathan Fontenot wrote:
On 12/09/2015 04:00 AM, xinhui wrote:
If kmemdup fails, We need kfree *buff* first then return -ENOMEM.
Otherwise there is a memory leak.
Signed-off-by: Pan Xinhui
Reviewed-by: Nathan Fontenot
Hi Nathan,
thank you for doing that :)
th
Daniel Axtens writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
> > Could you explain why it's useful, and what it's useful for. Moreover,
> > it's POWER8 feature, right?
>
> I'm not sure whether you're asking about the script or
On Tue, Dec 01, 2015 at 08:42:10PM -0300, Geyslan G. Bem wrote:
> The vcpu_book3s struct is assigned but never used. So remove it.
>
> Signed-off-by: Geyslan G. Bem
Thanks, applied to my kvm-ppc-next branch.
Paul.
___
Linuxppc-dev mailing list
Linuxpp
This hooks up UBSAN support for PowerPC.
So far it's found some interesting cases where we don't properly sanitise
input to shifts, including one in our futex handling. Nothing critical,
but interesting and worth fixing.
CC: Andrey Ryabinin
---
This to be applied on top of next with Andrey's pa
Currently we copy the whole mm_context_t to the paca but only access a
few bits of it. This is wasteful of space paca and also takes quite
some time in the hot path of context switching.
This patch pulls in only the required bits from the mm_context_t to
the paca and on context switch, copies onl
From: Pan Xinhui
When we merge two contiguous partitions whose signatures are marked
NVRAM_SIG_FREE, We need update prev's length and checksum, then write it
to nvram, not cur's. So lets fix this mistake now.
Also use memset instead of strncpy to set the partition's name. It's
more readable if w
On Wed, 2015-12-09 at 18:02 -0600, Scott Wood wrote:
> Originally the mpc85xx-pci-edac driver bound directly to the PCI
> controller node.
>
> Commit 905e75c46dba5f30 ("powerpc/fsl-pci: Unify pci/pcie
> initialization code") turned the PCI controller code into a platform
> device. Since we can't
27 matches
Mail list logo