Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures

2006-10-03 Thread Ewan Mellor
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

Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures

2006-10-03 Thread Hollis Blanchard
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

Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures

2006-10-03 Thread Keir Fraser
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.

[XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Maria Butrico
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

Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures

2006-10-03 Thread Aron Griffis
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

Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG

2006-10-03 Thread Jimi Xenidis
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 asm/debugger.h. This will cause the redundancy definition

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Jimi Xenidis
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

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Amos Waterland
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

Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG

2006-10-03 Thread Amos Waterland
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

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Maria Butrico
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

Re: [XenPPC] Re: Automated reliability report for SMP patch on JS2x

2006-10-03 Thread Jimi Xenidis
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

[PATCH] Re: [XenPPC] XenPPC: redundancy definition of __trap_to_gdb with CRASH_DEBUG

2006-10-03 Thread Tony Breeds
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