WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] suspending a domain in the ngio world

To: Kip Macy <kmacy@xxxxxxxxxxx>
Subject: Re: [Xen-devel] suspending a domain in the ngio world
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 15 May 2004 18:43:19 +0100
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 15 May 2004 18:45:27 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Sat, 15 May 2004 10:02:40 PDT." <20040515094502.B86487@xxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> questions:
> 1)
> Does this extend as far as not being able to stop without destroying at
> all?
> I can still interact with the domain over its console.

I checked in a fix for this a couple of hours ago -- it was stopping
a domain from dying except via a forced destroy from DOM0 (e.g.,
/sbin/reboot within the domain itself wouldn't work). So a stop
request should now stop the domain. Won't be much use though as I'm
pretty sure it won't start up again happily!

> ============================================================
> 2)
> I take it that many of the following are expected right now when
> destroying a domain with I/O in flight:
> 
> (XEN) DOM0: (file=memory.c, line=935) Unknown domain '2'
> (file=main.c, line=266) Failed MMU update transferring to DOM2

Yep, I see this. As I said: xend can just about set up a basic
interface between a guest and a device-driver backend. It's not got
functionality for tearing the interface down properly, which leaves
the backend driver in a confused state, getting you a bunch of
(fairly harmless) errors.

> [root@xen-vm0 ~]$ while (1)
> while? dd if=/dev/zero of=/tmp/bwout count=1024 bs=1024k
> while? end
> 1024+0 records in
> 1024+0 records out
> 1024+0 records in
> 1024+0 records out
> 1024+0 records in
> 1024+0 records out
> 1024+0 records in
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process umount
> I guess memory management is a work in progress?

This is within DOM1 (i.e., not DOM0) right? If so, I guess that doing
this 'dd' test within DOM0 doesn't get you similar messages? 

This is rather unexpected -- if you could add a stack backtrace to the
out-of-memory path in the page allocator (page_alloc.c in Xenolinux)
an d post me that with the kernel image (vmlinux) then I'll see what I
can work out. I guess I haven't tested all that hard so there might be
a memory leak.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel