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