Hi,
On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:
Anju T Sudhakar writes:
Call trace observed during boot:
What's the actual oops?
The actual oops is:
[0.750749] PCI: CLS 0 bytes, default 128
[0.750855] Unpacking initramfs...
[1.570445] Freeing initrd memory
Acked-by: Minghuan Lian
> -Original Message-
> From: Bao Xiaowei [mailto:xiaowei@nxp.com]
> Sent: Tuesday, October 24, 2017 4:31 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Madalin-crist
Hi Xiaowei,
Please see my comments inline.
> -Original Message-
> From: Bao Xiaowei [mailto:xiaowei@nxp.com]
> Sent: Tuesday, October 24, 2017 4:31 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; bhelg...@google.com; shawn...@kernel.o
Acked-by: Minghuan Lian
> -Original Message-
> From: Bao Xiaowei [mailto:xiaowei@nxp.com]
> Sent: Tuesday, October 24, 2017 4:31 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Madalin-crist
On 01/11/17 17:09, Thomas Gleixner wrote:
> On Wed, 1 Nov 2017, Qiang Zhao wrote:
>> Michael Ellerman wrote
>>>
>>> Qiang Zhao writes:
>>>
Hi all,
Could anybody review this patchset and take action on them? Thank you!
>>>
>>> Who maintains this? I don't actually know, it's not powe
On Wed, 1 Nov 2017, Oleg Nesterov wrote:
> On 11/01, Petr Mladek wrote:
> >
> > On Tue 2017-10-31 12:48:52, Miroslav Benes wrote:
> > > + if (task->flags & PF_KTHREAD) {
> > > + /*
> > > + * Wake up a kthread which still has not been migrated.
> > > +
/commits/Balbir-Singh/powerpc-xmon-Support-dumping-software-pagetables/20171102-071230
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-currituck_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce
On Mon, 2017-10-30 at 15:12:08 UTC, "Naveen N. Rao" wrote:
> This reverts commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference
> function descriptor for non-text symbols").
>
> Chandan reported that on newer kernels, trying to enable function_graph
> tracer on ppc64 (BE) locks up the system w
On Mon, 2017-10-30 at 15:12:09 UTC, "Naveen N. Rao" wrote:
> This makes the changes introduced in commit 83e840c770f2c5
> ("powerpc64/elfv1: Only dereference function descriptor for non-text
> symbols") to be specific to the kprobe subsystem.
>
> We previously changed ppc_function_entry() to alway
From: Madhavan Srinivasan
Call trace observed during boot:
[0.750749] PCI: CLS 0 bytes, default 128
[0.750855] Unpacking initramfs...
[1.570445] Freeing initrd memory: 23168K
[1.571090] rtas_flash: no firmware flash support
[1.573873] nest_capp0_imc performance monitor hardwa
fsp2 board setup with l2 setup and irq handlers
for some critical exceptions.
Ivan Mikhaylov (4):
44x/fsp2: add fsp2 headers
44x/fsp2: l2 setup with error clear
44x/fsp2: tvsense workaround for dd1
44x/fsp2: add irq error handlers
arch/powerpc/include/asm/fsp2_reg.h | 272 +
* add cmu, plbX, l2 register definitions
Signed-off-by: Ivan Mikhaylov
---
arch/powerpc/include/asm/fsp2_reg.h | 272 +++
1 files changed, 272 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsp2_reg.h
diff --git a/arch/powerpc/include
Signed-off-by: Ivan Mikhaylov
---
arch/powerpc/platforms/44x/fsp2.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/44x/fsp2.c
b/arch/powerpc/platforms/44x/fsp2.c
index 92e9804..9585725 100644
--- a/arch/powerpc
* tvsense(temperature and voltage sensors) may provide
erratic sense values which may result in parity errors
on CMU.
Signed-off-by: Ivan Mikhaylov
---
arch/powerpc/platforms/44x/fsp2.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/pla
* add irq error handlers for cmu, plb, opb, mcue, conf
with debug information output in case of problem.
Signed-off-by: Ivan Mikhaylov
---
arch/powerpc/platforms/44x/fsp2.c | 204 -
1 files changed, 203 insertions(+), 1 deletions(-)
diff --git a/arch/power
On Tue, Oct 31, 2017 at 12:48:52PM +0100, Miroslav Benes wrote:
> +
> +/*
> + * Sends a fake signal to all non-kthread tasks with TIF_PATCH_PENDING set.
> + * Kthreads with TIF_PATCH_PENDING set are woken up. Only admin can request
> this
> + * action currently.
> + */
> +void klp_force_signals(vo
On Tue, Oct 31, 2017 at 12:48:52PM +0100, Miroslav Benes wrote:
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index bf8c8fd72589..b7c60662baf3 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -440,6 +440,7 @@ EXPORT_SYMBOL_GPL(klp_enable_patch);
> *
On 11/02, Miroslav Benes wrote:
>
> On Wed, 1 Nov 2017, Oleg Nesterov wrote:
>
> > Note also that wake_up_state(TASK_INTERRUPTIBLE) won't wakeup the TASK_IDLE
> > kthreads, and most of the kthreads which use TASK_INTERRUPTIBLE should use
> > TASK_IDLE today, because in most cases TASK_INTERRUPTIBLE
On 26/10/2017 10:14, kemi wrote:
> Some regression is found by LKP-tools(linux kernel performance) on this patch
> series
> tested on Intel 2s/4s Skylake platform.
> The regression result is sorted by the metric will-it-scale.per_process_ops.
Hi Kemi,
Thanks for reporting this, I'll try to addr
Hi Andrea,
Thanks for reviewing this series, and sorry for the late answer, I took few
days off...
On 26/10/2017 12:18, Andrea Arcangeli wrote:
> Hello Laurent,
>
> Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea...@intel.com> shows
> significant slowdown even for brk/malloc ops both single and
>
On 02/11/2017 16:16, Laurent Dufour wrote:
> Hi Andrea,
>
> Thanks for reviewing this series, and sorry for the late answer, I took few
> days off...
>
> On 26/10/2017 12:18, Andrea Arcangeli wrote:
>> Hello Laurent,
>>
>> Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea...@intel.com> shows
>> si
On Thu, Nov 02, 2017 at 06:25:11PM +0100, Laurent Dufour wrote:
> I think there is some memory barrier missing when the VMA is modified so
> currently the modifications done in the VMA structure may not be written
> down at the time the pte is locked. So doing that change will also requires
> to ca
The migration of LPARs across Power systems affects many attributes
including that of the associativity of memory blocks and CPUs. The
patches in this set are intended to recognize changes to that associativity
as represented by various device-tree properties, and generate calls
to other code laye
hotplug/memory: Recognize more changes to the associativity of memory
blocks described by the 'ibm,dynamic-memory' property regarding the
topology of LPARS in Post Migration events. Previous efforts only
recognized whether a block's assignment had changed in the property.
Topology migration requir
powerpc/hotplug/memory: In an LPAR migration scenario, the property
"ibm,associativity-lookup-arrays" may change. In the event that a
row of the array differs, locate all assigned memory blocks with that
'aa_index' and 're-add' them to the system memory block data structures.
In the process of the
powerpc/hotplug/memory: Apply changes to the associativity of memory
blocks described by the 'ibm,dynamic-memory-v2' property regarding
the topology of LPARS in Post Migration events. Previous efforts
only recognized whether a block's assignment had changed in the
property. Topology migration req
The QS21/22 IBM Cell blades had a southbridge chip called Axon. This
could have DDR DIMMs attached to it, though they were not directly
usable as RAM, instead they could be used as some sort of buffer, if
applications were written specifically to use the block device
provided by the driver.
Althou
Madhavan Srinivasan writes:
> On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:
>> Anju T Sudhakar writes:
>>
>>> Call trace observed during boot:
>> What's the actual oops?
>
> I could recreate this in mambo with CPUS=2 and THREAD=2
That boots fine for me.
Presumably you've also
On Thu, 2017-11-02 at 12:12:26 UTC, Anju T Sudhakar wrote:
> From: Madhavan Srinivasan
>
> Call trace observed during boot:
>
> [0.750749] PCI: CLS 0 bytes, default 128
> [0.750855] Unpacking initramfs...
> [1.570445] Freeing initrd memory: 23168K
> [1.571090] rtas_flash: no firm
On Thu, 2017-11-02 at 12:55 +1100, Nicholas Piggin wrote:
> DD2.1 does not have to flush the ERAT after a state-loss idle. It also
> does not have to save and restore MMCR0 (although it does have to save
> restore in deep idle states, like other PMU registers).
Minor nit, can we do this as two sep
BUG_ON() should be reserved in situations where we can not longer
guarantee the integrity of the system. In the case where
powernv_flash_async_op() receives an impossible op, we can still
guarantee the integrity of the system.
Signed-off-by: Cyril Bur
Acked-by: Boris Brezillon
---
drivers/mtd/d
Because the MTD core might split up a read() or write() from userspace
into several calls to the driver, we may fail to get a token but already
have done some work, best to return -EINTR back to userspace and have
them decide what to do.
Signed-off-by: Cyril Bur
Acked-by: Boris Brezillon
---
dr
Also export opal_error_code() so that it can be used in modules
Signed-off-by: Cyril Bur
---
arch/powerpc/platforms/powernv/opal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 65c79ecf5a4d..041ddbd1fc57
From: Stewart Smith
Parallel sensor reads could run out of async tokens due to
opal_get_sensor_data grabbing tokens but then doing the sensor
read behind a mutex, essentially serializing the (possibly
asynchronous and relatively slow) sensor read.
It turns out that the mutex isn't needed at all,
There are no callers of both __opal_async_get_token() and
__opal_async_release_token().
This patch also removes the possibility of "emergency through
synchronous call to __opal_async_get_token()" as such it makes more
sense to initialise opal_sync_sem for the maximum number of async
tokens.
Signe
V5: Address review from Boris Brezillon, thanks!
Minor cleanups and descriptions - no functional changes.
V4: Rework and rethink.
To recap:
Userspace MTD read()s/write()s and erases to powernv_flash become
calls into the OPAL firmware which subsequently handles flash access.
Because the read()s,
While this driver expects to interact asynchronously, OPAL is well
within its rights to return OPAL_SUCCESS to indicate that the operation
completed without the need for a callback. We shouldn't treat
OPAL_SUCCESS as an error rather we should wrap up and return promptly to
the caller.
Signed-off-b
This patch adds an _interruptible version of opal_async_wait_response().
This is useful when a long running OPAL call is performed on behalf of a
userspace thread, for example, the opal_flash_{read,write,erase}
functions performed by the powernv-flash MTD driver.
It is foreseeable that these funct
Future work will add an opal_async_wait_response_interruptible()
which will call wait_event_interruptible(). This work requires extra
token state to be tracked as wait_event_interruptible() can return and
the caller could release the token before OPAL responds.
Currently token state is tracked wit
powernv_flash_probe() has pointless goto statements which jump to the
end of the function to simply return a variable. Rather than checking
for error and going to the label, just return the error as soon as it is
detected.
Signed-off-by: Cyril Bur
Acked-by: Boris Brezillon
---
drivers/mtd/devic
The OPAL calls performed in this driver shouldn't be using
opal_async_wait_response() as this performs a wait_event() which, on
long running OPAL calls could result in hung task warnings. wait_event()
prevents timely signal delivery which is also undesirable.
This patch also attempts to quieten do
On Friday 03 November 2017 05:49 AM, Michael Ellerman wrote:
Madhavan Srinivasan writes:
On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:
Anju T Sudhakar writes:
Call trace observed during boot:
What's the actual oops?
I could recreate this in mambo with CPUS=2 and THREA
Since v2: Split up the features into two patches.
I kept Vaidy's reviewed-by because the end result code was not changed.
Nicholas Piggin (3):
powerpc: add POWER9_DD20 feature
powerpc/64s/idle: avoid POWER9 DD1 and DD2.0 ERAT workaround on DD2.1
powerpc/64s/idle: avoid POWER9 DD1 and DD2.0
Cc: Michael Neuling
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/cputable.h | 5 -
arch/powerpc/kernel/cputable.c | 20
arch/powerpc/kernel/dt_cpu_ftrs.c | 2 ++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/a
DD2.1 does not have to flush the ERAT after a state-loss idle.
Performance testing was done on a DD2.1 using only the stop0 idle state
(the shallowest state which supports state loss), using context_switch
selftest configured to ping-poing between two threads on the same core
and two different cor
DD2.1 does not have to save MMCR0 for all state-loss idle states,
only after deep idle states (like other PMU registers).
Reviewed-by: Vaidyanathan Srinivasan
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/idle_book3s.S | 31 +++
1 file changed, 19 insertions
On Fri, 03 Nov 2017 12:13:19 +1100
Michael Neuling wrote:
> On Thu, 2017-11-02 at 12:55 +1100, Nicholas Piggin wrote:
> > DD2.1 does not have to flush the ERAT after a state-loss idle. It also
> > does not have to save and restore MMCR0 (although it does have to save
> > restore in deep idle stat
If the host takes a system reset interrupt while a guest is running,
the CPU must exit the guest before processing the host exception
handler.
After this patch, taking a sysrq+x with a CPU running in a guest
gives a trace like this:
cpu 0x27: Vector: 100 (System Reset) at [c00fdf5776f0]
On Fri, Nov 03, 2017 at 03:38:03PM +1100, Nicholas Piggin wrote:
> If the host takes a system reset interrupt while a guest is running,
> the CPU must exit the guest before processing the host exception
> handler.
>
> After this patch, taking a sysrq+x with a CPU running in a guest
> gives a trace
On Friday 03 November 2017 05:49 AM, Michael Ellerman wrote:
Madhavan Srinivasan writes:
On Wednesday 01 November 2017 06:22 AM, Michael Ellerman wrote:
Anju T Sudhakar writes:
Call trace observed during boot:
What's the actual oops?
I could recreate this in mambo with CPUS=2 and THREA
50 matches
Mail list logo
