On 20/06/13 11:38, Jan Beulich wrote:
On 19.06.13 at 17:25, David Vrabel wrote:
>> syscore_suspend() and syscore_resume() expect there to be only one
>> online CPU. e.g., hrtimers_resume() only triggers events for the
>> current CPU. Xen's suspend path was leaving all VCPUs online and then
>>> On 19.06.13 at 17:25, David Vrabel wrote:
> syscore_suspend() and syscore_resume() expect there to be only one
> online CPU. e.g., hrtimers_resume() only triggers events for the
> current CPU. Xen's suspend path was leaving all VCPUs online and then
> attempting to fixup problems afterwards
On 19/06/13 18:11, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 19, 2013 at 04:25:20PM +0100, David Vrabel wrote:
>> From: David Vrabel
>>
>> syscore_suspend() and syscore_resume() expect there to be only one
>> online CPU. e.g., hrtimers_resume() only triggers events for the
>> current CPU. Xen's
On Wed, Jun 19, 2013 at 04:25:20PM +0100, David Vrabel wrote:
> From: David Vrabel
>
> syscore_suspend() and syscore_resume() expect there to be only one
> online CPU. e.g., hrtimers_resume() only triggers events for the
> current CPU. Xen's suspend path was leaving all VCPUs online and then
>
From: David Vrabel
syscore_suspend() and syscore_resume() expect there to be only one
online CPU. e.g., hrtimers_resume() only triggers events for the
current CPU. Xen's suspend path was leaving all VCPUs online and then
attempting to fixup problems afterwards (e.g., with an explicit call
to cl
5 matches
Mail list logo