Electrical computers and digital processing systems: support – Computer power control
Reexamination Certificate
2000-04-20
2004-11-30
Lee, Thomas (Department: 2116)
Electrical computers and digital processing systems: support
Computer power control
C713S320000
Reexamination Certificate
active
06826701
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to computer devices, and more particularly to power management in compute-related devices.
BACKGROUND OF THE INVENTION
ACPI (Advanced Configuration and Power Interface) is an open industry specification that defines a flexible and extensible interface for computer power management and related control operations. In general, the interface enables and supports power management through improved hardware and operating system coordination. ACPI allows the operating system to control the power states of many ACPI-compliant hardware components, and/or to pass information to and from some hardware components.
The ACPI Specification 1.0b describes how a system vendor can use General Purpose Events (GPE) to inform the operating system that a certain event has occurred. The specification distinguishes between run-time GPEs, which are related to events that occur while the computer is running, (e.g., state changes related to a thermal sensor or the power remaining in a battery), and wake GPEs, which are related to events that occur to possibly wake the computer system (or one or more devices therein) while the computer /device is in one of a plurality of sleep states. The specification allows the two types of events to be intermixed onto the same hardware signal.
ACPI enables individual devices of the computer system to go into a sleep state, thereby conserving power on the computer system. Device states may range from a D
0
(working state) to D
3
(fully off) state. The computer system as well may go into sleep-relative states, which may range from system state S
0
(working) to S
5
(fully off) with various possible states (e.g., S
1
, light sleep, S
3
deep sleep, S
4
hibernation) in between. Wakeup signaling events, such as the opening of a lid on a laptop computer, the pressing of a keyboard key, moving of a mouse, and so forth, are supposed to wake the devices and the system as necessary, such as to match a user's preferences. More particularly, wake event signals are issued by a corresponding hardware device to a Status register pin, (e.g., a low signal is output to a formerly high signal register location, or vice versa). If the software is enabled for such an event, i.e., in a counterpart Enable register, some action (e.g., a system control interrupt or SCI) will be taken to wake a sleeping computer and/or a device associated with that register location. For example, one type of wake event that may result in a specific device being woken up is to wake up a modem (move the modem from the D
3
to the D
0
state, as well as wake the computer if necessary) when a telephone ring is detected.
While the ACPI specification thus provides directions for properly waking computer systems and the devices therein, a significant problem is that many system vendors connect certain wake GPEs in a way that violates the specification, thereby potentially confounding the operating system. Normally, when the operating system takes a GPE event, it begins by masking off the GPE Enable register for that event, processing the event, clearing the GPE Status register for that event, and then re-enabling that event in the Enable register. However, if the hardware is implemented incorrectly, the operating system is not able to clear the GPE Status register when it normally should, i.e., when the operating system performs its interrupt handling processing (to run a GPE method) and then attempts to clear the GPE Status register, the underlying hardware event is not dismissed by the hardware as it should be. Then, when the event is re-enabled in the Enable register, the event fires again. In other words, if a hardware signal cannot be cleared in accordance with the ACPI specification, the operating system thinks that the signal is cleared, whereby the signal is re-enabled and the operating system receives another notification that the event has fired and repeats the process. If the signal is still not cleared, then the operating system, which handles interrupts at a higher priority than other processing, is essentially stuck in an infinite loop handling interrupts (a general purpose event (GPE) storm) that cannot be terminated until the signal is clear. As a result, when the operating system tries to wake up from the sleep state, it cannot, because the GPE events will not clear, causing an interrupt storm. This may also occur while the device is in a running state, and an event signal corresponding to waking a device, such as a network card, cannot be cleared. Unfortunately for the owners of such machines, a vast number of machines are “broken” in precisely this manner, whereby their sleep features cannot be properly used. Further complicating matters is that certain hardware devices use GPE pins that share wake-up and run-time events.
SUMMARY OF THE INVENTION
Briefly, the present invention provides a method and system that solves the problem of interrupt storms by selectively enabling wake GPEs (in the Enable register) only when the operating system wants the particular devices associated with the wake GPEs to be able to notify the operating system that a wake event has occurred. The operating system thus intelligently manages wake GPEs. The operating system also distinguishes between events that are exclusively wake, run-time, and shared wake and run-time events. As part of handling the GPEs, the operating system may run control methods, and selectively re-run a control method when necessary to do so, such as if the execution of the control method failed, for example, because of a low memory condition.
To this end, in one implementation described herein, the present invention utilizes several algorithms to manipulate and remember various sets of state regarding GPEs. In this implementation, the sets of states are maintained in operating-system-internal structures referred to herein as software registers (a block of storage allocated in the computer's main memory, having an arbitrary location, size and contents), including a GpeWakeHandler software register, which comprises a mask of bits representing GPEs used exclusively for wake-up events, a GpeSpecialHandler software register, which comprises a mask of bits representing GPEs which might be used for wake-up events but should be treated as regular GPEs, and a GpePending software register, which comprises a mask of bits which represent GPEs on which processing has started, but has not yet completed. A GpeRunMethod software register is also provided for tracking the running of the control method associated with each GPE, and a GpeComplete software register is provided to track completed events. In general, one difference between the GpeRunMethod software register and the GpePending software register is that GpeRunMethod software is only set until such a time as the ACPI driver is able to run the appropriate method. Once the ACPI driver is in a position to run the proper method, the GpeRunMethod software register is cleared. In comparison, the GpePending software register is set until the appropriate GPE method has successfully completed. The GpeRunMethod software register may be selectively reset to enable the same control method to be run again if needed, such as in the case of a failure.
The ACPI driver uses these masks in combination with a GpeEnable software register, GpeWakeEnable software register (which maintains a list of GPE pins which are enabled because of a wakeup event) and GpeCurEnable software register (which provides a mask of bits which are currently enabled) to intelligently manage the GPEs, and re-run control methods that fail to properly execute.
At boot time, the ACPI driver uses an algorithm to examine the system tables
amespace (built from firmware information) to determine which GPEs are associated with wake-up events, either exclusively or shared with run-time events, so that they can be managed differently from the other pins (which will be managed according to the ACPI specification). In particular, the ACPI driver looks for and specially handles the Lid, Po
Law Offices of Albert S. Michalik PLLC
Lee Thomas
Microsoft Corporation
Yanchus, III Paul
LandOfFree
Re-running general purpose event control methods in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Re-running general purpose event control methods in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Re-running general purpose event control methods in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3289820