x86: Expected system state when resumed
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)
Signature · 2 lines
In the end, they will not say, "those were dark times," they will ask "why were their poets silent?" - Bertold Brecht
Quoted 10 lines · 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.
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
Quoted 12 lines · Rafael J. Wysocki
Quoted 10 lines · 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.
Quoted 4 lines
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
On Jul 21 2009, at 22:48, Rafael J. Wysocki was caught saying:
Quoted 12 lines · Deepak Saxena
Quoted 10 lines
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.
Quoted 4 lines
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
Signature · 2 lines
In the end, they will not say, "those were dark times," they will ask "why were their poets silent?" - Bertold Brecht
Quoted 18 lines · Deepak Saxena
On Jul 21 2009, at 22:48, Rafael J. Wysocki was caught saying:
Quoted 12 lines · Deepak Saxena
Quoted 10 lines
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.Quoted 4 lines
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.
Quoted 4 lines
Thanks. I am using 2.6.30.1 and the standard x86 HPET driver which has
IRQF_TIMERset 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
Quoted 10 lines · 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.
Well, acpi spec should answer that...
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html