* Re: [patch] powerpc: sysfs fix compiler warning
From: Christian Krafft @ 2007-06-29 16:10 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200706291657.20942.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]
On Fri, 29 Jun 2007 16:57:20 +0200
Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
> > From: Christian Krafft <krafft@de.ibm.com>
> >
> > This patch fixes the following compiler warning:
> > arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> > `sysfs_create_group',
> >
> > Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> >
> > --- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
> > +++ linux-2.6/arch/powerpc/kernel/sysfs.c
> > @@ -380,16 +380,25 @@ int cpu_add_sysdev_attr_group(struct att
> > {
> > int cpu;
> > struct sys_device *sysdev;
> > + int error = 0;
> >
> > mutex_lock(&cpu_mutex);
> >
> > for_each_possible_cpu(cpu) {
> > sysdev = get_cpu_sysdev(cpu);
> > - sysfs_create_group(&sysdev->kobj, attrs);
> > + error = sysfs_create_group(&sysdev->kobj, attrs);
> > +
> > + if (error) {
> > + for_each_possible_cpu(cpu) {
> > + sysdev = get_cpu_sysdev(cpu);
> > + sysfs_remove_group(&sysdev->kobj, attrs);
>
> Is sysfs_remove_group() safe to call on kobjs for which
> we did not call sysfs_create_group()?
I only looked into it a little and haven't seen a problem.
From the interface point of view I would say it would be a bug, if it's not safe.
But I will do a short test on this.
>
> > + }
> > + break;
> > + }
> > }
> >
> > mutex_unlock(&cpu_mutex);
> > - return 0;
> > + return error;
> > }
> > EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
> >
> >
> >
>
>
>
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 16:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200706291805.42528.arnd@arndb.de>
On Jun 29, 2007, at 11:05 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Kumar Gala wrote:
>>> Would it work reliably if we switch the arguments to
>>> '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
>>> might be better than taking it out entirely.
>>
>> Is there a reason you didn't use -mcpu=power3 and -mcpu=rs64 for
>> those to CPU options?
>
> Not an important one. From looking at gcc source, it seemed to
> me that power3, rs64 and powerpc64 all specify the same instruction
> set, so I went for the most generic one.
>
> I guess we could always pass -mcpu=power3 instead of -mcpu=powerpc64
> if that solves the problem.
It did for me, the issue is you can still get an -mcpu=powerpc64 for
iseries via:
+ default "-mcpu=powerpc64" if PPC64
- k
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Arnd Bergmann @ 2007-06-29 16:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <5921DF9C-31D0-4805-B699-4E634DAA2FB4@kernel.crashing.org>
On Friday 29 June 2007, Kumar Gala wrote:
> > Would it work reliably if we switch the arguments to
> > '-mcpu=3Dpowerpc64 -m64' instead of '-m64 -mcpu=3Dpowerpc64'? That
> > might be better than taking it out entirely.
>=20
> Is there a reason you didn't use -mcpu=3Dpower3 and -mcpu=3Drs64 for =A0
> those to CPU options?
Not an important one. From looking at gcc source, it seemed to
me that power3, rs64 and powerpc64 all specify the same instruction
set, so I went for the most generic one.
I guess we could always pass -mcpu=3Dpower3 instead of -mcpu=3Dpowerpc64
if that solves the problem.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Segher Boessenkool @ 2007-06-29 16:05 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, David Woodhouse
In-Reply-To: <1183130011.30145.35.camel@weaponx.rchland.ibm.com>
>>> + remain in bug-fix only mode until it's scheduled removal.
>>> Platforms
>>
>> http://www.angryflower.com/itsits.gif
>
> That's it? I'm scheduling the demise of an entire architecture
> sub-tree
> and the only comment you can make is about a superfluous apostrophe? ;)
Oh there are bigger issues with your patch...
s/the the/to the/
> Anyway, I'll fix it after waiting a bit more to see if anyone has
> further comments.
I think we all agree arch/ppc/ has to DIE so it's all up
to Paul now to schedule its execution...
Segher
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Josh Boyer @ 2007-06-29 15:32 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, david
In-Reply-To: <jehcoqsrzw.fsf@sykes.suse.de>
On Fri, 2007-06-29 at 17:24 +0200, Andreas Schwab wrote:
> Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
>
> > +install: dtc ftdump
> > + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> > + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> > + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
>
> Don't put a slash after $(DESTDIR). You'll end up with a doulbe slash.
/me bangs head on desk.
Why is it that the 9 line patches are always the most screwed up ones?
I'll fix it again. Maybe after more coffee.
josh
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Andreas Schwab @ 2007-06-29 15:24 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183128803.30145.29.camel@weaponx.rchland.ibm.com>
Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
> +install: dtc ftdump
> + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
Don't put a slash after $(DESTDIR). You'll end up with a doulbe slash.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Andreas Schwab @ 2007-06-29 15:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions.
The assembler should be called with -a64, which has the effect of
defaulting to -mppc64.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: David Woodhouse @ 2007-06-29 15:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183130011.30145.35.camel@weaponx.rchland.ibm.com>
On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> That's it? I'm scheduling the demise of an entire architecture
> sub-tree and the only comment you can make is about a superfluous
> apostrophe? ;)
Sorry, allow me to rephrase...
http://www.angryflower.com/itsits.gif
DIE arch/ppc DIE!
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Josh Boyer @ 2007-06-29 15:13 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183128867.1170.341.camel@pmac.infradead.org>
On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > + remain in bug-fix only mode until it's scheduled removal. Platforms
>
> http://www.angryflower.com/itsits.gif
That's it? I'm scheduling the demise of an entire architecture sub-tree
and the only comment you can make is about a superfluous apostrophe? ;)
Anyway, I'll fix it after waiting a bit more to see if anyone has
further comments.
josh
^ permalink raw reply
* Re: 2.4/2.6/ppc/powerpc/8245/8347e
From: Marc Leeman @ 2007-06-29 14:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070628180632.GA2660@chiana.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]
More platforms and higher bitrate tests (I've left the previous post in
comment):
> a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
> b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
> c) 8347e/2.6.21.1/gianfar @400 Mhz
> d) XScale-IXP42x/2.6.18-4/ixp4xx @266 MHz (NSLU2)
e) 8245/2.6.17/e100: 3.5.10-k2-NAPI @350 MHz
f) 405/2.6.22-rc6/smsc9117 @200 MHz
g) 405/2.4.32/IBM OCP EMAC: 2.0 @266 MHz
h) Coppermine/2.6.18/e100: 3.5.10-k2-NAPI @930 MHz
> (2.3.43-k1 is the e100 driver version).
Platform h is just an old server as reference to see if a 2.6.x scales
as bad with an e100 on a different architecture.
>
> The process load for taking in the data is:
>
> a) 4-5% [3]
> b) 10-11%
> c) 13-14%
> d) 4-5%
e) 10-11%
f) 2-3%
g) 5%
h) 0%
This situation is even (a lot) worse when increasing the bitrate. When
a bitrate of 12 Mbps is used, we get the following results:
a) 4-5%
b) 18%
c) 35%
d) 4-7%
e) 18%
f) -
g) -
h) 1-2 %
> While the current 8347/gianfar platform is the worst performer, the
> 2.6 kernel with the 2.4 e100 (before the rewrite) seems to perform
> poorly too [4].
>
> So the 834x preforms worse wrt the 8245 based configuration even though
> it is slightly higher clocked.
>
> It seems as if I bumped into the problem that lead me stick with the 2.4
> in the first place for this 8245 platform; but never got round to
> investigating. I find these results especially intriguing when
> considering an ARM platform (NSLU2 device) that I had around, clocked at
> only 66% of the 8347 and at 80% of the 8245 performs certainly in par
> with the last one...
The load is even worsening in a non linearly as the bitrate goes up (I
coult not test all the platforms for this since not all the embedded
platforms are located in our network and I've rallied some collegues
from over the company to get some other platforms tested, probably I
will get more data next week).
> Even though I will need to recheck this (results to follow), a quick
> test didn't reveal any significant difference between a ppc and powerpc
> arch in the kernel.
>
> It does look like, on our 8245/83xx platforms, the 2.6.x kernel performs
> worse wrt the 2.4 ppc kernels and the 83xx configuration is worse wrt
> the 8245 based configuration [5]. In retrospect, we had signals that
> there was a problem with the 8245/83xx performance over the network last
> year when investigating gstreamer, but due to time pressure but assumed
> it was due to gstreamer and not the processor. This came as a suprise to
> some of the ppl on the gstreamer mailing list that reported performant
> ports to ARM architectures.
If I look at platform (f), 405/2.6.22-rc6, it doesn't seem to be a
general powerpc problem, but just a 824x/83xx or platform issue.
> The results with the NSLU2 will certainly put heat on us from management
> when redesigning or for follow up designs :(
>
> Anyhow, I'm currently extending my test setups since this is an
> important problem and set back.
>
> If anyone has a hint to explaining what is going on here, please do
> since solving this will certainly beat redesigning (esp. considering the
> timeframe we've been assigned).
>
>
> I've only found one relevant reference to 2.4/2.6 network performance
> decrease at this point [6].
>
>
> [1] sources attached
mcrecv -a 225.1.2.3 -p 12345
mcsend -a 225.1.2.3 -p 12345 -b 8192
--
greetz, marc
Aeryn, did I say or do anything to piss you off? I mean other than
caving in the side of your head?
Crichton - Die Me, Dichotomy
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: sysfs fix compiler warning
From: Michael Buesch @ 2007-06-29 14:57 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070629165010.1ec5f082@localhost>
On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch fixes the following compiler warning:
> arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> `sysfs_create_group',
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
> --- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
> +++ linux-2.6/arch/powerpc/kernel/sysfs.c
> @@ -380,16 +380,25 @@ int cpu_add_sysdev_attr_group(struct att
> {
> int cpu;
> struct sys_device *sysdev;
> + int error = 0;
>
> mutex_lock(&cpu_mutex);
>
> for_each_possible_cpu(cpu) {
> sysdev = get_cpu_sysdev(cpu);
> - sysfs_create_group(&sysdev->kobj, attrs);
> + error = sysfs_create_group(&sysdev->kobj, attrs);
> +
> + if (error) {
> + for_each_possible_cpu(cpu) {
> + sysdev = get_cpu_sysdev(cpu);
> + sysfs_remove_group(&sysdev->kobj, attrs);
Is sysfs_remove_group() safe to call on kobjs for which
we did not call sysfs_create_group()?
> + }
> + break;
> + }
> }
>
> mutex_unlock(&cpu_mutex);
> - return 0;
> + return error;
> }
> EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
>
>
>
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: David Woodhouse @ 2007-06-29 14:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1182952173.9889.4.camel@weaponx.rchland.ibm.com>
On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> + remain in bug-fix only mode until it's scheduled removal. Platforms
http://www.angryflower.com/itsits.gif
--
dwmw2
^ permalink raw reply
* [PATCH v2] dtc: Add install makefile target
From: Josh Boyer @ 2007-06-29 14:53 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev, david
Add a minimal install target
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
--- dtc.orig/Makefile
+++ dtc/Makefile
@@ -4,6 +4,10 @@ LDFLAGS = -Llibfdt
BISON = bison
+INSTALL = /usr/bin/install
+DESTDIR =
+BINDIR = /usr/bin
+
#
# Overall rules
#
@@ -113,3 +117,8 @@ endif
#
TESTS_PREFIX=tests/
include tests/Makefile.tests
+
+install: dtc ftdump
+ $(INSTALL) -d $(DESTDIR)/$(BINDIR)
+ $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
+ $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
^ permalink raw reply
* [patch] powerpc: sysfs fix compiler warning
From: Christian Krafft @ 2007-06-29 14:50 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
From: Christian Krafft <krafft@de.ibm.com>
This patch fixes the following compiler warning:
arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
`sysfs_create_group',
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
--- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6/arch/powerpc/kernel/sysfs.c
@@ -380,16 +380,25 @@ int cpu_add_sysdev_attr_group(struct att
{
int cpu;
struct sys_device *sysdev;
+ int error = 0;
mutex_lock(&cpu_mutex);
for_each_possible_cpu(cpu) {
sysdev = get_cpu_sysdev(cpu);
- sysfs_create_group(&sysdev->kobj, attrs);
+ error = sysfs_create_group(&sysdev->kobj, attrs);
+
+ if (error) {
+ for_each_possible_cpu(cpu) {
+ sysdev = get_cpu_sysdev(cpu);
+ sysfs_remove_group(&sysdev->kobj, attrs);
+ }
+ break;
+ }
}
mutex_unlock(&cpu_mutex);
- return 0;
+ return error;
}
EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] dtc: Add install makefile target
From: Josh Boyer @ 2007-06-29 14:50 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, david
In-Reply-To: <20070629143414.GA13053@aepfle.de>
On Fri, 2007-06-29 at 16:34 +0200, Olaf Hering wrote:
> On Fri, Jun 29, Josh Boyer wrote:
>
> > +DESTDIR = /
> > +BINDIR = usr/bin
>
> +DESTDIR=
> +BINDIR=/usr/bin
>
> Just like every other package out there.
Urgh. I thought I had fixed that already. Will resubmit.
josh
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 14:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200706291545.53890.arnd@arndb.de>
On Jun 29, 2007, at 8:45 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Paul Mackerras wrote:
>> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
>> the command line, and that means that gcc *doesn't* put "-mppc64" the
>> as command line, and as barfs on the 64-bit instructions. That's
>> presumably a gcc bug, but we'll have to work around it. I think the
>> best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
>> specific CPU is selected.
>
> I can't reproduce the problem here unfortunately. My idea was to
> always
> pass _some_ -mcpu= flag, in order to make sure it does not use
> an inappropriate default, e.g. when the compiler is built for a
> default
> for power4 but you actually want to build a power3 kernel.
>
> Would it work reliably if we switch the arguments to
> '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
> might be better than taking it out entirely.
Is there a reason you didn't use -mcpu=power3 and -mcpu=rs64 for
those to CPU options?
- k
^ permalink raw reply
* Re: [PATCH] dtc: Add install makefile target
From: Olaf Hering @ 2007-06-29 14:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183125374.30145.14.camel@weaponx.rchland.ibm.com>
On Fri, Jun 29, Josh Boyer wrote:
> +DESTDIR = /
> +BINDIR = usr/bin
+DESTDIR=
+BINDIR=/usr/bin
Just like every other package out there.
^ permalink raw reply
* [PATCH] dtc: Add install makefile target
From: Josh Boyer @ 2007-06-29 13:56 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev, david
Add a minimal install target
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
--- dtc.orig/Makefile
+++ dtc/Makefile
@@ -4,6 +4,10 @@ LDFLAGS = -Llibfdt
BISON = bison
+INSTALL = /usr/bin/install
+DESTDIR = /
+BINDIR = usr/bin
+
#
# Overall rules
#
@@ -113,3 +117,8 @@ endif
#
TESTS_PREFIX=tests/
include tests/Makefile.tests
+
+install: dtc ftdump
+ $(INSTALL) -d $(DESTDIR)/$(BINDIR)
+ $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
+ $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Arnd Bergmann @ 2007-06-29 13:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
On Friday 29 June 2007, Paul Mackerras wrote:
> It turns out that with Arnd's patches we now get "-mcpu=3Dpowerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. =A0That's
> presumably a gcc bug, but we'll have to work around it. =A0I think the
> best thing is just to not put the -mcpu=3Dpowerpc64 in CFLAGS when no
> specific CPU is selected.
I can't reproduce the problem here unfortunately. My idea was to always
pass _some_ -mcpu=3D flag, in order to make sure it does not use
an inappropriate default, e.g. when the compiler is built for a default
for power4 but you actually want to build a power3 kernel.
Would it work reliably if we switch the arguments to
'-mcpu=3Dpowerpc64 -m64' instead of '-m64 -mcpu=3Dpowerpc64'? That
might be better than taking it out entirely.
Arnd <><
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Sergei Shtylyov @ 2007-06-29 12:54 UTC (permalink / raw)
To: kgdb-bugreport
Cc: linux-kernel, linuxppc-dev, Mariusz Kozlowski, paulus,
jason.wessel, Andrew Morton
In-Reply-To: <200706291432.10128.m.kozlowski@tuxland.pl>
Hello.
Mariusz Kozlowski wrote:
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
> in .config. Unselect one of them.
> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
I'm not sure if this will work out but maybe it's worth to disable XMON if
KGDB is selected, like this?
config XMON
bool "Include xmon kernel debugger"
depends on DEBUGGER && !KGDB
> Regards,
> Mariusz
WBR, Sergei
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Mariusz Kozlowski @ 2007-06-29 12:32 UTC (permalink / raw)
To: Andrew Morton, paulus, xfs-masters; +Cc: linuxppc-dev, linux-kernel, xfs
In-Reply-To: <20070628034321.38c9f12b.akpm@linux-foundation.org>
Hello,
allmodconfig on powerpc (iMac g3) fails due to
git-kgdb.patch. allmodconfig defaults should be changed?
CC arch/powerpc/kernel/kgdb.o
arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
in .config. Unselect one of them.
make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
make: *** [arch/powerpc/kernel] Blad 2
anyway after unselecting XMON we can see:
CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o
fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat'
undeclared (first use in this function)
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
reported only once
fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
make[1]: *** [fs/xfs] Blad 2
This is just allmodconfig - not a .config that's used daily by users but I'm
used to compiling the kernel using it anyway 8)
Regards,
Mariusz
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Joakim Tjernlund @ 2007-06-29 11:34 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1178892748.9018.13.camel@saruman.qstreams.net>
On Fri, 2007-05-11 at 10:12 -0400, Ben Warren wrote:
> Alex,
>=20
> On Fri, 2007-05-11 at 10:29 +0100, Alex Zeffertt wrote:
> > Hi,
> >=20
> > Thanks for your reply Ben, but I think my problem is slightly =
different. It is not
> > that the sense (high/low/rising/falling) of the interrupt is wrong, =
but that the
> > kernel will not allow me to register the handler.
> >=20
> > I've changed my code to:
> >=20
> > struct device_node *np =3D of_find_node_by_type(NULL, "ipic");
> > struct irq_host *host =3D irq_find_host(np);
> > int rc;
> >=20
> > unsigned int virq =3D irq_find_mapping(host, 5);
> > set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
> > rc =3D request_irq(virq, mpc832xemds_phy_interrupt, =
IRQF_SHARED, "pm5384", dev);
> >=20
> > but the last line still returns a non-zero error code.
> >=20
> > Is there a new way of requesting to install a handler for external =
interrupts? I
> > can't find any powerpc examples in the kernel tree....
> >=20
> Sorry, I missed a bit of the implementation. You need to register the
> IRQs before attempting to attach an ISR. Here's some sample code that
> works for me. You'll probably need different IRQs, based on what your
> board does:
>=20
> /* All external IRQs + Generic timer IRQs must be initialized by BSP =
*/
> const int bsp_irqs[] =3D {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, =
72};
>=20
> Add this to your BSP IRQ init code (void __init xxx_init_IRQs())
>=20
>=20
> for (i=3D0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq =3D irq_create_mapping(NULL, bsp_irqs[i]);
>=20
> That should do it.
>=20
> regards,
> Ben
Hi Ben
I too am adding such a IRQ for my PHY connected to external IRQ2.
The PHY is connetced to UCC2.
I have this in my DTS for the PHY:
mdio@2320 {
#address-cells =3D <1>;
#size-cells =3D <0>;
reg =3D <2320 18>;
device_type =3D "mdio";
compatible =3D "ucc_geth_phy";
phy1: ethernet-phy@0 {
interrupt-parent =3D <&ipic>;
interrupts =3D <12 2>; //EXT IRQ2
reg =3D <0>; // 0
device_type =3D "ethernet-phy";
interface =3D <3>; //ENET_100_MII
};
Now the things is that the IRQ works with and without the
/* All external IRQs + Generic timer IRQs must be initialized by BSP */
const int bsp_irqs[] =3D {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, =
72};
for (i=3D0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
virq =3D irq_create_mapping(NULL, bsp_irqs[i]);
code in my bsp. There is one difference though.
Printing the irq num in phy_interrupt:
static irqreturn_t phy_interrupt(int irq, void *dev_id)
{
struct net_device *dev =3D (struct net_device *)dev_id;
struct ucc_geth_private *ugeth =3D netdev_priv(dev);
ugeth_vdbg("%s: IN", __FUNCTION__);
printk(KERN_ERR "PHY IRQ:%d \n", irq);
Shows a difference:
with the bsp code added it prints:
PHY IRQ:18
and when I remove the bsp code it prints:
PHY IRQ:19
So what is correct, should I add the bsp code or not?
Jocke
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-29 10:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20928a2e8680e3d9214f1eb24ea87abd@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> First, I'm looking for a help and advice why the current _set_L2CR()
>>>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
>>>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>>>
>>>
>>> I think that if anyone here could answer this straight
>>> away, the source code would have been fixed already ;-)
>>
>>
>> I think I can try to answer this question. Please, look through my
>> thoughts below and correct me if I'm somewhere wrong.
>
>
> You forgot step 0: the goal of flushing the caches here
> is to make sure there is no data at all in there after it
> has finished.
>
>> The current scheme of flushing the caches is based on a number of
>> consecutive lwz/dcbf instructions. A contiguous memory region
>> (started from zero) is read by series of lwz commands and then cache
>> is flushed using a sequence of dcbf instructions with addresses from
>> this memory range. If I understand correctly, to get this approach
>> working it is required to guarantee that after reading the memory
>> region, each line in a cache should be used and keep data from this
>> region. Otherwise, if some cache lines keep data from another address
>> range they will not be flushed by the dcbf instructions sequence.
>
>
> Yes, you need to ensure there is nothing interfering (SMP
> agents, DMA agents, prefetch engines...), and you need to
> know the line replacement policy, to make this work;
> furthermore, you need to be quite careful in your code to
> make sure the intended L2 stores are the _only_ L2 traffic
> you generate.
>
>> Further, how cache lines are utilized is dictated by a cache lines
>> replacement policy. I didn't go in to details deeply, but on MPC7450
>> L1 cache lines replacement policy seems to satisfy the requirement
>> above. At least the MPC7450 reference manual describes L1 cache
>> flushing algorithm based on a sequence of lwz/dcbf instructions.
>>
>> But regarding to L2/L3 caches, the manual describes two different
>> cache line replacement policies. And the both are pseudo-random
>
>
> At least on is the "standard" PowerPC pseudo-LRU tree, no?
> That one flushes fine using this strategy.
The PLRU is implemented in the the L1 cache only, And yes, it does allow
to flush the cache using the lwz/dcbf sequence.
The L2/L3 caches use two different pseudo-random number generators based
on CPU clocks. The first one is just 3-bit modulo 8 counter incremented
on every clock cycle. On each cache miss it is used to choice a cache
line in a set. The second is more complicated and consists of 16 latches
clocked on every clock cycle with 3 XOR functions. And L2/L3 take
"random" numbers from 3 latches of 16.
>
>> and differ by implementation of random number generator. It means
>> that a cache line in a set is chosen randomly, and that, in turn,
>> means that there is a probability that some cache lines are not used
>> during reading of the contiguous memory region and not flushed by the
>> dcbf instruction sequence.
>
>
> Knowing that there is no "outside" interference, and knowing
> the "random" algorithm, can give plenty guarantees.
Agree. In case of cache flushing there is no interference and all the
instructions use known numbers of clock cycles, so it is possible (at
least in theory) to predict all the "random" numbers and to say whether
all the cache lines will be used or not in each particular case. But
the nature of the algorithms does not guarantee the preferable result in
general.
>
>> For example, on MPC7448 there is a eight-way set-associative 1Mb L2
>> cache that consist of 2048 sets x 8 ways per set. And even if a set N
>> has been accessed M times (M > 8) there is a chance that some cache
>> line is set N has never been used, but another line has been used
>> twice or more. Of course, the probability of such situation decreases
>> with increasing of N.
>
Opps, misprint.. I meant M in last sentence :-)
Thank you,
Vlad.
>
> You can make sure, too. Just trying to statistically get
> to the point where you are sure the whole cache is flushed
> is not going to work *at all*, you need to use deeper knowledge
> of how the cache works.
>
>> Current _set_L2CR() implementation reads first 4Mb of memory to flush
>> the L2 cache. I have increased this size up to 16 Mb and now things
>> work fine. But I don't think that is a right way to fix the problem
>> because there is no any way to define the upper limit of memory size
>> to guarantee flushing of each cache line. 16Mb is too large though.
>> It seems more reasonable to use a stable and guaranteed way to flush
>> the cache implemented in hardware.
>
>
> Yes, use the hardware flush mechanism. Please :-)
>
> [I think the erratum is about insn fetches to L2 that you
> have no way too stop. <handwaving>Something like that,
> anyway.</handwaving>]
>
>
> Segher
>
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Segher Boessenkool @ 2007-06-29 9:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.53604.173632.186062@cargo.ozlabs.ibm.com>
>> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
>> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
>> GCC command line, too, you need it, and it solves this issue
>> as a side effect.
>
> No, actually the command line had -m64 on it. The situation is this:
>
> gcc -m64 -mtune=power4 works
> gcc -m64 -mcpu=powerpc64 -mtune=power4 fails.
>
> The problem is in the spec file where it works out what parameters to
> pass to `as'. Without any -mcpu it correctly defaults to passing
> -mppc64 (when -m64 is given). It then also has a list of -mcpu values
> and the corresponding flag to pass to as, but powerpc64 isn't in that
> list. Thus with -mcpu=powerpc64 we don't get -mppc64 passed to as.
Oh okay, badness. What's the GCC PR #?
Segher
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-29 9:49 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3312@zch01exm26.fsl.freescale.net>
>> No. The #address-cells is determined by the bus binding,
>> so that all RapidIO busses on the planet can be represented
>> in a similar way in the OF device tree. Take for example
>> the PCI binding, which gives you three address cells -- one
>> to distinguish between different address spaces (configuration
>> space, legacy I/O space, memory mapped space) and to contain
>> some flags (prefetchable vs. non-prefetchable, etc.); the
>> other two 32-bit cells contain a 64-bit address, although
>> config and legacy I/O never are more than 32 bit, and many
>> PCI devices can't do 64-bit addressing at all.
>>
>> Now, there is no OF binding for RapidIO yet of course, but
>> it would be good to start thinking about one while doing
>> the binding for your specific controller -- it will make
>> life easier down the line for everyone, including yourself.
>>
> How about I add more words here for more clear expression?
> Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".
You should more explicitly define the address format, i.e.
what every bit means -- just saying it is 64 or 96 bits isn't
enough. While you're doing that, think of a way that can
represent _every possible_ RapidIO address, not just the ones
supported by this particular controller.
Segher
^ 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