* [PATCH v3] powerpc: use a kmem cache for DTL buffers
From: Nishanth Aravamudan @ 2011-04-14 5:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302754363.12513.89.camel@concordia>
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Create a special kmem
cache for DTL buffers with the alignment requirement.
---
Change from v1: removed extraneous #include.
Change from v2: instead of overallocating and aligning, use a kmem cache
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..629b703 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -287,14 +287,17 @@ static int alloc_dispatch_logs(void)
int cpu, ret;
struct paca_struct *pp;
struct dtl_entry *dtl;
+ struct kmem_cache *dtl_cache;
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
+ dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
+ DISPATCH_LOG_BYTES, 0, NULL);
+
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: Add an ePAPR compliant boot wrapper
From: Michael Ellerman @ 2011-04-14 4:25 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20110414004303.GZ3151@yookeroo>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
On Thu, 2011-04-14 at 10:43 +1000, David Gibson wrote:
> On Wed, Apr 13, 2011 at 09:05:12AM -0400, Josh Boyer wrote:
> > On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
> > >+++ b/arch/powerpc/boot/epapr.c
> > >@@ -0,0 +1,69 @@
> > >+/*
> > >+ * Bootwrapper for ePAPR compliant firmwares
> >
> > Out of curiosity, do we have a list of the ePAPR compliant firmwares (if
> > any)?
>
> The one this has been tested with is a revised (internal, so far)
> version of SLOF. For the platform that I believe Michael is in the
> middle of upstreaming support for.
Yep.
> > >+#include "ops.h"
> > >+#include "stdio.h"
> > >+#include "planetcore.h"
> > >+#include "dcr.h"
> > >+#include "4xx.h"
> > >+#include "io.h"
> >
> > Do you need planetcore, dcr, and 4xx.h included here? I don't see
> > anything used that would require them.
>
> Ah, no. Leftovers from the files I based this on, I think.
I'll send a new version.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc: align DTL buffer to AMS boundary
From: Michael Ellerman @ 2011-04-14 4:12 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras
In-Reply-To: <1302733988-23037-1-git-send-email-nacc@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
On Wed, 2011-04-13 at 15:33 -0700, Nishanth Aravamudan wrote:
> PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
> in the PAPR) and can not cross a memory entitlement granule boundary
> (4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
> kmalloc does not guarantee an alignment of the allocation, though,
> beyond 8 bytes (at least in my understanding). Over-allocate and align
> the resulting address.
You can specify alignment by creating your own kmem_cache, ie.
kmem_cache_create().
Obviously there will be some overhead to create the cache structure, but
I'd think it will be less than 4k * NR_CPUs.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Where is CONFIG_BOOT_LOAD ?
From: Benjamin Herrenschmidt @ 2011-04-14 2:52 UTC (permalink / raw)
To: Joachim Förster; +Cc: linuxppc-dev, Florian Vögel, Guillaume Dargaud
In-Reply-To: <4DA485CD.6060604@gmx.de>
On Tue, 2011-04-12 at 19:03 +0200, Joachim Förster wrote:
> Note that the default 0x400... is the link address of the zImage
> wrapper
> rather than the one of THE kernel.
>
> Currently the link address seems to be hard-coded into
> arch/powerpc/boot/wrapper
> (a shell script). Since long ago I'm wondering why the maintainers
> did
> that. But I guess there is a reason, because it wasn't that way in
> the
> old arch/ppc days ;-) ...
>
> Is configuring the zImage-piggy-back-loader through menuconfig & co
> evil?
Well, not really evil but if you need a special setting for your board,
you add a case for that board in the wrapper script. The idea is that
the boot wrapper can be build outside of the kernel build tree itself.
IE. A distro could (and sometimes do) ship with the standalone boot
directory, possibly the .o's already built, and will "wrap" the zImage
at install time.
Cheers,
Ben.
^ permalink raw reply
* Re: PowerMacintosh B&W G4 boot failure - linux-2.6.36.x
From: Benjamin Herrenschmidt @ 2011-04-14 2:49 UTC (permalink / raw)
To: acrux; +Cc: Nello M, linuxppc-dev
In-Reply-To: <20110413202714.ad1b5697.acrux_it@libero.it>
On Wed, 2011-04-13 at 20:27 +0200, acrux wrote:
> i guess it's a different problem from the PegasosI G3 but i could be wrong.
>
> I'd like to receive feedbacks and a working kernel config if someone is running with success
> linux-2.6.26.x on a Pmac B&W G3. This machine, altough obsolete, is still quite common
The snapshot you posted doesn't have much information... there's no
obvious error for example in there...
What video driver are you trying to use ? Have you tried plain offb ?
(disabling whatever is the native driver for your video card, ie,
radeonfb or aty128fb or even atyfb, dunno what you have in there).
You can also try something like "udbg-immortal" on the kernel command
line see if that brings you more debug output.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add an ePAPR compliant boot wrapper
From: David Gibson @ 2011-04-14 0:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: Michael Ellerman, linuxppc-dev, Paul Mackerras
In-Reply-To: <20110413130512.GD26874@zod.rchland.ibm.com>
On Wed, Apr 13, 2011 at 09:05:12AM -0400, Josh Boyer wrote:
> On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
> >+++ b/arch/powerpc/boot/epapr.c
> >@@ -0,0 +1,69 @@
> >+/*
> >+ * Bootwrapper for ePAPR compliant firmwares
>
> Out of curiosity, do we have a list of the ePAPR compliant firmwares (if
> any)?
The one this has been tested with is a revised (internal, so far)
version of SLOF. For the platform that I believe Michael is in the
middle of upstreaming support for.
> >+ *
> >+ * Copyright 2010 David Gibson <david@gibson.dropbear.id.au>, IBM Corporation.
> >+ *
> >+ * Based on earlier bootwrappers by:
> >+ * (c) Benjamin Herrenschmidt <benh@kernel.crashing.org>, IBM Corp,\
> >+ * and
> >+ * Scott Wood <scottwood@freescale.com>
> >+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
> >+ *
> >+ * This program is free software; you can redistribute it and/or modify it
> >+ * under the terms of the GNU General Public License version 2 as published
> >+ * by the Free Software Foundation.
> >+ */
> >+
> >+#include "ops.h"
> >+#include "stdio.h"
> >+#include "planetcore.h"
> >+#include "dcr.h"
> >+#include "4xx.h"
> >+#include "io.h"
>
> Do you need planetcore, dcr, and 4xx.h included here? I don't see
> anything used that would require them.
Ah, no. Leftovers from the files I based this on, I think.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: kevin diggs @ 2011-04-13 23:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <1302736869.28876.91.camel@pasglop>
Hi,
On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
>> > Actually I do get a crash in X later on... something in the radeon
>> DRM
>> > interrupt code is getting what looks like a NULL dereference. I'll
>> try
>> > to dig that one later on. I don't know if it's related to your
>> problem
>> > at all though.
>> >
>> In this context, what does 'crash' mean? The X thingy goes down? Or
>> the whole OS?
>
> Depends, with xmon enabled you get into xmon :-) Dunno if the oops is
> fatal but it could be.
>
> Cheers,
> Ben.
>
>
As I think I have the same hardware as you (7,3, radeon 9600) If you
can tell me how to reproduce it maybe I can poke around a little.
Thus, at least temporarily, freeing you up for other stuff.
I kinda need a break from fighting with GCC.
kevin
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Benjamin Herrenschmidt @ 2011-04-13 23:21 UTC (permalink / raw)
To: kevin diggs; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <BANLkTimc84A8kddarnhvrcab3iKZc0HZAg@mail.gmail.com>
On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
> > Actually I do get a crash in X later on... something in the radeon
> DRM
> > interrupt code is getting what looks like a NULL dereference. I'll
> try
> > to dig that one later on. I don't know if it's related to your
> problem
> > at all though.
> >
> In this context, what does 'crash' mean? The X thingy goes down? Or
> the whole OS?
Depends, with xmon enabled you get into xmon :-) Dunno if the oops is
fatal but it could be.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 22:33 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302706373-11653-1-git-send-email-nacc@us.ibm.com>
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Over-allocate and align
the resulting address. Tested both with and without AMS on a p7
partition.
---
Change from v1: removed extraneous #include.
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..a67be48 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -293,14 +293,15 @@ static int alloc_dispatch_logs(void)
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmalloc_node(DISPATCH_LOG_BYTES + DISPATCH_LOG_BYTES - 1,
+ GFP_KERNEL, cpu_to_node(cpu));
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
pr_warn("Stolen time statistics will be unreliable\n");
break;
}
+ dtl = PTR_ALIGN(dtl, DISPATCH_LOG_BYTES);
pp->dtl_ridx = 0;
pp->dispatch_log = dtl;
--
1.7.4.1
^ permalink raw reply related
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Andy Furniss @ 2011-04-13 20:01 UTC (permalink / raw)
To: Michel Dänzer
Cc: KH, LKML, dri-devel, Greg, Uwe Kleine-König, linuxppc-dev
In-Reply-To: <1302704124.15520.72.camel@thor.local>
Michel Dänzer wrote:
>>> That does sound like the GPU locks up. Do you get any messages in dmesg
>>> about lockups and attempts to reset the GPU at any time?
>>
>> No.
>
> Hmm, I guess the constant SIGALRMs might prevent the lockup detection
> from kicking in... Maybe you can try starting the X server with
> -dumbSched to see if that gets things along any further, but in the end
> there's probably no way around figuring out what causes the lockup and
> fixing that anyway.
I have an old AGP box that locks with 600g + agpgart - It used to give
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't
anymore. I can still sysrq OK.
I wonder if something changed in recent months in the drm/whatever code
that has changed/blocked the logging.
^ permalink raw reply
* Re: Powerpc compile error with 2.6.39-rc3 and non-SMP configs
From: Paul Gortmaker @ 2011-04-13 15:45 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linuxppc-dev
In-Reply-To: <20110413101737.GA25514@gibson.comsick.at>
On 11-04-13 06:17 AM, Michael Guntsche wrote:
> Hi,
>
> Commit b987812b3fc "powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP."
> breaks compilation on non SMP powerpc machines.
Ah crap. I compile tested on SMP, so didn't see that.
> I wonder if this commit is really neccessary in the first place. The
> function definition itself is already between an
Your analysis is right, but I think getting rid of the #ifdefs is
still the right approach where possible. I'll send a fix shortly.
Thanks for the report.
P.
>
> #ifdef CONFIG_SMP (line 56)
> #endif
>
> block so only exists if SMP=y and PPC_STD_MMU_64=y.
> Furthermore the stub in your patch is only created if SMP=y and
> PPC_STD_MMU_64=n which breaks non-SMP configs.
>
> Kind regards,
> Michael Guntsche
^ permalink raw reply
* Re: PowerMacintosh B&W G4 boot failure - linux-2.6.36.x
From: acrux @ 2011-04-13 18:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nello M
In-Reply-To: <BANLkTikwJ81ZxtHoJOpu_OW8bCcPTm8F9w@mail.gmail.com>
i guess it's a different problem from the PegasosI G3 but i could be wrong.
I'd like to receive feedbacks and a working kernel config if someone is running with success linux-2.6.26.x on a Pmac B&W G3. This machine, altough obsolete, is still quite common.
--nico
--
acrux <acrux_it@libero.it>
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: kevin diggs @ 2011-04-13 17:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <1302685102.28876.81.camel@pasglop>
HI,
On Wed, Apr 13, 2011 at 3:58 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> Actually I do get a crash in X later on... something in the radeon DRM
> interrupt code is getting what looks like a NULL dereference. I'll try
> to dig that one later on. I don't know if it's related to your problem
> at all though.
>
In this context, what does 'crash' mean? The X thingy goes down? Or
the whole OS?
Cheers,
kevin.
> Cheers,
> Ben.
^ permalink raw reply
* [PATCH] powerpc/kexec: fix regression causing compile failure on UP
From: Paul Gortmaker @ 2011-04-13 16:30 UTC (permalink / raw)
To: benh; +Cc: Paul Gortmaker, mike, linuxppc-dev
Recent commit b987812b3fcaf70fdf0037589e5d2f5f2453e6ce caused
a compile failure on UP because a considerably large block
of the file was included within CONFIG_SMP, hence making a stub
function not exposed on UP builds when it needed to be.
Relocate the stub to the #else /* ! CONFIG_SMP */ section
and also annotate the relevant else/endif so that nobody
else falls into the same trap I did.
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
** compile tested on both UP & SMP this time! **
arch/powerpc/kernel/crash.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d3d416..5b5e1f0 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,7 +163,7 @@ static void crash_kexec_prepare_cpus(int cpu)
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
-#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
+#ifdef CONFIG_PPC_STD_MMU_64
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -188,9 +188,7 @@ static void crash_kexec_wait_realmode(int cpu)
}
mb();
}
-#else
-static inline void crash_kexec_wait_realmode(int cpu) {}
-#endif
+#endif /* CONFIG_PPC_STD_MMU_64 */
/*
* This function will be called by secondary cpus or by kexec cpu
@@ -235,7 +233,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
crash_ipi_callback(regs);
}
-#else
+#else /* ! CONFIG_SMP */
+static inline void crash_kexec_wait_realmode(int cpu) {}
+
static void crash_kexec_prepare_cpus(int cpu)
{
/*
@@ -255,7 +255,7 @@ void crash_kexec_secondary(struct pt_regs *regs)
{
cpus_in_sr = CPU_MASK_NONE;
}
-#endif
+#endif /* CONFIG_SMP */
/*
* Register a function to be called on shutdown. Only use this if you
--
1.7.3.3
^ permalink raw reply related
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-13 15:38 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104131721.34123.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/13 17:21:33:
>
> Hi Joakim,
>
> On Wednesday 13 April 2011 16:58:21 Joakim Tjernlund wrote:
> > > This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
> > > __copy_tofrom_user() fails with return code 4 (called via
> > > ftrace_modify_code()).
> > >
> > > Before digging deeper: Has anybody tried/tested ftrace on MPC8xx? Any
> > > ideas what going wrong here?
> >
> > Just an idea, remove the usage of dcbX insn, these has been problematic
> > before.
>
> I originally tested with 2.6.32. Same problem there. And your 8xx patches with
> the dcbX changes are not included in 2.6.32 yet.
OK
>
> > How big was the size to copy_tofrom_user()? Did it mange to copy
> > any bytes?
>
> The size in __copy_tofrom_user is 4. And its the first call in
> ftrace_modify_code() that fails directly. This works just fine on a PPC440EPx
> board.
Since the size is only 4 it would not use dcbX anyway(I think).
Then is is probably called with the wrong addresses?
Jocke
^ permalink raw reply
* Re: PowerMacintosh B&W G4 boot failure - linux-2.6.36.x
From: nello martuscielli @ 2011-04-13 15:32 UTC (permalink / raw)
To: linuxppc-dev
could it be the same issue i've on my old Pegasos1 G3 ??
regards,
Nello
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Stefan Roese @ 2011-04-13 15:21 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF32A80193.EF3E454E-ONC1257871.005204A6-C1257871.00523F24@transmode.se>
Hi Joakim,
On Wednesday 13 April 2011 16:58:21 Joakim Tjernlund wrote:
> > This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
> > __copy_tofrom_user() fails with return code 4 (called via
> > ftrace_modify_code()).
> >
> > Before digging deeper: Has anybody tried/tested ftrace on MPC8xx? Any
> > ideas what going wrong here?
>
> Just an idea, remove the usage of dcbX insn, these has been problematic
> before.
I originally tested with 2.6.32. Same problem there. And your 8xx patches with
the dcbX changes are not included in 2.6.32 yet.
> How big was the size to copy_tofrom_user()? Did it mange to copy
> any bytes?
The size in __copy_tofrom_user is 4. And its the first call in
ftrace_modify_code() that fails directly. This works just fine on a PPC440EPx
board.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 15:15 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8ACF4@saturn3.aculab.com>
On 13.04.2011 [15:59:44 +0100], David Laight wrote:
> > From:
> > linuxppc-dev-bounces+david.laight=aculab.com@lists.ozlabs.org
> > [mailto:linuxppc-dev-bounces+david.laight=aculab.com@lists.ozl
> > abs.org] On Behalf Of Nishanth Aravamudan
> > Sent: 13 April 2011 15:53
> > To: Ben Herrenschmidt
> > Cc: linuxppc-dev@ozlabs.org; Paul Mackerras; Anton Blanchard
> > Subject: [PATCH] powerpc: align DTL buffer to AMS boundary
> >
> > PAPR specifies that DTL buffers can not cross AMS environments (aka
> CMO
> > in the PAPR) and can not cross a memory entitlement granule boundary
> > (4k)....
>
> How big is the buffer being allocated?
> If it is much less than 4k then it might be worth allocating
> a buffer of the correct size, and only if that crosses a 4k boundary
> allocate the larger buffer.
Currently, DISPATCH_LOG_BYTES is 4k (which I assume was actually in
deference to this requirement).
> Also, if the buffer is ever freed, the actual base address is needed
> for the free.
I didn't see any free patch for this sequence of code -- which make
sense as this allocation occurs under a for_each_possible_cpu loop.
Thanks for the feedback,
Nish
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-13 14:58 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104131632.21350.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/13 16:32:21:
>
> Hi,
>
> I noticed that ftrace doesn't seem to work on MPC8xx. I'm trying to use it on
> an MPC855T board, but ftrace oopses upon startup:
>
> [ 0.028785] ftrace: allocating 10312 entries in 31 pages
> [ 0.038594] ------------[ cut here ]------------
> [ 0.038760] WARNING: at kernel/trace/ftrace.c:1014
> [ 0.038889] Modules linked in:
> [ 0.039062] NIP: c00666a0 LR: c006782c CTR: 00000001
> [ 0.039249] REGS: c0381e60 TRAP: 0700 Not tainted (2.6.38-default+)
> [ 0.039417] MSR: 00021032 <ME,CE,IR,DR> CR: 53009393 XER: a000af7f
> [ 0.039856] TASK = c0360500[0] 'swapper' THREAD: c0380000
> [ 0.040001] GPR00: 00000001 c0381f10 c0360500 ffffffff c02962c8 00000000
> c02962c4 00000000
> [ 0.040487] GPR08: 1de1a3e3 00000000 000258e3 c0381f40 93009399 10091a60
> 03fff800 0040055c
> [ 0.040977] GPR16: 00000001 00000001 ffffffff 007fff00 03ff9fb0 00000000
> 00000000 c0384080
> [ 0.041459] GPR24: c000f234 00000000 024acd00 00009032 c02962c8 c384553c
> c02962c8 c0381f10
> [ 0.042054] NIP [c00666a0] ftrace_bug+0x13c/0x1c4
> [ 0.042268] LR [c006782c] ftrace_process_locs+0x1b4/0x2b0
> [ 0.042405] Call Trace:
> [ 0.042592] [c0381f10] [c006fce8] ftrace_now+0x30/0x78 (unreliable)
> [ 0.042889] [c0381f40] [c006782c] ftrace_process_locs+0x1b4/0x2b0
> [ 0.043182] [c0381f70] [c0339944] ftrace_init+0x1e8/0x21c
> [ 0.043443] [c0381fb0] [c0333964] start_kernel+0x284/0x2a0
> [ 0.043704] [c0381ff0] [c0002224] start_here+0x44/0xa8
> [ 0.043869] Instruction dump:
> [ 0.044013] 2f9e0003 7f1ed800 3bbd0001 7f44d378 409dffc8 3c60c02f 3863101c
> 4bfbbbb9
> [ 0.044508] 48000080 3d20c04b 8929bc82 69200001 <0f000000> 2f890000
> 40be0010 38000001
> [ 0.045206] ---[ end trace 31fd0ba7d8756001 ]---
> [ 0.045349] ftrace faulted on writing [<c02962c8>] dns_query+0x8/0x278
> ...
>
>
> This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
> __copy_tofrom_user() fails with return code 4 (called via
> ftrace_modify_code()).
>
> Before digging deeper: Has anybody tried/tested ftrace on MPC8xx? Any ideas
> what going wrong here?
Just an idea, remove the usage of dcbX insn, these has been problematic before.
How big was the size to copy_tofrom_user()? Did it mange to copy any bytes?
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc: align DTL buffer to AMS boundary
From: David Laight @ 2011-04-13 14:59 UTC (permalink / raw)
To: linuxppc-dev
> From:=20
> linuxppc-dev-bounces+david.laight=3Daculab.com@lists.ozlabs.org=20
> [mailto:linuxppc-dev-bounces+david.laight=3Daculab.com@lists.ozl
> abs.org] On Behalf Of Nishanth Aravamudan
> Sent: 13 April 2011 15:53
> To: Ben Herrenschmidt
> Cc: linuxppc-dev@ozlabs.org; Paul Mackerras; Anton Blanchard
> Subject: [PATCH] powerpc: align DTL buffer to AMS boundary
>=20
> PAPR specifies that DTL buffers can not cross AMS environments (aka
CMO
> in the PAPR) and can not cross a memory entitlement granule boundary
> (4k)....
How big is the buffer being allocated?
If it is much less than 4k then it might be worth allocating
a buffer of the correct size, and only if that crosses a 4k boundary
allocate the larger buffer.
Also, if the buffer is ever freed, the actual base address is needed
for the free.
David
^ permalink raw reply
* [PATCH] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 14:52 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Over-allocate and align
the resulting address. Tested both with and without AMS on a p7
partition.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..7df5ddb 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -39,6 +39,7 @@
#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#include <linux/memblock.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -293,14 +294,15 @@ static int alloc_dispatch_logs(void)
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmalloc_node(DISPATCH_LOG_BYTES + DISPATCH_LOG_BYTES - 1,
+ GFP_KERNEL, cpu_to_node(cpu));
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
pr_warn("Stolen time statistics will be unreliable\n");
break;
}
+ dtl = PTR_ALIGN(dtl, DISPATCH_LOG_BYTES);
pp->dtl_ridx = 0;
pp->dispatch_log = dtl;
--
1.7.4.1
^ permalink raw reply related
* FTrace on MPC8xx
From: Stefan Roese @ 2011-04-13 14:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
Hi,
I noticed that ftrace doesn't seem to work on MPC8xx. I'm trying to use it on
an MPC855T board, but ftrace oopses upon startup:
[ 0.028785] ftrace: allocating 10312 entries in 31 pages
[ 0.038594] ------------[ cut here ]------------
[ 0.038760] WARNING: at kernel/trace/ftrace.c:1014
[ 0.038889] Modules linked in:
[ 0.039062] NIP: c00666a0 LR: c006782c CTR: 00000001
[ 0.039249] REGS: c0381e60 TRAP: 0700 Not tainted (2.6.38-default+)
[ 0.039417] MSR: 00021032 <ME,CE,IR,DR> CR: 53009393 XER: a000af7f
[ 0.039856] TASK = c0360500[0] 'swapper' THREAD: c0380000
[ 0.040001] GPR00: 00000001 c0381f10 c0360500 ffffffff c02962c8 00000000
c02962c4 00000000
[ 0.040487] GPR08: 1de1a3e3 00000000 000258e3 c0381f40 93009399 10091a60
03fff800 0040055c
[ 0.040977] GPR16: 00000001 00000001 ffffffff 007fff00 03ff9fb0 00000000
00000000 c0384080
[ 0.041459] GPR24: c000f234 00000000 024acd00 00009032 c02962c8 c384553c
c02962c8 c0381f10
[ 0.042054] NIP [c00666a0] ftrace_bug+0x13c/0x1c4
[ 0.042268] LR [c006782c] ftrace_process_locs+0x1b4/0x2b0
[ 0.042405] Call Trace:
[ 0.042592] [c0381f10] [c006fce8] ftrace_now+0x30/0x78 (unreliable)
[ 0.042889] [c0381f40] [c006782c] ftrace_process_locs+0x1b4/0x2b0
[ 0.043182] [c0381f70] [c0339944] ftrace_init+0x1e8/0x21c
[ 0.043443] [c0381fb0] [c0333964] start_kernel+0x284/0x2a0
[ 0.043704] [c0381ff0] [c0002224] start_here+0x44/0xa8
[ 0.043869] Instruction dump:
[ 0.044013] 2f9e0003 7f1ed800 3bbd0001 7f44d378 409dffc8 3c60c02f 3863101c
4bfbbbb9
[ 0.044508] 48000080 3d20c04b 8929bc82 69200001 <0f000000> 2f890000
40be0010 38000001
[ 0.045206] ---[ end trace 31fd0ba7d8756001 ]---
[ 0.045349] ftrace faulted on writing [<c02962c8>] dns_query+0x8/0x278
...
This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
__copy_tofrom_user() fails with return code 4 (called via
ftrace_modify_code()).
Before digging deeper: Has anybody tried/tested ftrace on MPC8xx? Any ideas
what going wrong here?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Michel Dänzer @ 2011-04-13 14:15 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <20110413122751.GA21050@iram.es>
On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:=20
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel D=C3=A4nzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:=20
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D=C3=A4nzer wrote:
> > > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D=C3=A4nzer wrot=
e:
> > > > > > >=20
> > > > > > > With no_wb=3D1 the driver goes a bit further but the X server=
ends
> > > > > > > up in an infinite ioctl loop and the logs are:=20
> > > > > >=20
> > > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file=
as well.
> > > > >=20
> > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE=
.
> > > >=20
> > > > Note that it's normal for this ioctl to be called every time before=
the
> > > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioc=
tl
> > > > always returns an error, this may not indicate a problem on its own=
.=20
> > >=20
> > > It seems to be an infinite loop, always returning EINTR because
> > > of regular SIGALRM delivery.
> >=20
> > That does sound like the GPU locks up. Do you get any messages in dmesg
> > about lockups and attempts to reset the GPU at any time?
>=20
> No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add an ePAPR compliant boot wrapper
From: Josh Boyer @ 2011-04-13 13:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <732a8ac3a24023f021908d03bd84b76638f381f1.1302676893.git.michael@ellerman.id.au>
On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
>+++ b/arch/powerpc/boot/epapr.c
>@@ -0,0 +1,69 @@
>+/*
>+ * Bootwrapper for ePAPR compliant firmwares
Out of curiosity, do we have a list of the ePAPR compliant firmwares (if
any)?
>+ *
>+ * Copyright 2010 David Gibson <david@gibson.dropbear.id.au>, IBM Corporation.
>+ *
>+ * Based on earlier bootwrappers by:
>+ * (c) Benjamin Herrenschmidt <benh@kernel.crashing.org>, IBM Corp,\
>+ * and
>+ * Scott Wood <scottwood@freescale.com>
>+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
>+ *
>+ * This program is free software; you can redistribute it and/or modify it
>+ * under the terms of the GNU General Public License version 2 as published
>+ * by the Free Software Foundation.
>+ */
>+
>+#include "ops.h"
>+#include "stdio.h"
>+#include "planetcore.h"
>+#include "dcr.h"
>+#include "4xx.h"
>+#include "io.h"
Do you need planetcore, dcr, and 4xx.h included here? I don't see
anything used that would require them.
josh
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-13 12:27 UTC (permalink / raw)
To: Michel Dänzer
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <1302696736.15520.63.camel@thor.local>
On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote:
> On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > > > > >
> > > > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > > > up in an infinite ioctl loop and the logs are:
> > > > >
> > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
> > > >
> > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > >
> > > Note that it's normal for this ioctl to be called every time before the
> > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > always returns an error, this may not indicate a problem on its own.
> >
> > It seems to be an infinite loop, always returning EINTR because
> > of regular SIGALRM delivery.
>
> That does sound like the GPU locks up. Do you get any messages in dmesg
> about lockups and attempts to reset the GPU at any time?
No.
Gabriel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox