All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kip Macy <kmacy@fsmware.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: suspending a domain in the ngio world
Date: Sat, 15 May 2004 10:02:40 -0700 (PDT)	[thread overview]
Message-ID: <20040515094502.B86487@demos.bsdclusters.com> (raw)
In-Reply-To: <E1BP1lu-0005dl-00@mta1.cl.cam.ac.uk>

questions:
1)
Does this extend as far as not being able to stop without destroying at
all?
kmacy@curly r ./xc_dom_control.py list
Dom  Name             Mem(kb)  CPU  State  Time(ms)
0    Domain-0          257128   0    r-    28516
1    This is VM 2       64920   0    --     5227
kmacy@curly r ./xc_dom_control.py stop 1
return code 0
kmacy@curly r ./xc_dom_control.py list
Dom  Name             Mem(kb)  CPU  State  Time(ms)
0    Domain-0          257052   0    r-    28769
1    This is VM 2       64996   0    --     5245

I can still interact with the domain over its console.

============================================================
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
========================================================
3)
I just did the following:
[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
1024+0 records out
1024+0 records in
1024+0 records out

and then I saw this on the machine console:

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process python
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process syslogd
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process sendmail
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process ypbind
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process ypbind
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process sshd
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process sshd
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process tcsh
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process crond
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process crond
(XEN) (file=traps.c, line=469) GPF (0004): fc520e08 -> fc52e2d2
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process portmap
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process umount


I guess memory management is a work in progress?

Thanks.


				-Kip


On Sat, 15 May 2004, Keir Fraser wrote:

> > Ok - thanks. Is this because all the dependencies for stopping a domain
> > are not in place? Or are the interfaces in flux in general? What I'm
> > trying to do is get the bits in place for core debugging of non-
> > privileged domains.
>
> xend doesn't do setup/teardown of i/o connections properly yet. What's
> there is a very basic lashup to create very simple configurations --
> but not enough to suspend/resume them.
>
>  -- 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
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

  reply	other threads:[~2004-05-15 17:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040513221648.W77678@demos.bsdclusters.com>
2004-05-14  6:35 ` system lockup when starting secondary domains Keir Fraser
2004-05-14 20:56   ` Kip Macy
2004-05-14 21:02     ` never mind was " Kip Macy
2004-05-14 21:25     ` telnet xend Kip Macy
2004-05-14 21:33       ` Ian Pratt
2004-05-14 21:48         ` Kip Macy
2004-05-14 22:37           ` Kip Macy
2004-05-14 22:39             ` Kip Macy
2004-05-14 22:49             ` Ian Pratt
2004-05-14 23:14               ` Kip Macy
2004-05-15  4:26               ` suspending a domain in the ngio world Kip Macy
2004-05-15  5:17                 ` Kip Macy
2004-05-15  8:16                 ` Keir Fraser
2004-05-15 15:51                   ` Kip Macy
2004-05-15 16:12                     ` Keir Fraser
2004-05-15 17:02                       ` Kip Macy [this message]
2004-05-15 17:43                         ` Keir Fraser
2004-05-15 18:10                           ` Kip Macy
2004-05-15 23:21                             ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040515094502.B86487@demos.bsdclusters.com \
    --to=kmacy@fsmware.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.