From: Paul Mackerras
Signed-off-by: Paul Mackerras
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/powerpc/mm/Makefile | 2 +-
tools/testing/selftests/powerpc/mm/subpage_prot.c | 201 ++
2 files changed, 202 insertions(+), 1 deletion(-)
create mode 1006
This one should go to stable - this was the first bug uncovered after
fixing the sleep while atomic and force unbinding the driver.
Cheers,
-Ian
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
> From: Ian Munsie
>
> If we need to force detach a context (e.g. due to EEH or simpl
This one would be nice to go to stable, but I'm not sure it really meets
the rules. It could be a problem for userspace error paths checking the
result of MMIO reads, but only if the AFU has actually been unexpectedly
disabled somehow yet the PSL is still responding...
I don't think this is a high
This one would be nice to go to stable, but I'm not sure if it's
critical enough to justify it since it only reduces the number of
available interrupts (and therefore, contexts) that can be used by the
card (so, maybe you can only run 507 contexts simultaneously instead of
509)...
Cheers,
-Ian
__
This one needs to go to stable - I've hit it a couple of times while
testing bad AFUs and it results in an unkillable process.
Cheers,
-Ian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sun, 2014-12-07 at 23:31 +0100, Rickard Strandqvist wrote:
> Remove the function cmo_high_show() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> arch/powerpc/kernel/vio.c |5
This patch will definitely need to go to stable - we've run into issues
a couple of times when something has gone wrong on an AFU and ended up
taking down the whole system as a result of this bug.
Cheers,
-Ian
___
Linuxppc-dev mailing list
Linuxppc-dev@
On Fri, 2014-12-05 at 12:52 -0600, Scott Wood wrote:
> On Fri, 2014-12-05 at 16:14 +0100, Greg Kurz wrote:
> > The smt-enabled kernel parameter basically leaves unwanted cpus executing
> > in firmware or wherever they happen to be. The very same applies to the
> > ibm,smt-enabled DT property which
On 12/08/2014 09:54 PM, Steven Rostedt wrote:
> On Mon, 8 Dec 2014 14:27:01 +1100
> Anton Blanchard wrote:
>
>> I have a busy ppc64le KVM box where guests sometimes hit the infamous
>> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>>
>> BUG_ON(td->cpu != smp_processor_id());
>>
>> Bas
On Thu, Dec 04, 2014 at 09:51:59PM -0600, Scott Wood wrote:
> This patch is going to conflict with commit a4ae8f3b0f7ac6ab3 "clk: drop
> owner assignment from platform_drivers" in linux-next -- or rather,
> you've based this on that patch, but it's not in mpe's next branch, so I
> get a merge confl
Hi Ingo,
> At that point I thought the previous task_cpu() was somewhat ingrained
> in the scheduler and came up with the patch. If not, we could go on a
> hunt to see what else needs fixing.
I had another look. The scheduled does indeed make assumptions about the
previous task_cpu, but we have a
On Mon, 2014-12-08 at 21:55 +0100, Wolfram Sang wrote:
> On Tue, Dec 09, 2014 at 07:13:15AM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote:
> > > The patch exposes the available i2c busses on the PowerNV platform
> > > to the kernel and implements th
On Mon, 2014-12-08 at 09:23 +0100, Greg Kurz wrote:
> On Fri, 5 Dec 2014 12:52:45 -0600
> Scott Wood wrote:
>
> > On Fri, 2014-12-05 at 16:14 +0100, Greg Kurz wrote:
> > > The smt-enabled kernel parameter basically leaves unwanted cpus executing
> > > in firmware or wherever they happen to be. Th
On Monday 08 December 2014 11:22 AM, Paul Mackerras wrote:
> On Thu, Dec 04, 2014 at 12:58:23PM +0530, Shreyas B. Prabhu wrote:
>> Winkle is a deep idle state supported in power8 chips. A core enters
>> winkle when all the threads of the core enter winkle. In this state
>> power supply to the ent
On Tue, Dec 09, 2014 at 07:13:15AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote:
> > The patch exposes the available i2c busses on the PowerNV platform
> > to the kernel and implements the bus driver to support i2c and
> > smbus commands.
> > The dri
On Monday, December 08, 2014 12:59:32 PM Richard Guy Briggs wrote:
> Since both ppc and ppc64 have LE variants which are now reported by uname,
> add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add
> AUDIT_ARCH_PPC*LE variants.
>
> Without this, perf trace and auditctl fail.
>
> Mainli
On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote:
> The patch exposes the available i2c busses on the PowerNV platform
> to the kernel and implements the bus driver to support i2c and
> smbus commands.
> The driver uses the platform device infrastructure to probe the busses
> on the platform
On Mon, 2014-12-08 at 09:21 -0600, Nathan Fontenot wrote:
> > Oh I was hoping you would not say that :(
>
> Heh! hint taken. I won't cc you.
>
> >
> > Seriously? Parsing binary blobs from userspace? Don't do that, you
> > know better.
>
> Yes, not ideal. One thing to note here is that the cod
Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.
Without this, perf trace and auditctl fail.
Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64
Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.
Without this, perf trace and auditctl fail.
Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64
On 12/03/2014 10:31 PM, Greg KH wrote:
> On Wed, Dec 03, 2014 at 09:07:27PM -0600, Nathan Fontenot wrote:
>> On 12/01/2014 10:26 PM, Greg KH wrote:
>>> On Mon, Dec 01, 2014 at 09:41:03AM -0600, Nathan Fontenot wrote:
On 11/26/2014 09:12 PM, Benjamin Herrenschmidt wrote:
> Hi Greg,
>
>>
This patch fixes a section mismatch warning
WARNING: vmlinux.o(.text+0x213b6): Section mismatch in reference from the
function chrp_init_early() to the variable .init.data:boot_command_line
The function chrp_init_early() references
the variable __initdata boot_command_line.
This is often because
Compilation with #define STRICT_MM_TYPECHECKS in arch/powerpc/include/asm/page.h
fails due to missing use of pgprot_val() when using pgprot_t objects.
arch/powerpc/mm/pgtable_32.c: In function '__ioremap_caller':
arch/powerpc/mm/pgtable_32.c:185:9: error: invalid operands to binary | (have
'long
On Mon, 8 Dec 2014 14:27:01 +1100
Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the infamous
> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong C
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep idle states. The commit expected the platforms to
register for this mode explicitly when they lacked a better external device
to w
On Mon, Dec 08, 2014 at 12:02:55PM +, Preeti U Murthy wrote:
> On 12/08/2014 04:18 PM, Mark Rutland wrote:
> > Hi Preeti,
> >
> > On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote:
> >> Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
> >> hrtimer based bro
On 12/08/2014 04:18 PM, Mark Rutland wrote:
> Hi Preeti,
>
> On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote:
>> Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
>> hrtimer based broadcast mode for those platforms in which local timers stop
>> when CPUs enter
Am 08.12.2014 um 12:26 schrieb Stephen Rothwell:
> Hi Christian,
>
> After merging the acess_once tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> arch/powerpc/mm/hugetlbpage.c: In function 'find_linux_pte_or_hugepte':
> arch/powerpc/mm/hugetlbpage.c:981:3: error: inva
Hi Christian,
After merging the acess_once tree, today's linux-next build (powerpc
allnoconfig) failed like this:
arch/powerpc/mm/hugetlbpage.c: In function 'find_linux_pte_or_hugepte':
arch/powerpc/mm/hugetlbpage.c:981:3: error: invalid initializer
pud = ACCESS_ONCE(*pudp);
^
arch/powerpc
On Sat, Dec 06, 2014 at 11:37:24PM -0800, Sukadev Bhattiprolu wrote:
> Jiri Olsa [jo...@redhat.com] wrote:
>
> | anyway we could assign directly to the param term name as you do,
> | but I think we just need to mark the term as parametrized, like:
> |
> | in /sys/bus/event_source/devices/pmu/even
Hi Preeti,
On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote:
> Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
> hrtimer based broadcast mode for those platforms in which local timers stop
> when CPUs enter deep idle states. The commit expected the platforms
From: Kumar Gala
Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
Signed-off-by: Chunhe Lan
Signed-off-by: Poonam Aggrwal
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
---
arch/p
From: Kumar Gala
Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
Signed-off-by: Chunhe Lan
Signed-off-by: Poonam Aggrwal
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
---
arch/p
From: Kumar Gala
Change-Id: I16e63db731e55a3d60d4e147573c1af8718082d3
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
---
arch/powerpc/boot/dts/fsl/qoriq-bman1-portals.dtsi | 90
From: Kumar Gala
Change-Id: I16e63db731e55a3d60d4e147573c1af8718082d3
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
---
arch/powerpc/boot/dts/fsl/qoriq-qman1-portals.dtsi | 101 +++
This supports SoC(s) with multiple B/QMan instances
Signed-off-by: Emil Medve
---
Documentation/devicetree/bindings/soc/fsl/bman.txt | 10 ++
Documentation/devicetree/bindings/soc/fsl/qman.txt | 10 ++
2 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindi
'ranges' are specified as not as
Signed-off-by: Emil Medve
---
Documentation/devicetree/bindings/soc/fsl/bman.txt | 2 +-
Documentation/devicetree/bindings/soc/fsl/qman.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.t
v5: Fix the alloc-ranges property
Factorize the SoC specific reserved-memory properties
v4: Add binding for the portals phandle
Fix portals phandle
v3: Remove no-map
Adjust alloc-ranges for the 32-/36-bit SoC(s)
v2: Remove some reserved-memory properties
On Mon, Dec 8, 2014 at 11:24 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v3.18[1] to v3.18-rc7[3], the summaries are:
> - build errors: +13/-11
(ignoring non-interesting things)
+ /home/kisskb/slave/src/arch/powerpc/lib/sstep.c: error: 'do_lfd'
undeclared (first use in this functio
Hi Ingo,
> So we cannot call set_task_cpu() because in the normal life time
> of a task the ->cpu value gets set on wakeup. So if a task is
> blocked right now, and its affinity changes, it ought to get a
> correct ->cpu selected on wakeup. The affinity mask and the
> current value of ->cpu g
On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>> This patch adds four new ELF core note sections for powerpc
>>> transactional memory and one new ELF core note section for
>>> power
* Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the
> infamous "kernel BUG at kernel/smpboot.c:134!" issue during
> boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
> output confir
On Fri, 5 Dec 2014 12:52:45 -0600
Scott Wood wrote:
> On Fri, 2014-12-05 at 16:14 +0100, Greg Kurz wrote:
> > The smt-enabled kernel parameter basically leaves unwanted cpus executing
> > in firmware or wherever they happen to be. The very same applies to the
> > ibm,smt-enabled DT property which
From: Ian Munsie
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO region further, which
they may have mapped with mmap().
This patch unmaps any mapped MMIO re
From: Ian Munsie
In this particular error path we have already allocated the AFU
interrupts, but have not yet set the status to STARTED. The detach
context code will only attempt to release the interrupts if the context
is in state STARTED, so in this case the interrupts would remain
allocated.
From: Ian Munsie
When we deactivate the AFU directed mode we free the scheduled process
area, but did not clear the register in the hardware that has a pointer
to it.
This should be fine since we will have already cleared out every context
and we won't do anything that would cause the hardware t
From: Ian Munsie
Upon inspection of the implementation specific registers, it was
discovered that the high bit of the implementation specific RXCTL
register was enabled, which enables the DEADB00F debug feature.
The debug feature causes MMIO reads to a disabled AFU to respond with
0xDEADB00F ins
From: Ian Munsie
If a context is being detached and we get a translation fault for it
there is little point getting it's mm and handling the fault, so just
respond with an address error and return earlier.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/fault.c | 6 ++
1 file changed, 6 ins
From: Ian Munsie
In the event that something goes wrong in the hardware and it is unable
to complete a process element comment we would end up polling forever,
effectively making the associated process unkillable.
This patch adds a timeout to the process element command code path, so
that we wil
From: Ian Munsie
We had a known sleep while atomic bug if a CXL device was forcefully
unbound while it was in use. This could occur as a result of EEH, or
manually induced with something like this while the device was in use:
echo :01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind
The issue was
50 matches
Mail list logo
