Le 26/08/2021 à 05:21, Michael Ellerman a écrit :
Nathan Chancellor writes:
On Tue, Apr 13, 2021 at 04:38:10PM +, Christophe Leroy wrote:
Using asm goto in __WARN_FLAGS() and WARN_ON() allows more
flexibility to GCC.
...
This patch as commit 1e688dd2a3d6 ("powerpc/bug: Provide better
Christophe Leroy writes:
> HMT_xxx macros are macros for adjusting thread priority
> (hardware multi-threading) are macros inherited from PPC64
> via commit 5f7c690728ac ("[PATCH] powerpc: Merged ppc_asm.h")
>
> Those instructions are pointless on PPC32, but some common
> fonctions like arch_cpu_i
Le 26/08/2021 à 05:41, Michael Ellerman a écrit :
Christophe Leroy writes:
There is no point in modifying MSR_LE bit on CPUs not supporting
little endian.
Isn't that an ABI break?
Or an ABI fix ? I don't know.
My first thought was that all other 32 bits architectures were returning -EIN
On Mon, Aug 23, 2021, Mathieu Desnoyers wrote:
> [ re-send to Darren Hart ]
>
> - On Aug 23, 2021, at 11:18 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On Aug 20, 2021, at 6:50 PM, Sean Christopherson sea...@google.com
> > wrote:
> >
> >> Add a test to verify
* Michael Ellerman [2021-08-25 23:01:42]:
> Srikar Dronamraju writes:
> > * Laurent Dufour [2021-08-23 11:21:33]:
> >> Le 21/08/2021 à 12:25, Srikar Dronamraju a écrit :
> >> > Currently, a debug message gets printed every time an attempt to
> >> > add(remove) a CPU. However this is redundant i
* Christian Zigotzky [2021-08-16 14:29:21]:
Hi Christian,
> I tested the RC6 of kernel 5.14 today and unfortunately the issue still
> exists. We have figured out that only P5040 SoCs are affected. [1]
> P5020 SoCs display the correct values.
> Please check the CPU changes in the PowerPC updates
Christophe Leroy writes:
> There is no point in modifying MSR_LE bit on CPUs not supporting
> little endian.
Isn't that an ABI break?
set_endian(PR_ENDIAN_BIG) should work on a big endian CPU, even if it
does nothing useful.
cheers
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/ke
Ganesh writes:
> On 8/24/21 6:18 PM, Michael Ellerman wrote:
>
>> Ganesh Goudar writes:
>>> Add test for real address or control memory address access
>>> error handling, using NX-GZIP engine.
>>>
>>> The error is injected by accessing the control memory address
>>> using illegal instruction, on
allmodconfig
i386 randconfig-c001-20210825
sh rsk7269_defconfig
powerpc cm5200_defconfig
arm u8500_defconfig
powerpc mpc512x_defconfig
powerpc ebony_defconfig
arm
Excerpts from Segher Boessenkool's message of August 19, 2021 1:06 am:
> On Fri, Aug 13, 2021 at 04:08:13PM +1000, Nicholas Piggin wrote:
>> This one possibly the branches end up in predictors, whereas conditional
>> trap is always just speculated not to hit. Branches may also have a
>> throughput
nked in:
> [2.177481][T1] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
>5.14.0-rc7-next-20210825 #1
> [2.177520][T1] NIP: c07ff81c LR: c090a038 CTR:
>
> [2.177557][T1] REGS: c73c32a0 TRAP: 0700 Tainted
Ganesh writes:
> On 8/24/21 12:09 PM, Michael Ellerman wrote:
>> Ganesh Goudar writes:
>>> Add support to parse and log control memory access
>>> error for pseries.
>>>
>>> Signed-off-by: Ganesh Goudar
>>> ---
>>> v2: No changes in this patch.
>>> ---
>>> arch/powerpc/platforms/pseries/ras.c |
-by: Christophe Leroy
This patch as commit 1e688dd2a3d6 ("powerpc/bug: Provide better
flexibility to WARN_ON/__WARN_FLAGS() with asm goto") cause a WARN_ON in
klist_add_tail to trigger over and over on boot when compiling with
clang:
[2.177416][T1] WARNING: CPU: 0 PID: 1 at
On Mon, Aug 23, 2021 at 12:53:39PM +0200, Niklas Schnelle wrote:
> On Fri, 2021-08-20 at 17:37 -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> > > The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> > > PCI arch code of both
On Wed, Aug 25, 2021 at 05:06:29PM +0530, Ganesh wrote:
>
> On 8/25/21 2:54 AM, Segher Boessenkool wrote:
> >On Tue, Aug 24, 2021 at 04:39:57PM +1000, Michael Ellerman wrote:
> >>>+ case MC_ERROR_CTRL_MEM_ACCESS_PTABLE_WALK:
> >>>+ mce_err.u.ra_error_type =
> >>>+
There is no point in modifying MSR_LE bit on CPUs not supporting
little endian.
Just like done for get_endian(), make set_endian() return
EINVAL in that case.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/process.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/k
HMT_xxx macros are macros for adjusting thread priority
(hardware multi-threading) are macros inherited from PPC64
via commit 5f7c690728ac ("[PATCH] powerpc: Merged ppc_asm.h")
Those instructions are pointless on PPC32, but some common
fonctions like arch_cpu_idle() use them.
So make them empty o
Srikar Dronamraju writes:
> * Laurent Dufour [2021-08-23 11:21:33]:
>> Le 21/08/2021 à 12:25, Srikar Dronamraju a écrit :
>> > Currently, a debug message gets printed every time an attempt to
>> > add(remove) a CPU. However this is redundant if the CPU is already added
>> > (removed) from the nod
On 8/25/21 2:54 AM, Segher Boessenkool wrote:
On Tue, Aug 24, 2021 at 04:39:57PM +1000, Michael Ellerman wrote:
+ case MC_ERROR_CTRL_MEM_ACCESS_PTABLE_WALK:
+ mce_err.u.ra_error_type =
+ MCE_RA_ERROR_PAGE_TABLE_WALK_LOAD_STORE_FO
On 8/24/21 6:18 PM, Michael Ellerman wrote:
Ganesh Goudar writes:
Add test for real address or control memory address access
error handling, using NX-GZIP engine.
The error is injected by accessing the control memory address
using illegal instruction, on successful handling the process
attemp
On 8/24/21 12:09 PM, Michael Ellerman wrote:
Hi Ganesh,
Some comments below ...
Ganesh Goudar writes:
Add support to parse and log control memory access
error for pseries.
Signed-off-by: Ganesh Goudar
---
v2: No changes in this patch.
---
arch/powerpc/platforms/pseries/ras.c | 21 ++
Reading the CFAR register is quite costly (~20 cycles on POWER9). It is
a good idea to have for most synchronous interrupts, but for async ones
it is much less important.
Doorbell, external, and decrementer interrupts are the important
asynchronous ones. HV interrupts can't skip CFAR if KVM HV is
Enabling MSR[EE] in interrupt handlers while interrupts are still soft
masked allows PMIs to profile interrupt handlers to some degree, beyond
what SIAR latching allows.
When perf is not being used, this is almost useless work. It requires an
extra mtmsrd in the irq handler, and it also opens the
Interrupt code enables MSR[EE] in some irq handlers while keeping local
irqs disabled via soft-mask, allowing PMI interrupts to be taken as
soft-NMI to improve profiling of irq handlers.
When perf is not enabled, there is no point to doing this, it's
additional overhead. So provide a function that
Similarly to the system call change in the previous patch, the mtmsrd to
enable RI can be combined with the mtmsrd to enable EE for interrupts
which enable the latter, which tends to be the important synchronous
interrupts (i.e., page faults).
Do this by enabling EE and RI together at the beginnin
Here's a few stragglers. The first patch was submitted already but had
some bugs with unrecoverable exceptions on HPT (current->blah being
accessed before MSR[RI] was enabled). Those should be fixed now.
The others are generally for helping asynch interrupts, which are a bit
harder to measure well
Hi Aneesh,
On Wed, 25 Aug 2021 09:54:47 +0530 "Aneesh Kumar K.V"
wrote:
>
> Fix make htmldocs related errors with the newly added associativity.rst
> doc file.
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Aneesh Kumar K.V
> ---
> Documentation/powerpc/associativity.rst | 29 +++
Le 24/08/2021 à 15:16, Segher Boessenkool a écrit :
Hi!
On Tue, Aug 24, 2021 at 07:54:22AM +0200, Christophe Leroy wrote:
Le 23/08/2021 à 20:46, Segher Boessenkool a écrit :
On Mon, Aug 23, 2021 at 03:29:12PM +, Christophe Leroy wrote:
Instructions lmw/stmw are interesting for function
From: Segher Boessenkool
> Sent: 24 August 2021 16:28
>
> On Tue, Aug 24, 2021 at 08:16:00AM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 24, 2021 at 07:54:22AM +0200, Christophe Leroy wrote:
> > > >On mpccore both lmw and stmw are only N+1 btw. But the serialization
> > > >might cost anothe
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed
oprofile.
Remove all remaining parts of it.
Signed-off-by: Christophe Leroy
Acked-by: Viresh Kumar
---
arch/powerpc/include/asm/cputable.h | 3 --
arch/powerpc/kernel/cputable.c| 66 +--
arch/
From: Rashmica Gupta
Currently the perf CPU backend drivers detect what CPU they're on using
cur_cpu_spec->oprofile_cpu_type.
Although that works, it's a bit crufty to be using oprofile related fields,
especially seeing as oprofile is more or less unused these days.
It also means perf is relian
31 matches
Mail list logo
