[PATCH] Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
On Tue, Oct 03, 2006 at 02:56:14PM -0400, Amos Waterland wrote:
> I'm not positive of this, but I'm pretty sure that this is caused by
> improper dependency checking. I suspect that you changed from
> debug=n to debug=y and got this. I'd suggest doing a `make clean' and
> trying again without your patch.
I came accross the same probelm with a clean build. The patch below fixes it
for me.
Reorder includes to help the complier and avoid redundat definition of
__trap_to_gdb.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
xen/arch/powerpc/gdbstub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff -r d1374d869111 xen/arch/powerpc/gdbstub.c
--- a/xen/arch/powerpc/gdbstub.cWed Oct 04 13:44:07 2006 +1000
+++ b/xen/arch/powerpc/gdbstub.cWed Oct 04 14:46:07 2006 +1000
@@ -20,12 +20,12 @@
#include
#include
-#include
#include
#include
#include
#include
#include
+#include
#include
asm(".globl trap_instruction\n"
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/
Jan 15-20 2007 The Australian Linux Technical Conference!
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x
On Oct 3, 2006, at 3:21 PM, Maria Butrico wrote: Jimi, the problem with this approach is that as changes are made to the Xen code, you have no idea if they make the smp situation better or worse. If you introduce a bug only visible with SMP or more likely to happen running MP you don't find out until someone picks up your code and applies the smp patch. This is exactly the reason why we won't make SMP the default. I'll try my best not to break it and yes I do use the SMP patch to test bigger commits, but its important for all to realize that the maintainers of XenPPC do _not_ consider SMP stable, its just a fact. -JX Jimi Xenidis wrote: On Oct 3, 2006, at 12:25 PM, Maria Butrico wrote: What's really interesting to me about this is that the invocation of the icache invalidation did not go in till later. But it did include the I/D cache flush of text. The i-cache invalidate you speak requires the running of DomUs So if anything we could find this to be even more reliable one the other changes are also picked up. not much has happened that would effect boot and ssh to dom0 I missed this: what is transient? I would like to suggest that the SMP patch be applied to the base, and that in those case where we known that SMP fails, like on maples, we use the nosmp option. I'm still not prepared to take the SMP patch, the I-Cache invalidate fix has improved the situation on maple, but not enough to convince me that there are no more troubles waiting to pounce. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x
Jimi, the problem with this approach is that as changes are made to the Xen code, you have no idea if they make the smp situation better or worse. If you introduce a bug only visible with SMP or more likely to happen running MP you don't find out until someone picks up your code and applies the smp patch. Jimi Xenidis wrote: On Oct 3, 2006, at 12:25 PM, Maria Butrico wrote: What's really interesting to me about this is that the invocation of the icache invalidation did not go in till later. But it did include the I/D cache flush of text. The i-cache invalidate you speak requires the running of DomUs So if anything we could find this to be even more reliable one the other changes are also picked up. not much has happened that would effect boot and ssh to dom0 I missed this: what is transient? I would like to suggest that the SMP patch be applied to the base, and that in those case where we known that SMP fails, like on maples, we use the nosmp option. I'm still not prepared to take the SMP patch, the I-Cache invalidate fix has improved the situation on maple, but not enough to convince me that there are no more troubles waiting to pounce. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
On Tue, Oct 03, 2006 at 02:53:02PM -0400, Yi Ge wrote: > It seems the gcc couldn't find the prototype of __trap_to_gdb when make the > function call in debugger_trap_fatal(). So I added an extern prototype here > with ifndef macro. I'm not positive of this, but I'm pretty sure that this is caused by improper dependency checking. I suspect that you changed from debug=n to debug=y and got this. I'd suggest doing a `make clean' and trying again without your patch. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
Here is the error message I got on building xen:
In file included from /home/gy/xenppc-unstable.hg/xen/include/asm/page.h:33,
from /home/gy/xenppc-unstable.hg/xen/include/xen/gdbstub.h:25,
from gdbstub.c:23:
/home/gy/xenppc-unstable.hg/xen/include/asm/debugger.h: In function `debugger_trap_fatal':
/home/gy/xenppc-unstable.hg/xen/include/asm/debugger.h:84: warning: implicit declaration of function `__trap_to_gdb'
In file included from gdbstub.c:23:
/home/gy/xenppc-unstable.hg/xen/include/xen/gdbstub.h: At top level:
/home/gy/xenppc-unstable.hg/xen/include/xen/gdbstub.h:60: warning: redundant redeclaration of '__trap_to_gdb'
/home/gy/xenppc-unstable.hg/xen/include/asm/debugger.h:84: warning: previous implicit declaration of '__trap_to_gdb' was here
make[3]: *** [gdbstub.o] Error 1
make[2]: *** [/home/gy/xenppc-unstable.hg/xen/arch/powerpc/built_in.o] Error 2
make[1]: *** [/home/gy/xenppc-unstable.hg/xen/xen] Error 2
make: *** [build] Error 2
It seems the gcc couldn't find the prototype of __trap_to_gdb when make the function call in debugger_trap_fatal(). So I added an extern prototype here with ifndef macro.
Best Regards,
Yi Ge, PhD
IBM China Research Lab
Tel: (86-10) 58748024
Fax: (86-10) 58748230
E-Mail : [EMAIL PROTECTED]
Notes Mail: Yi Ge/China/[EMAIL PROTECTED]
Building 19 Zhongguancun Software Park,
8 Dongbeiwang WestRoad, Haidian District,
Beijing,P.R.C.100094
Jimi Xenidis <[EMAIL PROTECTED]>
Jimi Xenidis <[EMAIL PROTECTED]>
2006-10-03 13:19
To
Yi Ge/China/[EMAIL PROTECTED]
cc
xen-ppc-devel@lists.xensource.com
Subject
Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
Not sure what the redundancy is?
I see 2 prototypes and you have added one.
please explain.
-JX
On Oct 3, 2006, at 12:23 PM, Yi Ge wrote:
> It looks like the compiler's problem: it makes a implicit
> definition of __trap_to_gdb on the . This will
> cause the redundancy definition warning and stop the build process
> in default compiling setting.
>
>
>
> diff -r d1f6d0f820d8 xen/include/asm-powerpc/debugger.h
> --- a/xen/include/asm-powerpc/debugger.h Mon Oct 02 21:43:09 2006
> -0400
> +++ b/xen/include/asm-powerpc/debugger.h Tue Oct 03 11:49:57 2006
> -0400
> @@ -74,6 +74,10 @@ extern void __warn(char *file, int line)
>
> #include
>
> +#ifndef TRAP_TO_GDB
> +extern int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long
> cookie);
> +#define TRAP_TO_GDB
> +#endif
> static inline int debugger_trap_fatal(
> unsigned int vector, struct cpu_user_regs *regs)
> {
> diff -r d1f6d0f820d8 xen/include/xen/gdbstub.h
> --- a/xen/include/xen/gdbstub.h Mon Oct 02 21:43:09 2006 -0400
> +++ b/xen/include/xen/gdbstub.h Tue Oct 03 11:50:50 2006 -0400
> @@ -56,8 +56,10 @@ void gdb_send_reply(const char *buf, str
> void gdb_send_reply(const char *buf, struct gdb_context *ctx);
>
> /* gdb stub trap handler: entry point */
> +#ifndef TRAP_TO_GDB
> int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long cookie);
> -
> +#define TRAP_TO_GDB
> +#endif
> /* arch specific routines */
> u16 gdb_arch_signal_num(
> struct cpu_user_regs *regs, unsigned long cookie);
>
>
> Best Regards,
> Yi Ge
>
>
> ___
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x
On Tue, Oct 03, 2006 at 12:25:33PM -0400, Maria Butrico wrote: > What's really interesting to me about this is that the invocation of the > icache invalidation did not go in till later. So if anything we could find > this to be even more reliable one the other changes are also picked up. The key commit from my perspective was the flush of the icache on secondary processor spinup. That made SMP spinup on JS2x quite solid, in my experiments. The function you are talking about is relevant when destroying a domain and loading a new one, I believe. Note that the tests reported in this email only create domains, because I knew that the invocation you are talking about had not gone in yet. > I missed this: what is transient? Transient is how my tool classifies things like the network going down for five minutes at 3:00 a.m., which causes TFTP to fail. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x
On Oct 3, 2006, at 12:25 PM, Maria Butrico wrote: What's really interesting to me about this is that the invocation of the icache invalidation did not go in till later. But it did include the I/D cache flush of text. The i-cache invalidate you speak requires the running of DomUs So if anything we could find this to be even more reliable one the other changes are also picked up. not much has happened that would effect boot and ssh to dom0 I missed this: what is transient? I would like to suggest that the SMP patch be applied to the base, and that in those case where we known that SMP fails, like on maples, we use the nosmp option. I'm still not prepared to take the SMP patch, the I-Cache invalidate fix has improved the situation on maple, but not enough to convince me that there are no more troubles waiting to pounce. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
Not sure what the redundancy is?
I see 2 prototypes and you have added one.
please explain.
-JX
On Oct 3, 2006, at 12:23 PM, Yi Ge wrote:
It looks like the compiler's problem: it makes a implicit
definition of __trap_to_gdb on the . This will
cause the redundancy definition warning and stop the build process
in default compiling setting.
diff -r d1f6d0f820d8 xen/include/asm-powerpc/debugger.h
--- a/xen/include/asm-powerpc/debugger.h Mon Oct 02 21:43:09 2006
-0400
+++ b/xen/include/asm-powerpc/debugger.h Tue Oct 03 11:49:57 2006
-0400
@@ -74,6 +74,10 @@ extern void __warn(char *file, int line)
#include
+#ifndef TRAP_TO_GDB
+extern int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long
cookie);
+#define TRAP_TO_GDB
+#endif
static inline int debugger_trap_fatal(
unsigned int vector, struct cpu_user_regs *regs)
{
diff -r d1f6d0f820d8 xen/include/xen/gdbstub.h
--- a/xen/include/xen/gdbstub.h Mon Oct 02 21:43:09 2006 -0400
+++ b/xen/include/xen/gdbstub.h Tue Oct 03 11:50:50 2006 -0400
@@ -56,8 +56,10 @@ void gdb_send_reply(const char *buf, str
void gdb_send_reply(const char *buf, struct gdb_context *ctx);
/* gdb stub trap handler: entry point */
+#ifndef TRAP_TO_GDB
int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long cookie);
-
+#define TRAP_TO_GDB
+#endif
/* arch specific routines */
u16 gdb_arch_signal_num(
struct cpu_user_regs *regs, unsigned long cookie);
Best Regards,
Yi Ge
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On 3/10/06 17:39, "Aron Griffis" <[EMAIL PROTECTED]> wrote: > Keir Fraser wrote: [Tue Oct 03 2006, 11:59:28AM EDT] >> Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development >> is frozen until 3.0.3-0 is released. > > Hi Keir, > > Why are you doing it this way? I thought a staging tree was somewhere > you could test builds prior to moving changesets to the live tree, so > you could yank the changesets, reset the staging tree, etc. without > affecting anybody. Shouldn't there be a separate staging tree for > xen-3.0.3-testing? Plus if xen-unstable is staging for > xen-3.0.3-testing, then it seems like branching was pointless. Since development is frozen to concentrate on bug fixing, we may as well use xen-unstable as the staging point for candidate patches rather than creating an entirely new tree. Creating an explicit xen-3.0.3-testing tree and announcing official release candidates encourages a broader range of people to test the code (many will not touch xen-unstable at all). Development is not frozen because we are using xen-unstable as a staging tree. It is frozen simply because we are at the bug-fixing stage in the release cycle. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
Keir Fraser wrote: [Tue Oct 03 2006, 11:59:28AM EDT] > Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development > is frozen until 3.0.3-0 is released. Hi Keir, Why are you doing it this way? I thought a staging tree was somewhere you could test builds prior to moving changesets to the live tree, so you could yank the changesets, reset the staging tree, etc. without affecting anybody. Shouldn't there be a separate staging tree for xen-3.0.3-testing? Plus if xen-unstable is staging for xen-3.0.3-testing, then it seems like branching was pointless. Aron ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: Automated reliability report for SMP patch on JS2x
What's really interesting to me about this is that the invocation of the icache invalidation did not go in till later. So if anything we could find this to be even more reliable one the other changes are also picked up. I missed this: what is transient? I would like to suggest that the SMP patch be applied to the base, and that in those case where we known that SMP fails, like on maples, we use the nosmp option. Maria Butrico [EMAIL PROTECTED] ux.ibm.com To 10/03/2006 11:54 xen-ppc-devel@lists.xensource.com AM cc Subject Automated reliability report for SMP patch on JS2x An automated process has boooted Xen on two JS21 blades and one JS20 blade a total of 1241 times, recording 0 failures and 1237 passes, using a correctness criteria of the creation of four domU's for the first JS21, the launch of the ssh daemon for the second JS21, and the creation of two domU's for the JS20. The version of Xen used was changeset dd95dd13cd3e+, which is the following tip of tree changeset plus the bootargs simplification patch plus the SMP patch: changeset: 12184:02f6e775deb1 user:Jimi Xenidis <[EMAIL PROTECTED]> date:Mon Oct 02 11:07:54 2006 -0400 summary: Add Function to completely flush the I-Cache for a processor --- changeset : dd95dd13cd3e+ machine : cso92 pass: 401 fail: 0 transient : 3 total : 404 reliability : 100.0% changeset : dd95dd13cd3e+ machine : kpblade7 pass: 423 fail: 0 transient : 1 total : 424 reliability : 100.0% changeset : dd95dd13cd3e+ machine : kpblade1 pass: 413 fail: 0 transient : 0 total : 413 reliability : 100.0% ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG
It looks like the compiler's problem: it makes a implicit definition of __trap_to_gdb on the . This will cause the redundancy definition warning and stop the build process in default compiling setting.
diff -r d1f6d0f820d8 xen/include/asm-powerpc/debugger.h
--- a/xen/include/asm-powerpc/debugger.h Mon Oct 02 21:43:09 2006 -0400
+++ b/xen/include/asm-powerpc/debugger.h Tue Oct 03 11:49:57 2006 -0400
@@ -74,6 +74,10 @@ extern void __warn(char *file, int line)
#include
+#ifndef TRAP_TO_GDB
+extern int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long cookie);
+#define TRAP_TO_GDB
+#endif
static inline int debugger_trap_fatal(
unsigned int vector, struct cpu_user_regs *regs)
{
diff -r d1f6d0f820d8 xen/include/xen/gdbstub.h
--- a/xen/include/xen/gdbstub.h Mon Oct 02 21:43:09 2006 -0400
+++ b/xen/include/xen/gdbstub.h Tue Oct 03 11:50:50 2006 -0400
@@ -56,8 +56,10 @@ void gdb_send_reply(const char *buf, str
void gdb_send_reply(const char *buf, struct gdb_context *ctx);
/* gdb stub trap handler: entry point */
+#ifndef TRAP_TO_GDB
int __trap_to_gdb(struct cpu_user_regs *regs, unsigned long cookie);
-
+#define TRAP_TO_GDB
+#endif
/* arch specific routines */
u16 gdb_arch_signal_num(
struct cpu_user_regs *regs, unsigned long cookie);
Best Regards,
Yi Ge
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On 3/10/06 16:53, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> I've got no particular problem with these patches (we'll host the >> buildroot tar on xenbits, which was the only query). The tree's >> feature-frozen now though -- we're at RC2 -- so these will drop in >> immediately after the release. > > Which tree, xen-3.0.3-testing? I was asking about xen-unstable... Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development is frozen until 3.0.3-0 is released. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On Tue, 2006-10-03 at 16:30 +0100, Ewan Mellor wrote: > > > Ewan, if you have some problem with patch 1/6, could you still apply > the > > rest to xen-unstable? 2/6 wouldn't apply cleanly, but should be easy > to > > do by hand. > > I've got no particular problem with these patches (we'll host the > buildroot tar on xenbits, which was the only query). The tree's > feature-frozen now though -- we're at RC2 -- so these will drop in > immediately after the release. Which tree, xen-3.0.3-testing? I was asking about xen-unstable... -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Automated reliability report for SMP patch on JS2x
An automated process has boooted Xen on two JS21 blades and one JS20 blade a total of 1241 times, recording 0 failures and 1237 passes, using a correctness criteria of the creation of four domU's for the first JS21, the launch of the ssh daemon for the second JS21, and the creation of two domU's for the JS20. The version of Xen used was changeset dd95dd13cd3e+, which is the following tip of tree changeset plus the bootargs simplification patch plus the SMP patch: changeset: 12184:02f6e775deb1 user:Jimi Xenidis <[EMAIL PROTECTED]> date:Mon Oct 02 11:07:54 2006 -0400 summary: Add Function to completely flush the I-Cache for a processor --- changeset : dd95dd13cd3e+ machine : cso92 pass: 401 fail: 0 transient : 3 total : 404 reliability : 100.0% changeset : dd95dd13cd3e+ machine : kpblade7 pass: 423 fail: 0 transient : 1 total : 424 reliability : 100.0% changeset : dd95dd13cd3e+ machine : kpblade1 pass: 413 fail: 0 transient : 0 total : 413 reliability : 100.0% ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On Tue, Oct 03, 2006 at 10:20:36AM -0500, Hollis Blanchard wrote: > On Mon, 2006-10-02 at 13:23 +0100, Ewan Mellor wrote: > > On Mon, Oct 02, 2006 at 03:57:26PM +0800, Tony Breeds wrote: > > > > > Hi All, > > > These patches update the xm-test code to be more easily portable > > > to new architecture. This focus of this endeavor is PPC but I believe > > > that IA64 also benefits. > > > > > > Patch summary: > > > > > > 1: Instead of using a dated snapshot (which no longer exists) > > > use buildroot-snapshot. > > > > The last time I built a xm-test ramdisk, the buildroot-snapshot was broken, > > and I had to go back a few days to find a working one. I'm wary of using > > buildroot-snapshot for that reason. Does anyone work within the buildroot > > community? Perhaps we could persuade them to keep "released" versions > > around, > > rather than just the expiring, daily snapshots? > > Ewan, if you have some problem with patch 1/6, could you still apply the > rest to xen-unstable? 2/6 wouldn't apply cleanly, but should be easy to > do by hand. I've got no particular problem with these patches (we'll host the buildroot tar on xenbits, which was the only query). The tree's feature-frozen now though -- we're at RC2 -- so these will drop in immediately after the release. Ewan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On Mon, 2006-10-02 at 13:23 +0100, Ewan Mellor wrote: > On Mon, Oct 02, 2006 at 03:57:26PM +0800, Tony Breeds wrote: > > > Hi All, > > These patches update the xm-test code to be more easily portable > > to new architecture. This focus of this endeavor is PPC but I believe > > that IA64 also benefits. > > > > Patch summary: > > > > 1: Instead of using a dated snapshot (which no longer exists) > > use buildroot-snapshot. > > The last time I built a xm-test ramdisk, the buildroot-snapshot was broken, > and I had to go back a few days to find a working one. I'm wary of using > buildroot-snapshot for that reason. Does anyone work within the buildroot > community? Perhaps we could persuade them to keep "released" versions around, > rather than just the expiring, daily snapshots? Ewan, if you have some problem with patch 1/6, could you still apply the rest to xen-unstable? 2/6 wouldn't apply cleanly, but should be easy to do by hand. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
