* Re: [PATCH 1/10] spidernet: skb used after netif_receive_skb
From: Jeff Garzik @ 2007-05-24 21:25 UTC (permalink / raw)
To: Linas Vepstas
Cc: Andrew Morton, netdev, Florin Malita, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20070522230942.GT5921@austin.ibm.com>
Linas Vepstas wrote:
> From: Florin Malita <fmalita@gmail.com>
>
> The stats update code in spider_net_pass_skb_up() is touching the skb
> after it's been passed up to the stack. To avoid that, just update the
> stats first.
>
> Signed-off-by: Florin Malita <fmalita@gmail.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> ----
>
> drivers/net/spider_net.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied to #upstream-fixes
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Arnd Bergmann @ 2007-05-24 21:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1180038295.3360.29.camel@zod.rchland.ibm.com>
On Thursday 24 May 2007, Josh Boyer wrote:
>=20
> > I think it should really use -mcpu=3Dpowerpc on all files.
> > The problem that Dave saw was the result of using a compiler
> > that defaults to -mcpu=3D8540, which uses instruction that
> > don't work on 440.
>=20
> You sure? =A0It griped about isel, and isel is implemented on all 440s
> with the exception of 440GP. =A0Yay for consistency.
strange indeed. -m440 does enable PPC_OPCODE_ISEL in the current
gas version, and probably all old ones as well.
> > The common files really need to be built with -mcpu flags that
> > make the code work on any system if you want to be able
> > to use just a single boot wrapper binary for all.
>=20
> Yeah, it's finding those combinations that work for all the existing
> toolchains out there that's the issue. =A0That, or making the wrapper not
> compile all the platform files... =A0I don't know which makes more sense.
I've looked up the gas source and found two ways that allow us to
compile everywhere:
1. Pass -Wa,-many to gcc
This will really allow any possible instruction to be assembled, including
the old POWER architecture, but also includes all the other strange
stuff like -maltivec, -mspe, -me500, ...
2. protect the use of special instructions with .machine directives.
You can write all the inline assemblies like
.machine push
.machine 440
<440 specific instruction>
.machine pop
This should work in any reasonably recent version of binutils, meaning
that we don't need to pass stuff like -Wa,-m440 any more.
Arnd <><
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Mark A. Greer @ 2007-05-24 21:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1180038295.3360.29.camel@zod.rchland.ibm.com>
On Thu, May 24, 2007 at 03:24:55PM -0500, Josh Boyer wrote:
> On Thu, 2007-05-24 at 22:21 +0200, Arnd Bergmann wrote:
> > On Thursday 24 May 2007, Josh Boyer wrote:
> > The common files really need to be built with -mcpu flags that
> > make the code work on any system if you want to be able
> > to use just a single boot wrapper binary for all.
>
> Yeah, it's finding those combinations that work for all the existing
> toolchains out there that's the issue. That, or making the wrapper not
> compile all the platform files... I don't know which makes more sense.
The number of files in the bootwrapper is bound to grow, there are
so many combinations that will never be used together, and we're
bumping into lots of toolchain issues, that I'm beginning to think
that paring down wrapper.a is the way to go.
Mark
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Josh Boyer @ 2007-05-24 20:24 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705242221.17790.arnd@arndb.de>
On Thu, 2007-05-24 at 22:21 +0200, Arnd Bergmann wrote:
> On Thursday 24 May 2007, Josh Boyer wrote:
> >
> > > Nothing is telling GCC what CPU to compile for, so it
> > > will just use the compiler's default, which very likely
> > > is not what you want. For files that will only ever
> > > be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
> >
> > We could add that to the per-file flags already, right?
>
> I think it should really use -mcpu=powerpc on all files.
> The problem that Dave saw was the result of using a compiler
> that defaults to -mcpu=8540, which uses instruction that
> don't work on 440.
You sure? It griped about isel, and isel is implemented on all 440s
with the exception of 440GP. Yay for consistency.
> The common files really need to be built with -mcpu flags that
> make the code work on any system if you want to be able
> to use just a single boot wrapper binary for all.
Yeah, it's finding those combinations that work for all the existing
toolchains out there that's the issue. That, or making the wrapper not
compile all the platform files... I don't know which makes more sense.
josh
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 20:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1180035543.3360.25.camel@zod.rchland.ibm.com>
>> Nothing is telling GCC what CPU to compile for, so it
>> will just use the compiler's default, which very likely
>> is not what you want. For files that will only ever
>> be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
>
> We could add that to the per-file flags already, right?
Yes, exactly.
Segher
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Arnd Bergmann @ 2007-05-24 20:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1180035543.3360.25.camel@zod.rchland.ibm.com>
On Thursday 24 May 2007, Josh Boyer wrote:
>=20
> > Nothing is telling GCC what CPU to compile for, so it
> > will just use the compiler's default, which very likely
> > is not what you want. =A0For files that will only ever
> > be used on 440, the correct flags are -mcpu=3D440 -Wa,-m440 .
>=20
> We could add that to the per-file flags already, right?
I think it should really use -mcpu=3Dpowerpc on all files.
The problem that Dave saw was the result of using a compiler
that defaults to -mcpu=3D8540, which uses instruction that
don't work on 440.
The common files really need to be built with -mcpu flags that
make the code work on any system if you want to be able
to use just a single boot wrapper binary for all.
Arnd <><
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Josh Boyer @ 2007-05-24 19:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <2ded9f19fbaf49a89ed6e32de87f5828@kernel.crashing.org>
On Thu, 2007-05-24 at 21:05 +0200, Segher Boessenkool wrote:
> > $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> > $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
>
> Probably -Wa,-m440 works better. However...
>
> > /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> > -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> > -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> > /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-
> > linux-gnuspe/4.2.0/include
> > -fPIC -fno-stack-protector -Iarch/powerpc/boot
> > -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot
> > -Wa,-mbooke
> > -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
>
> Nothing is telling GCC what CPU to compile for, so it
> will just use the compiler's default, which very likely
> is not what you want. For files that will only ever
> be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
We could add that to the per-file flags already, right?
josh
^ permalink raw reply
* Re: [PATCH 2.6.21-rt7] PowerPC: fix clockevents for classic CPUs
From: Segher Boessenkool @ 2007-05-24 19:10 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, mingo, tglx, linux-kernel
In-Reply-To: <200705242225.30225.sshtylyov@ru.mvista.com>
> * We must write a positive value to the decrementer to clear
> - * the interrupt on the IBM 970 CPU series. In periodic mode,
> - * this happens when the decrementer gets reloaded later, but
> - * in one-shot mode, we have to do it here since an event handler
> - * may skip loading the new value...
> + * the interrupt on POWER4+ compatible CPUs.
No, it is *not* only on POWER4+ compatible CPUs. Sigh.
Segher
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 19:05 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <4655C7A6.2050606@mvista.com>
> $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
Probably -Wa,-m440 works better. However...
> /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-
> linux-gnuspe/4.2.0/include
> -fPIC -fno-stack-protector -Iarch/powerpc/boot
> -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot
> -Wa,-mbooke
> -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
Nothing is telling GCC what CPU to compile for, so it
will just use the compiler's default, which very likely
is not what you want. For files that will only ever
be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Andy Fleming @ 2007-05-24 18:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <1179960728.32247.953.camel@localhost.localdomain>
On May 23, 2007, at 17:52, Benjamin Herrenschmidt wrote:
>
>> On power up, because this pin is pulled high by the LED, the
>> TXC_RXC_DELAY mode is enabled, causing a 1.9ns delay between the
>> clock
>> and data on the GMII interface. Tsi109 could not operate properly
>> with
>> this delay. The TXC_RXC_DELAY mode has to be disabled by software.
>>
>> If the Quality/TXC_RXC_DELAY pin is left not connected PHY will
>> work in
>> normal mode without delay and therefore the workaround is not
>> required.
>
> Ok, so this is a workaround that is specific to the Holly board...
> interesting. I have to figure out what is the best way of having it
> in a
> "generic" PHY driver for the BCM5461A chip.
Yeah, this is a whole category of thing that the PHY Lib doesn't
handle very well. My problem is that I can envision several
categories of board-specific workarounds:
1) board-specific initialization
2) board-specific fixups after a reset
3) board-specific fixups when changing/reading the PHY link state
4) board-specific interrupt fixups
5) Others I haven't thought of
I'm loathe to turn the PHY code into the PCI code by having almost
every operation call out to board-specific hooks, so it would be good
if we could get it down to one or two.
For instance, I think #1 might usually be workable by passing in PHY-
specific flags, and letting the PHY driver deal with it in
config_init. This might even be workable for the BCM5461A chip as
mentioned above. You could define a BCM5461A_TXC_RXC_DELAY_DISABLE
flag, and have the config_init code check for that flag and perform
the necessary disable.
I had hoped most board-specific situations could be handled that way,
but there's also the case where resetting the PHY requires board code
to respond (by setting a board register, or somesuch).
It's really quite a mess. Any suggestions are quite welcome.
Andy
^ permalink raw reply
* [PATCH 2.6.21-rt7] PowerPC: fix clockevents for classic CPUs
From: Sergei Shtylyov @ 2007-05-24 18:25 UTC (permalink / raw)
To: tglx, mingo; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200705172142.26739.sshtylyov@ru.mvista.com>
Uncoditionally set a maximum positive value to the decrementer before calling
an event handler for all "classic" PPC CPUs (although this is only necessary
to clear interrupt on POWER4+, I've been asked to do it this way) -- otherwise
it wouldn't have been done for an offline CPU in periodic mode since the event
reprogramming has been delegated to the timer subsystem.
Also, as the classic decrementer doesn't have periodic mode, make set_mode()
method for this case completely empty.
While at it, add a switch case for CLOCK_EVT_MODE_RESUME to hush the warning.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
Testing on "classic" CPUs is still needed (used to work atop of 2.6.18-rt7).
arch/powerpc/kernel/time.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -166,11 +166,14 @@ static void decrementer_set_mode(enum cl
case CLOCK_EVT_MODE_SHUTDOWN:
tcr &= ~TCR_DIE;
break;
+ case CLOCK_EVT_MODE_RESUME:
+ break;
}
mtspr(SPRN_TCR, tcr);
-#endif
+
if (mode == CLOCK_EVT_MODE_PERIODIC)
decrementer_set_next_event(tb_ticks_per_jiffy, dev);
+#endif
}
static struct clock_event_device decrementer_clockevent = {
@@ -549,16 +552,12 @@ void timer_interrupt(struct pt_regs * re
irq_enter();
#ifdef CONFIG_GENERIC_CLOCKEVENTS
-#ifdef CONFIG_PPC_MULTIPLATFORM
+#if !defined(CONFIG_40x) && !defined(CONFIG_BOOKE)
/*
* We must write a positive value to the decrementer to clear
- * the interrupt on the IBM 970 CPU series. In periodic mode,
- * this happens when the decrementer gets reloaded later, but
- * in one-shot mode, we have to do it here since an event handler
- * may skip loading the new value...
+ * the interrupt on POWER4+ compatible CPUs.
*/
- if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_MODE_PERIODIC)
- set_dec(DECREMENTER_MAX);
+ set_dec(DECREMENTER_MAX);
#endif
/*
* We can't disable the decrementer, so in the period between
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Josh Boyer @ 2007-05-24 18:09 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4655D353.6000304@ru.mvista.com>
On Thu, 2007-05-24 at 22:02 +0400, Sergei Shtylyov wrote:
> Dave Jiang wrote:
>
> > Has anyone been able to build mpc85xx_* from the latest powerpc.git? I have
> > tried mpc85xx_cds and mpc8560_ads. I pulled a new git tree and attempted to
> > build and hit the error message below.
>
> > Also, if I comment out the two lines in arch/powerpc/boot/Makefile that was
> > introduced by the 440 Ebony support patch everything is fine.
>
> > $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> > $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
>
> > make -f
> > /home/djiang/community/git-repos/tmp/ppc-master/scripts/Makefile.modpost vmlinux
> > scripts/mod/modpost -o
> > /home/djiang/community/git-repos/tmp/ppc-master/Module.symvers
> > arch/powerpc/kernel/head_fsl_booke.o init/built-in.o usr/built-in.o
> > arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
> > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
> > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
> > kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> > security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
> > lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
> > WARNING: arch/powerpc/mm/built-in.o(.text+0x10bc): Section mismatch: reference
> > to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
> > rm -f .old_version
> > make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> > arch/powerpc/boot/uImage
> > /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> > -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> > -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> > /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
> > -fPIC -fno-stack-protector -Iarch/powerpc/boot
> > -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
> > -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
> > /home/djiang/tmp/cc2UVyci.s: Assembler messages:
> > /home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
> > make[1]: *** [arch/powerpc/boot/ebony.o] Error 1
>
> I wonder WTF ebony.c gets built for MPC85xx targets? :-O
Because it's part of the bootwrapper and all platform files get built no
matter what the actual target is at the moment.
We might want to take a look at why we're doing that again.
josh
^ permalink raw reply
* Re: [PATCH] IB/ehca: fix wrong number of send WRs returned
From: Roland Dreier @ 2007-05-24 18:05 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200705241651.09411.fenkes@de.ibm.com>
thanks, applied.
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Sergei Shtylyov @ 2007-05-24 18:02 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <4655C7A6.2050606@mvista.com>
Dave Jiang wrote:
> Has anyone been able to build mpc85xx_* from the latest powerpc.git? I have
> tried mpc85xx_cds and mpc8560_ads. I pulled a new git tree and attempted to
> build and hit the error message below.
> Also, if I comment out the two lines in arch/powerpc/boot/Makefile that was
> introduced by the 440 Ebony support patch everything is fine.
> $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
> make -f
> /home/djiang/community/git-repos/tmp/ppc-master/scripts/Makefile.modpost vmlinux
> scripts/mod/modpost -o
> /home/djiang/community/git-repos/tmp/ppc-master/Module.symvers
> arch/powerpc/kernel/head_fsl_booke.o init/built-in.o usr/built-in.o
> arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
> arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
> arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
> lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
> WARNING: arch/powerpc/mm/built-in.o(.text+0x10bc): Section mismatch: reference
> to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
> rm -f .old_version
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage
> /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
> -fPIC -fno-stack-protector -Iarch/powerpc/boot
> -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
> -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
> /home/djiang/tmp/cc2UVyci.s: Assembler messages:
> /home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
> make[1]: *** [arch/powerpc/boot/ebony.o] Error 1
I wonder WTF ebony.c gets built for MPC85xx targets? :-O
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: remove dead EEH code.
From: Linas Vepstas @ 2007-05-24 18:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070524095327.75e239b2.sfr@canb.auug.org.au>
On Thu, May 24, 2007 at 09:53:27AM +1000, Stephen Rothwell wrote:
> On Wed, 23 May 2007 12:23:38 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
> >
> > @@ -1221,11 +1220,10 @@ static int proc_eeh_show(struct seq_file
> > "check not wanted=%ld\n"
> > "eeh_total_mmio_ffs=%ld\n"
> > "eeh_false_positives=%ld\n"
> > - "eeh_ignored_failures=%ld\n"
> > "eeh_slot_resets=%ld\n",
> > no_device, no_dn, no_cfg_addr,
> > ignored_check, total_mmio_ffs,
> > - false_positives, ignored_failures,
> > + false_positives,
> > slot_resets);
>
> This changes a user visible interface - are we sure noone uses it?
> (I suspect it is fine because of the format, but just asking anyway.)
The only user I know of is a "how to test eeh" document that has
a snapshot of this. For the most part, EEH has been very
out-of-the-limelight.
--linas
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Dave Jiang @ 2007-05-24 17:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1180028269.3360.21.camel@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 2007-05-24 at 10:13 -0700, Dave Jiang wrote:
>> /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
>> -fPIC -fno-stack-protector -Iarch/powerpc/boot
>> -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
>> -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
>> /home/djiang/tmp/cc2UVyci.s: Assembler messages:
>> /home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
>
> What versions of binutils, and gcc are you using?
>
> It seems we're going to have to start doing conditional per-file CFLAGS
> or something else if we continue to compile all the platform files in
> the bootwrapper. I'm not too thrilled with that.
>
> josh
gcc 4.2.0
binutils 2.17.50
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] IB/ehca: Refactor "maybe missed event" code
From: Roland Dreier @ 2007-05-24 17:40 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200705241651.05860.fenkes@de.ibm.com>
This isn't fixing anything is it? I think it's 2.6.23 material;
correct me if I'm wrong.
- R.
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Josh Boyer @ 2007-05-24 17:37 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <4655C7A6.2050606@mvista.com>
On Thu, 2007-05-24 at 10:13 -0700, Dave Jiang wrote:
> Has anyone been able to build mpc85xx_* from the latest powerpc.git? I have
> tried mpc85xx_cds and mpc8560_ads. I pulled a new git tree and attempted to
> build and hit the error message below.
>
> Also, if I comment out the two lines in arch/powerpc/boot/Makefile that was
> introduced by the 440 Ebony support patch everything is fine.
>
> $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
Without those, other toolchains will break on those files because they
don't understand mtdcr/mfdcr by default.
> make -f
> /home/djiang/community/git-repos/tmp/ppc-master/scripts/Makefile.modpost vmlinux
> scripts/mod/modpost -o
> /home/djiang/community/git-repos/tmp/ppc-master/Module.symvers
> arch/powerpc/kernel/head_fsl_booke.o init/built-in.o usr/built-in.o
> arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
> arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
> arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
> lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
> WARNING: arch/powerpc/mm/built-in.o(.text+0x10bc): Section mismatch: reference
> to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
> rm -f .old_version
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage
> /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
> -fPIC -fno-stack-protector -Iarch/powerpc/boot
> -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
> -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
> /home/djiang/tmp/cc2UVyci.s: Assembler messages:
> /home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
What versions of binutils, and gcc are you using?
It seems we're going to have to start doing conditional per-file CFLAGS
or something else if we continue to compile all the platform files in
the bootwrapper. I'm not too thrilled with that.
josh
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Add EEH sysfs blinkenlights
From: Linas Vepstas @ 2007-05-24 17:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523232256.GJ29914@localdomain>
On Wed, May 23, 2007 at 06:22:56PM -0500, Nathan Lynch wrote:
> Hi Linas-
>
> Linas Vepstas wrote:
> >
> > Add sysfs blinkenlights for EEH statistics. Shuffle the
> > eeh_add_device_tree() call so that it appears in the correct
> > sequence.
>
> ( blinkenlights? :)
Alles touristen und non-technischen looken peepers! Das machinkontrol is
nicht for gefengerpoken und mittengrabben. Oderwise is easy schnappen
der springenverk, blowenfus, und poppencorken mit spitzensparken. Der
machine is diggen by experten only. Is nicht fur geverken by das
dumpkopfen. Das rubber necken sightseenen keepen das cotton-picken hands
in das pockets. So relaxen, und vatchen das blinkenlights.
> To me this seems a somewhat terse changelog considering that the patch
> introduces a user-visible interface. The changelog does not really
> say what the code is doing or why, or who will use it.
At this time, there are no planned user-space tools that would look
at this. Its intended primarily for sysadmins and service, to determine
what, exactly, is going on in the system. I'd been planning on adding
this for years, but recent email exchanges made it clear that this needs
to get done.
> > +#define EEH_SHOW_ATTR(_name,_memb,_format) \
> > +static ssize_t eeh_show_##_name(struct device *dev, \
> > + struct device_attribute *attr, char *buf) \
>
> I have been frustrated by similar constructions more than once in the
> midst of debugging. I know this has become a common practice with
> sysfs-related code, but using cpp to generate function names
> completely defeats grep etc. when you're trying to track down a
> problem, and I'd not like to see this sort of thing propagated.
I understand the frustration. But I also would hate to have 5 or 6
nearly identidical subroutines, one after the other. Perhaps the
answer is to avoid te ## pste token, and instead do something
like this:
+#define EEH_SHOW_ATTR(_fullname,_memb,_format) \
+static ssize_t _fullname(struct device *dev, \
+ struct device_attribute *attr, char *buf) \
That way, grep will suceed in finding the "full name".
> > +void eeh_sysfs_add_device(struct pci_dev *pdev);
> > +void eeh_sysfs_remove_device(struct pci_dev *pdev);
>
> Don't you need dummy static inline placeholders for CONFIG_EEH=n?
Hmm. I think these are only called fom the dlpar code, and
neither dlpar nor pseries pci will work if eeh is config'ed off...
I don't know how to make CONFIG_PCI depend on CONFIG_EEH, though ...
strange situation.
--linas
^ permalink raw reply
* 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Dave Jiang @ 2007-05-24 17:13 UTC (permalink / raw)
To: linuxppc-dev
Has anyone been able to build mpc85xx_* from the latest powerpc.git? I have
tried mpc85xx_cds and mpc8560_ads. I pulled a new git tree and attempted to
build and hit the error message below.
Also, if I comment out the two lines in arch/powerpc/boot/Makefile that was
introduced by the 440 Ebony support patch everything is fine.
$(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
$(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
make -f
/home/djiang/community/git-repos/tmp/ppc-master/scripts/Makefile.modpost vmlinux
scripts/mod/modpost -o
/home/djiang/community/git-repos/tmp/ppc-master/Module.symvers
arch/powerpc/kernel/head_fsl_booke.o init/built-in.o usr/built-in.o
arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
WARNING: arch/powerpc/mm/built-in.o(.text+0x10bc): Section mismatch: reference
to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
rm -f .old_version
make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
arch/powerpc/boot/uImage
/opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
-Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-builtin -nostdinc -isystem
/opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
-fPIC -fno-stack-protector -Iarch/powerpc/boot
-I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
-c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
/home/djiang/tmp/cc2UVyci.s: Assembler messages:
/home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
make[1]: *** [arch/powerpc/boot/ebony.o] Error 1
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* RE: Problems in 2.6 memory management on 8xx
From: Joakim Tjernlund @ 2007-05-24 17:10 UTC (permalink / raw)
To: 'Detlev Zundel'; +Cc: linuxppc-dev
In-Reply-To: <m2hcq2b26n.fsf@sowhat.denx.de>
> -----Original Message-----
> From: Detlev Zundel [mailto:dzu@denx.de]
> Sent: den 24 maj 2007 18:46
> To: joakim.tjernlund@transmode.se
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Problems in 2.6 memory management on 8xx
>
> Hi Joakim,
>
> > On Thu, 2007-05-24 at 17:23 +0200, Joakim Tjernlund wrote:
> >> On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
> >> > Hi,
> >> >
> >> > working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
> >> > behaviour exemplified by the simple attached demo
> program. An icbi
> >> > from userspace on an address that is mapped only lazily
> gets into an -
> >> > though interruptible - loop. Locking the icbi target in
> question with
> >> > mlock circumvents this problem.
> >>
> >> 8xx is buggy w.r.t cache instructions. They do not update the
> >> DAR register in the TLB miss/TLB error handlers.
> >> The TLB miss handler does not use the DAR reg but the TLB error
> >> handler do. Thats why it works when you mlock the memory.
> >>
> >> This bug isn't documented but Freescale has confirmed it.
> >> You can search the archives some years back for more info.
> >>
> >> Jocke
> >
> > BTW, it is possible to workaround this problem in the kernel by
> > tagging DAR with an impossible value and compare DAR against it
> > in the DTLB Error handler. If a match, then do a instruction decode
> > to get the regs involved and calculate the faulting address.
> >
> > I did this several years ago for 2.4 in assembler and posted
> > it, but it was rejected.
> > One should bail out to handle_page_fault and do the
> > calculations there instead(less likely to break that way)
> >
> > Found one version of the patch here:
> > http://patchwork.ozlabs.org/linuxppc/patch?id=1307
>
> Thanks for shedding some light on this problem. I already found the
> patch you refer to and also wondered why it was never accepted. Was
> there a technical reason or did it simply slip everybodys attention?
Can't really rember the details, but I think Dan Malek didn't
like it because it was hard to maintain and usally one can avoid
the problem.
I have been using that patch on our 860/862 boards for years now
and it works fine.
Jocke
^ permalink raw reply
* Re: Problems in 2.6 memory management on 8xx
From: Detlev Zundel @ 2007-05-24 16:45 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1180023834.1468.64.camel@gentoo-jocke.transmode.se>
Hi Joakim,
> On Thu, 2007-05-24 at 17:23 +0200, Joakim Tjernlund wrote:
>> On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
>> > Hi,
>> >
>> > working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
>> > behaviour exemplified by the simple attached demo program. An icbi
>> > from userspace on an address that is mapped only lazily gets into an -
>> > though interruptible - loop. Locking the icbi target in question with
>> > mlock circumvents this problem.
>>
>> 8xx is buggy w.r.t cache instructions. They do not update the
>> DAR register in the TLB miss/TLB error handlers.
>> The TLB miss handler does not use the DAR reg but the TLB error
>> handler do. Thats why it works when you mlock the memory.
>>
>> This bug isn't documented but Freescale has confirmed it.
>> You can search the archives some years back for more info.
>>
>> Jocke
>
> BTW, it is possible to workaround this problem in the kernel by
> tagging DAR with an impossible value and compare DAR against it
> in the DTLB Error handler. If a match, then do a instruction decode
> to get the regs involved and calculate the faulting address.
>
> I did this several years ago for 2.4 in assembler and posted
> it, but it was rejected.
> One should bail out to handle_page_fault and do the
> calculations there instead(less likely to break that way)
>
> Found one version of the patch here:
> http://patchwork.ozlabs.org/linuxppc/patch?id=1307
Thanks for shedding some light on this problem. I already found the
patch you refer to and also wondered why it was never accepted. Was
there a technical reason or did it simply slip everybodys attention?
Cheers
Detlev
--
Men are born ignorant, not stupid; they are made stupid by education.
--Bertrand Russell
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: Problems in 2.6 memory management on 8xx
From: Joakim Tjernlund @ 2007-05-24 16:23 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-dev
In-Reply-To: <1180020200.1468.51.camel@gentoo-jocke.transmode.se>
On Thu, 2007-05-24 at 17:23 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
> > Hi,
> >
> > working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
> > behaviour exemplified by the simple attached demo program. An icbi
> > from userspace on an address that is mapped only lazily gets into an -
> > though interruptible - loop. Locking the icbi target in question with
> > mlock circumvents this problem.
>
> 8xx is buggy w.r.t cache instructions. They do not update the
> DAR register in the TLB miss/TLB error handlers.
> The TLB miss handler does not use the DAR reg but the TLB error
> handler do. Thats why it works when you mlock the memory.
>
> This bug isn't documented but Freescale has confirmed it.
> You can search the archives some years back for more info.
>
> Jocke
BTW, it is possible to workaround this problem in the kernel by
tagging DAR with an impossible value and compare DAR against it
in the DTLB Error handler. If a match, then do a instruction decode
to get the regs involved and calculate the faulting address.
I did this several years ago for 2.4 in assembler and posted
it, but it was rejected.
One should bail out to handle_page_fault and do the
calculations there instead(less likely to break that way)
Found one version of the patch here:
http://patchwork.ozlabs.org/linuxppc/patch?id=1307
Jocke
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: Wolfgang Reissnegger @ 2007-05-24 15:42 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-dev, David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <46558E54.80909@ru.mvista.com>
Hi Andrei, David,
It's great to hear that Andrei's git tree is active again.
As you might have heard, Xilinx is in the process of setting up a git
tree as well. Right now we are waiting for the new hosting machines to
be installed. We should get those machines up and running shortly
(within a couple weeks).
Currently the tree is based on mainline and adds support for MicroBlaze.
I also intent to merge Grant Likely's virtex-dev branch, the framebuffer
patch and the various other contributions that are out there.
We are also in the process of changing our internal coding guidelines to
match the common Linux style (e.g. u32, u16 types, 8 char wide (tab)
indentation, curly brace location etc) to make it easier to integrate
code into the kernel and push it upstream.
I'll send an update once we have the server up and running.
Thanks,
Wolfgang
Andrei Konovalov wrote:
> Hi David,
>
> David H. Lynch Jr. wrote:
>> Andrei Konovalov wrote:
>>> Hello,
>>>
>>> My Xilinx Virtex Development tree is now alive again.
>>>
>>> Please use the dev branch (master is just the ko copy):
>>> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
>>> Currently it has a patch to enable the framebuffer
>>> on ML403 and ML300 plus TEMAC driver that uses
>>> the PHY lib (FIFO mode support only).
>>> The TEMAC driver is work in progress.
>>> In the queue are SGDMA TEMAC support, and SPI driver
>>> (master only).
>>>
>>> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
>>> The comments / opinions on how to get this driver (not the current incomplete
>>> version of course) accepted into the ko tree are very welcomed.
>>>
>> I have an almost working FIFO TEMAC driver. It is similarly based.
>> it started out based on the Trek webserver sample
>
> Is this a reference design by Xilinx? Linux based or standalone?
>
>> I spent probably 3-4 days de-EDKing it into something that fit into a
>> single source and was closer to ko norms.
>> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
>> if it could be helpful in anyway.
>> I am all for getting an acceptable driver into the ko tree.
>
> You could post your driver to the list when you think it is in good enough shape.
> If your driver is based on the linux TEMAC driver from EDK, it shouldn't
> be very different from my version (my added value is mostly replacing the
> custom PHY code with the PHY lib stuff). Then we could merge our drivers (or
> whatever would make sense).
>
> I would be interested to have a look at your current code just to see
> how much has it cost to "de-EDK" the FIFO part. You could email me
> your (even not quite working) driver privately if you want.
>
>
> Thanks,
> Andrei
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Problems in 2.6 memory management on 8xx
From: Joakim Tjernlund @ 2007-05-24 15:23 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-dev
In-Reply-To: <m2fy5mcqut.fsf@sowhat.denx.de>
On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
> Hi,
>
> working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
> behaviour exemplified by the simple attached demo program. An icbi
> from userspace on an address that is mapped only lazily gets into an -
> though interruptible - loop. Locking the icbi target in question with
> mlock circumvents this problem.
8xx is buggy w.r.t cache instructions. They do not update the
DAR register in the TLB miss/TLB error handlers.
The TLB miss handler does not use the DAR reg but the TLB error
handler do. Thats why it works when you mlock the memory.
This bug isn't documented but Freescale has confirmed it.
You can search the archives some years back for more info.
Jocke
>
> I tested this code on 2.6.21 on 4xx and 82xx only to prove that those
> combinations, as expected, don't have this problem. Vitaly Bordug was
> kind enough to test the code on an 8xx hw supported by a recent kernel
> and acknowledged it still being present.
>
> As I don't have time to investigate this any further, I at least want
> to document this problem with this post. Maybe someone else can help
> out here.
>
> Thanks
> Detlev
>
> plain text document attachment (Makefile)
> CC=$(CROSS_COMPILE)gcc
> AS=$(CROSS_COMPILE)as
> CFLAGS=-g
>
> %.o: %.S
> $(CC) -c -o $@ $<
>
> all: icbi
>
> icbi: icbi.o icbi_trigger.o
>
> clean:
> rm -f *.o *~ icbi
> _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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