Date: Mon, 19 Jun 2000 21:18:09 -0600 From: Warner Losh <imp@village.org> To: acpi-jp@jp.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report Message-ID: <200006200318.VAA64942@harmony.village.org> In-Reply-To: Your message of "Mon, 19 Jun 2000 22:01:20 CDT." <Pine.NEB.3.96.1000619215655.23894A-100000@shell-1.enteract.com> References: <Pine.NEB.3.96.1000619215655.23894A-100000@shell-1.enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ cc trimmed ]] S4 state is the lowest power, longest wakeup latency state supported by acpi. In this state all devices are powered down. The OS context is preserved. That's how it is different from the G3 state (shutdown/power off). It is not safe to take the computer apart when in S4 state, but it is in G3 state. In addition, the machine may automatically be awoken from the S4 state, but not the G3 state. Personally, I don't see why we can't just save to the partition/reserved area on the disk that is used for the current BIOS save to disk functionality. The S5 state is like the G3 state, but it can be left via software, while the G3 state cannot. At least that's what my copy of the acpi spec tells me. That's why they are different. It is a subtle distinction, but one that is worth making, imho, if we are going to suppport ACPI to its fullest. I think that we'll need to support this eventually. Iwasaki-san's demo on the tokyo train was certainly interesting. I liked it very much. He was also talking about the problems of some BIOS' S2 and S3 sleep states needing a protected mode driver, or something of the sort to deal with properly... That's going to be interesting. I read that the S3 state is exited via the reset vector maybe in real-mode... The spec was a little unclear on this point, or maybe I've not read enough of it :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006200318.VAA64942>