x86: Expected system state when resumed

x86: Expected system state when resumed

[Deepak Saxena]

I am working on getting suspend/resume working on an x86 system
(OLPC XO-1.5) where we are implementing ACPI based suspend/resume
using Open Firmware and what I am seeing right now is that on 
resume, we're not receiving interrupts so the system locks
up in the suspend path when msleep() is called from the EHCI
HCD resume code. lapic_resume() is being called so the APIC
is being restored.  I'm looking for information on what else
Linux's expectation from the firmware when control is handed back 
before I start dumping every system register pre and post resume.

Thanks,
~Deepak (an ARM person swimming in x86 land)

-- 
In the end, they will not say, "those were dark times,"  they will ask
"why were their poets silent?" - Bertold Brecht

Re: x86: Expected system state when resumed

[Rafael J. Wysocki]

On Tuesday 21 July 2009, Deepak Saxena wrote:
> 
> I am working on getting suspend/resume working on an x86 system
> (OLPC XO-1.5) where we are implementing ACPI based suspend/resume
> using Open Firmware and what I am seeing right now is that on 
> resume, we're not receiving interrupts so the system locks
> up in the suspend path when msleep() is called from the EHCI
> HCD resume code. lapic_resume() is being called so the APIC
> is being restored.  I'm looking for information on what else
> Linux's expectation from the firmware when control is handed back 
> before I start dumping every system register pre and post resume.

If that's 2.6.30 or later and your timer interrupt is MSI, for example, please
check if the timer interrupt is marked as IRQF_TIMER.  If it's not,
suspend_device_irqs() will mark it as disabled and it won't work during
early resume.

Best,
Rafael

Re: x86: Expected system state when resumed

[Wu Zhangjin]

On Tue, 2009-07-21 at 22:48 +0200, Rafael J. Wysocki wrote:
> On Tuesday 21 July 2009, Deepak Saxena wrote:
> > 
> > I am working on getting suspend/resume working on an x86 system
> > (OLPC XO-1.5) where we are implementing ACPI based suspend/resume
> > using Open Firmware and what I am seeing right now is that on 
> > resume, we're not receiving interrupts so the system locks
> > up in the suspend path when msleep() is called from the EHCI
> > HCD resume code. lapic_resume() is being called so the APIC
> > is being restored.  I'm looking for information on what else
> > Linux's expectation from the firmware when control is handed back 
> > before I start dumping every system register pre and post resume.
> 
> If that's 2.6.30 or later and your timer interrupt is MSI, for example, please
> check if the timer interrupt is marked as IRQF_TIMER.  If it's not,
> suspend_device_irqs() will mark it as disabled and it won't work during
> early resume.

Hi, Rafael

This IRQF_TIMER flag also works for me, thanks very much.

is there a need to tell all the guys who are maintaining the
platform-specific STR/Standby to mark their external timer interrupt to
IRQF_TIMER? or, pushing a patch to fix all of the relative timer
interrupts existing in the kernel. otherwise, they will waste time to
debug and fix this problem, hope they can search this E-mail and the
relative commits:

1. commit fee803b2f0c28c78984fc319bd4b88ad47117368
    x86: hpet: Mark per cpu interrupts IRQF_TIMER to prevent resume
failure
2. commit 936577c61d0c10b8929608a92c98d839b22053bc
    x86: Add IRQF_TIMER to legacy x86 timer interrupt descriptors

Regards,
Wu Zhangjin

Re: x86: Expected system state when resumed

[Deepak Saxena]

On Jul 21 2009, at 22:48, Rafael J. Wysocki was caught saying:
> On Tuesday 21 July 2009, Deepak Saxena wrote:
> > 
> > I am working on getting suspend/resume working on an x86 system
> > (OLPC XO-1.5) where we are implementing ACPI based suspend/resume
> > using Open Firmware and what I am seeing right now is that on 
> > resume, we're not receiving interrupts so the system locks
> > up in the suspend path when msleep() is called from the EHCI
> > HCD resume code. lapic_resume() is being called so the APIC
> > is being restored.  I'm looking for information on what else
> > Linux's expectation from the firmware when control is handed back 
> > before I start dumping every system register pre and post resume.
> 
> If that's 2.6.30 or later and your timer interrupt is MSI, for example, please
> check if the timer interrupt is marked as IRQF_TIMER.  If it's not,
> suspend_device_irqs() will mark it as disabled and it won't work during
> early resume.

Thanks. I am using 2.6.30.1 and the standard x86 HPET driver which has 
IRQF_TIMER set so this is not the issue. I've determined that if I boot 
with "noapic", I can suspend/resume, but the system runs very slow as the
PATA controller is now polled instead of irq driven.

~Deepak

-- 
In the end, they will not say, "those were dark times,"  they will ask
"why were their poets silent?" - Bertold Brecht

Re: [linux-pm] x86: Expected system state when resumed

[Rafael J. Wysocki]

On Wednesday 22 July 2009, Deepak Saxena wrote:
> On Jul 21 2009, at 22:48, Rafael J. Wysocki was caught saying:
> > On Tuesday 21 July 2009, Deepak Saxena wrote:
> > > 
> > > I am working on getting suspend/resume working on an x86 system
> > > (OLPC XO-1.5) where we are implementing ACPI based suspend/resume
> > > using Open Firmware and what I am seeing right now is that on 
> > > resume, we're not receiving interrupts so the system locks
> > > up in the suspend path when msleep() is called from the EHCI
> > > HCD resume code. lapic_resume() is being called so the APIC
> > > is being restored.  I'm looking for information on what else
> > > Linux's expectation from the firmware when control is handed back 
> > > before I start dumping every system register pre and post resume.
> > 
> > If that's 2.6.30 or later and your timer interrupt is MSI, for example, please
> > check if the timer interrupt is marked as IRQF_TIMER.  If it's not,
> > suspend_device_irqs() will mark it as disabled and it won't work during
> > early resume.
> 
> Thanks. I am using 2.6.30.1 and the standard x86 HPET driver which has 
> IRQF_TIMER set so this is not the issue. I've determined that if I boot 
> with "noapic", I can suspend/resume, but the system runs very slow as the
> PATA controller is now polled instead of irq driven.

So it looks like with IO-APIC enabled the timer interrupts don't reach the CPU
during resume, which indicates that the post-resume status of the IO-APIC is
somewhat not as expected.

Best,
Rafael

Re: x86: Expected system state when resumed

[Pavel Machek]

On Tue 2009-07-21 09:45:42, Deepak Saxena wrote:
> 
> I am working on getting suspend/resume working on an x86 system
> (OLPC XO-1.5) where we are implementing ACPI based suspend/resume
> using Open Firmware and what I am seeing right now is that on 
> resume, we're not receiving interrupts so the system locks
> up in the suspend path when msleep() is called from the EHCI
> HCD resume code. lapic_resume() is being called so the APIC
> is being restored.  I'm looking for information on what else
> Linux's expectation from the firmware when control is handed back 
> before I start dumping every system register pre and post resume.

Well, acpi spec should answer that...
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html