When a computer goes into ACPI S4 state it saves its RAM contents to disk and shuts down.
But what happens to registers, VRAM, or volatile memory inside extension cards or similar?
Add a comment
|
3 Answers
The TL:DR answer to your question is: Not as a part of the hardware/BIOS S4 implementation, though there is nothing stopping the OS/drivers from doing it.
According to the ACPI specification the Operating System is responsible for initializing all system devices to a usable state after restoring from an S4 hibernation.
ACPI Spec page 7-142 "System \ _S4 State":
- Devices states are compatible with the current Power Resource states. In other words, all devices are in the D3 state when the system state is S4
The D3 state is defined as:
D3 - Off:
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on. Since device context and power are lost, devices in this state do not decode their addresses lines. Devices in this state have the longest restore times.
All classes of devices define this state.
For the driver to function under Windows (or any OS for that matter) then it will have to allocate any buffers necessary and store some quantity of state information. This will be stored in the OS memory space and thus will be stored in the hibernation file.
The OS knows what devices to initialize and likely just calls the registered driver initialization code which will check whether any state information was saved in its internal buffers and restore the card to a usable state.
This just reiterates that the cards themselves know nothing of how to bring themselves out of hibernation state and come up into their default "power on" state until Windows (through the drivers) tells it otherwise. There is no requirement to store the card registers outside of OS dependent drivers which will get their memory space saved by the hibernation process.
answered Aug 17, 2013 at 18:19
-
If I read you right, the VRAM and other extension cards caches are saved in RAM within their respectives drivers. On exit of hibernation these drivers are in charge to reinstall these extension memory contents. Did I understand you right?– danCommented Aug 18, 2013 at 21:10
-
1That is how my understanding of it works. The OS (and by extension device drivers) have the responsibility for ensuring that all devices are restored to a usable state after a hibernation event. VRAM may not need to be specifically "saved" as VRAM simply stores a representation of what the system wants so it can be recovered by "replaying" the screen drawing process e.g. take this bitmap and draw it here, then draw this line and so on, all things that will be stored in system ram rather than just VRAM. Something similar is true for all other devices/drivers coming out of hibernation.– Mokubai ♦Commented Aug 18, 2013 at 21:23
-
SIMPLY WRONG. The default size of the hibernation file (hiberfil.sys) varies depending on the amount of RAM installed on your PC. The VRAM in modern video cards can be as large or larger than the computer's RAM, but doesn't enter into this calculation. If one replaces the video card by one with larger VRAM, Windows will not reallocate hiberfil.sys! The reason for that is of-course that Windows doesn't save VRAM or any other device-memory (unless the device keeps its memory in RAM).– harrymcCommented Aug 19, 2013 at 5:33
-
→ harrymc: no needs to shout ☺. This question wasn't flagged as Windows. Perhaps some readers might be waiting an analysis of the behaviour of some different OSes.– danCommented Aug 19, 2013 at 5:56
-
@danielAzuelos: Not shouting, just flagging an error for future readers. Anyone who ever used a 32-bit operating system of any kind should know that a part of the RAM is used as device-memory for drivers, and that the largest part is usually taken for the video-card, which is the reason that a 4 GB computer cannot use the entire 4 GB. The drivers of course don't expect Windows to keep their on-board memory, nor would Microsoft ever agree to support third-party drivers, video or otherwise. I don't think this is (or can be) different for Linux/Mac with thousands of devices to support.– harrymcCommented Aug 19, 2013 at 6:21
When the computer's execution is interrupted for sleeping, all CPU registers for the current executing thread(s) are saved in system RAM, as is the normal procedure with interrupts. So these are saved with the RAM and can be seamlessly restarted on wake.
Video RAM or VRAM is not saved and will have to be re-generated by the OS when it wakes to refresh the display, which it does automatically. So a black screen might result for an extremely short (usually unnoticeable) time.
If a used extension card is withdrawn during the sleep, the process that is using it will fail after wake, as will any CD-reading software if the CD is withdrawn, or any process using an outstanding Internet connection. What happens then depends on how that process was programmed.
-
1
-
-
@danielAzuelos: Video RAM is located on the graphics card and its contents are generated either by the card itself or by the CPU. It once resided in RAM and was used to store the frame-buffer in graphics adapters, but is now used less because video cards have become more powerful than the CPU. Windows only saves RAM and not device-memory.– harrymcCommented Aug 17, 2013 at 7:51
-
→ harrymc: how is the VRAM content regenerated? If it isn't saved within the process context, how is the graphical context rebuilt? This graphical context, at the time slice of an interrupt, might be the result of millions of elementary operations on the GPU. If this VRAM isn't saved, how this huge set of operations is replayed?– danCommented Aug 18, 2013 at 21:07
-
@danielAzuelos: The graphical device contexts are invalidated and refreshed, even if this takes several minutes.– harrymcCommented Aug 19, 2013 at 5:36
They are according to wikipedia: S4: Hibernation or Suspend to Disk. All content of main memory is saved to non-volatile memory such as a hard drive, and is powered down. Also according to here.
Specifically it is said:
S3 - "Suspend to RAM"
All power to the cpu is shut off, and the contents of its registers are flushed to RAM, which remains on. In Microsoft Windows, the "Standby" command can be associated with this state if enabled in the BIOS. Because it requires a high degree of coordination between the cpu, chipset, devices, OS, BIOS, and OS device drivers, this system state is the most prone to errors and instability. Pavel Machek has created a small document with some hints how to solve problems with S3. You can find it in the kernel sources at Documentation/power/tricks.txt. S3 is currently not supported by the 2.4.x kernel series in Linux. S4 - "Suspend to Disk"
CPU power shut off as in S3, but RAM is written to disk and shut off as well. In Microsoft Windows, the "Hibernate" command is associated with this state. A variation called S4BIOS is most prevalent, where the system image is stored and loaded by the BIOS instead of the OS. Because the contents of RAM are written out to disk, system context is maintained. For example, unsaved files would not be lost following an S4 transition. S4 is currently not supported by the 2.4.x kernel series in Linux, but you might have good luck with SWSUSP. Some machines offer S4_BIOS whose support is considered to be experimental within Linux/ACPI.
-
The original question was about a key storage point in modern computers: the VRAM and all other forms of volatile memory embedded in extension cards. How are they saved? Some VRAM may reach 1Gbyte.– danCommented Aug 17, 2013 at 13:52