Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek <xhejtman@ics.muni.cz>]

> Yep -- here's the quote from ACPI 3.0b:
> 
> OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the following
> order:
> 1.OSPM decides (through a policy scheme) to place the system into a
> sleeping state.
> 2._TTS(Sx) is run, where Sx is the desired sleep state to enter.
> 3. OSPM notifies all native device drivers of the sleep state transition
> 4._PTS is run
> 5.OSPM readies system for the sleep state transition
> 6._GTS is run
> 7.OSPM writes the sleep vector and the system enters the specified Sx
> sleep state.
> 8.System Wakes up
> 9._BFS is run
> 10.OSPM readies system for the return from the sleep state transition
> 11._WAK is run
> 12. OSPM notifies all native device drivers of the return from the sleep
> state transition
> 13._TTS(0) is run to indicate the return to the S0 state.
> 
> Technically we write the sleep vector too early as well.
> And we don't evaluate _TTS at all -- though _TTS was
> added only as of ACPI 3.0 and I've not seen it implemented on
> any of the systems I've got.

However, we still do something wrong with ACPI and suspend-to-ram because my
system is unable to reboot after resume from ram. The only way to reboot is to
disable the ACPI in the machine_emergency_restart(). (in particular, keyboard
LEDs flash as the reset has been issued but the BIOS logo does not appear.)

Any ideas, Len?

Andrew dislikes the patch resulted from this bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=6655

Anyway, it works for me pretty well.

-- 
Lukáš Hejtmánek
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html