When we hit the fadump crash via the panic path the pstore update is
missing. This is observed when commit 8341f2f222d7 ("sysrq: Use panic()
to force a crash") changed the sysrq-trigger to take panic path instead
of die path.
The PPC panic event handler addresses the system panic in two different
rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200605
i386 randconfig-a006-20200605
i386 randconfig-a002-20200605
On Sat, Jun 6, 2020, at 02:12, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> > > > Third party precompiled stuff doesn't really need to concern us, since
> > > > none really exists.
> > >
>
Linus Torvalds writes:
> On Fri, Jun 5, 2020 at 12:01 PM Linus Torvalds
> wrote:
>>
>> ..and then when I actually compared whether I otherwise got the same
>> result as you, I realized that this all depends on the module tree.
>>
>> I'll go merge that first, and then re-do this all. Oh well.
>
>
Linus Torvalds writes:
> On Fri, Jun 5, 2020 at 9:38 AM Michael Ellerman wrote:
>>
>> I've pushed the result of my resolution of the conflicts to the powerpc/merge
>> branch, if you want to look at that, though I've also tried to describe it in
>> full below.
>
> I ended up doing the machine_chec
On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote:
> On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> > > Third party precompiled stuff doesn't really need to concern us, since
> > > none really exists.
> >
> > ... Yet. And if you claim you support ELFv2, not mentioning the
On Saturday, May 30, 2020 3:17:24 PM PDT Will Springer wrote:
> On Saturday, May 30, 2020 8:37:43 AM PDT Christophe Leroy wrote:
> > There is a series at
> > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231
> > to switch powerpc to the Generic C VDSO.
> >
> > Can you try and s
Hi!
On Fri, Jun 05, 2020 at 01:50:46PM -0400, Rich Felker wrote:
> On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> > > I'm also not really all that convinced that vectors make a huge
> > > difference in non-specialized code (autovectorization still has a way to
> > > go)
>
On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually*
> > > > requires VSX - I don't think co
On Fri, Jun 5, 2020 at 12:50 PM Ira Weiny wrote:
>
> On Fri, Jun 05, 2020 at 05:11:35AM +0530, Vaibhav Jain wrote:
> > Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
> > module and add the command family NVDIMM_FAMILY_PAPR to the white list
> > of NVDIMM command sets. Also a
On Fri, Jun 5, 2020 at 12:01 PM Linus Torvalds
wrote:
>
> ..and then when I actually compared whether I otherwise got the same
> result as you, I realized that this all depends on the module tree.
>
> I'll go merge that first, and then re-do this all. Oh well.
Ok, redone and pushed out. Can you c
The pull request you sent on Sat, 06 Jun 2020 02:38:49 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.8-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ae77150d94d3b535c7b85e6b3647113095e79bf
Thank you!
--
Deet-doot-do
On Fri, Jun 05, 2020 at 05:11:35AM +0530, Vaibhav Jain wrote:
> Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
> module and add the command family NVDIMM_FAMILY_PAPR to the white list
> of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
> nvdimm command ma
On Fri, Jun 5, 2020 at 10:13 AM Ira Weiny wrote:
>
> On Fri, Jun 05, 2020 at 05:11:34AM +0530, Vaibhav Jain wrote:
> > Since papr_scm_ndctl() can be called from outside papr_scm, its
> > exposed to the possibility of receiving NULL as value of 'cmd_rc'
> > argument. This patch updates papr_scm_ndc
On Fri, Jun 5, 2020 at 9:38 AM Michael Ellerman wrote:
>
> I've pushed the result of my resolution of the conflicts to the powerpc/merge
> branch, if you want to look at that, though I've also tried to describe it in
> full below.
I ended up doing the machine_check_exception() differently, becaus
On Fri, Jun 05, 2020 at 05:11:36AM +0530, Vaibhav Jain wrote:
> This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
> that returns a newly introduced 'struct nd_papr_pdsm_health' instance
> containing dimm health information back to user space in response to
> ND_CMD_CALL. This functi
On Fri, Jun 5, 2020 at 8:22 AM Vaibhav Jain wrote:
[..]
> > Oh, why not define a maximal health payload with all the attributes
> > you know about today, leave some room for future expansion, and then
> > report a validity flag for each attribute? This is how the "intel"
> > smart-health payload w
On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually*
> > > > requires VSX - I don
On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > The thing is, I've yet to see in which way the ELFv2 ABI *actually*
> > > requires VSX - I don't think compiling for 970 introduces any actual
> > > differences. There w
On Fri, Jun 05, 2020 at 05:11:34AM +0530, Vaibhav Jain wrote:
> Since papr_scm_ndctl() can be called from outside papr_scm, its
> exposed to the possibility of receiving NULL as value of 'cmd_rc'
> argument. This patch updates papr_scm_ndctl() to protect against such
> possibility by assigning it p
Hi Linus,
Please pull powerpc updates for 5.8.
Unfortunately we've ended up with quite a few conflicts, which is primarily my
fault for pushing things to next too late. Lesson learnt.
I've pushed the result of my resolution of the conflicts to the powerpc/merge
branch, if you want to look at tha
On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
Yes today's linux-next boots on my powerpc 8xx board.
Christophe
Hello Christophe,
Thanks for testing.
I was able to perform a 'git bisect' [1] and identified the bad commit.
[2] I reverted this commit and after that the kernel boots and wo
Andrew Donnellan writes:
> The CXL_AFU_DRIVER_OPS Kconfig option was added to coordinate merging of
> new features. It no longer serves any purpose, so remove it.
>
> Signed-off-by: Andrew Donnellan
>
> ---
> v1->v2:
> - keep CXL_LIB for now to avoid breaking a driver that is currently out of
>
On 6/5/20 2:37 AM, David Gibson wrote:
The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
which will need the use of the internal command/response buffer. But,
we're issuing this *before* we've waited to make sure that buffer is
allocated.
This can result in intermittent
"Williams, Dan J" writes:
>> -Original Message-
>> From: Vaibhav Jain
>> Sent: Thursday, June 4, 2020 2:06 AM
>> To: Williams, Dan J ; linuxppc-
>> d...@lists.ozlabs.org; linux-nvd...@lists.01.org; linux-
>> ker...@vger.kernel.org
>> Cc: Santosh Sivaraj ; Aneesh Kumar K . V
>> ; Steven R
> >diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> >b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> >index 803940d..3448459 100644
> >--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
> >+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
> >@@ -1100,7 +1100,7 @@ void kvmppc_radix_flush_memslot(struct kvm *k
From: Joe Perches
IS_ENABLED() matches names exactly, so the missing "CONFIG_" prefix
means this code would never be built.
Also fixes a missing newline in pr_warn().
Signed-off-by: Joe Perches
Link:
https://lore.kernel.org/lkml/b08611018fdb6d88757c6008a5c02fa0e07b32fb.ca...@perches.com
Signe
Hi Zong,
Le 6/3/20 à 10:52 PM, Zong Li a écrit :
On Wed, Jun 3, 2020 at 4:01 PM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we co
From: Thomas Falcon
[ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.
Signed-off-by: Thomas Falc
From: Thomas Falcon
[ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.
Signed-off-by: Thomas Falc
From: Thomas Falcon
[ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.
Signed-off-by: Thomas Falc
From: Thomas Falcon
[ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.
Signed-off-by: Thomas Falc
From: Thomas Falcon
[ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ]
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.
Signed-off-by: Thomas Falc
Hi Athira,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on next-20200605]
[cannot apply to kvm-ppc/kvm-ppc-next mpe/next v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Le 31/05/2020 à 04:27, Ram Pai a écrit :
During the life of SVM, its GFNs can transition from secure to shared
state and vice-versa. Since the kernel does not track GFNs that are
shared, it is not possible to disambiguate a shared GFN from a GFN whose
PFN has not yet been migrated to a device-PFN
PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB).
First is the addition of BHRB disable bit and second new filtering
modes for BHRB.
BHRB disable is controlled via Monitor Mode Control Register A (MMCRA)
bit 26, namely "BHRB Recording Disable (BHRBRD)". This field controls
Base enablement patch to register performance monitoring
hardware support for power10. Patch introduce the raw event
encoding format, defines the supported list of events, config
fields for the event attributes and their corresponding bit values
which are exported via sysfs.
Patch also enhances th
Events of type PERF_TYPE_HW_CACHE was described for Power PMU
as: int (*cache_events)[type][op][result];
where type, op, result values unpacked from the event attribute config
value is used to generate the raw event code at runtime.
So far the event code values which used to create these cache-re
From: Madhavan Srinivasan
Add power10 feature function to dt_cpu_ftrs.c along
with a power10 specific init() to initialize pmu sprs.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/include/asm/reg.h| 3 +++
arch/powerpc/kernel/cpu_setup_power.S | 7 +++
arch/powerpc/kernel/dt
PowerISA v3.1 has added new performance monitoring unit (PMU)
special purpose registers (SPRs). They are
Monitor Mode Control Register 3 (MMCR3)
Sampled Instruction Event Register A (SIER2)
Sampled Instruction Event Register B (SIER3)
Patch addes support to save/restore these new
SPRs while enter
From: Madhavan Srinivasan
PowerISA v3.1 added three new perfromance
monitoring unit (PMU) speical purpose register (SPR).
They are Monitor Mode Control Register 3 (MMCR3),
Sampled Instruction Event Register 2 (SIER2),
Sampled Instruction Event Register 3 (SIER3).
Patch here adds a new dump funct
From: Madhavan Srinivasan
PowerISA v3.1 includes new performance monitoring unit(PMU)
special purpose registers (SPRs). They are
Monitor Mode Control Register 3 (MMCR3)
Sampled Instruction Event Register 2 (SIER2)
Sampled Instruction Event Register 3 (SIER3)
MMCR3 is added for further sampling
The patch series adds support for power10 PMU hardware.
And code changes are based on powerpc/next.
Athira Rajeev (4):
KVM: PPC: Book3S HV: Save/restore new PMU registers
powerpc/perf: Update Power PMU cache_events to u64 type
powerpc/perf: power10 Performance Monitoring support
powerpc/pe
43 matches
Mail list logo
