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] xen 4.1 rc2 test report ( 5new issues found)

On Sun, 30 Jan 2011, Zheng, Shaohui wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > Sent: Saturday, January 29, 2011 12:55 AM
> > To: Zheng, Shaohui
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] xen 4.1 rc2 test report ( 5new issues found)
> > 
> > On Fri, 28 Jan 2011, Zheng, Shaohui wrote:
> > > Save/Restore(1 bug)
> > > 1. RHEL6 guest fail to do save/restore (Community)
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1716
> > 
> > the bug has been filed on red hat's bugzilla
> > 
> Let 's track it in xen's bugzilla, too.
> 

Yep, good idea.


> > 
> > > 3. xl does not check the memory size of guest(Community)
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1729
> > 
> > I am not entirely sure we should try to solve this bug, after all we
> > should always try to do what the user asks us to do, even if it doesn't
> > make sense :)
> > 
> 
> It is a critical issue in fact. the request to create a very large guest will 
> fail obviously, but the system status already becomes abnormal. It prints a 
> lot error information continuously. 
> 
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 512)
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 
> of 512)
> 
> And We cannot create any guest any more except reboot the system.
> 

I see. That is definitely a bug and I can reproduce it.
I don't think xl is doing anything wrong here, because it is correctly
reporting an error and cleaning up the domain.
The problem is that xen keeps printing

"memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 512)"

even after xl returned (!!!).
Could it be an problem caused by the hypercall continuation (CC'ing
Keir and Tim)?


> > 
> > > 4. "xl vcpu-set" causes dom0 crash or panic (Community)
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
> > 
> > The repro steps say: "xl vcpu-set 0 16" but the vcpu-set commands
> > actually takes 3 arguments:
> > 
> > Usage: xl [-v] vcpu-pin <Domain> <VCPU|all> <CPUs|all>
> > 
> > In any case the bug looks like a dom0 kernel bug more than anything
> > else...
> > 
> 
> You are showing the Usage of "xl vcpu-pin", not "xl vcpu-set",  "xl vcpu-set" 
> takes 2 arguments.
> 
> [root@vt-nhm7 ~]# xl help vcpu-set
> Usage: xl [-v] vcpu-set <Domain> <vCPUs>
> 
> Set the number of active VCPUs allowed for the domain.
> 

Ooops, my mistake :)
vcpu-set only writes to xenstore, so this is defenitely a dom0 kernel
bug (CC'ing Jeremy).


> 
> > > 5. "xl vcpu-list" does not response after run vcpu-pin(Community)
> > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1731
> > 
> > Are use sure this is not just because the system has become very very
> > slow because 5 vcpus are running in a single pcpu?
> > Because I tried the very same steps reported above and it seems to work
> > for me.
> 
> It is NOT because we bind too much vcpu to the a single pcpu.  "xm vcpu-list" 
> can list the vcpus which does not do the binding only, but for the binded 
> vcpu, even though we bind only one vcpu to a pcpu, "xl vcpu-list" command 
> does not return, either. We need to type "CTRL-C" to terminate it.
> 

Strange. Could you run xl vcpu-list with strace?
Do you have any more logging (xen or dom0 serial)?
I suspect there might be a bug underneath...

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>