[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen4.2 S3 regression?
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@xxxxxxxxxx> 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@xxxxxxxx> wrote:
>>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@xxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
