Talk:Advanced Configuration and Power Interface
From Wikipedia, the free encyclopedia
Contents |
[edit] Interface not Feature
"The other important feature of ACPI is in bringing power management features currently only available in portable computers to desktop computers and servers." This sentence is some kind of missleading. As the name says ACPI is an "interface" not a feature list. Of course ACPI defines system states and many things more but it is not mandatory that they exist. But if they have do be as defined in the specification.
--mac_c 10:30, 13 Aug 2004 (UTC)
[edit] Questions
The currently exiting APM model ...: sounds like APM is what is sold with today's computers, while ACPI is still under development. Is this correct ?? -- Frau Holle 20:54, 7 Sep 2004 (UTC)
ACPI still under development?: It depends on who you ask. Generally ACPI is a bunch of concepts and not a real piece of hardware. And the development of these concepts was finished some time ago. But the problem is that some hardware venodors still use old implementations of ACPI (i.e. ACPI v1.2 instead of ACPI 2.0). That makes it a little bit hard to write good driver modules for that particular hardware. Another problem is that until ACPI 2.0 the communication channels between ACPI an the OS were not specified exactly enough so the developers were allowed to use what they prefer. And that lead to several problems which are still present. --mac_c 13:05, 14 Oct 2004 (UTC)
assigns .. control to the BIOS: sounds as if a BIOS is a process running simultaneously with an OS kernel. In my understanding, a BIOS can provide routines that can be called by the OS, but it is not precise language saying that the BIOS is in control of anything. I would like to see an expert comment on this or improve the article. Thanks, Frau Holle 20:54, 7 Sep 2004 (UTC)
- The BIOS controls everything! —The preceding unsigned comment was added by Quantum Burrito (talk • contribs) 00:01, 15 January 2007 (UTC).
[edit] Merge
It has been suggested that the ACPI article be merged into this one. I agree. Discuss. - dcljr (talk) 01:24, 26 September 2005 (UTC)
- apparently this has happened. --MarSch 16:43, 7 May 2006 (UTC)
[edit] Linux still has incomplete support for ACPI.
Linux still has incomplete support for ACPI.
I disagree. Linux supports almost all ACPI hardware, and supports all sleep states. Hibernation is now fully supported. Does anyone disagree with removing this? 65.10.176.144 01:41, 29 May 2006 (UTC)
- I cannot find anything about it in the refs, so go ahead. --MarSch 11:03, 29 May 2006 (UTC)
- Linux fails to work properly with buggy BIOSes and DSDTs - yet windows still copes. Also, to the last of my recollection, speedstep isn't handled via ACPI but (still) directly frobbing the PSRs. --moof 12:02, 29 May 2006 (UTC)
- It is not fair to blame the "buggyness" of Linux or even windows on any unspecified piece of hardware. Essentially, it is up to the final OEM/ hardware manufacturer to "debug" ACPI and get it working with each OS they want to support. Many times there will need to be a work around which is then tested on a specific version of a specific OS. It is unlikely a desktop system will be tested with more than one OS in the contemporary market(whatever OS is pre-installed).
- Because Linux is not as commonly installed as Windows and because there are so very many Linux Distro's, it is almost never likely that ACPI support will be as robust for the Linux crowd as a general rule. This is not the fault or a deficiency in any Linux distribution, it is the legacy from trying to have infinite hardware configuration compatible with infinite software packages.--Riluve 20:14, 12 June 2006 (UTC)
- I got a computer to suspend-to-RAM (S3) with Ubuntu but it took a long time to resume from the S3 state (about as long as booting Windows on the same machine). Secondly, before it would go into S3, it would turn the hard drive off, back on, then off again (that would seem to add some extra wear to the drive). I want to buy a desktop but I can't even find a report of one that can suspend-to-RAM with Linux or BSD. The reports I have found have all been for laptops. Jobbon 00:03, 5 March 2007 (UTC)
[edit] ACPI States:
Do systems really distinguish between S4 and G2? To the best of my knowlege the system does not know or care of the difference. In the case of windows, AFAICT, S4 the boot process simply looks for the hibernation file, and if one is found, then the it is used to restore the system. So the hardware has no reason to distinguish.
AFAICT the difference between G2 and G3 in most system is that in G2 the PSU still provides power to certain components (system clock, network card, etc), while in G3 the PSU provides no power to the system, either due to power outage, or removed plug.
Is the above all correct, or am I missing something? Tacvek 20:57, 30 May 2006 (UTC)
- Not correct.
- G2=S5 - there is no preparation for recovery or any recovery after G2/S5. There is not a giant distinction from the hardware point of view, but their is one - the S4 sleep state register will not be set in G2/S5. Only if this register is set will anyone (the BIOS or the OS) try to do a recovery (including looking for a hibernation file). The BIOS specifically will behave very differently between G2/S5 and G1/S4. e.g. after a G2/S5 the BIOS will HAVE to perform a full POST. After a G1/S4, it may choose to do an abbreviated POST. After a G2/S5, the BIOS will boot with INT19 which may load GUB or LILO. After a G1/S4, a properly working BIOS will NOT do an INT19, it will NOT load the MBR, rather it will jump to a pre-specified location/entry point for the OS that performed the G1/S4 in the first place. Additionally, the discussion of G2/G3 is a little confused. G2/G3 are indistinguishable from the machine point of view. No additional system state or power is maintained in G2 vs G3. They are merely technically different in that with G3 the power is physically removed and the software controlled powerbutton has no chance then to re-apply power to the system. --Riluve 20:37, 12 June 2006 (UTC)
-
- Sounds like it would have made sense to put the "S4 sleep state register" on the system partition but they put it in the CMOS so the computer could come out of hybernation more quickly. That would mean it is safe to unplug the computer when it is hibernated, so long as the battery isn't removed (and has enough charge), in that it will still restore the hybernated state. You could hibernate the computer, unplug the computer to remove an expansion card, and the hybernated state would still be restored. Is that correct? Jobbon 04:45, 5 March 2007 (UTC)
[edit] Not working perfectly
ACPI does not work flawlessly as one might think. Windows XP for example has problems sometimes with coming back from one of the S states. This should be mentioned in my opinion. --Abdull 11:19, 5 June 2006 (UTC)
- ACPI requires a high level of co-operation between the device drivers, the hardware, and the OS itself. One of the biggest problems with device driver development for Windows over the past several years has been the issue of getting the sleep-state/power management code right. The Windows Driver Foundation is a programming model recently introduced by Microsoft to address a lot of these problems when developing drivers for Windows. Warrens 13:35, 5 June 2006 (UTC)
- The incomplete or "flawless" aspect of ACPI is really up to the final vendor/(OEM). If ACPI is not working properly complain to the people you bought it from. Unfortunately, these companies set aggressive schedules which don’t allow them to fix all the bugs in their hardware. They just do the best they can and then shove their machines onto the market because they know they can pass their issues off on other associated venders like Windows or the BIOS.
- And no, I am no Windows apologist, I do however work with hardware manufacturers and I watch them make these business decisions everyday.--Riluve 20:07, 12 June 2006 (UTC)
