xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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'

  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).