Re: High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3080 bytes --]

On 28.03.2013 17:52, Jan Beulich wrote:
>>>> On 28.03.13 at 17:31, Marek Marczykowski <marmarek@invisiblethingslab.com>
> wrote:
>> On 28.03.2013 17:25, Jan Beulich wrote:
>>>>>> On 27.03.13 at 15:31, Marek Marczykowski <marmarek@invisiblethingslab.com>
>>> wrote:
>>>> On 27.03.2013 09:52, Jan Beulich wrote:
>>>>>>>> On 26.03.13 at 19:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>>> So vector e9 doesn't appear to be programmed in anywhere.
>>>>>
>>>>> Quite obviously, as it's the 8259A vector for IRQ 9. The question
>>>>> really is why an IRQ appears on that vector in the first place. The
>>>>> 8259A resume code _should_ leave all IRQs masked on a fully
>>>>> IO-APIC system (see my question raised yesterday).
>>>>>
>>>>> And that's also why I suggested, for an experiment, to fiddle with
>>>>> the loop exit condition to exclude legacy vectors (which wouldn't
>>>>> be a final solution, but would at least tell us whether the direction
>>>>> is the right one). In the end, besides understanding why an
>>>>> interrupt on vector E9 gets raised at all, we may also need to
>>>>> tweak the IRQ migration logic to not do anything on legacy IRQs,
>>>>> but that would need to happen earlier than in
>>>>> smp_irq_move_cleanup_interrupt(). Considering that 4.3
>>>>> apparently doesn't have this problem, we may need to go hunt for
>>>>> a change that isn't directly connected to this, yet deals with the
>>>>> problem as a side effect (at least I don't recall any particular fix
>>>>> since 4.2). One aspect here is the double mapping of legacy IRQs
>>>>> (once to their IO-APIC vector, and once to their legacy vector,
>>>>> i.e. vector_irq[] having two entries pointing to the same IRQ).
>>>>
>>>> So tried change loop condition to LAST_DYNAMIC_VECTOR and it doesn't hit 
>>>> that
>>>> BUG/ASSERT. But still it doesn't work - only CPU0 used by scheduler, also 
>>>> some
>>>> errors from dom0 kernel, and errors about PCI devices used by domU(1).
>>>>
>>>> Messages from resume (different tries):
>>>> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector.log 
>>>> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector2.log 
>>>
>>> Is that a sensible usage scenario at all? I would think that a
>>> prerequisite to host S3 is that all guests get suspended. 
>>
>> What do you mean by "suspended"? I haven't found any sane method to do that
>> with xl (only some manual xenstore write to control/shutdown). For now I do:
>>  - shutdown all network adapters in VMs
>>  - pause all VMs
> 
> Aren't there "xl save" and "xl restore"? And for HVM guests, I think
> there's also a way to do virtual S3.

xl save/restore takes far to much time.

I've tried xenstore-write "suspend" to control/shutdown, then xc_domain_resume
call some time ago, but I had some problems with that (unfortunately don't
remember details...).
This is basically what xl save and restore does, but without actual data dump.

-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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