Some people see things like "Exception: 501" in stack traces in dmesg
and assume that means that something has gone badly wrong, when in
fact "Exception: 501" just means a device interrupt was taken.
This changes "Exception" to "interrupt" to make it clearer that we
are just recording the fact of a
On Thu, Jun 12, 2014 at 03:43:55PM +0900, Joonsoo Kim wrote:
> On Thu, Jun 12, 2014 at 03:06:10PM +0900, Minchan Kim wrote:
> > On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
> > > ppc kvm's cma region management requires arbitrary bitmap granularity,
> > > since they want to reserve
Hi Srivatsa,
On Sat, Jun 7, 2014 at 7:16 AM, Srivatsa S. Bhat
wrote:
> And with the following hunk added (which I had forgotten earlier), it worked
> just
> fine on powernv :-)
How are the patches coming along?
I just hung a machine here while attempting to kexec. It appears to
have onlined al
On Thu, Jun 12, 2014 at 03:06:10PM +0900, Minchan Kim wrote:
> On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
> > ppc kvm's cma region management requires arbitrary bitmap granularity,
> > since they want to reserve very large memory and manage this region
> > with bitmap that one bit
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
> ppc kvm's cma region management requires arbitrary bitmap granularity,
> since they want to reserve very large memory and manage this region
> with bitmap that one bit for several pages to reduce management overheads.
> So support arbit
On Thu, Jun 12, 2014 at 02:52:20PM +0900, Minchan Kim wrote:
> On Thu, Jun 12, 2014 at 12:21:41PM +0900, Joonsoo Kim wrote:
> > ppc kvm's cma area management needs alignment constraint on
> > cma region. So support it to prepare generalization of cma area
> > management functionality.
> >
> > Addi
On Thu, Jun 12, 2014 at 02:25:43PM +0900, Minchan Kim wrote:
> On Thu, Jun 12, 2014 at 12:21:39PM +0900, Joonsoo Kim wrote:
> > We should free memory for bitmap when we find zone mis-match,
> > otherwise this memory will leak.
>
> Then, -stable stuff?
I don't think so. This is just possible leak
On Thu, Jun 12, 2014 at 12:21:41PM +0900, Joonsoo Kim wrote:
> ppc kvm's cma area management needs alignment constraint on
> cma region. So support it to prepare generalization of cma area
> management functionality.
>
> Additionally, add some comments which tell us why alignment
> constraint is n
On Thu, Jun 12, 2014 at 02:18:53PM +0900, Minchan Kim wrote:
> Hi Joonsoo,
>
> On Thu, Jun 12, 2014 at 12:21:38PM +0900, Joonsoo Kim wrote:
> > We don't need explicit 'CMA:' prefix, since we already define prefix
> > 'cma:' in pr_fmt. So remove it.
> >
> > And, some logs print function name and o
On Thu, Jun 12, 2014 at 10:11:19AM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim writes:
>
> > We don't need explicit 'CMA:' prefix, since we already define prefix
> > 'cma:' in pr_fmt. So remove it.
> >
> > And, some logs print function name and others doesn't. This looks
> > bad to me, so I unif
On Thu, Jun 12, 2014 at 12:21:40PM +0900, Joonsoo Kim wrote:
> To prepare future generalization work on cma area management code,
> we need to separate core cma management codes from DMA APIs.
> We will extend these core functions to cover requirements of
> ppc kvm's cma area management functionali
Hi Joonsoo,
On Thu, Jun 12, 2014 at 12:21:38PM +0900, Joonsoo Kim wrote:
> We don't need explicit 'CMA:' prefix, since we already define prefix
> 'cma:' in pr_fmt. So remove it.
>
> And, some logs print function name and others doesn't. This looks
> bad to me, so I unify log format to print funct
On Thu, Jun 12, 2014 at 12:21:39PM +0900, Joonsoo Kim wrote:
> We should free memory for bitmap when we find zone mis-match,
> otherwise this memory will leak.
Then, -stable stuff?
>
> Additionally, I copy code comment from ppc kvm's cma code to notify
> why we need to check zone mis-match.
>
>
Joonsoo Kim writes:
> ppc kvm's cma area management needs alignment constraint on
> cma region. So support it to prepare generalization of cma area
> management functionality.
>
> Additionally, add some comments which tell us why alignment
> constraint is needed on cma region.
>
> Signed-off-by:
Joonsoo Kim writes:
> To prepare future generalization work on cma area management code,
> we need to separate core cma management codes from DMA APIs.
> We will extend these core functions to cover requirements of
> ppc kvm's cma area management functionality in following patches.
> This separat
Joonsoo Kim writes:
> We should free memory for bitmap when we find zone mis-match,
> otherwise this memory will leak.
>
> Additionally, I copy code comment from ppc kvm's cma code to notify
> why we need to check zone mis-match.
>
> Signed-off-by: Joonsoo Kim
Reviewed-by: Aneesh Kumar K.V
>
Joonsoo Kim writes:
> We don't need explicit 'CMA:' prefix, since we already define prefix
> 'cma:' in pr_fmt. So remove it.
>
> And, some logs print function name and others doesn't. This looks
> bad to me, so I unify log format to print function name consistently.
>
> Lastly, I add one more deb
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitma
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Acked-by: Michal Nazarewicz
Acked-by: Paolo Bonzini
Signed-off-by: Joonsoo Kim
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builti
To prepare future generalization work on cma area management code,
we need to separate core cma management codes from DMA APIs.
We will extend these core functions to cover requirements of
ppc kvm's cma area management functionality in following patches.
This separation helps us not to touch DMA AP
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitma
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by:
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I add one more debug log on cma_activate_area().
Si
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Signed-off-by: Joonsoo Kim
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contig
Currently, we should take the mutex for manipulating bitmap.
This job may be really simple and short so we don't need to sleep
if contended. So I change it to spinlock.
Signed-off-by: Joonsoo Kim
diff --git a/mm/cma.c b/mm/cma.c
index 22a5b23..3085e8c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -27,
ppc kvm's cma area management needs alignment constraint on
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed on cma region.
Signed-off-by: Joonsoo Kim
diff --git a/drivers/b
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct cma *cma, int count,
This v2 patch is good,
Tested-by: Mike Qiu
On 06/11/2014 11:40 PM, Michal Marek wrote:
The rule to create the final images uses a zImage.% pattern.
Unfortunately, this also matches the names of the zImage.*.lds linker
scripts, which appear as a dependency of the final images. This somehow
work
On Wed, Jun 11, 2014 at 12:13:52AM -0700, Guenter Roeck wrote:
> Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
> Unfortunately, the structure is still used. This causes
> mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with
Applied, thanks,.
signature.asc
Descr
Commit 2749a2f26a7c (powerpc/book3s: Fix machine check handling for
unhandled errors) introduced a few ABIv2 issues.
We can maintain ABIv1 and ABIv2 compatibility by branching to the
function rather than the dot symbol.
Fixes: 2749a2f26a7c ("powerpc/book3s: Fix machine check handling for unhandle
On Thu, Jun 12, 2014 at 06:22:11AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-06-11 at 14:37 -0500, Christoph Lameter wrote:
> > Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
> > comes from a local_paca field and local_paca is in r13. That means that
> > for al
On Tue, 2014-06-10 at 11:41 +1000, Gavin Shan wrote:
> The patch adds new IOCTL commands for sPAPR VFIO container device
> to support EEH functionality for PCI devices, which have been passed
> through from host to somebody else via VFIO.
>
> Signed-off-by: Gavin Shan
> Acked-by: Alexander Graf
On Wed, 2014-06-11 at 10:44 -0500, Christoph Lameter wrote:
> This is under Ubuntu Utopic Unicorn on a Power 8 system while simply
> trying to build with the Ubuntu standard kernel config. It could be that
> these issues come about because we do not have an rc1 yet but I wanted to
> give some early
On Wed, 2014-06-11 at 14:37 -0500, Christoph Lameter wrote:
> Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
> comes from a local_paca field and local_paca is in r13. That means that
> for all percpu operations we first have to determine the address through a
> memory ac
Looking at arch/powerpc/include/asm/percpu.h I see that the per cpu offset
comes from a local_paca field and local_paca is in r13. That means that
for all percpu operations we first have to determine the address through a
memory access.
Would it be possible to put the paca at the beginning of the
This is under Ubuntu Utopic Unicorn on a Power 8 system while simply
trying to build with the Ubuntu standard kernel config. It could be that
these issues come about because we do not have an rc1 yet but I wanted to
give some early notice. Also this is a new arch to me so I may not be
aware of how
The rule to create the final images uses a zImage.% pattern.
Unfortunately, this also matches the names of the zImage.*.lds linker
scripts, which appear as a dependency of the final images. This somehow
worked when $(srctree) used to be an absolute path, but now the pattern
matches too much. List o
They're almost a duplicate of the boards array
and we can build them at run-time.
Signed-off-by: Laurentiu Tudor
---
arch/powerpc/platforms/85xx/corenet_generic.c | 49 +++
1 file changed, 20 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet
Hi Michal,
after ally you patch, it also has some issue, see below:
WARNING: 1 bad relocations
c1455040 R_PPC64_ADDR64uprobes_fetch_type_table
arch/powerpc/boot/Makefile:336: target
`arch/powerpc/boot/zImage.pseries' given more than once in the same rule.
gcc -m32 -Wp,-MD,arch/power
Dne 11.6.2014 14:21, Michal Marek napsal(a):
> On Wed, Jun 11, 2014 at 10:24:24AM +0200, Michal Marek wrote:
>> Dne 11.6.2014 08:02, Mike Qiu napsal(a):
>>> make[1]: Circular arch/powerpc/boot/zImage.lds.S <-
>>> arch/powerpc/boot/zImage.lds dependency dropped.
>>> make[1]: Circular arch/powerpc/bo
On Wed, Jun 11, 2014 at 10:24:24AM +0200, Michal Marek wrote:
> Dne 11.6.2014 08:02, Mike Qiu napsal(a):
> > make[1]: Circular arch/powerpc/boot/zImage.lds.S <-
> > arch/powerpc/boot/zImage.lds dependency dropped.
> > make[1]: Circular arch/powerpc/boot/zImage.coff.lds.S <-
> > arch/powerpc/boot/zI
T2080PCIe-RDB is a Freescale Reference Design Board that hosts T2080 SoC.
The board feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
DDR Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LP devices
- 72bit 4GB DDR3-LP SOD
Add support for Freescale T2080/T2081 QDS Development System Board.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor, with following major features:
T2080QDS feature overview:
Processor:
-
The T2080 QorIQ multicore processor combines four dual-threaded e6500 Power
Architecture processor cores with high-performance datapath acceleration
logic and network and peripheral bus interfaces required for networking,
telecom/datacom, wireless infrastructure, and mil/aerospace applications.
Th
On Wed, Jun 11, 2014 at 05:29:44PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2014-06-11 at 15:12 +0800, Wei Yang wrote:
>
>> Sorry for the long delay. It took me some time to investigate and test the
>> code.
>> Currently, the hotplug by qemu monitor command line has been verified. Two
>> pci
From: Mahesh Salgaonkar
Currently we forward MCEs to guest which have been recovered by guest.
And for unhandled errors we do not deliver the MCE to guest. It looks like
with no support of FWNMI in qemu, guest just panics whenever we deliver the
recovered MCEs to guest. Also, the existig code use
From: Mahesh Salgaonkar
We don't see MCE counter getting increased in /proc/interrupts which gives
false impression of no MCE occurred even when there were MCE events.
The machine check early handling was added for PowerKVM and we missed to
increment the MCE count in the early handler.
We also i
From: Mahesh Salgaonkar
Currently machine check handler does not check for stack overflow for
nested machine check. If we hit another MCE while inside the machine check
handler repeatedly from same address then we get into risk of stack
overflow which can cause huge memory corruption. This patch
From: Mahesh Salgaonkar
Current code does not check for unhandled/unrecovered errors and return from
interrupt if it is recoverable exception which in-turn triggers same machine
check exception in a loop causing hypervisor to be unresponsive.
This patch fixes this situation and forces hypervisor
As Ben suggested, it's meaningful to dump PE's location code
for site engineers when hitting EEH errors. The patch introduces
function eeh_pe_loc_get() to retireve the location code from
dev-tree so that we can output it when hitting EEH errors.
If primary PE bus is root bus, the PHB's dev-node wo
On Tue, Jun 10 2014, Joonsoo Kim wrote:
> Without including device.h, build failure occurs.
> In dma-contiguous.h, we try to access to dev->cma_area, so we need
> device.h. In the past, we included it luckily by swap.h in
> drivers/base/dma-contiguous.c. Swap.h includes node.h and then node.h
> in
Dne 11.6.2014 08:02, Mike Qiu napsal(a):
> Hi all,
>
> I recently build linux next kernel in IBM Power7 platform, use default
> config file copy from /boot/config-3.6.10-4.fc18.ppc64p7
>
> [root@cena01 linux-next]# uname -a
> Linux cena01.austin.ibm.com 3.15.0-rc1+ #47 SMP Thu Apr 24 20:59:46 CDT
vmemmap_populated() checks whether the [start, start + page_size) has valid
pfn numbers, to know whether a vmemmap mapping has been created that includes
this range.
Some range before end might not be checked by this loop:
sec11start..start11..sec11end/sec12start..endstart12..sec12end
as
vmemmap_free() does the opposite of vmemap_populate().
This patch also puts vmemmap_free() and vmemmap_list_free() into
CONFIG_MEMMORY_HOTPLUG.
Signed-off-by: Li Zhong
Cc: Nathan Fontenot
---
arch/powerpc/mm/init_64.c | 85 ++---
1 file changed, 64 ins
This is to be called in vmemmap_free(), leave the implementation on BOOK3E
empty as before.
Signed-off-by: Li Zhong
Cc: Nathan Fontenot
---
arch/powerpc/mm/hash_utils_64.c |2 +-
arch/powerpc/mm/init_64.c | 22 ++
2 files changed, 23 insertions(+), 1 deletion(-)
This patch implements vmemmap_list_free() for vmemmap_free().
The freed entries will be removed from vmemmap_list, and form a freed list,
with next as the header. The next position in the last allocated page is kept
at the list tail.
When allocation, if there are freed entries left, get it from t
On Wed, 2014-06-11 at 15:12 +0800, Wei Yang wrote:
> Sorry for the long delay. It took me some time to investigate and test the
> code.
> Currently, the hotplug by qemu monitor command line has been verified. Two pci
> device on the same bus have been hotpluged one by one successfully.
>
> Anoth
Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
Unfortunately, the structure is still used. This causes
mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with
sound/soc/fsl/fsl_dma.c:926:50:
error: invalid use of undefined type 'struct ccsr_ssi'
dma->ssi_stx_phys
On Mon, May 12, 2014 at 12:59:19PM +1000, Benjamin Herrenschmidt wrote:
>On Thu, 2014-05-08 at 14:30 +0800, Wei Yang wrote:
>> During the EEH hotplug event, pcibios_setup_device() will be invoked two
>> times. And the last time will trigger a warning of re-attachment of iommu
>> group.
>>
>> The t
60 matches
Mail list logo
