Frederic Barrat writes:
> Introduce a new 'flags' attribute per context and define its first bit
> to be a marker requiring all TLBIs for that context to be broadcasted
> globally. Once that marker is set on a context, it cannot be removed.
>
> Such a marker is useful for memory contexts used by
"Naveen N. Rao" writes:
> On 2017/04/27 08:19PM, Michael Ellerman wrote:
>> "Naveen N. Rao" writes:
>>
>> > It is actually safe to probe system_call() in entry_64.S, but only till
>> > .Lsyscall_exit. To allow this, convert .Lsyscall_exit to a non-local
>> > symbol __system_call() and blacklist
On 2017/04/27 02:06PM, Naveen N. Rao wrote:
> v2 changes:
> - Patches 3 and 4 from the previous series have been merged.
> - Updated to no longer blacklist functions involved with stolen time
> accounting.
>
> v1:
> https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg117514.html
> --
>
Avoid stuck and hacking jiffies for a long time and using msleep()
for certatin numeber of cylces without the factor of safety
but using the the long delay considering the factor of safety
with the while loop such that after msleep for a short period
of time we check the msg if it's OK, breaking t
HAVE_FUNCTION_GRAPH_FP_TEST reveals another area (apart from jprobes)
that conflicts with the function_graph tracer: xmon. This is due to the
use of longjmp() in various places in xmon.
To address this, pause function_graph tracing while in xmon.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/xm
This is very handy to catch potential crashes due to unexpected
interactions of function_graph tracer with weird things like
jprobes.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/asm-prototypes.h | 3 ++-
arch/powerpc/include/asm/ftrace.h | 3 +++
arch/powerpc/kern
Currently, ftrace_graph_caller() sets up a separate stack frame to save
some state before calling into prepare_ftrace_return(). Eliminate this
by calling into ftrace_graph_caller() right after the ftrace handler.
We make a few changes to accommodate this:
1. Currently, due to where it is present,
The existing comment around the location of mcount() call site in a
function is a bit confusing.
Depending on the gcc version, the mcount() call can either be the fourth
(gcc v6 and later) or the fifth instruction (gcc v5 and earlier) into a
function. So, the mcount call is actually within the fir
For -mprofile-kernel, there is no need to save LR into the ABI save
location on entry into ftrace_caller(). It is sufficient to have the
(possibly updated) return address in LR (and r0?). On return from
ftrace, this value is stored in the ABI save location if necessary.
Furthermore, we can also re
ftrace_caller() depends on a modified regs->nip to detect if a certain
function has been livepatched. However, with KPROBES_ON_FTRACE, it is
possible for regs->nip to have been modified by the jprobes pre_handler.
In this case, we do not want to invoke the livepatch_handler so as not
to consume the
For DYNAMIC_FTRACE_WITH_REGS, we should be passing-in the original set
of registers in pt_regs, to capture the state _before_ ftrace_caller.
However, we are instead passing the stack pointer *after* allocating a
stack frame in ftrace_caller. Fix this by saving the proper value of r1
in pt_regs. Als
This fixes a crash when function_graph and jprobes are used together.
This is essentially commit 237d28db036e ("ftrace/jprobes/x86: Fix
conflict between jprobes and function graph tracing"), but for powerpc.
Jprobes breaks function_graph tracing since the jprobe hook needs to use
jprobe_return(),
[Reposting this as I missed copying the distribution list in my
previous posting. For those who were copied previously, sorry for the spam]
This series initially started out as a fix for a single bug I found:
kernel Oops when jprobes is used with the function_graph tracer. Though
that particular b
[Copying linuxppc-dev list which I missed cc'ing initially]
On 2017/05/03 03:58PM, Steven Rostedt wrote:
> On Wed, 3 May 2017 23:43:41 +0530
> "Naveen N. Rao" wrote:
>
> > This fixes a crash when function_graph and jprobes are used together.
> > This is essentially commit 237d28db036e ("ftrace/
On Wed, 2017-05-03 at 04:44:59 UTC, Michael Ellerman wrote:
> Currently the radix TLB code includes support for CPUs that do *not*
> have MMU_FTR_LOCKLESS_TLBIE. On those CPUs we are required to take a
> global spinlock before issuing a tlbie.
>
> Radix can only be built for 64-bit Book3s CPUs, an
On Wed, 2017-05-03 at 03:24:08 UTC, Alistair Popple wrote:
> Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on
> NVLink2") forced all TCE kills to go via the OPAL call for
> NVLink2. However the PHB3 implementation of TCE kill was still being
> called directly from some functions
On Mon, 2017-05-01 at 00:53:31 UTC, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In some situations, a faulty AFU slice may create an interrupt storm of
> slice errors, rendering the machine unusable. Since these interrupts are
> informational only, present the interrupt once, then mask i
On Thu, 2017-04-27 at 05:28:22 UTC, Vaibhav Jain wrote:
> Fix a boundary condition where in some cases an eeh event that results
> in card reset isn't passed on to a driver attached to the virtual PCI
> device associated with a slice. This will happen in case when a slice
> attached device driver r
On Thu, 2017-04-27 at 05:23:25 UTC, Vaibhav Jain wrote:
> During an eeh event when the cxl card is fenced and card sysfs attr
> perst_reloads_same_image is set following warning message is seen in the
> kernel logs:
>
> [ 60.622727] Adapter context unlocked with 0 active contexts
> [ 60.6227
On Mon, 2017-04-24 at 10:46:59 UTC, Michael Ellerman wrote:
> The entire body of unregister_cpu_online() is inside an #ifdef
> CONFIG_HOTPLUG_CPU block. This is ugly and means we create an empty function
> when hotplug is disabled for no reason.
>
> Instead move the #ifdef out of the function body
On Wed, 2017-04-19 at 07:39:27 UTC, Russell Currey wrote:
> Remove unnecessary tags in eeh_handle_normal_event(), and add function
> comments for eeh_handle_normal_event() and eeh_handle_special_event().
>
> The only functional difference is that in the case of a PE reaching the
> maximum number o
On Wed, 2017-04-19 at 07:39:26 UTC, Russell Currey wrote:
> eeh_handle_special_event() is called when an EEH event is detected but
> can't be narrowed down to a specific PE. This function looks through
> every PE to find one in an erroneous state, then calls the regular event
> handler eeh_handle_
On Tue, 2017-04-18 at 19:12:17 UTC, Nicholas Piggin wrote:
> POWER9/ISAv3 has no VRMASD field in LPCR. Don't set reserved bits.
>
> Signed-off-by: Nicholas Piggin
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/700b7eadd5625d22b8235fb21259b3
cheers
On Tue, 2017-04-18 at 16:38:17 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> machine_check_early() gets called in real mode. The very first time when
> add_taint() is called, it prints a warning which ends up calling opal
> call (that uses OPAL_CALL wrapper) for writing it to consol
On Thu, 2017-03-16 at 03:04:40 UTC, Michael Neuling wrote:
> Currently if we oops caused by an 0x380 or 0x480 exception, we get a
> print which assumes SLB problems. With radix, these vectors have
> different meanings.
>
> This patch updates the oops message to reflect these different
> meanings.
On Fri, 2017-02-17 at 06:31:22 UTC, Michael Ellerman wrote:
> Otherwise we might select it when its dependenices aren't enabled,
> leading to a build break.
>
> It's default y anyway, so will be on unless someone disables it
> manually.
>
> Signed-off-by: Michael Ellerman
Applied to powerpc nex
On Wed, 2017-02-15 at 09:49:54 UTC, Michael Ellerman wrote:
> This code is undocumented and unclear, and we've already had one patch
> sent to remove it because it's "paradoxical and unnecessary". So
> document it to save our future selves from puzzling over it.
>
> Signed-off-by: Michael Ellerman
On Wed, 2016-10-19 at 03:16:00 UTC, Nicholas Piggin wrote:
> This is cruft to work around allmodconfig build breakage.
>
> Signed-off-by: Nicholas Piggin
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/084a275e4c9477c432b05e872c3a29
cheers
On Fri, 2016-07-22 at 07:16:35 UTC, Andrew Donnellan wrote:
> pnv_eeh_reset() has special handling for PEs whose primary bus is the root
> bus or the bus immediately underneath the root port.
>
> The cxl bi-modal card support added in b0b5e5918ad1 ("cxl: Add
> cxl_check_and_switch_mode() API to sw
With the introduction of 'fadump_append=' parameter to pass additional
parameters to fadump (capture) kernel, update documentation about it.
Signed-off-by: Hari Bathini
---
Changes from v4:
* Based on top of patchset that includes
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex
With fadump (dump capture) kernel booting like a regular kernel, it almost
needs the same amount of memory to boot as the production kernel, which is
unwarranted for a dump capture kernel. But with no option to disable some
of the unnecessary subsystems in fadump kernel, that much memory is wasted
On Wed, 2017-05-03 at 20:26 +1000, Michael Ellerman wrote:
> Couldn't we avoid the whole problem by just having two bolted slots for
> the stack, meaning we could have the current and next stack bolted at
> all times.
>
> That would mean we'd be using 4 slots for bolted entries, which is one
> mor
Hi Dave,
Thank you for the review. I will address your comment and update patchset..
Pasha
On 05/03/2017 10:34 AM, David Miller wrote:
From: Pavel Tatashin
Date: Fri, 24 Mar 2017 15:19:50 -0400
Allow clients to request non-zeroed memory from vmemmap allocator.
The following two public funct
From: Pavel Tatashin
Date: Fri, 24 Mar 2017 15:19:50 -0400
> Allow clients to request non-zeroed memory from vmemmap allocator.
> The following two public function have a new boolean argument called zero:
>
> __vmemmap_alloc_block_buf()
> vmemmap_alloc_block()
>
> When zero is true, memory that
capi2 and opencapi require the TLB invalidations being sent for
addresses used on the cxl adapter or opencapi device to be global, as
there's a translation cache in the PSL (for capi2) or NPU (for
opencapi). The CAPP (for PSL) and NPU snoop the power bus.
This is not new: for the hash memory model
The PSL needs to see all TLBI pertinent to the memory contexts used on
the cxl adapter. For the hash memory model, it was done by making all
TLBIs global as soon as the cxl driver is in us. For radix, we need
something similar, but we can refine and only convert to global the
invalidations for cont
Introduce a new 'flags' attribute per context and define its first bit
to be a marker requiring all TLBIs for that context to be broadcasted
globally. Once that marker is set on a context, it cannot be removed.
Such a marker is useful for memory contexts used by devices behind the
NPU and CAPP/PSL
On 05/03/2017 09:22 AM, Rashmica Gupta wrote:
> On 28/04/17 19:52, Anshuman Khandual wrote:
>> On 04/28/2017 11:12 AM, Rashmica Gupta wrote:
>>> Some powerpc hardware features may want to gain access to a chunk of
>> What kind of features ? Please add specifics.
>>
>>> undisturbed real memory. Thi
On 05/03/2017 11:38 AM, Rashmica Gupta wrote:
>
>
> On 03/05/17 13:52, Rashmica Gupta wrote:
>> On 28/04/17 19:52, Anshuman Khandual wrote:
>>
+static int check_memblock_online(struct memory_block *mem, void *arg)
+{
+if (mem->state != MEM_ONLINE)
+return -1;
On 05/03/2017 03:02 PM, Michael Ellerman wrote:
> Anshuman Khandual writes:
>
>> This is a trivial fix patch regarding mapped ranges in radix MMU
>> environment during boot. No functional change.
>>
>> Before the patch:
>>
>> $dmesg | grep Mapped
>> [0.00] Mapped range 0x0 - 0x20
Benjamin Herrenschmidt writes:
> On Wed, 2017-05-03 at 17:34 +1000, Nicholas Piggin wrote:
>> Extending the soft IRQ disable to cover PMU interrupts will allow this
>> hard disable to be removed from hash based kernels too, but they will
>> still have to soft-disable PMU interrupts.
>>
>> - Q1:
Hi Stephen,
On Wed, May 03, 2017 at 07:15:24PM +1000, Stephen Rothwell wrote:
> It looks like there is at least one more:
>
> drivers/soc/fsl/qbman/qman.c: In function 'qman_init_fq':
> drivers/soc/fsl/qbman/qman.c:1787:4: error: implicit declaration of function
> 'dma_map_single' [-Werror=impli
Anshuman Khandual writes:
> This is a trivial fix patch regarding mapped ranges in radix MMU
> environment during boot. No functional change.
>
> Before the patch:
>
> $dmesg | grep Mapped
> [0.00] Mapped range 0x0 - 0x20 with 0x4000
> [0.00] Mapped range 0x200
On Wed, 03 May 2017 10:28:27 +0200
Benjamin Herrenschmidt wrote:
> On Wed, 2017-05-03 at 17:34 +1000, Nicholas Piggin wrote:
> > Extending the soft IRQ disable to cover PMU interrupts will allow this
> > hard disable to be removed from hash based kernels too, but they will
> > still have to soft-
Hi Paul,
On Tue, May 02, 2017 at 06:21:12PM -0400, Paul Gortmaker wrote:
> In commit 461a6946b1f9 ("iommu: Remove pci.h include from
> trace/events/iommu.h") that header shuffle uncovered an implicit
> include in this driver, manifesting as:
>
> CC drivers/soc/fsl/qbman/qman_portal.o
>
Hi Joerg,
On Wed, 3 May 2017 10:42:40 +0200 Joerg Roedel wrote:
>
> On Tue, May 02, 2017 at 06:21:12PM -0400, Paul Gortmaker wrote:
> > In commit 461a6946b1f9 ("iommu: Remove pci.h include from
> > trace/events/iommu.h") that header shuffle uncovered an implicit
> > include in this driver, manife
On Wednesday 03 May 2017 12:43 PM, Hari Bathini wrote:
On Tuesday 02 May 2017 09:26 PM, Michal Suchanek wrote:
With fadump (dump capture) kernel booting like a regular kernel, it
almost
needs the same amount of memory to boot as the production kernel,
which is
unwarranted for a dump capture
On Wed, 2017-05-03 at 17:34 +1000, Nicholas Piggin wrote:
> Extending the soft IRQ disable to cover PMU interrupts will allow this
> hard disable to be removed from hash based kernels too, but they will
> still have to soft-disable PMU interrupts.
>
> - Q1: Can we do this? It gives nice profiles o
Commit 4387e9ff25 ("[POWERPC] Fix PMU + soft interrupt disable bug")
hard disabled interrupts over the low level context switch, because
the SLB management can't cope with a PMU interrupt accesing the stack
in that window.
Radix based kernel mapping does not use the SLB so it does not require
inte
On Tuesday 02 May 2017 09:26 PM, Michal Suchanek wrote:
With fadump (dump capture) kernel booting like a regular kernel, it almost
needs the same amount of memory to boot as the production kernel, which is
unwarranted for a dump capture kernel. But with no option to disable some
of the unnecess
50 matches
Mail list logo
