When booting on a machine that uses the compat pmu driver we see this:
[0.071192] GENERIC_COMPAT performance monitor hardware support registered
Which is a bit shouty. Give it a nicer name.
Signed-off-by: Joel Stanley
---
v2: Go with ISAv3
arch/powerpc/perf/generic-compat-pmu.c | 2 +-
On Tue, 31 May 2022 at 08:53, Madhavan Srinivasan wrote:
>
>
> On 5/26/22 12:07 PM, Joel Stanley wrote:
> > When booting on a machine that uses the compat pmu driver we see this:
> >
> > [0.071192] GENERIC_COMPAT performance monitor hardware support
> > registered
> Sorry that was my
> On 2 Jun 2022, at 2:00 am, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Wed, Jun 01, 2022 at 03:48:45PM +1000, Rohan McLure wrote:
>> +.macro BINOP_REGS op, rhs, start, end
>> +.Lreg=\start
>> +.rept (\end - \start + 1)
>> +\op .Lreg, \rhs
>> +.Lreg=.Lreg+1
>> +.endr
>>
On Friday 20 May 2022 14:30:02 Pali Rohár wrote:
> + linux-mm
>
> Do you know what are requirements for kernel to support non-contiguous
> memory support and what is needed to enable it for 32-bit powerpc?
Any hints?
> Currently powerpc arch code does not support "memblock.memory.cnt > 1"
>
On 6/9/22 13:21, Guilherme G. Piccoli wrote:
> First of all, thanks for looping me Bjorn! Much appreciated.
> I'm also CCing Ben and Gavin, that know a lot of PPC PCI stuff.
>
>
> On 09/06/2022 16:34, Bjorn Helgaas wrote:
>> [...]
>>> Upgrading powerpc kernels from LTS 4.4 version (which
First of all, thanks for looping me Bjorn! Much appreciated.
I'm also CCing Ben and Gavin, that know a lot of PPC PCI stuff.
On 09/06/2022 16:34, Bjorn Helgaas wrote:
> [...]
>> Upgrading powerpc kernels from LTS 4.4 version (which does not
>> contain mentioned commit) to new LTS
On Thursday 09 June 2022 14:34:51 Bjorn Helgaas wrote:
> On Thu, Jun 09, 2022 at 08:05:26PM +0200, Pali Rohár wrote:
> > On Thursday 09 June 2022 12:10:22 Bjorn Helgaas wrote:
> > > On Thu, Jun 09, 2022 at 06:27:25PM +0200, Pali Rohár wrote:
> > > > On Thursday 09 June 2022 11:22:55 Bjorn Helgaas
On Thu, Jun 09, 2022 at 08:05:26PM +0200, Pali Rohár wrote:
> On Thursday 09 June 2022 12:10:22 Bjorn Helgaas wrote:
> > On Thu, Jun 09, 2022 at 06:27:25PM +0200, Pali Rohár wrote:
> > > On Thursday 09 June 2022 11:22:55 Bjorn Helgaas wrote:
> > > > [+cc Guilherme, Michael, Ben (author of
The pull request you sent on Fri, 10 Jun 2022 00:59:45 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.19-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/95fc76c81b9270a9ab38f4947fe5cb786c8c79cc
Thank you!
--
On Thursday 09 June 2022 12:10:22 Bjorn Helgaas wrote:
> On Thu, Jun 09, 2022 at 06:27:25PM +0200, Pali Rohár wrote:
> > On Thursday 09 June 2022 11:22:55 Bjorn Helgaas wrote:
> > > [+cc Guilherme, Michael, Ben (author of 63a72284b159 and PPC folks),
> > > thread:
> > >
On 06 June 2022 at 07:06 pm, Rob Herring wrote:
On Mon, Jun 6, 2022 at 11:14 AM Christian Zigotzky
wrote:
On 06 June 2022 at 04:58 pm, Rob Herring wrote:
On Fri, May 27, 2022 at 9:23 AM Rob Herring wrote:
On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
wrote:
On 27 May 2022 at 10:14
On Thu, Jun 09, 2022 at 06:27:25PM +0200, Pali Rohár wrote:
> On Thursday 09 June 2022 11:22:55 Bjorn Helgaas wrote:
> > [+cc Guilherme, Michael, Ben (author of 63a72284b159 and PPC folks), thread:
> > https://lore.kernel.org/r/20220504175718.29011-1-p...@kernel.org]
> >
> > On Fri, May 06, 2022
On Thursday 09 June 2022 11:22:55 Bjorn Helgaas wrote:
> [+cc Guilherme, Michael, Ben (author of 63a72284b159 and PPC folks), thread:
> https://lore.kernel.org/r/20220504175718.29011-1-p...@kernel.org]
>
> On Fri, May 06, 2022 at 12:33:02AM +0200, Pali Rohár wrote:
> > On Thursday 05 May 2022
[+cc Guilherme, Michael, Ben (author of 63a72284b159 and PPC folks), thread:
https://lore.kernel.org/r/20220504175718.29011-1-p...@kernel.org]
On Fri, May 06, 2022 at 12:33:02AM +0200, Pali Rohár wrote:
> On Thursday 05 May 2022 15:10:01 Tyrel Datwyler wrote:
> > On 5/5/22 02:31, Pali Rohár
From: Sebastian Andrzej Siewior
> Sent: 09 June 2022 16:03
>
> On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> > Tasklets have long been deprecated as being too heavy on the system
> > by running in irq context - and this is not a performance critical
> > path. If a higher priority
On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> Tasklets have long been deprecated as being too heavy on the system
> by running in irq context - and this is not a performance critical
> path. If a higher priority process wants to run, it must wait for
> the tasklet to finish before doing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull powerpc fixes for 5.19:
The following changes since commit 6112bd00e84e5dbffebc3c1e908cbe914ca772ee:
Merge tag 'powerpc-5.19-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2022-05-28
11:27:17 -0700)
On Sat, 4 Jun 2022 17:50:50 +0900, Masahiro Yamada wrote:
> You cannot include here because it is generated
> in init/Makefile but there is no guarantee that it happens before
> arch/powerpc/mm/nohash/kaslr_booke.c is compiled for parallel builds.
>
> The places where you can reliably include
On Thu, 20 Jan 2022 20:44:18 -0500, He Ying wrote:
> The following KASAN warning was reported in our kernel.
>
> BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
> Read of size 4 at addr d216f958 by task ps/14437
>
> CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
On Thu, 19 May 2022 17:45:21 +1000, Paul Mackerras wrote:
> This marks more files and functions that can possibly be called in
> real mode as not to be instrumented by KASAN. Most were found by
> inspection, except for get_pseries_errorlog() which was reported as
> causing a crash in testing.
>
On Thu, 2 Jun 2022 00:31:14 +1000, Michael Ellerman wrote:
> KASAN causes increased stack usage, which can lead to stack overflows.
>
> The logic in Kconfig to suggest a larger default doesn't work if a user
> has CONFIG_EXPERT enabled and has an existing .config with a smaller
> value.
>
>
On Wed, 25 May 2022 13:26:39 +1000, Michael Ellerman wrote:
> The HAVE_IRQ_EXIT_ON_IRQ_STACK option tells generic code that irq_exit()
> is called while still running on the hard irq stack (hardirq_ctx[] in
> the powerpc code).
>
> Selecting the option means the generic code will *not* switch to
On Tue, 24 May 2022 16:53:53 +0530, Vaibhav Jain wrote:
> Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being
> reported with vPMEM when papr_scm probe is being called. The panic is of the
> form below and is observed only with following option disabled(profile) for
>
On Thu, 9 Jun 2022 23:32:45 +1000, Michael Ellerman wrote:
> The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
> to read/write registers of another process.
>
> To get/set a register, the API takes an index into an imaginary address
> space called the "USER area", where the
On Mon, 6 Jun 2022 03:37:05 +, cgel@gmail.com wrote:
> From: Minghao Chi
>
> Because clk_disable_unprepare/clk_prepare_enable already checked NULL clock
> parameter, so the additional checks are unnecessary, just remove them.
>
>
Applied to
The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
to read/write registers of another process.
To get/set a register, the API takes an index into an imaginary address
space called the "USER area", where the registers of the process are
laid out in some fashion.
The kernel
On Thu, Jun 09, 2022 at 03:28:55AM -0700, Wang Wenhu wrote:
> The l2-cache could be optionally configured as SRAM partly or fully.
> Users can make use of it as a block of independent memory that offers
> special usage, such as for debuging or other cratical status info
> storage which keeps
Le 01/06/2022 à 10:29, Christophe Leroy a écrit :
Le 01/06/2022 à 07:48, Rohan McLure a écrit :
[Vous ne recevez pas souvent de courriers de la part de
rmcl...@linux.ibm.com. Découvrez pourquoi cela peut être important à
l'adresse https://aka.ms/LearnAboutSenderIdentification.]
Syscall
On 2022-05-30 16:15:10 [-0700], Davidlohr Bueso wrote:
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index d0eab5700dc5..31b1900489e7 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -891,7 +891,7 @@ static void
On execve[at], we are zero'ing out most of the thread register state
including gpr[0], which contains the syscall number. Due to this, we
fail to trigger the syscall exit tracepoint properly. Fix this by
retaining gpr[0] in the thread register state.
Before this patch:
# tail
On Tuesday 24 May 2022 11:17:56 Pali Rohár wrote:
> On Friday 06 May 2022 00:33:02 Pali Rohár wrote:
> > On Thursday 05 May 2022 15:10:01 Tyrel Datwyler wrote:
> > > On 5/5/22 02:31, Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > On Thursday 05 May 2022 07:16:40 Christophe Leroy wrote:
> > > >>
On Tuesday 24 May 2022 11:23:32 Pali Rohár wrote:
> On Wednesday 11 May 2022 16:37:12 Pali Rohár wrote:
> > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
> > Hardware design is fully open
When KASAN is enabled, as shown by the Oops below, the 2k limit is not
enough to allow stack dump after a stack overflow detection when
CONFIG_DEBUG_STACKOVERFLOW is selected:
do_IRQ: stack overflow: 1984
CPU: 0 PID: 126 Comm: systemd-udevd Not tainted 5.18.0-gentoo-PMacG4 #1
Since commit 48cf12d88969 ("powerpc/irq: Inline call_do_irq() and
call_do_softirq()"), __do_irq() is not used outside irq.c
Reorder functions and make __do_irq() static and
drop the declaration in irq.h.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/irq.h | 1 -
Remove duplicated code by implementing a proper if/else.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index e5b7fb5282ee..b007f16ccbd3 100644
Hi Michael,
Le 06/06/2022 à 16:45, Michael Ellerman a écrit :
> Hi Ariel,
>
> I've added Christophe to Cc who works on ppc32.
I've added powerpc list
>
> I haven't actually reproduced the crash with gdbserver, but I have a
> test case which shows the bug, so I've been able to confirm it and
>
On 09/06/2022, 09:45:49, Michael Ellerman wrote:
> Nathan Lynch writes:
>> Laurent Dufour writes:
> ...
>>
>>> There are ongoing investigations to clarify where and how this latency is
>>> happening. I'm not excluding any other issue in the Linux kernel, but right
>>> now, this looks to be the
Nathan Lynch writes:
> Laurent Dufour writes:
...
>
>> There are ongoing investigations to clarify where and how this latency is
>> happening. I'm not excluding any other issue in the Linux kernel, but right
>> now, this looks to be the best option to prevent system crash during
>> LPM.
>
> It
38 matches
Mail list logo
