|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] suspending a domain in the ngio world
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@xxxxxxxxxxxxxxxxxxxxx
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] telnet xend, (continued)
- Re: [Xen-devel] telnet xend, Kip Macy
- Re: [Xen-devel] telnet xend, Kip Macy
- Re: [Xen-devel] telnet xend, Kip Macy
- Re: [Xen-devel] telnet xend, Ian Pratt
- Re: [Xen-devel] telnet xend, Kip Macy
- [Xen-devel] suspending a domain in the ngio world, Kip Macy
- Re: [Xen-devel] suspending a domain in the ngio world, Kip Macy
- Re: [Xen-devel] suspending a domain in the ngio world, Keir Fraser
- Re: [Xen-devel] suspending a domain in the ngio world, Kip Macy
- Re: [Xen-devel] suspending a domain in the ngio world, Keir Fraser
- Re: [Xen-devel] suspending a domain in the ngio world,
Kip Macy <=
- Re: [Xen-devel] suspending a domain in the ngio world, Keir Fraser
- Re: [Xen-devel] suspending a domain in the ngio world, Kip Macy
- Re: [Xen-devel] suspending a domain in the ngio world, Keir Fraser
|
|
|
|
|