Re: [Xen-devel] test report for Xen 4.3 RC1

["Ren, Yongjie" <yongjie.ren@xxxxxxxxx>]

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Wednesday, June 05, 2013 10:50 PM
> To: Ren, Yongjie
> Cc: george.dunlap@xxxxxxxxxxxxx; Xu, YongweiX; Liu, SongtaoX; Tian,
> Yongxue; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] test report for Xen 4.3 RC1
> 
> > >
> 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?
>
I think no. 
When it fails to online CPU #3 (trying online #1~#3), it doesn't show any info
about CPU #3 via the output of "devadm monitor --env" CMD. It does show
info about #1 and #2 which are onlined succefully.

> .. 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?
>
No, it doesn't work on other machines, either. I also tried on SandyBridge, 
IvyBridge desktop and Haswell mobile 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?
> 
Yes, with the patch we still see the update_sd_lb_stats crash.
It has almost the same trace log as before. Log file is attached.

> > > >
> > > > > > 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.
> 
sorry, when I said this message, I still use rhel6.4 kernel as the guest.
After upgrading guest kernel to 3.10.0-rc3, the result became better.
Basically vCPU increment/decrement can work fine. I'll close that bug.
But there's still a minor issue as following.
After booting guest with 'vcpus=4' and 'maxvcpus=32', change its vCPU number.
# xl vcpu-set $domID 32
then you can only get less than 32 (e.g. 19) CPUs in the guest; again, you set
vCPU number to 32 (from 19), then it works to get 32vCPU for the guest.
but 'xl vcpu-set $domID 8' can work fine as we expected.
vCPU decrement has the same result.
Can you also have a try to reproduce my issue?

> Could you give some more details? Could you include the
> /var/log/xen/qemu-... log file?
>
Attached the qemu log.

> You are using the traditional QEMU right? (you need to have this in your
> guest
> config:
> device_model_version = 'qemu-xen-traditional'
>
Yes. 

--
  Jay

Attachment: xl_vcpu-set_dom0_call_trace.log
Description: xl_vcpu-set_dom0_call_trace.log

Attachment: xl_vcpu-set_HVM_from_4_to_32_qemu-dm.log
Description: xl_vcpu-set_HVM_from_4_to_32_qemu-dm.log

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel