* Re: [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Shaun Ruffell @ 2011-04-15 3:45 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4DA78A44.1000704@windriver.com>
On 4/14/11 6:59 PM, Paul Gortmaker wrote:
> On 11-04-14 06:27 PM, Shaun Ruffell wrote:
>> This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
>
> A fix was already sent yesterday:
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-April/089559.html
>
> which relocates the stub function to where it needs to be. Your fix
> below would end up making duplicate stub functions.
Thanks for the reply. I didn't search the linuxppp-dev list before
sending in that patch, only the LKML. Sorry about the noise.
Cheers,
Shaun
^ permalink raw reply
* Re: [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Paul Gortmaker @ 2011-04-14 23:59 UTC (permalink / raw)
To: Shaun Ruffell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20110414222719.GA16256@digium.com>
On 11-04-14 06:27 PM, Shaun Ruffell wrote:
> This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
A fix was already sent yesterday:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-April/089559.html
which relocates the stub function to where it needs to be. Your fix
below would end up making duplicate stub functions.
Thanks,
Paul.
> "powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP" which resulted in
>
> arch/powerpc/kernel/crash.c: In function ‘default_machine_crash_shutdown’:
> arch/powerpc/kernel/crash.c:349: error: implicit declaration of function
> ‘crash_kexec_wait_realmode’
>
> message on when compiling on Blue&White G3 and CONFIG_SMP is not defined.
>
> Signed-off-by: Shaun Ruffell <sruffell@digium.com>
> ---
> arch/powerpc/kernel/crash.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 3d3d416..5e6e37f 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -255,6 +255,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
> {
> cpus_in_sr = CPU_MASK_NONE;
> }
> +
> +static inline void crash_kexec_wait_realmode(int cpu) {}
> +
> #endif
>
> /*
^ permalink raw reply
* Non-console UART issues with 8xx
From: Eran Duchan @ 2011-04-14 23:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Hey list
I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is a
general purpose UART (DTS is set up accordingly). No hardware or software
flow control for either.
The issue is simple: the non-console UART transmits garbled characters at
the end of the transmission. For example, set up SMC1 to console (works
perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something like
"1234567ø". Set the SCC4 as console (same baud rates) and the problem is
reversed (SCC4 works perfect, SMC1 transmit garbled).
Rx direction seems fine, after some rudementary testing.
I dived into the code and see that the console UART has a completely
different initialization sequence than the non-console UART. Short of diving
into this ancient CPM architecture - does anyone have an idea?
Thanks
Eran
[-- Attachment #2: Type: text/html, Size: 1159 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Shaun Ruffell @ 2011-04-14 22:27 UTC (permalink / raw)
To: Paul Gortmaker, Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
"powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP" which resulted in
arch/powerpc/kernel/crash.c: In function =E2=80=98default_machine_crash_s=
hutdown=E2=80=99:
arch/powerpc/kernel/crash.c:349: error: implicit declaration of functio=
n
=E2=80=98crash_kexec_wait_realmode=E2=80=99
message on when compiling on Blue&White G3 and CONFIG_SMP is not defined.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
---
arch/powerpc/kernel/crash.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d3d416..5e6e37f 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -255,6 +255,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
{
cpus_in_sr =3D CPU_MASK_NONE;
}
+
+static inline void crash_kexec_wait_realmode(int cpu) {}
+
#endif
=20
/*
--=20
1.7.4.3
^ permalink raw reply related
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Mikael Pettersson @ 2011-04-14 22:14 UTC (permalink / raw)
To: Hugh Dickins
Cc: Mikael Pettersson, Jens Axboe, linux-kernel, kevin diggs,
linuxppc-dev
In-Reply-To: <BANLkTimykvKp=bwsFyNE9fWqcE9Ffws6bA@mail.gmail.com>
On Thu, 14 Apr 2011 14:25:31 -0700, Hugh Dickins wrote:
> Mikael,
>
> Something worth trying: turn off CONFIG_IDE. That's what I need to
> boot 2.6.39-rc[1-3] on PowerPC G5.
>
> I know Jens has been fixing problems with IDE versus his plug/unplug
> changes, but it's still not fixed for me in rc3.
>
> In other mail http://lkml.org/lkml/2011/4/14/614
> I see Linus recommending his post-rc3 commit 6631e635c65d
> but I've not tried that myself yet.
>
> Hugh
Hugh,
With CONFIG_IDE disabled I could finally boot 2.6.39-rc3 on my G5.
I lost the DVD drive, but that's fine for now.
Thanks!
/Mikael
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Benjamin Herrenschmidt @ 2011-04-14 21:54 UTC (permalink / raw)
To: Hugh Dickins
Cc: Mikael Pettersson, Jens Axboe, linux-kernel, kevin diggs,
linuxppc-dev
In-Reply-To: <BANLkTimykvKp=bwsFyNE9fWqcE9Ffws6bA@mail.gmail.com>
On Thu, 2011-04-14 at 14:25 -0700, Hugh Dickins wrote:
>
> Something worth trying: turn off CONFIG_IDE. That's what I need to
> boot 2.6.39-rc[1-3] on PowerPC G5.
>
> I know Jens has been fixing problems with IDE versus his plug/unplug
> changes, but it's still not fixed for me in rc3.
>
> In other mail http://lkml.org/lkml/2011/4/14/614
> I see Linus recommending his post-rc3 commit 6631e635c65d
> but I've not tried that myself yet.
Well, the disk is SATA so it's CONFIG_ATA/libata, which works fine here,
unless you somewhat replaced your CD-ROM with a legacy IDE disk :-) Or
maybe the problem is related to the CD-ROM drive. There's a libata
driver for it nowadays, so you can use PATA_MACIO instead of IDE_PMAC
Cheers,
Ben.
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Hugh Dickins @ 2011-04-14 21:25 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: Jens Axboe, linux-kernel, kevin diggs, linuxppc-dev
In-Reply-To: <1302771756.15520.100.camel@thor.local>
On Thu, Apr 14, 2011 at 2:02 AM, Michel D=C3=A4nzer <michel@daenzer.net> wr=
ote:
> On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote:
>>
>> 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.
>
> FWIW, the problem Ben refers to might be fixed in current mainline by
> commit d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d which reverts
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 .
Mikael,
Something worth trying: turn off CONFIG_IDE. That's what I need to
boot 2.6.39-rc[1-3] on PowerPC G5.
I know Jens has been fixing problems with IDE versus his plug/unplug
changes, but it's still not fixed for me in rc3.
In other mail http://lkml.org/lkml/2011/4/14/614
I see Linus recommending his post-rc3 commit 6631e635c65d
but I've not tried that myself yet.
Hugh
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-14 19:21 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF71C64301.E54A0A3C-ONC1257872.005BD121-C1257872.005C754F@transmode.se>
>
> Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/14 17:59:30:
> >
> > Hi Joakim,
> >
> > On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > > > 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?
> >
> > No, addresses seem to be correct. I checked a bit further (I'm quite new to
> > the MPC8xx MMU) and it seems that trying to modify the code (that's the
> > destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
> > why this is the case. Perhaps an 8xx guru might chime in here. ;)
> >
> > BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
> > With this option enabled, the dynamic code modification works just fine.
> >
> > Joakim, Scott? Any ideas on this?
>
> hmm, I guess 8xx really maps kernel RO as RO :) Try
> changing in pte-8xx.h:
> - #define _PAGE_KERNEL_RO (_PAGE_SHARED)
> + #define _PAGE_KERNEL_RO (_PAGE_RW |_PAGE_SHARED)
hmm, I wonder if not this is the problem(in pte-common.h)
#if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH) ||\
defined(CONFIG_KPROBES)
#define PAGE_KERNEL_TEXT PAGE_KERNEL_X
#else
#define PAGE_KERNEL_TEXT PAGE_KERNEL_ROX
#endif
What is PAGE_KERNEL_TEXT for you?
I think it must be PAGE_KERNEL_X, otherwise kernel text will be readonly.
Jocke
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-14 16:49 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104141759.30446.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/14 17:59:30:
>
> Hi Joakim,
>
> On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > > 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?
>
> No, addresses seem to be correct. I checked a bit further (I'm quite new to
> the MPC8xx MMU) and it seems that trying to modify the code (that's the
> destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
> why this is the case. Perhaps an 8xx guru might chime in here. ;)
>
> BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
> With this option enabled, the dynamic code modification works just fine.
>
> Joakim, Scott? Any ideas on this?
hmm, I guess 8xx really maps kernel RO as RO :) Try
changing in pte-8xx.h:
- #define _PAGE_KERNEL_RO (_PAGE_SHARED)
+ #define _PAGE_KERNEL_RO (_PAGE_RW |_PAGE_SHARED)
^ permalink raw reply
* Re: PowerMacintosh B&W G3 boot failure - linux-2.6.36.x
From: acrux @ 2011-04-14 16:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Nello M, linuxppc-dev
In-Reply-To: <1302749356.28876.105.camel@pasglop>
On Thu, 14 Apr 2011 12:49:16 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 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...
>
I know, I received from it from a user. It's where the kernel hangs.
Anyway, the last year, i received many install failures report from
cruxppc users. I hope it's only my fault building the bootkernel and
i'd like to receive a feedback from others distro developers for this
specific machine.
I always avoided to collect obsolete machines thus I don't have a B&W G3
but now i'm looking for one.
> 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.
>
I'll try to receive more detailed info from that gentle user.
Thanks again for your kind support,
Nico
--
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Stefan Roese @ 2011-04-14 15:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF832AEAAB.68C38F85-ONC1257871.0055965D-C1257871.0055E1C2@transmode.se>
Hi Joakim,
On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > 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?
No, addresses seem to be correct. I checked a bit further (I'm quite new to
the MPC8xx MMU) and it seems that trying to modify the code (that's the
destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
why this is the case. Perhaps an 8xx guru might chime in here. ;)
BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
With this option enabled, the dynamic code modification works just fine.
Joakim, Scott? Any ideas on this?
Thanks,
Stefan
^ permalink raw reply
* Re: fsl elbc driver causes corruption with bus monitor timeouts while simultaneously access on Nor / Nand mtd partitions
From: Felix Radensky @ 2011-04-14 12:10 UTC (permalink / raw)
To: emre kara
Cc: Wood Scott-B07421, David Woodhouse, linux-kernel, bayraktarz,
Lan Chunhe-B25806, linux-mtd@lists.infradead.org, Scott Wood,
linuxppc-dev
In-Reply-To: <204286.97927.qm@web25602.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/html, Size: 1101 bytes --]
^ permalink raw reply
* Re: Where is CONFIG_BOOT_LOAD ?
From: Guillaume Dargaud @ 2011-04-14 9:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4DA485CD.6060604@gmx.de>
On Tuesday 12 April 2011 19:03:09 Joachim F=F6rster wrote:
> Note that the default 0x400... is the link address of the zImage wrapper
> rather than the one of THE kernel.
Yes, and I need more space for the uncompression to take place when using a=
ramdisk.
> 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 ;-) ...
Thanks for that. I'd been using "objcopy --change-addresses" to relocate th=
e elf file with success.
> Is configuring the zImage-piggy-back-loader through menuconfig & co evil?
That seems like a good idea. Maybe add some way to figure out if the uncomp=
ressed kernel overlaps the zImage wrapper ?
=2D-=20
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Michel Dänzer @ 2011-04-14 9:02 UTC (permalink / raw)
To: kevin diggs; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <BANLkTika8FY1dD_hOQ4wMhHzuQ2Qt8fg7A@mail.gmail.com>
On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote:=20
>=20
> 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.
> >
> >
>=20
> 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.
>=20
> I kinda need a break from fighting with GCC.
FWIW, the problem Ben refers to might be fixed in current mainline by
commit d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d which reverts
69a07f0b117a40fcc1a479358d8e1f41793617f2 .
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* fsl elbc driver causes corruption with bus monitor timeouts while simultaneously access on Nor / Nand mtd partitions
From: emre kara @ 2011-04-14 7:06 UTC (permalink / raw)
To: Scott Wood, Roy Zang
Cc: Wood Scott-B07421, felix, David Woodhouse, linux-kernel,
bayraktarz, Lan Chunhe-B25806, linuxppc-dev
Hi Scott, Roy.
Scott's "mtd: eLBC NAND: increase bus timeout to maximum" patch is excluded=
from kernel with Roy's "P4080/eLBC: Make Freescale elbc interrupt common t=
o elbc devices" patch. I don't know the reason for it but this causes bus m=
onitor timeouts and corrupts nand flash while using mainline kernel. As I k=
now there is an errata related to this topic, I think "increasing bus timeo=
ut to maximum" is a must.
You can easly generate this situation with below commands:
Note: mtd4 is a Nor and mtd9 is a Nand partition.
[root@P2020RDB root]# mount /dev/mtdblock9 /mnt/src/
mount: you must specify the filesystem type
[root@P2020RDB root]# mount /dev/mtdblock9 /mnt/src/ -t jffs2
=EF=BF=BD=EF=BF=BDJFFS2 notice: (1950) jffs2_build_xattr_subsystem: complet=
e building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xr=
ef (0 dead, 0 orphan) found.
[root@P2020RDB root]# dd if=3D/dev/mtd4 of=3D/mnt/src/uboot bs=3D1
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
fsl-lbc ffe05000.localbus: command failed: fir 412e0000 fcr 0 status 800000=
00 mdr c0
Read of newly-erased block at 0x00430000 failed: -74. Putting on bad_list
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
fsl-lbc ffe05000.localbus: command failed: fir 426db000 fcr 6070d000 status=
80000000 mdr ff
Erase at 0x0042c000 failed immediately: errno -5
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
Cfsl-lbc ffe05000.localbus: command failed: fir 412e0000 fcr 0 status 80000=
000 mdr c0
Read of newly-erased block at 0x00433000 failed: -74. Putting on bad_list
JFFS2: marking eraseblock at 00433000
Regards.
Emre
^ permalink raw reply
* [PATCH v4] powerpc: use a kmem cache for DTL buffers
From: Nishanth Aravamudan @ 2011-04-14 5:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302758026-29313-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). 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
Change from v3: handle cache creation failure
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 | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..9e20b83 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -287,14 +287,22 @@ 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);
+ if (!dtl_cache) {
+ pr_warn("Failed to create dispatch trace log buffer cache\n");
+ pr_warn("Stolen time statistics will be unreliable\n");
+ return 0;
+ }
+
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
* [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
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