Re: Xen4.2 S3 regression?

[Keir Fraser <keir.xen@gmail.com>]

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

disable_nonboot_cpus() -> cpu_down(1) -> ...

...and from there it is same as the xen-hptool case:
arch_do_sysctl() -> cpu_down_helper() -> cpu_down(1) ->
stop_machine_run(take_cpu_down, 1) -> [on CPU#1] take_cpu_down() ->
__cpu_disable()

On 20/09/2012 13:56, "Ben Guthro" <ben@guthro.net> wrote:

> It appears __cpu_disable() is not getting reached at all, for CPU1
> 
> I put a cpu id conditional BUG() call in there, to verify - and while it is
> reached when using 
> xen-hptool cpu-offline 1
> It never seems to be reached from the S3 path.
> 
> 
> What is the expected call chain to get into this code during S3?
> 
> 
> On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
>>> > CPU#1 got stuck in loop in cpu_init() as it appears to be Œalready
>>> > initialised¹ in cpu_initialized bitmap. CPU#0 detects it is stuck and
>>> > carries on, but the resume code assumes all CPUs are brought back online
>>> and
>>> > crashes later.
>> 
>> So this would suggest play_dead() (-> cpu_exit_clear() ->
>> cpu_uninit()) not getting reached during the suspend cycle.
>> That should be fairly easy to verify, as the serial console
>> ought to still work when the secondary CPUs get offlined.
>> 
>> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
>> not getting reached in __cpu_disable(), which would be in line
>> with the observation that none of the logs provided so far
>> showed anything being done by fixup_irqs() (called right
>> after clearing the online bit).
>> 
>> Jan
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 2419 bytes --]

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

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