On Tue, Aug 4, 2020 at 12:07 PM Joel Stanley wrote:
>
> Messy:
>
> $ git grep "define DBG(" arch/powerpc/ |grep -v print
> arch/powerpc/kernel/crash_dump.c:#define DBG(fmt...)
> arch/powerpc/kernel/iommu.c:#define DBG(...)
> arch/powerpc/kernel/legacy_serial.c:#define DBG(fmt...) do { } while(0)
>
Hi Michael,
On 04/08/20 6:38 am, Michael Ellerman wrote:
> Sandipan Das writes:
>> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>>> Sachin Sant writes:
> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
> On 02/08/20 4:45 pm, Sachin Sant wrote:
>> pkey_exec_prot test from linuxppc m
allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386 randconfig-a001-20200803
i386 randconfig-a002-20200803
i386 randconfig-a003-20200803
i386
allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386 randconfig-a001-20200803
i386 randconfig-a002
allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a004-20200803
i386 randconfig-a005-20200803
i386
On Power9 a pair of cores can be presented by the firmware as a big-core
for backward compatibility reasons, with 4 threads per (small) core and 8
threads per big-core. cpu_smt_mask() should generally point to the cpu mask
of the (small)core.
In order to maintain userspace backward compatibility (
cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
most architectures. One of the users of cpu_smt_mask(), would be to
identify idle-cores. On Power9, a pair of cores can be presented by the
firmware as a big-core for backward compatibility reasons.
In order to maintain userspace
For a power9 KVM guest with XIVE enabled, running a test loop
where we hotplug 384 vcpus and then unplug them, the following traces
can be seen (generally within a few loops) either from the unplugged
vcpu:
[ 1767.353447] cpu 65 (hwid 65) Ready to die...
[ 1767.952096] Querying DEAD? cpu 66 (6
On Tue, 4 Aug 2020 at 01:06, Oliver O'Halloran wrote:
>
> The "parent" variable in pnv_pci_ioda_configure_pe() isn't used for
> anything anymore and can be dropped.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Joel Stanley
On Tue, 4 Aug 2020 at 01:03, Oliver O'Halloran wrote:
>
> Comments opening with /** are parsed by kerneldoc and this causes the
> following warning to be printed:
>
> arch/powerpc/platforms/powernv/opal-prd.c:31: warning: cannot
> understand
> function prototype: 'struct opal_prd_
On Tue, 4 Aug 2020 at 01:01, Oliver O'Halloran wrote:
>
> There's a few scattered in the powernv platform.
>
> Signed-off-by: Oliver O'Halloran
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -38,7 +38,7 @@
>
> static int eeh_event_irq = -EINVAL;
>
> -void pnv_pcibios_bus_add_device(s
On Tue, 4 Aug 2020 at 00:57, Oliver O'Halloran wrote:
>
> When building with W=1 we get the following warning:
>
> arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
> arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
> empty body in an ‘if
Sandipan Das writes:
> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>> Sachin Sant writes:
On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
On 02/08/20 4:45 pm, Sachin Sant wrote:
> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
> build due to following
Building with W=1 results in the following warning:
In file included from arch/powerpc/platforms/powernv/vas-fault.c:16:
./arch/powerpc/include/asm/icswx.h:159:1: error: alignment 1 of ‘struct
coprocessor_request_block’ is less than 16 [-Werror=packed-not-aligned]
159 | } __packed;
The "parent" variable in pnv_pci_ioda_configure_pe() isn't used for
anything anymore and can be dropped.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/pow
Comments opening with /** are parsed by kerneldoc and this causes the
following warning to be printed:
arch/powerpc/platforms/powernv/opal-prd.c:31: warning: cannot understand
function prototype: 'struct opal_prd_msg_queue_item '
opal_prd_mesg_queue_item is an internal data struct
There's a few scattered in the powernv platform.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++--
arch/powerpc/platforms/powernv/rng.c | 2 +-
arch/powerpc/platforms/powernv/vas-window.c | 9 -
3 files changed, 7 insertions(+), 8 deleti
The asm/powernv.h header provides prototypes for functions which need to be
called by non-powernv platform code. Also include it in the powernv.h
that's local to the platform directory to squash some warnings about
non-static functions missing prototypes.
Also include powernv.h since from opal-mem
When building with W=1 we get the following warning:
arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
empty body in an ‘if’ statement [-Werror=empty-body]
276 | cpu, srr1);
Fixes the (mostly) suprious errors we get when building powernv with
W=1. More work is required to build all of powerpc with W=1, let alone
W=2.
Stephen Rothwell writes:
> On Mon, 03 Aug 2020 21:18:00 +1000 Michael Ellerman
> wrote:
>>
>> If we just move the include of asm/paca.h below asm-generic/percpu.h
>> then it avoids the bad circular dependency and we still have paca.h
>> included from percpu.h as before.
>>
>> eg:
>>
>> diff --
On Mon, Aug 03, 2020 at 03:57:11PM +1000, Michael Ellerman wrote:
> > I would assume the function should still be generated since those checks
> > are relevant, just the return value is bogus.
>
> Yeah, just sometimes missing warnings boil down to the compiler eliding
> whole sections of code, if
Le 30/07/2020 à 15:33, Pingfan Liu a écrit :
A bug is observed on pseries by taking the following steps on rhel:
-1. drmgr -c mem -r -q 5
-2. echo c > /proc/sysrq-trigger
And then, the failure looks like:
kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
kdump: saving vmcore-dm
> > +#undef SYS_pkey_mprotect
> > #define SYS_pkey_mprotect 386
>
> We shouldn't undef them.
>
> They should obviously never change, but if the system headers already
> have a definition then we should use that, so I think it should be:
>
> #ifndef SYS_pkey_mprotect
> #define SYS_pkey_mprotect
> On 03-Aug-2020, at 4:53 PM, Sandipan Das wrote:
>
> On some distros, there are conflicts w.r.t to redefinition
> of pkey syscall numbers which cause build failures. This
> fixes them.
>
> Reported-by: Sachin Sant
> Signed-off-by: Sandipan Das
> —
Thanks for the fix.
Tested-by: Sachin Sa
@@ -603,6 +606,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
}
lmb_set_nid(lmb);
+ lmb->flags |= DRCONF_MEM_ASSIGNED;
+
block_sz = memory_block_size_bytes();
/* Add the memory */
Since the lmb->flags is now set earlier, you should unset it in the ca
Michael Neuling writes:
> On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> SMT8. Bit 12 is set for SMT4.
>
> Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> this:
> cpu : POWER10, altivec supported
> revision: 17.0 (pvr 0080 1100)
>
>
Hi Michael,
On Mon, 03 Aug 2020 21:18:00 +1000 Michael Ellerman wrote:
>
> If we just move the include of asm/paca.h below asm-generic/percpu.h
> then it avoids the bad circular dependency and we still have paca.h
> included from percpu.h as before.
>
> eg:
>
> diff --git a/arch/powerpc/include
On Mon, Aug 03, 2020 at 09:18:00PM +1000, Michael Ellerman wrote:
> If we just move the include of asm/paca.h below asm-generic/percpu.h
> then it avoids the bad circular dependency and we still have paca.h
> included from percpu.h as before.
>
> eg:
>
> diff --git a/arch/powerpc/include/asm/perc
On 03/08/20 4:34 pm, Michael Ellerman wrote:
> Sandipan Das writes:
>> On some distros, there are conflicts w.r.t to redefinition
>> of pkey syscall numbers which cause build failures. This
>> fixes them.
>>
>> Reported-by: Sachin Sant
>> Signed-off-by: Sandipan Das
>> ---
>> Previous version
Hi Michael,
On Mon, Aug 3, 2020 at 1:09 PM Michael Ellerman wrote:
> Geert Uytterhoeven writes:
> > On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
> > wrote:
> >> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
> >> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
>
Hi Michael,
On 03/08/20 4:32 pm, Michael Ellerman wrote:
> Sachin Sant writes:
>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
>>> On 02/08/20 4:45 pm, Sachin Sant wrote:
pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
build due to following error:
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant
Signed-off-by: Sandipan Das
---
Previous versions can be found at:
v2:
https://lore.kernel.org/linuxppc-dev/566dde119ce71f00f9642807ba30ceb7f5
Willy Tarreau writes:
> On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
>> On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > We are getting build failures in some PowerPC configs for Linus' tree.
>> > See e.g. http://kisskb.ellerman.id.au/kiss
Geert Uytterhoeven writes:
> On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
> wrote:
>> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
>> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
>> > wrote:
>> > > /* If we have an image attached to us, it overrides a
Sandipan Das writes:
> On some distros, there are conflicts w.r.t to redefinition
> of pkey syscall numbers which cause build failures. This
> fixes them.
>
> Reported-by: Sachin Sant
> Signed-off-by: Sandipan Das
> ---
> Previous versions can be found at:
> v1:
> https://lore.kernel.org/linuxp
Sachin Sant writes:
>> On 02-Aug-2020, at 10:58 PM, Sandipan Das wrote:
>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>> build due to following error:
>>>
>>> gcc -std=gnu99 -O2 -Wall -Werror
>>> -DGIT_VERSION='"v5.8-rc7-1
* Michael Neuling [2020-08-03 13:56:00]:
> On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> SMT8. Bit 12 is set for SMT4.
>
> Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> this:
> cpu : POWER10, altivec supported
> revision: 17.0
Hi Segher,
On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
wrote:
> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
> > wrote:
> > > /* If we have an image attached to us, it overrides anything
> > > *
On Mon, Aug 3, 2020 at 11:53 AM Geert Uytterhoeven wrote:
> JFYI, when comparing v5.8[1] to v5.8-rc7[3], the summaries are:
> - build errors: +2/-3
+ /kisskb/src/arch/powerpc/include/asm/mmu.h: error: unknown type
name 'next_tlbcam_idx': => 139:22
v5.8/powerpc-gcc4.9/corenet64_smp_defconfig
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant
Signed-off-by: Sandipan Das
---
Previous versions can be found at:
v1:
https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandi...@l
Initialising the value before using it is generally regarded as a good
idea so do that.
Fixes: 4c51f3e1e870 ("powerpc/powernv/sriov: Make single PE mode a per-BAR
setting")
Reported-by: Nathan Chancellor
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-sriov.c | 4 +---
Some distros have the pkey syscall numbers defined under
unistd.h. This conflicts with the definitions in the pkeys
selftest header and causes build failures.
E.g. this works
$ grep -nr "SYS_pkey" /usr/include/
/usr/include/bits/syscall.h:1575:# define SYS_pkey_alloc __NR_pkey_alloc
/usr/inc
On Thu, Apr 30, 2020 at 11:15 PM Max Gurtovoy wrote:
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 57d3a6a..9ecc576 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -370
44 matches
Mail list logo
