On Feb 7, 2007, at 5:41 PM, Jerone Young wrote:
On Wed, 2007-02-07 at 17:37 -0500, Jimi Xenidis wrote:
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote:
OK all is well...no fire here...move along. I figured out what
happened.
I included the vmlinux as the DOM0_IMAGE and not the zImage. It
com
On Feb 7, 2007, at 5:38 PM, Hollis Blanchard wrote:
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message
happens
way before that point.
Thats not really true, dom0 is in .data, there are actually
additional
The patch removes the construction of a start_info_t structure for dom0,
no longer needed now that Linux and construct its own start_info_t.
Patch 2 fixes up Linux to not look for /xen/start-info and just create
one from the devtree.
Included in the patch are:
-remove the page allocated for the st
This patch cleans up xen_init_early() to construct a start_info_t only
from the devtree as Patch1 fixes xen to no longer create a start_info_t
for dom0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat outp
On Wed, 2007-02-07 at 17:37 -0500, Jimi Xenidis wrote:
> On Feb 7, 2007, at 12:48 PM, Jerone Young wrote:
>
> > OK all is well...no fire here...move along. I figured out what
> > happened.
> > I included the vmlinux as the DOM0_IMAGE and not the zImage. It
> > compiled
> > through .. it is a b
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message happens
way before that point.
The early boot code only tracks the first 32M of memory, and I believe
that is the problem here: we're overflowing the bitmap we're
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote:
OK all is well...no fire here...move along. I figured out what
happened.
I included the vmlinux as the DOM0_IMAGE and not the zImage. It
compiled
through .. it is a bit surprising the Xen died though and not during
loading of Dom0. So ultimat
So it looks like the problem has to do with tftp which apears to have a
64MB send limit. The file is over this and so everything does not make
it. Adding a check for dom0 image size does not good since the image
itself is not fully transfered. Which make since why you get the error:
boot_of_alloc_i
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
On Sat, 2007-01-27 at 13:00 -0800, Xen patchbot-unstable wrote:
> # HG changeset patch
> # User [EMAIL PROTECTED]
> # Date 1169836476 0
> # Node ID 32fd32bbf78d094e96027e3cea05fcbd92fee7a5
> # Parent 19a600376688577f0692eac022f05bc6df30ce93
> Add RCU support to Xen.
...
> @@ -658,6 +659,8 @@ vo
I'll give it a try.
On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote:
> I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with
> full debug symbols is 55MB here, which probably explains this problem.
>
> Could you see how easy it would be to catch this problem at runtime and
I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with
full debug symbols is 55MB here, which probably explains this problem.
Could you see how easy it would be to catch this problem at runtime and
have a nice panic? Checking dom0_len in __start_xen() would probably do
the trick, may
OK all is well...no fire here...move along. I figured out what happened.
I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled
through .. it is a bit surprising the Xen died though and not during
loading of Dom0. So ultimately this is a USER error ;-)
On Tue, 2007-02-06 at 17:58
Last time we saw this it had to do with building optimized and the
linker script simplification I attempted, so we were actually missing
bits.
before you do anything, try a clean build.
Another possibility is some corruption, you may want to debug what
the boot_of_allocator is reserving.
pushed.. thanks
On Feb 5, 2007, at 5:42 PM, Jerone Young wrote:
Yes..another Xencomm patch :-). The last one actually hit a bug
that was
currently in xen-linux with handling of domain control operation
XEN_DOMCTL_shadow_op. This fix is included in the patch. I've also
added error handling and
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID 5eca8383a521939f0d74e68eaddb049c5057742a
# Parent ab3b5849331da89e578ae0813021376d66b7f333
[XEN] xencomm fixes for various runtime situations
This patch makes xencomm safe for all allocations scenarios including:
- too early
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID 8bccc5d192be551cfe12e1c4d38bb49144f980aa
# Parent 5eca8383a521939f0d74e68eaddb049c5057742a
[POWERPC][XEN] Don't leak frame_list and don'r post process gnttab if OP fails
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
arc
17 matches
Mail list logo
