* [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17-rc6/arch/powerpc/Kconfig.debug linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug
--- linux-2.6.17-rc6/arch/powerpc/Kconfig.debug 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug 2006-06-13 21:39:24.000000000 +0000
@@ -18,6 +18,16 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES
+ help
+ Adds code to keep track of number of hypervisor calls made and
+ the amount of time spent in hypervisor calls.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile 2006-06-13 21:39:24.000000000 +0000
@@ -9,3 +9,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S 2006-06-13 21:39:24.000000000 +0000
@@ -25,7 +25,11 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_base)
+#else
_GLOBAL(plpar_hcall)
+#endif
HMT_MEDIUM
mfcr r0
@@ -52,7 +56,15 @@ _GLOBAL(plpar_hcall)
/* Simple interface with no output values (other than status) */
+#ifdef CONFIG_HCALL_STATS
_GLOBAL(plpar_hcall_norets)
+ b plpar_hcall_norets_C
+
+
+_GLOBAL(plpar_hcall_norets_base)
+#else
+_GLOBAL(plpar_hcall_norets)
+#endif
HMT_MEDIUM
mfcr r0
@@ -76,7 +88,11 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_8arg_2ret_base)
+#else
_GLOBAL(plpar_hcall_8arg_2ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -102,7 +118,11 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_4out_base)
+#else
_GLOBAL(plpar_hcall_4out)
+#endif
HMT_MEDIUM
mfcr r0
@@ -144,7 +164,11 @@ _GLOBAL(plpar_hcall_4out)
unsigned long *out6, 102(R1)
unsigned long *out7); 100(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_7arg_7ret_base)
+#else
_GLOBAL(plpar_hcall_7arg_7ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -193,7 +217,11 @@ _GLOBAL(plpar_hcall_7arg_7ret)
unsigned long *out8, 94(R1)
unsigned long *out9, 92(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_9arg_9ret_base)
+#else
_GLOBAL(plpar_hcall_9arg_9ret)
+#endif
HMT_MEDIUM
mfcr r0
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-06-13 21:39:24.000000000 +0000
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <asm/hvcall.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+static inline void update_stats(unsigned long opcode, unsigned long t_before)
+{
+ unsigned long op_index= opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ /* racey, but acceptable for non-critical stats */
+ hs->total_time += (mfspr(SPRN_PURR) - t_before);
+ hs->num_calls++;
+}
+
+extern long plpar_hcall_base (unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_norets_base(unsigned long opcode, ...);
+
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_norets_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_8arg_2ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_8arg_2ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, out1);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_4out_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_4out_base(opcode, arg1, arg2, arg3, arg4, out1,
+ out2, out3, out4);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_7arg_7ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_7arg_7ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, out1, out2, out3, out4,
+ out5, out6, out7);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_9arg_9ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_9arg_9ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9, out1, out2,
+ out3, out4, out5, out6, out7, out8,
+ out9);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
diff -Naupr linux-2.6.17-rc6/include/asm-powerpc/hvcall.h linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17-rc6/include/asm-powerpc/hvcall.h 2006-06-13 21:38:45.000000000 +0000
+++ linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h 2006-06-13 21:39:24.000000000 +0000
@@ -292,6 +292,13 @@ long plpar_hcall_9arg_9ret(unsigned long
unsigned long *out8,
unsigned long *out9);
+#ifdef CONFIG_HCALL_STATS
+struct hcall_stats {
+ unsigned long num_calls;
+ unsigned long total_time;
+};
+#endif /* CONFIG_HCALL_STATS */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-21 6:35 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 02:56:33PM -0700, Brian D. Carlstrom wrote:
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
There's always lead time to get things into distros, that would still be
true if you modified glibc instead as well.
-Olof
^ permalink raw reply
* Regarding MAL
From: Sangameshwar Pujari @ 2006-07-21 3:54 UTC (permalink / raw)
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
Hi,
i am porting a EMAC driver from NetBSD to my Xilinix ML403 embeddded =
board . NETBSD code is Having a Media Access Layer (MAL) , which i want =
to know bit , is it the same MAC layer .
regards
sangamesh
^ permalink raw reply
* RE: [Linux-ATM-General] mpc8360sar
From: Li Tony-r64360 @ 2006-07-21 2:36 UTC (permalink / raw)
To: Alex Zeffertt, Kumar Gala, Chu hanjin-r52514
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
In-Reply-To: <44BFABFD.1070904@cambridgebroadband.com>
Alex, we are working on the 8360 upstream. As the similarity between
832x and 8360, if the 8360 has benn accepted, it would be easy for 832x
upstream.
We have submit the 8360 patch to the opensource. But we are waiting it
to be accepted.
BTW, the new version QOC3-ATM card will adopt. The QOC3-ATM card code
need some modification.=20
I send the new code to you if it done. Ok ?
Tony
> -----Original Message-----
> From: Alex Zeffertt [mailto:ajz@cambridgebroadband.com]=20
> Sent: Friday, July 21, 2006 12:15 AM
> To: Kumar Gala
> Cc: Li Tony-r64360; linux-atm-general@lists.sourceforge.net;=20
> linuxppc-embedded@ozlabs.org
> Subject: Re: [Linux-ATM-General] mpc8360sar
>=20
> Kumar Gala wrote:
> >=20
> > On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote:
> >=20
> >>
> >>> Any reason we dont try to get your work up stream into=20
> the mainline=20
> >>> kernel?
> >>> - kumar
> >>
> >> I'd like to see it upstreamed - the more people who use it=20
> the more=20
> >> help I get!
> >>
> >> However, mpc8360sar is built on Freescale's BSP which adds basic=20
> >> support for the board, the MPC832xE-MDS, to the stock=20
> linux kernel. =20
> >> This support consists of the following patches:
> >>
> >> Patch0 : patch-2.6.11.bz2
> >> Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
> >> Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
> >> Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
> >> Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
> >> Patch5 : linux-2.6.11-mpc83xx-sec2.patch
> >> Patch6 : mpc832x-sec2v15-config-1.patch
> >> Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
> >> Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
> >> Patch9 : linux-2.6.11-mpc8360-general-1.patch
> >> Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
> >> Patch11 : linux-2.6.11-mpc832x-basic-4.patch
> >> Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
> >> Patch13 : linux-2.6.11-mpc832x-spi-1.patch
> >> Patch14 : linux-2.6.11-mpc832x-BIT.patch
> >> Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
> >> Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
> >> Patch17 : linux-2.6.11-mpc832x-atm-1.patch
> >>
> >> I guess there's no point upstreaming mpc8360sar until=20
> freescale have=20
> >> upstreamed these patches (and ported them to the current kernel).
> >=20
> > True, a large number of these patches are upstream, and if I had=20
> > access to MPC836x or MPC832x HW I'd work on getting the others that=20
> > are reasonable.
> >=20
> >> Alex
> >>
> >> PS It's probable that mpc8360sar actually only requires a=20
> handful of=20
> >> the above patches to be applied.
> >=20
> > Agreed.
> >=20
> > - kumar
>=20
>=20
> Tony, can you let me know when CONFIG_MPC832XE_MDS support is=20
> upstreamed to a kernel.org kernel. I'll then try to get the=20
> mpc8360sar working with this kernel and then upstream it.
>=20
> Alex
>=20
> PS I'm not entirely sure how "upstreaming" is done.
>=20
^ permalink raw reply
* mpic discovery on JS20
From: Amos Waterland @ 2006-07-20 23:16 UTC (permalink / raw)
To: linuxppc-dev
Current Linus and Paulus trees do this on JS20 blades with SLOF:
Failed to locate the MPIC interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
Maple: Found RTC at IO 0x1070
cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
sp: c00000007ef83d30
msr: 9000000000029032
current = 0xc00000000194d610
paca = 0xc00000000038f180
pid = 1, comm = swapper
kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
Doing a git-bisect produces this:
0ebfff1491ef85d41ddf9c633834838be144f69f is first bad commit
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon Jul 3 21:36:01 2006 +1000
[POWERPC] Add new interrupt mapping core and change platforms to use it
This adds the new irq remapper core and removes the old one. Because
there are some fundamental conflicts with the old code, like the value
of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
etc..., this commit also changes the relevant platform and driver code
over to use the new remapper (so as not to cause difficulties later
in bisecting).
This patch removes the old pre-parsing of the open firmware interrupt
tree along with all the bogus assumptions it made to try to renumber
interrupts according to the platform. This is all to be handled by the
new code now.
For the pSeries XICS interrupt controller, a single remapper host is
created for the whole machine regardless of how many interrupt
presentation and source controllers are found, and it's set to match
any device node that isn't a 8259. That works fine on pSeries and
avoids having to deal with some of the complexities of split source
controllers vs. presentation controllers in the pSeries device trees.
The powerpc i8259 PIC driver now always requests the legacy interrupt
range. It also has the feature of being able to match any device node
(including NULL) if passed no device node as an input. That will help
porting over platforms with broken device-trees like Pegasos who don't
have a proper interrupt tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: AltiVec in the kernel
From: Daniel Ostrow @ 2006-07-20 22:39 UTC (permalink / raw)
To: Brian D. Carlstrom
Cc: Olof Johansson, 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, 2006-07-20 at 14:56 -0700, Brian D. Carlstrom wrote:
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > > seems to show no where near that level of optimization, but I admit
> > > that I could have missed something.
> >
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy optimizations seem
> to be using 64-bit operations and that 128-bit AltiVec operations are
> still being solicited.
>
> I was encouraged to see the following:
>
> If you need to build generic distributions (supporting several
> <cpu_types>) you can leverage the dl_procinfo support built into
> glibc. This mechanism allows for multiple versions of the core
> libraries (libc, libm, librt, libpthread, libpthread_db) to be
> stored in hardware/platform specific subdirectories under /lib[64].
>
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
It has been part of Gentoo's glibc since 2.4 came out.
--Dan
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 21:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720190523.GA27775@pb15.lixom.net>
At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > seems to show no where near that level of optimization, but I admit
> > that I could have missed something.
>
> http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
Very interesting. According to that page, the memcpy optimizations seem
to be using 64-bit operations and that 128-bit AltiVec operations are
still being solicited.
I was encouraged to see the following:
If you need to build generic distributions (supporting several
<cpu_types>) you can leverage the dl_procinfo support built into
glibc. This mechanism allows for multiple versions of the core
libraries (libc, libm, librt, libpthread, libpthread_db) to be
stored in hardware/platform specific subdirectories under /lib[64].
However, I'm guessing this addon is not something found in common
distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
-bri
^ permalink raw reply
* mainly iSeries updates
From: Stephen Rothwell @ 2006-07-20 21:25 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
Hi Paul,
Please pull ozlabs.org:~sfr/kernels/sfr.git to get the following:
Michael Ellerman:
[POWERPC] iseries: Use device tree /system-id in /proc/iSeries/config
[POWERPC] iseries: Move e2a()/strne2a() into their only caller
[POWERPC] iseries: Cleanup e2a() and strne2a()
[POWERPC] iseries: Make ItExtVpdPanel private to iSeries
[POWERPC] iseries: Make HvLpConfig_get(Primary)LpIndex functions
[POWERPC] iseries: Move ItLpNaca into platforms/iseries
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] Fix a compiler warning in mm/tlb_64.c
[POWERPC] iseries: Move iommu_table_cb into platforms/iseries
Stephen Rothwell:
[POWERPC] iseries: A new iSeries console
[POWERPC] Make the hvc_console output buffer size settable
[POWERPC] iseries: Small viotape cleanup allowed by devfs removal
[POWERPC] iseries: Remove unnecessary include of iseries/hv_lp_event.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with ibm_emac driver
From: Eugene Surovegin @ 2006-07-20 19:56 UTC (permalink / raw)
To: Ian Remmler; +Cc: linuxppc-embedded
In-Reply-To: <20060720183242.GA22930@localhost>
On Thu, Jul 20, 2006 at 01:32:42PM -0500, Ian Remmler wrote:
> Hi,
>
> I'm having a problem with the ibm_emac driver for the built in
> gigabit ethernet on the 440gx. I was hoping someone could shed
> some light or at least point me in the right direction.
>
> I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
> problem we are having is this: when we push data over the emac
> interface (eth0 and eth1 both show the problem), we sporadically
> get a "MAL: Rx descriptor error..." from mal_rxde in
> ibm_ocp_mal.c.
>
> Occasionally, the interface will "freeze up" for a few seconds.
> An ifconfig down/up will bring it back, but from then on it will
> freeze up again right away.
>
> It looks to me like this error indicates that we're out of RX
> buffers, but I don't how we would be running out. I'm no kernel
> or networking expert, but I thought the TCP stack would take
> care of throttling itself to prevent that sort of thing. I
> would appreciate any help.
No idea what GMS is, but they seem to use old buggy EMAC driver.
You can use kernel.org's 2.6 or 2.4.31 backport at
http://kernel.ebshome.net/
As a side note, TCP cannot throttle _all_ Rx traffic, think for
example of a fast box sending a lot of small UDP packets to the 440gx.
--
Eugene
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 19:18 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153422097.19682.84.camel@saruman.qstreams.net>
On Jul 20, 2006, at 2:01 PM, Ben Warren wrote:
> Way cool! Thanks a lot. I'll try it out when my hardware comes in...
Cool, I no longer have access the the system that used the mux, so
when I rework the driver can I get you to test it?
- k
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-20 19:05 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <le8xmoktav.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> A quick grep memcpy in the recent glibc sources on my linux/ppc box
> seems to show no where near that level of optimization, but I admit
> that I could have missed something.
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
-Olof
^ permalink raw reply
* Re: I2C with bus muxes
From: Ben Warren @ 2006-07-20 19:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-embedded
In-Reply-To: <61F75343-B9B9-4349-A463-E39C7532A378@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
Way cool! Thanks a lot. I'll try it out when my hardware comes in...
regards,
Ben
On Thu, 2006-07-20 at 13:51 -0500, Kumar Gala wrote:
> On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
>
> > Hello,
> >
> > Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> > under the /sysfs device model? I have some optical transponders on my
> > board that through the wisdom of some committee all have the same
> > fixed
> > I2C address. To get around this, we put them behind muxes, creating
> > 'virtual' I2C busses. I imagine this could be modeled something like
> > the USB hub model, but that's just a first stab.
>
> I'm pretty sure I submitted a set of patches for this upstream.
> However there was some desire to hold off until some other changes.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
> http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
>
> - kumar
>
>
[-- Attachment #2: Type: text/html, Size: 1826 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 18:47 UTC (permalink / raw)
To: Linas Vepstas; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720174255.GP5905@austin.ibm.com>
At Thu, 20 Jul 2006 12:42:55 -0500,
Linas Vepstas wrote:
> > We found glibc sucked for that.
>
> Only because someone was asleep at the wheel, or there was a bug.
>
> When glibc gets ported to a new architecture, one of the earliest
> tasks is to create optimized versions of memcpy and the like.
> Presumably, on powerpc, this would have been done more than a
> decade ago; its hard for me to imagine that there'd be a problem
> there. Now, I haven't looked at the code, but I just can't imagine
> how this would not have been found and fixed by now. Is there
> really a problem wiht glibc performance on powerpc? I mean,
> this is a pretty serious accusation, and something that should
> be fixed asap.
In the course of my work, I use powerpc architecture simulators. When
working on Mac OS X with a G5, I had to implement some of the basic
AltiVec specifically for use by their libc memcpy implementation. A
quick grep memcpy in the recent glibc sources on my linux/ppc box seems
to show no where near that level of optimization, but I admit that I
could have missed something. However, I would not be surprised that
glibc avoided AltiVec specific optimizations since it would add to the
complexity of supporting various architectures with one binary. On Mac
OS X, libc actually delegated a small number of libc calls such as
memcpy via a kernel managed page at the end of the address space that
setup which routines to use based on currently running architecture.
-bri
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 18:51 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153408592.19682.39.camel@saruman.qstreams.net>
On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
> Hello,
>
> Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> under the /sysfs device model? I have some optical transponders on my
> board that through the wisdom of some committee all have the same
> fixed
> I2C address. To get around this, we put them behind muxes, creating
> 'virtual' I2C busses. I imagine this could be modeled something like
> the USB hub model, but that's just a first stab.
I'm pretty sure I submitted a set of patches for this upstream.
However there was some desire to hold off until some other changes.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
- kumar
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Benjamin Herrenschmidt @ 2006-07-20 18:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060719044510.24117.qmail@web36604.mail.mud.yahoo.com>
Only memory mapped into userland contexts can be paged out in the first
place.
Ben.
^ permalink raw reply
* Problem with ibm_emac driver
From: Ian Remmler @ 2006-07-20 18:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having a problem with the ibm_emac driver for the built in
gigabit ethernet on the 440gx. I was hoping someone could shed
some light or at least point me in the right direction.
I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
problem we are having is this: when we push data over the emac
interface (eth0 and eth1 both show the problem), we sporadically
get a "MAL: Rx descriptor error..." from mal_rxde in
ibm_ocp_mal.c.
Occasionally, the interface will "freeze up" for a few seconds.
An ifconfig down/up will bring it back, but from then on it will
freeze up again right away.
It looks to me like this error indicates that we're out of RX
buffers, but I don't how we would be running out. I'm no kernel
or networking expert, but I thought the TCP stack would take
care of throttling itself to prevent that sort of thing. I
would appreciate any help.
Thanks,
- Ian.
--
"A shark on whiskey is mighty risky.
A shark on beer is a beer engineer."
-- Dr. Worm
^ permalink raw reply
* Re: PHY Howto ?
From: Vitaly Bordug @ 2006-07-20 18:01 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44BFC2EF.5020305@dlasys.net>
On Thu, 20 Jul 2006 13:52:47 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
> If I am writing a network MAC driver, for hardware that has a phy
> that is already supported, if I provide the appropriate mdio_read() and
> mdio_write() calls to access the phy registers, and setup my config to
> include phylib and drivers for my specific phy, what else do I have to
> take care of with respect to the phy within my driver ?
>
> Are there some resources, howto's, examples, ... demonstrating
> how to use phylib ?
There is pretty good writeup in Documentation about your concern, find it at
Documentation/networking/phy.txt . Live example is obviously drivers/net/gianfar*
--
Sincerely,
Vitaly
^ permalink raw reply
* PHY Howto ?
From: David H. Lynch Jr. @ 2006-07-20 17:52 UTC (permalink / raw)
To: linuxppc-embedded
If I am writing a network MAC driver, for hardware that has a phy
that is already supported, if I provide the appropriate mdio_read() and
mdio_write() calls to access the phy registers, and setup my config to
include phylib and drivers for my specific phy, what else do I have to
take care of with respect to the phy within my driver ?
Are there some resources, howto's, examples, ... demonstrating
how to use phylib ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-20 17:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <001301c6abf8$73d780e0$99dfdfdf@bakuhatsu.net>
On Thu, Jul 20, 2006 at 07:31:32AM -0500, Matt Sealey wrote:
>
> What's the case in the kernel for the memcpy functions etc., are
> they optimized for doing things like longword copies rather than
> byte-per-byte etc.?
arch/powerpc/lib/copy_32.S
arch/powerpc/lib/memcpy_64.S
Looks pretty darned optimized to me.
> We found glibc sucked for that.
Only because someone was asleep at the wheel, or there was a bug.
When glibc gets ported to a new architecture, one of the earliest
tasks is to create optimized versions of memcpy and the like.
Presumably, on powerpc, this would have been done more than a
decade ago; its hard for me to imagine that there'd be a problem
there. Now, I haven't looked at the code, but I just can't imagine
how this would not have been found and fixed by now. Is there
really a problem wiht glibc performance on powerpc? I mean,
this is a pretty serious accusation, and something that should
be fixed asap.
--linas
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Alex Zeffertt @ 2006-07-20 16:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <EFE44D26-140D-4E33-A6BF-8D2C13C89821@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote:
>
>>
>>> Any reason we dont try to get your work up stream into the mainline
>>> kernel?
>>> - kumar
>>
>> I'd like to see it upstreamed - the more people who use it the more
>> help I get!
>>
>> However, mpc8360sar is built on Freescale's BSP which adds basic
>> support for the
>> board, the MPC832xE-MDS, to the stock linux kernel. This support
>> consists of the
>> following patches:
>>
>> Patch0 : patch-2.6.11.bz2
>> Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
>> Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
>> Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
>> Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
>> Patch5 : linux-2.6.11-mpc83xx-sec2.patch
>> Patch6 : mpc832x-sec2v15-config-1.patch
>> Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
>> Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
>> Patch9 : linux-2.6.11-mpc8360-general-1.patch
>> Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
>> Patch11 : linux-2.6.11-mpc832x-basic-4.patch
>> Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
>> Patch13 : linux-2.6.11-mpc832x-spi-1.patch
>> Patch14 : linux-2.6.11-mpc832x-BIT.patch
>> Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
>> Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
>> Patch17 : linux-2.6.11-mpc832x-atm-1.patch
>>
>> I guess there's no point upstreaming mpc8360sar until freescale have
>> upstreamed these patches (and ported them to the current kernel).
>
> True, a large number of these patches are upstream, and if I had access
> to MPC836x or MPC832x HW I'd work on getting the others that are
> reasonable.
>
>> Alex
>>
>> PS It's probable that mpc8360sar actually only requires a handful of
>> the above patches to be applied.
>
> Agreed.
>
> - kumar
Tony, can you let me know when CONFIG_MPC832XE_MDS support is upstreamed
to a kernel.org kernel. I'll then try to get the mpc8360sar working with this
kernel and then upstream it.
Alex
PS I'm not entirely sure how "upstreaming" is done.
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Paul Mackerras @ 2006-07-20 16:03 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
Andi Kleen, linux-kernel, linuxppc-dev, Anton Blanchard,
Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
Horms writes:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: multicast for 8260 for 2.6.13
From: Dan Malek @ 2006-07-20 15:44 UTC (permalink / raw)
To: Harnois Anne-Sophie; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D5D2488@rennsmail02.eu.thmulti.com>
On Jul 20, 2006, at 10:45 AM, Harnois Anne-Sophie wrote:
> In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list
> function is
> commented out and I can't figure out why.
Read the mailing list archives.
> I checked the code, removed the comments and tried it, and multicast
> seemed to work properly.
Sorry, but that code will never work on a 82xx.
> What am I missing?
> Could someone explain me why this is commented out?
Because it was copied from the 8xx many years ago when
I ported the driver, and the 82xx lacks the CRC generator
support. You can enable promiscuous mode, which is
what I suspect you did, and then the Linux IP stack will
do the multicast filtering.
By the way, this driver is obsolete and you should be
using the version in drivers/net/fs_enet.
Thanks.
-- Dan
^ permalink raw reply
* Re: multicast for 8260 for 2.6.13
From: Vitaly Bordug @ 2006-07-20 15:41 UTC (permalink / raw)
To: Harnois Anne-Sophie; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D5D2488@rennsmail02.eu.thmulti.com>
On Thu, 20 Jul 2006 16:45:11 +0200
"Harnois Anne-Sophie" <anne-sophie.harnois@thomson.net> wrote:
> Hello
>
> In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list function is
> commented out and I can't figure out why.
> I checked the code, removed the comments and tried it, and multicast
> seemed to work properly.
>
> What am I missing?
> Could someone explain me why this is commented out?
The reason is because the arch/ppc/8260_io/* is deprecated by drivers/net/fs_enet, hence
people switched to use it...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: I2C with bus muxes
From: Ben Warren @ 2006-07-20 15:36 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: Linuxppc-embedded
In-Reply-To: <44BF9FBA.8030201@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Thanks Travis,
On Thu, 2006-07-20 at 11:22 -0400, Travis B. Sawyer wrote:
> I have a driver for 2.4.x that works with our SFP/XFPs. We also have a
> bunch of other 'stuff'
> hanging off of muxes. I haven't given it a go on 2.6, but I have it
> compiled and it doesn't complain on
> startup.
>
I'm happy to see anything. Due to time constraints, I may end up doing
most of my devices stuff 2.4-style anyway, at least for now, since I
have a much firmer grasp on the concepts...
> Not sure if I should send it here, as it won't be in patch form...
>
Please pass your code along whenever it's convenient. Your call whether
to the list or just to me.
Cheers,
Ben
[-- Attachment #2: Type: text/html, Size: 1212 bytes --]
^ permalink raw reply
* multicast for 8260 for 2.6.13
From: Harnois Anne-Sophie @ 2006-07-20 14:45 UTC (permalink / raw)
To: linuxppc-embedded
Hello
In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list function is
commented out and I can't figure out why.=20
I checked the code, removed the comments and tried it, and multicast
seemed to work properly.=20
What am I missing?
Could someone explain me why this is commented out?
Many thanks,
Anne-Sophie
^ 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