RE: [Xen-devel] xen 4.1 rc2 test report ( 5new issues found)

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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