From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
"Xu, YongweiX" <yongweix.xu@intel.com>,
"Liu, SongtaoX" <songtaox.liu@intel.com>,
"Tian, Yongxue" <yongxue.tian@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: test report for Xen 4.3 RC1
Date: Wed, 5 Jun 2013 10:50:14 -0400 [thread overview]
Message-ID: <20130605145014.GA18940@phenom.dumpdata.com> (raw)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1001B010FB@SHSMSX102.ccr.corp.intel.com>
> > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1851
> > > >
> > > > That looks like you are hitting the udev race.
> > > >
> > > > Could you verify that these patches:
> > > > https://lkml.org/lkml/2013/5/13/520
> > > >
> > > > fix the issue (They are destined for v3.11)
> > > >
> > > Not tried yet. I'll update it to you later.
> >
> > Thanks!
> > >
> We tested kernel 3.9.3 with the 2 patches you mentioned, and found this
> bug still exist. For example, we did CPU online-offline for Dom0 for 100 times,
> and found 2 times (of 100 times) failed.
Hm, does it fail b/c udev can't online the sysfs entry?
.. snip..
> > >
> > > > >
> > > > > Old bugs: (11)
> > > > > 1. [ACPI] Dom0 can't resume from S3 sleep
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> > > >
> > > > That should be fixed in v3.11 (as now we have the fixes)
> > > > Could you try v3.10 with the Rafael's ACPI tree merged in?
> > > > (so the patches that he wants to submit for v3.11)
> > > >
> > > I re-tested with Rafel's linux-pm.git tree (master and acpi-hotplug
> > branch),
> > > and found Dom0 S3 sleep/resume can't work, either.
> >
> > The patches he has to submit for v3.11 are in the linux-next branch.
> > You need to use that branch.
> >
> Dom0 S3 sleep/resume doesn't work with linux-next branch, either.
> attached the log.
It does work on my box. So I am not sure if this is related to the
IvyTown box you are using. Does it work on other machines?
>
> > >
> > > > > 2. [XL]"xl vcpu-set" causes dom0 crash or panic
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
> > > >
> > > > That I think is fixed in v3.10. Could you please check v3.10-rc3?
> > > >
> > > Still exists on v3.10-rc3.
> > > The following command lines can reproduce it:
> > > # xl vcpu-set 0 1
> > > # xl vcpu-set 0 20
> >
> > Ugh, same exact stack trace? And can you attach the full dmesg or serial
> > output (so that Ican see what there is at bootup)
> >
> Yes, the same. Also attached in this mail.
One of the fixes is this one:
http://www.gossamer-threads.com/lists/xen/devel/284897
but the other ones I had not seen. I am wondering if the
update_sd_lb_stats is b/c of the previous conditions (that is the
tick_nohz_idle_start hadn't been called).
It is a shoot in the dark - but if you use the above mentioned patch
do you still see the update_sd_lb_stats crash?
> > >
> > > > > 4. 'xl vcpu-set' can't decrease the vCPU number of a HVM guest
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > > >
> > > > That I believe was an QEMU bug:
> > > > http://lists.xen.org/archives/html/xen-devel/2013-05/msg01054.html
> > > >
> > > > which should be in QEMU traditional now (05-21 was when it went
> > > > in the tree)
> > > >
> > > In this year or past year, this bug always exists (at least in our testing).
> > > 'xl vcpu-set' can't decrease the vCPU number of a HVM guest
> >
> > Could you retry with Xen 4.3 please?
> >
> With Xen 4.3 & Linux:3.10.0-rc3, I can't decrease the vCPU number of a guest.
Could you give some more details? Could you include the /var/log/xen/qemu-... log file?
You are using the traditional QEMU right? (you need to have this in your guest
config:
device_model_version = 'qemu-xen-traditional'
next prev parent reply other threads:[~2013-06-05 14:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 10:14 test report for Xen 4.3 RC1 Ren, Yongjie
2013-06-05 14:50 ` Konrad Rzeszutek Wilk [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-06-16 4:10 Ren, Yongjie
2013-06-17 14:23 ` Konrad Rzeszutek Wilk
2013-06-17 20:35 ` Konrad Rzeszutek Wilk
2013-06-17 20:36 ` Konrad Rzeszutek Wilk
2013-06-20 2:53 ` Ren, Yongjie
2013-06-21 18:17 ` Konrad Rzeszutek Wilk
2013-07-02 8:09 ` Ren, Yongjie
2013-07-02 13:36 ` Konrad Rzeszutek Wilk
2013-06-04 15:59 Ren, Yongjie
2013-06-04 16:35 ` Konrad Rzeszutek Wilk
2013-05-27 3:49 Ren, Yongjie
2013-05-28 15:15 ` Konrad Rzeszutek Wilk
2013-05-28 15:21 ` Konrad Rzeszutek Wilk
2013-05-28 15:24 ` George Dunlap
2013-11-11 10:22 ` Ian Campbell
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=20130605145014.GA18940@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=george.dunlap@eu.citrix.com \
--cc=songtaox.liu@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yongjie.ren@intel.com \
--cc=yongweix.xu@intel.com \
--cc=yongxue.tian@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).