On 02/09/15 00:24, Paul Mackerras wrote:
> On Tue, Sep 01, 2015 at 11:41:18PM +0200, Thomas Huth wrote:
>> The size of the Problem State Priority Boost Register is only
>> 32 bits, so let's change the type of the corresponding variable
>> accordingly to avoid future trouble.
>
> Since we're alread
On 02/09/15 00:55, Benjamin Herrenschmidt wrote:
> On Wed, 2015-09-02 at 08:45 +1000, Paul Mackerras wrote:
>> On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt
>> wrote:
>>> On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
The size of the Problem State Priority Boost Regis
> Am 02.09.2015 um 09:26 schrieb Thomas Huth :
>
>> On 02/09/15 00:55, Benjamin Herrenschmidt wrote:
>>> On Wed, 2015-09-02 at 08:45 +1000, Paul Mackerras wrote:
>>> On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt
>>> wrote:
On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wr
On 02/09/15 10:26, Alexander Graf wrote:
>
>> Am 02.09.2015 um 09:26 schrieb Thomas Huth :
>>
>>> On 02/09/15 00:55, Benjamin Herrenschmidt wrote:
On Wed, 2015-09-02 at 08:45 +1000, Paul Mackerras wrote:
On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt
wrote:
> O
On 09/02/2015 11:11 AM, Nishanth Aravamudan wrote:
When attempting to kdump with the 4.2 kernel, we see for each PCI
device:
pci 0003:01 : [PE# 000] Assign DMA32 space
pci 0003:01 : [PE# 000] Setting up 32-bit TCE table at 0..8000
pci 0003:01 : [PE# 000] Failed to create 32
The size of the Problem State Priority Boost Register is only
32 bits, but the kvm_vcpu_arch->pspb variable is declared as
"ulong", ie. 64-bit. However, the assembler code accesses this
variable with 32-bit accesses, and the KVM_REG_PPC_PSPB macro
is defined with SIZE_U32, too, so that the current
Hi Paul,
On Tue, Sep 01, 2015 at 10:45:40PM +0100, Paul E. McKenney wrote:
> On Tue, Sep 01, 2015 at 08:00:27PM +0100, Will Deacon wrote:
> > On Fri, Aug 28, 2015 at 04:39:21PM +0100, Peter Zijlstra wrote:
> > > Yes, the difference between RCpc and RCsc is in the meaning of RELEASE +
> > > ACQUIRE
Hello,
Worked on a modified version of the following selftest
test case in the kernel source.
tools/testing/selftests/vm/hugepage-mmap.c
This modified test will try to do the following sequence of
events in the same order.
(1) Allocate 16 Huge TLB pages (16MB each) through mmap
(2) mlock() the
On Wed, 2015-09-02 at 15:37 +0530, Anshuman Khandual wrote:
> Hello,
>
> Worked on a modified version of the following selftest
> test case in the kernel source.
>
> tools/testing/selftests/vm/hugepage-mmap.c
Please send the test case and how to run it here.
Mikey
> This modified test will try
On Wed, Sep 02, 2015 at 10:59:06AM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Tue, Sep 01, 2015 at 10:45:40PM +0100, Paul E. McKenney wrote:
> > On Tue, Sep 01, 2015 at 08:00:27PM +0100, Will Deacon wrote:
> > > On Fri, Aug 28, 2015 at 04:39:21PM +0100, Peter Zijlstra wrote:
> > > > Yes, the diff
On 09/02/2015 03:50 PM, Michael Neuling wrote:
> On Wed, 2015-09-02 at 15:37 +0530, Anshuman Khandual wrote:
>> Hello,
>>
>> Worked on a modified version of the following selftest
>> test case in the kernel source.
>>
>> tools/testing/selftests/vm/hugepage-mmap.c
>
> Please send the test case and
On Thu, 2015-08-27 at 15:58 +0200, leroy christophe wrote:
> Hi,
>
> Has anybody already used 'perf' tool on powerpc MPC83xx ?
>
> I have been succesfully using perf on MPC8xx, but on MPC83xx I get
> something strange.
>
> perf record/report reports addresses on user stack, as if it was mixing
Hi Will,
On 09/02/2015 05:59 AM, Will Deacon wrote:
> I just thought it was worth making this point, because it is prohibited
> in SC and I don't want people to think that our RELEASE/ACQUIRE operations
> are SC (even though they happen to be on arm64).
This is interesting information. Does that
On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar wrote:
> Hi Will,
>
> On 09/02/2015 05:59 AM, Will Deacon wrote:
>> I just thought it was worth making this point, because it is prohibited
>> in SC and I don't want people to think that our RELEASE/ACQUIRE operations
>> are SC (even though they happe
On 02.09.2015 [19:00:31 +1000], Alexey Kardashevskiy wrote:
> On 09/02/2015 11:11 AM, Nishanth Aravamudan wrote:
> >When attempting to kdump with the 4.2 kernel, we see for each PCI
> >device:
> >
> > pci 0003:01 : [PE# 000] Assign DMA32 space
> > pci 0003:01 : [PE# 000] Setting up 32-bit
On Wed, 2015-09-02 at 01:36 -0500, Andy Fleming wrote:
> This board uses a P5020 or P5040 chip, and boots just fine using
> the corenet_generic code. The device tree is very similar to the
> P5020DS, except that there is no Flash memory. The environment is,
> instead, stored on an MMC card on the m
On Wed, Sep 2, 2015 at 11:53 AM, Scott Wood wrote:
>
> On Wed, 2015-09-02 at 01:36 -0500, Andy Fleming wrote:
> > This board uses a P5020 or P5040 chip, and boots just fine using
> > the corenet_generic code. The device tree is very similar to the
> > P5020DS, except that there is no Flash memory.
On Wed, 2015-09-02 at 12:23 -0500, Andy Fleming wrote:
> On Wed, Sep 2, 2015 at 11:53 AM, Scott Wood wrote:
> >
> > On Wed, 2015-09-02 at 01:36 -0500, Andy Fleming wrote:
> > > This board uses a P5020 or P5040 chip, and boots just fine using
> > > the corenet_generic code. The device tree is very
On Wed, 2015-09-02 at 12:42 -0500, Scott Wood wrote:
> On Wed, 2015-09-02 at 12:23 -0500, Andy Fleming wrote:
> > On Wed, Sep 2, 2015 at 11:53 AM, Scott Wood
> > wrote:
> > >
> > > On Wed, 2015-09-02 at 01:36 -0500, Andy Fleming wrote:
> > > > This board uses a P5020 or P5040 chip, and boots jus
This board uses a P5020 chip, and boots just fine using
the corenet_generic code. The device tree is very similar to the
P5020DS, except that there is no Flash memory. The environment is,
instead, stored on an MMC card on the motherboard.
Signed-off-by: Andy Fleming
---
v2: Moved dts to cyrus_p50
Le 02/09/2015 16:20, Joakim Tjernlund a écrit :
On Thu, 2015-08-27 at 15:58 +0200, leroy christophe wrote:
Hi,
Has anybody already used 'perf' tool on powerpc MPC83xx ?
I have been succesfully using perf on MPC8xx, but on MPC83xx I get
something strange.
perf record/report reports addresses
On Fri, Aug 14, 2015 at 04:08:10PM -0500, Rob Herring wrote:
> On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier wrote:
> > Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> > to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
> > can be triggered if the property ha
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by using M64 BAR in Single PE mode to
cover only
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is extended with number of
roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
size could be calculated by (vfs_expanded * VF_BAR_size).
This patch simplifies the pnv_
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
from 64bit prefetchable window, which means M64 BAR can't work on it.
This patch makes this explicit.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Sha
At the moment 64bit-prefetchable window can be maximum 64GB, which is
currently got from device tree. This means that in shared mode the maximum
supported VF BAR size is 64GB/256=256MB. While this size could exhaust the
whole 64bit-prefetchable window. This is a design decision to set a
boundary to
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BARs in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
And in this patch, m64_wins is renamed to m
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Shan
---
arch/powerpc/pla
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
sparse.
This patch restructures the patch to allocate sparse PE# for VFs when M64
BAR is set to Single PE mode. Also it rename the offset to pe_num_map to
reflect the content is the PE number.
Signed-off-by: Wei Yang
Reviewed
On 09/03/2015 11:29 AM, Wei Yang wrote:
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by usi
On Wed, 2015-09-02 at 10:02 +0900, Simon Horman wrote:
> [CC linuxppc-dev]
>
> On Fri, Aug 21, 2015 at 12:51:16PM +1000, Samuel Mendoza-Jonas wrote:
> > Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> > meaning if we kexec from a little-endian kernel the target kernel will
>
Hi Linus,
Please pull powerpc updates for 4.3:
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
tags/powerpc-4.3-1
32 matches
Mail list logo
