From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [TESTDAY] Test report Date: Fri, 24 Jan 2014 14:06:19 -0500 Message-ID: <52E2B9AB.6090103@terremark.com> References: <52DDA807.2050703@terremark.com> <52E191BB.7040904@terremark.com> <20140124145840.GE12946@phenom.dumpdata.com> <52E29827.7000001@terremark.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7875061455415934661==" Return-path: In-Reply-To: <52E29827.7000001@terremark.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Don Slutz Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============7875061455415934661== Content-Type: multipart/alternative; boundary="------------070901010209060000050803" --------------070901010209060000050803 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 01/24/14 11:43, Don Slutz wrote: > On 01/24/14 09:58, Konrad Rzeszutek Wilk wrote: >> On Thu, Jan 23, 2014 at 05:03:39PM -0500, Don Slutz wrote: >>> On 01/20/14 18:35, Konrad Rzeszutek Wilk wrote: >>>> Don Slutz wrote: >>> [snip] >>> >>>>> WARNING: g.e. still in use! >>>>> WARNING: g.e. still in use! >>>>> WARNING: g.e. still in use! >>>>> pm_op(): platform_pm_resume+0x0/0x50 returns -19 >>>>> PM: Device i8042 failed to resume: error -19 >>>>> INFO: task sadc:22164 blocked for more then 120 seconds. >>>>> "echo 0 >..." >>>>> INFO: task sadc:22164 blocked for more then 120 seconds. >>>>> >>>>> [root@dcs-xen-54 ~]# xl des 17 >>>>> [root@dcs-xen-54 ~]# xl restore -V >>>>> /big/xl-save/centos-6.4-x86_64.0.save >>>>> >>>>> >>>>> Not sure if this is expected or not. >>>> I think Ian saw this with the 'fast-cancel' something resume but I might be incorrect. Did it work if you used xend (you might have to configure it be enabled)? >>> I have not used xend/xe in a long time. I did need to configure it. >>> >>> Does not start: >>> >>> >>> # /etc/init.d/xend start >>> WARNING: Enabling the xend toolstack. >>> xend is deprecated and scheduled for removal. Please migrate >>> to another toolstack ASAP. >>> Traceback (most recent call last): >>> File "/usr/sbin/xend", line 110, in >>> sys.exit(main()) >>> File "/usr/sbin/xend", line 91, in main >>> start_blktapctrl() >>> File "/usr/sbin/xend", line 77, in start_blktapctrl >>> start_daemon("blktapctrl", "") >>> File "/usr/sbin/xend", line 74, in start_daemon >>> os.execvp(daemon, (daemon,) + args) >>> File "/usr/lib64/python2.7/os.py", line 344, in execvp >>> _execvpe(file, args) >>> File "/usr/lib64/python2.7/os.py", line 380, in _execvpe >>> func(fullname, *argrest) >>> OSError: [Errno 2] No such file or directory >>> >>> >>> How important is it to try this? >> It tells us whether the issue is indeed with the 'fast-cancel' thing. >> >> But, I do recall seeing a patch from Ian Jackson for this - I just >> don't remember what it was called - it was posted here and perhaps >> applying it would help? > > I have not found a patch. The bug #30: > > > http://bugs.xenproject.org/xen/bug/30 > > Looks to me like the issue I am seeing. The Guest I was testing this on is an old kernel (as far as this bug) and so I would expect it might be related. > > > Here is what I see that may link it to this: > > *From*: Ian Campbell > *To*: Ian Jackson > *Cc*:xen-devel@lists.xen.org > *Subject*: Re: [Xen-devel] 3.4.70+ kernel WARNING spew dysfunction on failed migration > *Date*: Fri, 10 Jan 2014 10:26:31 +0000 > > ... > > Looks like RHEL4 (linux-2.6.9-89.0.16.EL kernel) doesn't have the > support for the new mode at all. > > It would probably be wise to validate this under xend before chasing > red-herrings with xl. > > Ian. > > > So I will continue the fight to get xend running. > > -Don > > Ah, now have xend running, but still need to convert from an xl.cfg file to a xmdomain.cfg... Having not used xm in years, this will take a while. The man page does not say how to build an hvm guest. I did another test and Fedora 19 (x86_64) saved just fine. So this looks to be bug #30. If I understand this all, this means that the older linux kernels will fail this way also if a migrate fails and the source guest is restarted. So, do I continue to get xend working, or just say it is an example of bug #30? -Don Slutz > > > >>> -Don Slutz >>> > --------------070901010209060000050803 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 01/24/14 11:43, Don Slutz wrote:
On 01/24/14 09:58, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 23, 2014 at 05:03:39PM -0500, Don Slutz wrote:
On 01/20/14 18:35, Konrad Rzeszutek Wilk wrote:
Don Slutz <dslutz@verizon.com> wrote:
[snip]

WARNING: g.e. still in use!
WARNING: g.e. still in use!
WARNING: g.e. still in use!
pm_op(): platform_pm_resume+0x0/0x50 returns -19
PM: Device i8042 failed to resume: error -19
INFO: task sadc:22164 blocked for more then 120 seconds.
"echo 0 >..."
INFO: task sadc:22164 blocked for more then 120 seconds.

[root@dcs-xen-54 ~]# xl des 17
[root@dcs-xen-54 ~]# xl restore -V
/big/xl-save/centos-6.4-x86_64.0.save


Not sure if this is expected or not.
I think Ian saw this with the 'fast-cancel' something resume but I might be incorrect. Did it work if you used xend (you might have to configure it be enabled)?
I have not used xend/xe in a long time.  I did need to configure it.

Does not start:


# /etc/init.d/xend start
WARNING: Enabling the xend toolstack.
xend is deprecated and scheduled for removal. Please migrate
to another toolstack ASAP.
Traceback (most recent call last):
  File "/usr/sbin/xend", line 110, in <module>
    sys.exit(main())
  File "/usr/sbin/xend", line 91, in main
    start_blktapctrl()
  File "/usr/sbin/xend", line 77, in start_blktapctrl
    start_daemon("blktapctrl", "")
  File "/usr/sbin/xend", line 74, in start_daemon
    os.execvp(daemon, (daemon,) + args)
  File "/usr/lib64/python2.7/os.py", line 344, in execvp
    _execvpe(file, args)
  File "/usr/lib64/python2.7/os.py", line 380, in _execvpe
    func(fullname, *argrest)
OSError: [Errno 2] No such file or directory


How important is it to try this?
It tells us whether the issue is indeed with the 'fast-cancel' thing.

But, I do recall seeing a patch from Ian Jackson for this - I just
don't remember what it was called - it was posted here and perhaps
applying it would help?

I have not found a patch.  The bug #30:


http://bugs.xenproject.org/xen/bug/30

Looks to me like the issue I am seeing.  The Guest I was testing this on is an old kernel (as far as this bug) and so I would expect it might be related.


Here is what I see that may link it to this:

From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 3.4.70+ kernel WARNING spew dysfunction on failed migration
Date: Fri, 10 Jan 2014 10:26:31 +0000

...
Looks like RHEL4 (linux-2.6.9-89.0.16.EL kernel) doesn't have the
support for the new mode at all.

It would probably be wise to validate this under xend before chasing
red-herrings with xl.

Ian.

So I will continue the fight to get xend running.

   -Don



Ah, now have xend running, but still need to convert from an xl.cfg file to a xmdomain.cfg...  Having not used xm in years, this will take a while.  The man page does not say how to build an hvm guest.

I did another test and Fedora 19 (x86_64) saved just fine.  So this looks to be bug #30.

If I understand this all, this means that the older linux kernels will fail this way also if a migrate fails and the source guest is restarted.

So, do I continue to get xend working, or just say it is an example of bug #30?

    -Don Slutz





    -Don Slutz



--------------070901010209060000050803-- --===============7875061455415934661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7875061455415934661==--