Re: S3 resume issues

[Tomasz Wroblewski <tomasz.wroblewski@citrix.com>]

On 02/01/13 14:08, Ben Guthro wrote:
> I'm starting a new thread on this, to attempt to not confuse this 
> issue, with the other S3 issue reported by Marek Marczykowski against 4.1
> If you prefer I continue that thread instead, please let me know, and 
> I will be happy to do so.
>
> Some background:
> I am attempting to chase down yet another S3 issue in the Xen-4.2 / 
> unstable tree, seen on some (but not all) platforms.
> The particular machine I am able to reproduce it 100% of the time is a 
> Lenovo T430 (Ivy bridge laptop)
>
I've been debugging this same issue alongside Ben, happening on Lenovo 
T520 laptop. Found out that this is fixable by putting

mdelay(500)

in arch/x86/acpi/power.c : enter_state()

pretty much doesn't matter where in this function this is placed, fixes 
the issue. Further debugging what happens during just the period of this 
mdelay() revealed that there is hardware apic timer interrupt firing 
during that period, which if not serviced before the S3 suspend, will 
cause a failure after resume.

So this interrupt is serviced in apic.c apic_timer_interrupt(). It 
mainly just asserts TIMER_SOFTIRQ. Indeed, replacing the mdelay() with 
raise_softirq(TIMER_SOFTIRQ) anywhere in enter_state() fixes the problem 
as well.

So my theory is that the local apic timer state is lost during the S3 
suspend, causing a failure to fire off the timer interrupt and 
subsequent failure to assert the TIMER_SOFTIRQ. Given that some timers 
in sched_credit.c and schedule.c seem to be hanging on this timer 
softirq in order to keep the scheduler going, I suspect the scheduler 
stops working properly after the resume.

Does that sound plausible? Asserting the TIMER_SOFTIRQ on resume path 
seems to be one way of fixing this, is there any better way? Like for 
example some tweaks to lapic_suspend() / lapic_resume() to do extra 
preservation of the lapic timer/interrupt state ?