Re: [PATCH] powerpc/eeh: Fix wrong flag passed to eeh_unfreeze_pe()

Gavin Shan writes: > In __eeh_clear_pe_frozen_state(), we should pass the flag's value > instead of its address to eeh_unfreeze_pe(). This doesn't introduce > any problems, but the code is just wrong. It means any caller that passes false, will be getting the wrong

Re: [PATCH v5 2/2] KVM: PPC: Exit guest upon MCE when FWNMI capability is enabled

On 01/16/2017 10:05 AM, Paul Mackerras wrote: > On Fri, Jan 13, 2017 at 04:51:45PM +0530, Aravinda Prasad wrote: >> Enhance KVM to cause a guest exit with KVM_EXIT_NMI >> exit reason upon a machine check exception (MCE) in >> the guest address space if the KVM_CAP_PPC_FWNMI >> capability is

Re: [PATCH] powerpc/eeh: Enable IO path on permanent error

On Fri, 2017-01-06 at 10:39 +1100, Gavin Shan wrote: > We give up recovery on permanent error, simply shutdown the affected > devices and remove them. If the devices can't be put into quiet state, > they spew more traffic that is likely to cause another unexpected EEH > error. This was observed on

[PATCH v2] powerpc/perf: use MSR to report privilege level on P9 DD1

Since SIER and SIAR updates are not valid for some samples, patch forces the use of MSR and regs->nip instead for misc_flag updates. This is done by adding a new ppmu flag and updating user_siar value in perf_read_regs() accordingly. Signed-off-by: Madhavan Srinivasan

Re: [PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping()

On Tue, Jan 17, 2017 at 12:36:53PM -0600, Reza Arbab wrote: > On Tue, Jan 17, 2017 at 12:55:13PM +0530, Balbir Singh wrote: > > On Mon, Jan 16, 2017 at 01:07:46PM -0600, Reza Arbab wrote: > > > Use remove_pagetable() and friends for radix vmemmap removal. > > > > > > We do not require the

Re: [PATCH v5 3/4] powerpc/mm: add radix__remove_section_mapping()

On Tue, Jan 17, 2017 at 12:36:21PM -0600, Reza Arbab wrote: > On Tue, Jan 17, 2017 at 12:52:51PM +0530, Balbir Singh wrote: > > Shouldn't most of these functions have __meminit? > > I don't think so. The mapping functions are __meminit, but the unmapping > functions are completely within #ifdef

Re: [PATCH v5 1/4] powerpc/mm: refactor radix physical page mapping

On Tue, Jan 17, 2017 at 12:34:56PM -0600, Reza Arbab wrote: > Thanks for your review! > > On Tue, Jan 17, 2017 at 12:16:35PM +0530, Balbir Singh wrote: > > On Mon, Jan 16, 2017 at 01:07:43PM -0600, Reza Arbab wrote: > > > --- a/arch/powerpc/mm/pgtable-radix.c > > > +++

Re: [PATCH] powerpc: Use octal numbers for file permissions

On Tue, 2017-01-17 at 20:52 +1100, Michael Ellerman wrote: > Cyril Bur writes: > > > On Thu, 2017-01-12 at 14:54 +1100, Russell Currey wrote: > > > Symbolic macros are unintuitive and hard to read, whereas octal constants > > > are much easier to interpret. Replace macros

Re: [PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

On Tue, Jan 17, 2017 at 11:26 AM, Ard Biesheuvel wrote: > The modversion symbol CRCs are emitted as ELF symbols, which allows us to > easily populate the kcrctab sections by relying on the linker to associate > each kcrctab slot with the correct value. > > This has a

[PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

The modversion symbol CRCs are emitted as ELF symbols, which allows us to easily populate the kcrctab sections by relying on the linker to associate each kcrctab slot with the correct value. This has a couple of downsides: - Given that the CRCs are treated as memory addresses, we waste 4 bytes

[PATCH v4 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols

In preparation of modifying the core modversions code to emit the CRCs as 32-bit quantities, ensure that 64-bit PowerPC will be able to deal with this when CONFIG_RELOCATABLE=y, in which case the CRCs will be emitted into the final ELF binary as R_PPC64_ADDR32 relocations. Since 32-bit

[PATCH v4 1/3] powerpc/reloc32: fix corrupted modversion CRCs

Commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix causes perf issues") fixed an issue with relocatable PIE kernels in a way that essentially reintroduced the issue again for 32-bit builds. Since the chosen approach does is not applicable to 32-bit, fix the issue by updating the

[PATCH v4 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y

This series is a followup to the single patch 'modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs', of which three versions have been sent out so far [0][1][2] Given the recent issues regarding modversions, I have added some more people to cc this time. As pointed out by

Re: [PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping()

On Tue, Jan 17, 2017 at 12:55:13PM +0530, Balbir Singh wrote: On Mon, Jan 16, 2017 at 01:07:46PM -0600, Reza Arbab wrote: Use remove_pagetable() and friends for radix vmemmap removal. We do not require the special-case handling of vmemmap done in the x86 versions of these functions. This is

Re: [PATCH v5 3/4] powerpc/mm: add radix__remove_section_mapping()

On Tue, Jan 17, 2017 at 12:52:51PM +0530, Balbir Singh wrote: Shouldn't most of these functions have __meminit? I don't think so. The mapping functions are __meminit, but the unmapping functions are completely within #ifdef CONFIG_MEMORY_HOTPLUG already. On Mon, Jan 16, 2017 at 01:07:45PM

Re: [PATCH v5 1/4] powerpc/mm: refactor radix physical page mapping

Thanks for your review! On Tue, Jan 17, 2017 at 12:16:35PM +0530, Balbir Singh wrote: On Mon, Jan 16, 2017 at 01:07:43PM -0600, Reza Arbab wrote: --- a/arch/powerpc/mm/pgtable-radix.c +++ b/arch/powerpc/mm/pgtable-radix.c @@ -107,54 +107,66 @@ int radix__map_kernel_page(unsigned long ea,

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

On Friday 06 January 2017 07:33 AM, Dave Young wrote: On 01/05/17 at 11:01pm, Hari Bathini wrote: Get rid of multiple definitions of append_elf_note() & final_note() functions. Reuse these functions compiled under CONFIG_CRASH_CORE Also, define Elf_Word and use it instead of generic u32 or

Re: Normal service will resume shortly ...

Welcome Back! I believe that the following patch set should go into 4.10: https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-December/152079.html "powerpc/devtree: Add support for 2 new DRC properties" Would you please take a look at it? Michael On 01/16/2017 03:33 AM, Michael Ellerman

Re: [PATCH] powerpc: Use octal numbers for file permissions

It has been pointed out that this actually occured in 2017. My apologies. On 17/01/2017 9:50 PM, "Oliver O'Halloran" wrote: > "It's possible I missed one, but I did genuinely review all of it" > > Cyril Bur, 2016 > In a hobart pub, specifically The Winston > > On 17/01/2017

Re: [PATCH] powerpc: Use octal numbers for file permissions

"It's possible I missed one, but I did genuinely review all of it" Cyril Bur, 2016 In a hobart pub, specifically The Winston On 17/01/2017 8:53 PM, "Michael Ellerman" wrote: > Cyril Bur writes: > > > On Thu, 2017-01-12 at 14:54 +1100, Russell Currey

Re: [PATCH] powerpc: Use octal numbers for file permissions

Cyril Bur writes: > On Thu, 2017-01-12 at 14:54 +1100, Russell Currey wrote: >> Symbolic macros are unintuitive and hard to read, whereas octal constants >> are much easier to interpret. Replace macros for the basic permission >> flags (user/group/other read/write/execute)

Re: Normal service will resume shortly ...

Hi Michael, Welcome back!! Can you please take a look at: https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-November/151426.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-November/150452.html Thanks, Ravi On Monday 16 January 2017 03:03 PM, Michael Ellerman wrote: > Hi folks, >