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