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 b
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 archit
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 th
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 fo
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 re
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/debugg
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 patc
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 changese
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
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 t
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 any
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
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
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
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 th
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 fi
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
17 matches
Mail list logo
