Re: [Xen-devel] Xen4.2 S3 regression?

[Ben Guthro <ben@xxxxxxxxxx>]

On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

That's because CPU1 is stuck in cpu_init() (in the infinite loop after
printing "CPU#1 already initialized!"), as Keir pointed out yesterday.

I've done some more tracing on this, and instrumented cpu_init(), cpu_uninit() - and found something I cannot quite explain.

I was most interested in the cpu_initialized mask, set just above these two functions (and only used in those two functions)

I convert  cpu_initialized to a string, using cpumask_scnprintf - and print it out when it is read, or written in these two functions.

When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and I am able to print this to the console to verify.

However, when the machine is returning from S3, and going through cpu_init - the bit is set again.

Could this be an issue of caches not being flushed?

I see that the last thing done before acpi_enter_sleep_state actually writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU_CACHE()

This analysis seems unlikely, at this point...but I'm not sure what to make of the data other than a cache issue.

Am I "barking up the wrong tree" here?

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