* 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: 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
* [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: [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
* 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: 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
* [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
* [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
* 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
* 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: 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] 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: [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: 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 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: [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] 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: 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: 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: [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:10 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.
Also, Paul asked for some Kconfig help to be added to
PPC_CPU_SELECTION & CPU_DEFAULT
- k
^ permalink raw reply
* Re: mpc8270 & Intel 82551ER on 2.6.17.14
From: Muruga Ganapathy @ 2007-06-29 16:48 UTC (permalink / raw)
To: Pradyumna Sampath, Nicholas Hickman, linuxppc-embedded
1. You may want to check whether the device is configured properly by
enabling the debug statements or using the lspci command. I mean the
BAR registers.
2. Also check whether correct the interrupt is assigned to the
device using cat /proc/interrupts command under linux.
3. As far as the EEPROM is concerned, you need to enable debug to check
whether there is any check sum error. If there is a check sum error
in EEPROM, the device may not come up too. As you are using it in
powerpc platform, you need to take care of the endianess while
writing to the EEPROM.
Hope this helps!
Thanks
G.Muruganandam
> Hi Nicholas,
>
> On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
> >
> >
> > I am having trouble getting two 82551ER Ethernet controllers
running in
> > Linux. I am able to scan the PCI bus and see the devices and I was
even
> > able to program the EEPROM from U-boot.
> >
> > In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c.
I've been
> > using the e100 drive that comes with the 2.6.17.14 kernel and have
also
> > tried the driver directly from Intel. Both give the same results.
The PCI
> > scan shows the correct output for how the device should be
configured.
> <snip..>
>
> I have the same, exact same problem. But there are some of the
> differences with the setup though. I have an MPC5200B and the other
> difference is that I have a 2.6.21-rt3. However its the same ethernet
> controller.
>
> I am trying out a few things here, some of them being complete
> guesses. But if I hit something, I will let this list know. Anyone
> else had similar issues ? Request you to please holler.
>
> regards
> prady
> --
> htp://prady.livejournal.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
*************************************************************
GDA Technologies, Inc.
1010 Rincon Circle
San Jose CA, 95131
Phone (408) 432-3090
Fax (408) 432-3091
Accelerate Your Innovation
**************************************************************
=====
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the
sender immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
====
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Ben Warren @ 2007-06-29 16:43 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <1183116892.20673.66.camel@gentoo-jocke.transmode.se>
Hi Jocke,
On Fri, 2007-06-29 at 13:34 +0200, Joakim Tjernlund wrote:
<snip>
> 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 = <1>;
> #size-cells = <0>;
> reg = <2320 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> phy1: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <12 2>; //EXT IRQ2
> reg = <0>; // 0
> device_type = "ethernet-phy";
> interface = <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[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, 72};
> for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq = 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 = (struct net_device *)dev_id;
> struct ucc_geth_private *ugeth = 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
I had to add this board initialization code because on my CPU (8349),
certain interrupts weren't automatically mapped by built-in kernel code.
Interrupts simply weren't firing, because they hadn't been enabled in
the IPIC. Your case is different, because the MDIO device tree entry is
parsed by common code (arch/powerpc/sysdev/something).
You probably don't need to explicitly map IRQs unless they're being used
by custom device drivers. I don't know why you'd get a different
virtual mapping, though. I guess you're effectively mapping the same
IRQ twice, and I don't know what that does. Part of me wants to say "if
it works properly, who cares", but that's how we get into trouble...
Somebody like Kumar Gala could probably provide a real answer.
regards,
Ben
^ permalink raw reply
* RE: mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-06-29 16:54 UTC (permalink / raw)
To: Muruga Ganapathy, Pradyumna Sampath, linuxppc-embedded
In-Reply-To: <200706291648.l5TGmSS17074@sierra.gdatech.com>
Thanks for the reply.
I believe that the EEPROM is programmed correctly. At lease the driver
seems to think so. I am still leaning towards the interrupts not being
properly initialized on the PCI bus. I am currently trying to track
this down. =20
Here's the output of what I have for one of the Ethernet controllers.
# cat /proc/interrupts
CPU0 =20
20: 0 CPM2 SIU Level eth0
24: 0 CPM2 SIU Level PQ2 PCI cascade
40: 154 CPM2 SIU Level cpm_uart
BAD: 0
# lspci -vvv
00:12.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast
Ethernet Controller (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=3Dmedium =
>TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min, 14000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 20
Region 0: Memory at 00000000affff000 (32-bit, non-prefetchable)
[size=3D4K]
Region 1: I/O ports at 1ffffc0 [size=3D64]
Region 2: Memory at 00000000affc0000 (32-bit, non-prefetchable)
[size=3D128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=3D0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=3D0 DScale=3D2 PME-
ethtool -e eth0
Offset Values
------ ------
0x0000 00 50 c2 70 7a 01 80 a1 ff ff 01 02 01 47 ff ff=20
0x0010 ff ff ff ff a0 d0 00 00 00 00 ff ff ff ff ff ff=20
0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 92 3d=20
Thanks again,
-Nick
-----Original Message-----
From: Muruga Ganapathy [mailto:gmuruga@gdatech.com]=20
Sent: Friday, June 29, 2007 12:48 PM
To: Pradyumna Sampath; Nicholas Hickman; linuxppc-embedded@ozlabs.org
Subject: Re: mpc8270 & Intel 82551ER on 2.6.17.14
1. You may want to check whether the device is configured properly by
enabling the debug statements or using the lspci command. I mean the=20
BAR registers.
2. Also check whether correct the interrupt is assigned to the=20
device using cat /proc/interrupts command under linux.=20
3. As far as the EEPROM is concerned, you need to enable debug to check=20
whether there is any check sum error. If there is a check sum error=20
in EEPROM, the device may not come up too. As you are using it in=20
powerpc platform, you need to take care of the endianess while=20
writing to the EEPROM.
Hope this helps!
Thanks
G.Muruganandam
> Hi Nicholas,
>=20
> On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
> >
> >
> > I am having trouble getting two 82551ER Ethernet controllers
running in
> > Linux. I am able to scan the PCI bus and see the devices and I was
even
> > able to program the EEPROM from U-boot.
> >
> > In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. =20
I've been
> > using the e100 drive that comes with the 2.6.17.14 kernel and have
also
> > tried the driver directly from Intel. Both give the same results. =20
The PCI
> > scan shows the correct output for how the device should be
configured.
> <snip..>
>=20
> I have the same, exact same problem. But there are some of the=20
> differences with the setup though. I have an MPC5200B and the other=20
> difference is that I have a 2.6.21-rt3. However its the same ethernet=20
> controller.
>=20
> I am trying out a few things here, some of them being complete=20
> guesses. But if I hit something, I will let this list know. Anyone=20
> else had similar issues ? Request you to please holler.
>=20
> regards
> prady
> --
> htp://prady.livejournal.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
*************************************************************
GDA Technologies, Inc. =09
1010 Rincon Circle
San Jose CA, 95131
Phone (408) 432-3090
Fax (408) 432-3091
Accelerate Your Innovation=09
**************************************************************
=3D=3D=3D=3D=3D
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the sender
immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
=3D=3D=3D=3D
^ permalink raw reply
* Re: PCI IO range limitation
From: Matt Sealey @ 2007-06-29 17:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <1183075997.5521.292.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>>>> Hi,
>>>>
>>>> Trying to change PCI IO window base for 52xx target I found that
>>>> we are pretty much limited to a "0" offset only.
>>> We just fixed that for 64 bits but 32 bits still has the limitation.
>>> Note that it's not a very good idea to have your IO range at !0 if
>>> you're going to use anything ISA-like, such as a VGA video card or other
>>> legacy devices behind a PCI southbridge or SuperIO.
>> The chances of that on an MPC52xx platform are practically zero, aren't
>> they?
>
> Euh... don't you use VGA video cards on Efika ? :-)
Define "legacy device"? What should that entail? You mean like mapping
most of those registers to the first couple of kilobytes of "IO"?
If they're just left as their own on their own as PCI devices, why would
it matter what the window was?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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