Storing data related to system initialization in memory while determining and storing data if an exception has taken place during initialization

[0001] The present invention relates to the field of computer systems, and more particularly to system error analysis and system debugging.

[0002] When initializing or booting a computer platform, there are two primary stages of system evolution. First, in the pre-boot environment, the system performs tasks such as preparing the hardware, discovering and/or checking the memory, initializing the chipset, and so on. These tasks may be performed by BIOS or firmware in order to prepare the system to boot a target. Typically, the target to be booted is an operating system (O/S). After the target is booted, the system is in a run-time environment controlled by the O/S.

[0003] In the case of a catastrophic failure, there is relatively little visibility into the cause of an error within the pre-boot environment. Within the pre-boot environment itself, errors may be detected using a Power-On Self Test (POST) card, or other debug techniques. However, debug techniques such as POST do not typically provide a comprehensive log of pre-boot data; they simply provide information about the point at which a critical error has occurred.

[0004] There is also no mechanism by which the operating system may be notified of other non-critical issues that are encountered during pre-boot. The operating system and programs which are running on the O/S must rely upon the integrity of the underlying operating system and platform in order to function correctly. The existence of a non-critical error in the pre-boot environment may lead to a critical error or failure in the run-time environment. The O/S has no visibility of certain hardware issues that occurred during the pre-boot which the firmware would be aware of. Some examples of hardware problems that may occur in the pre-boot environment which the O/S may not be aware of, and that a user may not be able to find in a dump file, include the existence of a bad microprocessor (CPU), problems with chipset timing, or a bad disk.

[0010] Embodiments of a method for providing system state information for a computer system are disclosed. The computer system may be any system which includes at least a processor (CPU) and memory, including, but not limited to, a personal computer (PC), a mobile computer, a server, or a handheld device. These systems may include various types of software, firmware, and hardware.

[0011] Reference throughout this specification to “one embodiment” or “an embodiment” indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0012] FIG. 1 illustrates a computer system 102 in the pre-boot environment 100 according to an embodiment of the present invention. Computer system 102 may include a CPU 104, a chipset 106, non-volatile memory 108, such as a hard disk or flash memory, and system memory 110, such as SDRAM or another type of volatile memory. Computer system 102 may also include other components, including but not limited to items such as a network interface, a video interface, and other peripheral devices which are not illustrated.

[0013] When the system 102 is powered on, system initialization begins. During system initialization, in the pre-boot environment, system BIOS, firmware, drivers, or other system components may provide data related to the system initialization. This data may include, but is not limited to, state data 112, warning data 114, and error data 116. State data 112 may include information such as driver initialization status, driver version numbers, or other data related to the state of the system that a user may be interested in accessing. Warning data 114 may include information which indicates that something unexpected (but not fatal) has occurred, or may include non-critical information related to potential CPU, chipset, or memory issues. An example of potential warning data may be an indication that the temperature of the CPU is beyond a threshold value, or that there are timing issues with the chipset or memory. Error data 116 may include data related to critical errors which cause system initialization to fail.

[0014] State data 112, warning data 114, and error data 116 may be written to a centralized data hub 120 in the pre-boot environment. By using a data hub which has all state, warning, and error messages posted to it, one may initiate a dump of core data to the hard disk or other non-volatile memory. This may allow the core data to be accessed at some time after the system failure for analysis of the issue which may have caused the failure. In one embodiment, a user may choose what data is written to the data hub 120, and may choose, for example, to store only certain types of data, such as warning or error data, and may choose not to store state data.

[0015] In the pre-boot environment, the data hub 120 may reside initially in system memory 110. The contents of the data hub may be written 130 to non-volatile memory 108 upon the occurrence of a specific event, such as when an exception occurs, or upon transition to the O/S runtime environment. Updating the data hub contents in non-volatile memory 108 frequently may cause system performance during initialization to decrease. However, more frequent updates of the data hub contents in non-volatile memory, such as an update each time state data is generated by the system, may be useful if the system fails to boot the target. In this case, all data generated during system initialization up until the time of system failure would be stored in non-volatile memory and may be accessible for post-failure analysis.

[0016] The system may also include various components capable of executing instructions to accomplish an embodiment of the present invention. For example, the system may include and/or be coupled to at least one machine-accessible medium. As used in this specification, a “machine” includes, but is not limited to, any data processing device with one or more processors. A machine-accessible medium includes any mechanism that stores and/or transmits information in any form accessible by a data processing device, including but not limited to recordable/non-recordable media (such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, and flash memory devices), as well as electrical, optical, acoustical, or other form of propagated signals (such as carrier waves, infrared signals, and digital signals).

[0017] According to an embodiment, the system may include various other well known components. The processor and machine-accessible media may be communicatively coupled using a bridge/memory controller, and the processor may be capable of executing instructions stored in the machine accessible media. The bridge/memory controller may be coupled to a graphics controller, and the graphics controller may control the output of display data on a display device. Similarly, an audio adapter may be coupled to the bridge/memory controller to control the output of audio to a speaker. The bridge/memory controller may be coupled to one or more buses. A host bus controller, such as a Universal Serial Bus (USB) host controller may be coupled to the bus(es) and a plurality of devices may be coupled to the USB. For example, user input devices such as a keyboard and mouse may be included in the data processing device for providing input data. The data processing device may additionally include a network interface (e.g., a network interface card and/or a modem) capable of coupling the device to a network.

[0018] FIG. 2 illustrates conceptually the computer system 102 of FIG. 1 in the run-time environment 200 according to an embodiment of the present invention. In the run-time environment, an operating system (O/S) 202 or other target may be running on the system 102. Upon transition to the run-time environment, the data hub contents 120 (FIG. 1) from the pre-boot environment 100 (FIG. 1) may be exported to data hub record information 204 (FIG. 2), which may enable the O/S 202 to readily access the information in the run-time environment. In embodiments of the present invention, the data hub record information 204 may exist as either an ACPI SSDT record or to an EFI (Extensible Firmware Interface) configuration table in the run-time environment. EFI is a public industry specification that describes an abstract programmatic interface between platform firmware and shrink-wrap operating systems or other custom application environments. The EFI framework standard includes provisions for extending basic input output system (“BIOS”) code functionality beyond that provided by the BIOS code stored in a platform's boot firmware device.

[0019] The O/S may access the ACPI SSDT records or the EFI configuration table to determine what system state, warning, and/or error data may have been collected in the pre-boot environment. Furthermore, the O/S may utilize this data to analyze any errors or dumps which may occur in the run-time environment. This may effectively provide the O/S with visibility into certain issues that may have occurred in the pre-boot environment, and furthermore may facilitate the ability to use data from the pre-boot environment to debug issues which may occur in the run-time environment.

[0020] FIG. 3 illustrates an embodiment of the present invention wherein a client 204 external to system 102 may be able to access the contents of the data hub 120. This may aid in debugging a system or system components when the system either fails to boot the target, or where the system successfully boots the target but a component of the system fails or does not operate properly and no run-time data related to the component exists.

[0021] FIG. 4 illustrates an embodiment of the present invention wherein the system 102 may send the contents of the data hub 120 to an external remote system or service technician 206. This may aid in system debug in instances where the system must be serviced remotely. In one embodiment, a user may press a key on the keyboard or perform another action during system initialization to send the contents of the data hub 120 to a remote system 206.

[0022] FIG. 5 is a flowchart illustrating an embodiment of the present invention. Although the following operations may be described as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged without departing from the spirit of embodiments of the invention. In block 300, the system is powered on. This begins the system initialization process. Next, in block 302, the platform may be initialized and an exception handler may be installed. Next, in block 304, the data hub repository may be initialized. The data hub repository may be an entity in system memory, and may be used to store system data, including, but not limited to state data, warning data, and error data. In block 306, the entry point of the data hub repository is registered with the exception handler. Thus, if an exception is generated, the exception handler may know where to begin logging state/warning/error data in memory.

[0023] If an exception is generated, block 308, then all data hub records are read, and the contents of the data hub are written to a non-volatile target, as shown by block 310. In one embodiment, the non-volatile target may be a hard disk drive. In another embodiment, the non-volatile target may be flash memory. After the contents of the data hub are written to a non-volatile target, the system policy may be enacted, block 312. In one embodiment, the platform may send an alert broadcast over a network so that a remote server may retrieve the error log from the non-volatile target to see what happened. In another embodiment, firmware may launch an error viewer to view the contents of the data hub.

[0024] In one embodiment, the contents of the data hub may be written to a non-volatile target upon the occurrence of events other than exceptions. The contents of the data hub may be written to a non-volatile target each time state information is generated. While this implementation may decrease system performance, it may also ensure that all pre-boot data is logged to non-volatile memory and that none is lost due to system failure.

[0025] If no exception is generated, in block 314 the system may check to see if any state information has been exported by a driver or by firmware. If no state information has been exported, the system may continue to polling to determine if/when state information is exported. When state information is exported, data hub record data may be built, as illustrated in block 316. The state information is placed in the data hub repository. After each data hub record is created, at block 316, the system determines whether a transition to the runtime environment is occurring. If there is no transition to the runtime environment, the system continues polling to determine if any exceptions have occurred (block 308) or if any state information has been exported (block 314).

[0026] Upon transition to the runtime environment, the data hub record information is exported (block 320). The data hub record information may be exported to either an ACPI SSDT record or to an EFI configuration table. The O/S may access the ACPI SSDT records or the EFI configuration table to determine what system state, warning, and/or error data may have been collected in the pre-boot environment.

[0027] Thus, methods to provide system state information in a platform-agnostic manner have been disclosed. These methods may be implemented in software or firmware, among other implementations. In the above description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Embodiments have been described with reference to specific exemplary embodiments thereof. It will, however, be evident to persons having the benefit of this disclosure that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments described herein. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.