* Re: [git pull] Please pull powerpc.git merge branch
From: Sean MacLennan @ 2008-08-05 6:27 UTC (permalink / raw)
Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080805021205.438365c0@lappy.seanm.ca>
False alarm. They hardcoded the arch into the include. So
#include <asm-powerpc/time.h>
no longer works but
#include <asm/time.h>
does. This is an artifact from when we where trying to use arch/ppc.
Cheers,
Sean
^ permalink raw reply
* Quick question about dts
From: M. Warner Losh @ 2008-08-05 6:56 UTC (permalink / raw)
To: linuxppc-embedded
I have a .dts file that works with 2.6.18 (MV Pro 5.0). I encode it
directly into the kernel image. However, when I try to use it with my
2.6.23, 2.6.24 or 2.6.25 kernel trees, it doesn't work at all. In the
MV Pro 5.0 kernel, I hacked the startup sequence to store a pointer to
this blob in r3 so that it is moved in. I've done something similar
in -current (for reasons that are too complicated to really explain
well, we can't do this via the normal boot loader mechanisms). The
dtc complains that the interrupt-controller property is obsolete on
the chosen device.
Does any documentation exist for how dts has evolved? I'd like to
forward port what I have without examining the .dts files from both
versions and guessing...
Warner
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Benjamin Herrenschmidt @ 2008-08-05 7:16 UTC (permalink / raw)
To: Paul Collins
Cc: J. Bruce Fields, Neil Brown, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <871w145ar3.fsf@burly.wgtn.ondioline.org>
On Tue, 2008-08-05 at 16:47 +1200, Paul Collins wrote:
> It's about four years old. It was in storage for about six months and I
> got it repaired a few weeks ago (display cable and inverter). The sort
> of crazy crap I've been reporting certainly smacks of memory corruption.
> But on the other hand, 2.6.25 (Debian's) and 2.6.26 (my own) have been
> trouble-free.
Any chance you can bisect the problem ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
From: Stephen Rothwell @ 2008-08-05 7:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080805062012.2A161DDE1A@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
Hi Ben,
Just a trivial note ..
On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> +++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05 16:09:47.000000000 +1000
> @@ -18,7 +18,7 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> -#undef DEBUG
> +#define DEBUG
You will turn this off again before it goes into Paulus' tree, right? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Quick question about dts
From: Marco Stornelli @ 2008-08-05 7:35 UTC (permalink / raw)
To: M. Warner Losh; +Cc: linuxppc-embedded
In-Reply-To: <20080805.005649.1713918190.imp@bsdimp.com>
M. Warner Losh ha scritto:
> I have a .dts file that works with 2.6.18 (MV Pro 5.0). I encode it
> directly into the kernel image. However, when I try to use it with my
> 2.6.23, 2.6.24 or 2.6.25 kernel trees, it doesn't work at all. In the
> MV Pro 5.0 kernel, I hacked the startup sequence to store a pointer to
> this blob in r3 so that it is moved in. I've done something similar
> in -current (for reasons that are too complicated to really explain
> well, we can't do this via the normal boot loader mechanisms). The
> dtc complains that the interrupt-controller property is obsolete on
> the chosen device.
>
> Does any documentation exist for how dts has evolved? I'd like to
> forward port what I have without examining the .dts files from both
> versions and guessing...
>
> Warner
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Check out the kernel documentation booting-without-of.txt of your version.
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
From: Benjamin Herrenschmidt @ 2008-08-05 8:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080805172803.1c556b37.sfr@canb.auug.org.au>
On Tue, 2008-08-05 at 17:28 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> Just a trivial note ..
>
> On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > +++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05 16:09:47.000000000 +1000
> > @@ -18,7 +18,7 @@
> > * 2 of the License, or (at your option) any later version.
> > */
> >
> > -#undef DEBUG
> > +#define DEBUG
>
> You will turn this off again before it goes into Paulus' tree, right? :-)
Ahah ! Good catch :-)
Yup, I will. I forgot to add RFC in fact, as this is what that patch is
at least for today. I need to run a few more tests tomorrow before
paulus merges it.
Cheers,
Ben.
^ permalink raw reply
* gianfar on mpc8313
From: Dominik Bozek @ 2008-08-05 8:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
do someone know how to speedup the gianfar on mpc8313? (core:333MHz,
csb:133MHz, ddr:266MHz)
I'm able to achieve 56MB/s (from device) and 48MB/s (to device), but
only if the ethernet interface use jumbo packets (mtu 9000). With
default mtu the transfers are 33MB/s and 27MB/s.
I'm using kernel 2.6.20 + patches from freescale, but I make some tests
with 2.6.26 (eg. because of DMA engine support). I haven't notice any
improvement in the transfer (I don't take care about cpu usage).
Is there anybody who got higher transfers? Can you share some information?
--
Regards
Domino
^ permalink raw reply
* Run Linux Kernel 2.6.26 with u-boot 1.1.2 - problem
From: Zhivko Yordanov @ 2008-08-05 9:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a PowerPC embedded board with CPU 7448 and Chipset Marvell 64560.
Till now, on board runs U-boot 1.1.2 and Linux kernel 2.6.12, with patches
from Marvell.
I ported the Marvell patch to Linux 2.6.26, but I can't start it. Now I'm
searching for the problem. Is this possible with old u-boot (1.1.2) to start
new versions of Linux kernel, or I need to port u-boot too?
Best regards,
Zhivko Yordanov
^ permalink raw reply
* Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
From: Sebastien Dugue @ 2008-08-05 8:26 UTC (permalink / raw)
To: benh
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217898226.24157.120.camel@pasglop>
Hi Benjamin,
On Tue, 05 Aug 2008 11:03:46 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
> > The radix tree used for fast irq reverse mapping by the XICS is initialized
> > late in the boot process, after the first interrupt (IPI) gets registered
> > and after the first IPI is received.
> >
> > This patch moves the initialization of the XICS radix tree earlier into
> > the boot process in smp_xics_probe() (the mm is already up but no interrupts
> > have been registered at that point) to avoid having to insert a mapping into
> > the tree in interrupt context. This will help in simplifying the locking
> > constraints and move to a lockless radix tree in subsequent patches.
>
> I'm not too happy with the moving of the radix tree init to platform
> code.
>
> The fact that the revmap code uses a radix tree should be mostly
> transparent to the XICS code. I don't like adding this explicit code
> from xics to initialize it.
OK, I'm fine with that.
>
> I think the tree should still be initialized from generic code and it
> can be done as late as we want as interrupts work without the tree being
> there, they are just a bit slower.
>
> I believe the right approach is:
>
> - Remove the populating of the tree from the revmap function as
> you already do
> - Move it to irq_create_mapping() for the normal case
Agreed.
> - For pre-existing interrupt, have the generic code that initializes
> the radix tree walk through all interrupts and setup the revmap for
> them. If that needs locking vs. concurrent irq_create_mapping, it's
> easy to use one of the available spinlocks for that.
That's what I wanted to avoid to not add some new complexity, but I can
see that my approach makes some assumptions about initializations order
that I'm no longer comfortable with. Will do as you suggest as it's
way more explicit.
Thanks a lot for your comments.
Sebastien.
>
> Cheers,
> Ben.
>
>
> > Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Michael Ellerman <michael@ellerman.id.au>
> > ---
> > arch/powerpc/kernel/irq.c | 17 -----------------
> > arch/powerpc/platforms/pseries/smp.c | 1 +
> > arch/powerpc/platforms/pseries/xics.c | 5 +++++
> > arch/powerpc/platforms/pseries/xics.h | 1 +
> > 4 files changed, 7 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index d972dec..9bef9f3 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -1016,23 +1016,6 @@ void irq_early_init(void)
> > get_irq_desc(i)->status |= IRQ_NOREQUEST;
> > }
> >
> > -/* We need to create the radix trees late */
> > -static int irq_late_init(void)
> > -{
> > - struct irq_host *h;
> > - unsigned long flags;
> > -
> > - irq_radix_wrlock(&flags);
> > - list_for_each_entry(h, &irq_hosts, link) {
> > - if (h->revmap_type == IRQ_HOST_MAP_TREE)
> > - INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
> > - }
> > - irq_radix_wrunlock(flags);
> > -
> > - return 0;
> > -}
> > -arch_initcall(irq_late_init);
> > -
> > #ifdef CONFIG_VIRQ_DEBUG
> > static int virq_debug_show(struct seq_file *m, void *private)
> > {
> > diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
> > index 9d8f8c8..3d4429a 100644
> > --- a/arch/powerpc/platforms/pseries/smp.c
> > +++ b/arch/powerpc/platforms/pseries/smp.c
> > @@ -130,6 +130,7 @@ static void smp_xics_message_pass(int target, int msg)
> >
> > static int __init smp_xics_probe(void)
> > {
> > + xics_radix_revmap_init();
> > xics_request_IPIs();
> >
> > return cpus_weight(cpu_possible_map);
> > diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
> > index 0fc830f..d6e28f9 100644
> > --- a/arch/powerpc/platforms/pseries/xics.c
> > +++ b/arch/powerpc/platforms/pseries/xics.c
> > @@ -556,6 +556,11 @@ static struct irq_host_ops xics_host_ops = {
> > .xlate = xics_host_xlate,
> > };
> >
> > +void __init xics_radix_revmap_init(void)
> > +{
> > + INIT_RADIX_TREE(&xics_host->revmap_data.tree, GFP_ATOMIC);
> > +}
> > +
> > static void __init xics_init_host(void)
> > {
> > if (firmware_has_feature(FW_FEATURE_LPAR))
> > diff --git a/arch/powerpc/platforms/pseries/xics.h b/arch/powerpc/platforms/pseries/xics.h
> > index 1c5321a..11490be 100644
> > --- a/arch/powerpc/platforms/pseries/xics.h
> > +++ b/arch/powerpc/platforms/pseries/xics.h
> > @@ -19,6 +19,7 @@ extern void xics_setup_cpu(void);
> > extern void xics_teardown_cpu(void);
> > extern void xics_kexec_teardown_cpu(int secondary);
> > extern void xics_cause_IPI(int cpu);
> > +extern void xics_radix_revmap_init(void);
> > extern void xics_request_IPIs(void);
> > extern void xics_migrate_irqs_away(void);
> >
>
>
^ permalink raw reply
* Re: PS3 early lock-up
From: Geert Uytterhoeven @ 2008-08-05 9:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux/PPC Development
In-Reply-To: <1217900430.24157.142.camel@pasglop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1072 bytes --]
On Tue, 5 Aug 2008, Benjamin Herrenschmidt wrote:
> > > Can you find out where that stupid value comes from ?
> >
> > I didn't have time to look at in detail, but it fails from the
> > ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c):
> >
> > htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size,
> > pgprot_val(PAGE_READONLY_X));
> >
> > IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is
> > why I used pgprot_val(PAGE_READONLY_X) here.
>
> Why are you mapping it in the first place btw ? Do you actually use that
> mapping ?
arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-05 9:43 UTC (permalink / raw)
To: michael; +Cc: Neil Brown, nfsv4, linux-kernel, J. Bruce Fields, linuxppc-dev
In-Reply-To: <1217910862.7951.22.camel@localhost>
Michael Ellerman <michael@ellerman.id.au> writes:
> I see you have FTRACE enabled. That's new and could potentially bugger
> things up without the compiler knowing, so can you turn that off.
With FTRACE disabled, doing cross-builds from the 2.6.26 amd64 client, a
setup that normally triggers the problem on the 2nd or 3rd build, I was
able to do 10 complete builds. ("make clean oldconfig vmlinux modules")
So it looks like ftrace is the cause, or at least provokes some other
usually-latent problem. I wasn't using it, so I'll just leave it off.
> And can you enable CONFIG_CODE_PATCHING_SELFTEST and
> CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed
> that /could/ (maybe) cause random blow ups.
With those options enabled, I get this:
Running code patching self-tests ...
Running feature fixup self-tests ...
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: floating point support in the driver.
From: Misbah khan @ 2008-08-05 9:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <48969805.40904@ovro.caltech.edu>
Hi David ,
Thank you for your reply.
I am running the algorithm on OMAP processor (arm-core) and i did tried the
same on iMX processor which takes 1.7 times more than OMAP.
It is true that the algorithm is performing the vector operation which is
blowing the cache .
But the question is How to lock the cache ? In driver how should we
implement the same ?
An example code or a document could be helpful in this regard.
--- Misbah <><
David Hawkins-3 wrote:
>
>
> Hi Misbah,
>
> I would recommend you look at your floating-point code again
> and benchmark each section. You should be able to estimate
> the number of clock cycles required to complete an operation
> and then check that against your measurements.
>
> Depending on whether your algorithm is processing intensive
> or data movement intensive, you may find that the big time
> waster is moving data on or off chip, or perhaps its a large
> vector operation that is blowing out the cache. If you
> do find that, then on some processors you can lock the
> cache, so your algorithm would require a custom driver
> that steals part of the cache from the OS, but the floating point
> code would not run in the kernel, it would run on data
> stored in the stolen cache area. You can lock both instructions
> and data in the cache; eg. an FFT routine can be locked in
> the instruction cache, while FFT data is in the data cache.
> I'm not sure how easy this is to do under Linux though.
>
> Here's an example of the level of detail you can get
> downto when benchmarking code:
>
> http://www.ovro.caltech.edu/~dwh/correlator/pdf/dsp_programming.pdf
>
> The FFT routine used on this processor made use of both
> the instruction and data cache (on-chip SRAM) on the
> DSP.
>
> This code is being re-developed to run on a MPC8349EA PowerPC
> with FPU. I did some initial testing to confirm that the
> FPU operates as per the data sheet, and will eventually get
> around to more complete testing.
>
> Which processor were you running your code on, and what
> frequency were you operating the processor at? How does
> the algorithm timing compare when run on other processors,
> eg. your desktop or laptop machine?
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18827857.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: PS3 early lock-up
From: Benjamin Herrenschmidt @ 2008-08-05 10:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.64.0808051142160.18419@vixen.sonytel.be>
> arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
Ah, I missed that one. Indeed it -is- used.
Ok, that leaves us with 2 options:
- Change ps3_hpte_updatepp() to not read from the hash table via that
mapping (ie, do you have an LV1 call to read an HPTE ? Do you measure
any significant performance loss using that instead ? updatepp shouldn't
be something called -that- often).
- Add a way to setup HPTEs using 3 PPP bits. I'm not going to implement
that for the main hash code just yet though (the assembly) but it might
be possible to implement it specifically for mappings bolted. That
means it would only work when the mapping is done early but on PS3, we
know that the hash table is always mapped early.
The later would be a matter of taking my htab_convert_pte_flags() function
and making it capable, when _PAGE_USER is _not_ set and _PAGE_RW is not
set neither, to set PPP to 110.
You could do that by adding:
if (!(pteflags & (_PAGE_USER | _PAGE_RW)))
rflags |= (1 << 1) | (1 << 63);
Dbl check that the resulting mapping isn't accessible to user space though.
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
From: Sebastien Dugue @ 2008-08-05 8:27 UTC (permalink / raw)
To: benh
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217898303.24157.122.camel@pasglop>
On Tue, 05 Aug 2008 11:05:03 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > - Remove the populating of the tree from the revmap function as
> > you already do
> > - Move it to irq_create_mapping() for the normal case
> > - For pre-existing interrupt, have the generic code that initializes
> > the radix tree walk through all interrupts and setup the revmap for
> > them. If that needs locking vs. concurrent irq_create_mapping, it's
> > easy to use one of the available spinlocks for that.
>
> And in fact, you may even be able to avoid GFP_ATOMIC completely here
> and switch it to GFP_KERNEL since irq_create_mapping() can sleep afaik,
> provided that you avoid the spinlocking.
Well, maybe, will have to look into this in details.
Thanks,
Sebastien.
>
> Ben.
>
>
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc - Make the irq reverse mapping radix tree lockless
From: Sebastien Dugue @ 2008-08-05 8:28 UTC (permalink / raw)
To: Daniel Walker
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217867496.3946.33.camel@localhost.localdomain>
On Mon, 04 Aug 2008 09:31:36 -0700 Daniel Walker <dwalker@mvista.com> wrote:
> On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
>
> > --- a/arch/powerpc/include/asm/irq.h
> > +++ b/arch/powerpc/include/asm/irq.h
> > @@ -119,6 +119,7 @@ struct irq_host {
> > } linear;
> > struct radix_tree_root tree;
> > } revmap_data;
> > + spinlock_t tree_lock;
>
> You have a tabbing issue above..
Yuck, right.
Thanks,
Sebastien.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-08-05 11:11 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <1217884211.20260.144.camel@nimitz>
On (04/08/08 14:10), Dave Hansen didst pronounce:
> On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
> > We are a lot more reliable than we were although exact quantification is
> > difficult because it's workload dependent. For a long time, I've been able
> > to test bits and pieces with hugepages by allocating the pool at the time
> > I needed it even after days of uptime. Previously this required a reboot.
>
> This is also a pretty big expansion of fs/hugetlb/ use outside of the
> filesystem itself. It is hacking the existing shared memory
> kernel-internal user to spit out effectively anonymous memory.
>
> Where do we draw the line where we stop using the filesystem for this?
> Other than the immediate code reuse, does it gain us anything?
>
> I have to think that actually refactoring the filesystem code and making
> it usable for really anonymous memory, then using *that* in these
> patches would be a lot more sane. Especially for someone that goes to
> look at it in a year. :)
>
See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
To get that right between children, you end up something very fs-like
when the child needs to fault in a page that is already populated by the
parent. I strongly suspect we end up back at hugetlbfs backing it :/
If you were going to do such a thing, you'd end up converting something
like ramfs to hugetlbfs and sharing that.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: PS3 early lock-up
From: Benjamin Herrenschmidt @ 2008-08-05 11:31 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <1217932117.24157.185.camel@pasglop>
> You could do that by adding:
>
> if (!(pteflags & (_PAGE_USER | _PAGE_RW)))
> rflags |= (1 << 1) | (1 << 63);
>
> Dbl check that the resulting mapping isn't accessible to user space though.
Make these 1UL << x, and a proper patch would have to also test
that the CPU supports the 3rd PP bit. We probably need to add
a CPU feature bit for that.
Ben.
^ permalink raw reply
* 64-bit build failure without hugetlbfs
From: Johannes Berg @ 2008-08-05 11:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
LD vmlinux.o
mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
(.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here
mm/built-in.o: In function `arch_get_unmapped_area_topdown':
(.opd+0x2730): multiple definition of `arch_get_unmapped_area_topdown'
arch/powerpc/mm/built-in.o:(.opd+0x918): first defined here
mm/built-in.o: In function `.arch_get_unmapped_area':
(.text+0x1ce3c): multiple definition of `.arch_get_unmapped_area'
arch/powerpc/mm/built-in.o:(.text+0x72b8): first defined here
mm/built-in.o: In function `arch_get_unmapped_area':
(.opd+0x2718): multiple definition of `arch_get_unmapped_area'
arch/powerpc/mm/built-in.o:(.opd+0x930): first defined here
make: *** [vmlinux.o] Error 1
enabling hugetlbfs cures it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Michael Ellerman @ 2008-08-05 11:53 UTC (permalink / raw)
To: Paul Collins
Cc: Neil Brown, linux-kernel, J. Bruce Fields, linuxppc-dev,
Steven Rostedt
In-Reply-To: <87zlnrer06.fsf@burly.wgtn.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
On Tue, 2008-08-05 at 21:43 +1200, Paul Collins wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
>
> > I see you have FTRACE enabled. That's new and could potentially bugger
> > things up without the compiler knowing, so can you turn that off.
>
> With FTRACE disabled, doing cross-builds from the 2.6.26 amd64 client, a
> setup that normally triggers the problem on the 2nd or 3rd build, I was
> able to do 10 complete builds. ("make clean oldconfig vmlinux modules")
>
> So it looks like ftrace is the cause, or at least provokes some other
> usually-latent problem. I wasn't using it, so I'll just leave it off.
OK, that's sort of good, but also not. I can't see anything in the
ftrace code that explains it, but I guess it's lurking. We'll try and
reproduce locally and bang on it.
Thanks for chasing it, and let us know if you get an oops with
CONFIG_FTRACE=n.
> > And can you enable CONFIG_CODE_PATCHING_SELFTEST and
> > CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed
> > that /could/ (maybe) cause random blow ups.
>
> With those options enabled, I get this:
>
> Running code patching self-tests ...
> Running feature fixup self-tests ...
That's good, they only print if they fail.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* linux kernel under psim (powerpc emulator)
From: Mihaela Grigore @ 2008-08-05 13:04 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Has anyone tried or knows if it is possible to run a 2.6 linux kernel
under psim?
ps: please add me in cc in a reply to this message.
^ permalink raw reply
* Re: 64-bit build failure without hugetlbfs
From: Sebastien Dugue @ 2008-08-05 13:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1217936390.3603.34.camel@johannes.berg>
On Tue, 05 Aug 2008 13:39:49 +0200 Johannes Berg <johannes@sipsolutions.net> wrote:
> LD vmlinux.o
> mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
> (.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
> arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here
> mm/built-in.o: In function `arch_get_unmapped_area_topdown':
> (.opd+0x2730): multiple definition of `arch_get_unmapped_area_topdown'
> arch/powerpc/mm/built-in.o:(.opd+0x918): first defined here
> mm/built-in.o: In function `.arch_get_unmapped_area':
> (.text+0x1ce3c): multiple definition of `.arch_get_unmapped_area'
> arch/powerpc/mm/built-in.o:(.text+0x72b8): first defined here
> mm/built-in.o: In function `arch_get_unmapped_area':
> (.opd+0x2718): multiple definition of `arch_get_unmapped_area'
> arch/powerpc/mm/built-in.o:(.opd+0x930): first defined here
> make: *** [vmlinux.o] Error 1
>
> enabling hugetlbfs cures it.
>
> johannes
Or disabling CONFIG_PPC_64K_PAGES if you do not want to enable hugetlbfs...
Sebastien.
^ permalink raw reply
* Re: Run Linux Kernel 2.6.26 with u-boot 1.1.2 - problem
From: Marco Stornelli @ 2008-08-05 13:22 UTC (permalink / raw)
To: Zhivko Yordanov; +Cc: linuxppc-embedded
In-Reply-To: <200808051109.20398.jivkojj@uni-kassel.de>
Zhivko Yordanov ha scritto:
> Hi all,
>
> I have a PowerPC embedded board with CPU 7448 and Chipset Marvell 64560.
> Till now, on board runs U-boot 1.1.2 and Linux kernel 2.6.12, with patches
> from Marvell.
>
> I ported the Marvell patch to Linux 2.6.26, but I can't start it. Now I'm
> searching for the problem. Is this possible with old u-boot (1.1.2) to start
> new versions of Linux kernel, or I need to port u-boot too?
>
> Best regards,
> Zhivko Yordanov
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Have you wrote the dts file? I suggest you to change Uboot, 1.1.2 is
pretty old and if I remember correctly it doesn't support the dts, so
you should build a cuImage with the dts embedded in the kernel.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* hang w/ppc6xx_defconfig related to 'simple-bus' compatible
From: Kumar Gala @ 2008-08-05 13:21 UTC (permalink / raw)
To: ppc-dev list
I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600)
system. If I remove the 'simple-bus' compatible from the soc node in
the .dts it works. Otherwise it hangs at but and looks to be crashed
in the serial driver due to accessing memory at 0.
I've tried the same .dts (w/'simple-bus') using the
mpc8641_hpcn_defconfig and things work.
Any one got any ideas?
- k
^ permalink raw reply
* [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
From: Michael Ellerman @ 2008-08-05 13:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Milton Miller
In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the irq when we originally
received it - when it was spurious.
This can be reproduced trivially by banging the keyboard while kexec'ing on
a P5 LPAR, even though the hvc_console driver request's the console irq later
in boot, the console is non-functional because we're receiving no console
interrupts.
So when we receive a spurious irq, EOI it, and then mask it.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/xics.c | 29 ++++++++++++++++++++---------
1 files changed, 20 insertions(+), 9 deletions(-)
Probably 27 material unless there are objections ..
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..dc007f4 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -321,21 +321,26 @@ static unsigned int xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+ iosync();
+ direct_xirr_info_set((0xff << 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+ xics_eoi_hwirq_direct((unsigned int)irq_map[virq].hwirq);
+}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
- direct_xirr_info_set((0xff << 24) | irq);
+ lpar_xirr_info_set((0xff << 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
- iosync();
- lpar_xirr_info_set((0xff << 24) | irq);
+ xics_eoi_hwirq_lpar((unsigned int)irq_map[virq].hwirq);
}
static inline unsigned int xics_remap_irq(unsigned int vec)
@@ -350,9 +355,15 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
if (likely(irq != NO_IRQ))
return irq;
- printk(KERN_ERR "Interrupt %u (real) is invalid,"
- " disabling it.\n", vec);
+ pr_err("%s: no mapping for hwirq %u, disabling it.\n", __func__, vec);
+
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ xics_eoi_hwirq_lpar(vec);
+ else
+ xics_eoi_hwirq_direct(vec);
+
xics_mask_real_irq(vec);
+
return NO_IRQ;
}
--
1.5.5
^ permalink raw reply related
* [PATCH] ibmebus/of_platform: Move "name" sysfs attribute into generic OF devices
From: Joachim Fenkes @ 2008-08-05 14:30 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-Dev, LKML, David S. Miller
Cc: Stephen Rothwell, Olaf Hering, Paul Mackerras, Christoph Raisch,
Alexander Schmidt, Stefan Roscher
Recent of_platform changes made of_bus_type_init() overwrite the bus type's
.dev_attrs list, so move ibmebus' "name" attribute (which is needed by eHCA
userspace support) into generic OF device code. Tested on POWER.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
arch/powerpc/kernel/ibmebus.c | 12 ------------
drivers/of/device.c | 10 ++++++++++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9d42eb5..a063622 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -233,17 +233,6 @@ void ibmebus_free_irq(u32 ist, void *dev_id)
}
EXPORT_SYMBOL(ibmebus_free_irq);
-static ssize_t name_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%s\n", to_of_device(dev)->node->name);
-}
-
-static struct device_attribute ibmebus_dev_attrs[] = {
- __ATTR_RO(name),
- __ATTR_NULL
-};
-
static char *ibmebus_chomp(const char *in, size_t count)
{
char *out = kmalloc(count + 1, GFP_KERNEL);
@@ -327,7 +316,6 @@ static struct bus_attribute ibmebus_bus_attrs[] = {
struct bus_type ibmebus_bus_type = {
.uevent = of_device_uevent,
- .dev_attrs = ibmebus_dev_attrs,
.bus_attrs = ibmebus_bus_attrs
};
EXPORT_SYMBOL(ibmebus_bus_type);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8a1d93a..51e5214 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -57,6 +57,15 @@ static ssize_t devspec_show(struct device *dev,
return sprintf(buf, "%s\n", ofdev->node->full_name);
}
+static ssize_t name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev;
+
+ ofdev = to_of_device(dev);
+ return sprintf(buf, "%s\n", ofdev->node->name);
+}
+
static ssize_t modalias_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -71,6 +80,7 @@ static ssize_t modalias_show(struct device *dev,
struct device_attribute of_platform_device_attrs[] = {
__ATTR_RO(devspec),
+ __ATTR_RO(name),
__ATTR_RO(modalias),
__ATTR_NULL
};
--
1.5.5
^ 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