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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.13 at 17:31, Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
> On 28.03.2013 17:25, Jan Beulich wrote:
>>>>> On 27.03.13 at 15:31, Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>> On 27.03.2013 09:52, Jan Beulich wrote:
>>>>>>> On 26.03.13 at 19:50, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.

Jan


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