Techniques for headless server manageability and autonomous logging

Abstract

Techniques for headless server manageability and autonomous logging are described. An embodiment of the claimed invention includes a computing device having a host processor and a manageability controller, the host processor being used to execute a firmware environment. The firmware environment retains a frame buffer in main memory and loads a graphics protocol driver to provide the frame buffer to an operating system of the computing device. The operating system renders a graphics image to the frame buffer using the graphics driver. The manageability controller reads the graphics image from the frame buffer and can transmit the graphics image to a remote computing device. In response to a fatal error of the computing device, the manageability controller can store the graphics image in a non-volatile storage device. The host processor can assert a host reset signal in response to the fatal error, and the manageability controller can send an acknowledgment to the host processor after storing the graphics image. Other embodiments are described and claimed.

Description

Background Art

[0001] Server computing devices in large data centers typically run in a headless configuration without easy access to a local console or other human interface devices (e.g., keyboard, mouse, and display). In fact, some headless devices may not include a graphics controller or other video output hardware. For platform manageability, many server computing devices and / or server boards include out-of-band (OOB) manageability features. For example, a server board may include a board management controller (BMC) that provides keyboard, mouse, and video redirection (KVMr) services for the server device. A typical BMC may provide KVMr services by including dedicated video graphics adapter (VGA) hardware in the BMC. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] In the accompanying drawings, the concepts described herein are illustrated by way of example and not by way of limitation. For simplicity and clarity of illustration, the elements shown in the accompanying drawings are not necessarily drawn to scale. Where deemed appropriate, reference numerals have been repeated between the drawings to indicate corresponding or similar elements.

[0003] Figure 1 is a simplified block diagram of at least one embodiment of a computing device for headless server manageability and autonomic logging;

[0004] Figure 2 It can be Figure 1 A simplified block diagram of at least one embodiment of an environment established by a computing device;

[0005] Figure 3 is used for Figure 1-2 A simplified flowchart of at least one embodiment of a method performed by a manageable server and executed by a computing device of

[0006] Figure 4 is used for Figure 1-2 A simplified flow chart of at least one embodiment of a method of server manageability and autonomous logging performed by a computing device. DETAILED DESCRIPTION

[0007] Although the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments of the present disclosure have been shown in the drawings as examples and will be described in detail herein. However, it should be understood that there is no intention to limit the concepts of the present disclosure to the specific forms disclosed, but on the contrary, it is intended to cover all modifications, equivalents and alternatives consistent with the present disclosure and the appended claims.

[0008] References in the specification to "one embodiment," "an embodiment," "an exemplary embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may or may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described. Additionally, it should be appreciated that an item included in a list in the form of "at least one of A, B, and C" may mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C). Similarly, an item listed in the form of "at least one of A, B, or C" may mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).

[0009] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transient or non-transient machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure (e.g., volatile or non-volatile memory, media disk, or other media device) for storing or transmitting information in a form that can be read by a machine.

[0010] In the accompanying drawings, certain structural or method features may be shown in a specific arrangement and / or order. However, it should be understood that such specific arrangement and / or order may not be necessary. On the contrary, in some embodiments, such features may be arranged in a different manner and / or order than shown in the exemplary drawings. In addition, the inclusion of structural or method features in a particular drawing does not imply that such features are required in all embodiments, and in some embodiments, such features may not be included, or may be combined with other features.

[0011] View now Figure 1, in an exemplary embodiment, a computing device 100 for headless server manageability and autonomous logging is shown. As shown, the computing device 100 includes a host processor 120 and a manageability controller 130. In use, as described in more detail below, the computing device 100 retains a frame buffer in main memory for use by a graphics driver. Primary graphics (e.g., operating system graphics, console messages, or other primary output) are rendered to the frame buffer using the graphics driver. The manageability controller 130 can access the graphics data in the frame buffer to provide keyboard, video, and mouse redirection (KVMr) services to one or more remote computing devices. In response to a crash or other fatal error, the manageability controller 130 can log the graphics data in non-volatile storage for subsequent review by an administrator. Therefore, the computing device 100 can provide KVMr manageability without the need for dedicated VGA hardware, which can reduce the cost and / or complexity of server board components. In addition, the computing device 100 can improve crash recovery or otherwise improve error troubleshooting by automatically retaining the content of any error message or other information displayed by the computing device 100 before the computing device 100 is reset. Crash information can be logged automatically without the need for an active KVMr session to the remote console device.

[0012] Computing device 100 may be embodied as any type of computing or computer device capable of performing the functions described herein, including but not limited to: a mobile computer, a multiprocessor system, a server, a rack-mount server, a blade server, a laptop computer, a notebook computer, a tablet computer, a wearable computing device, a network appliance, a web appliance, an embedded system, a distributed computing system, a processor-based system, and / or a consumer electronic device. Figure 1 As shown in , computing device 100 illustratively includes processor 120, input / output subsystem 122, memory 124, data storage device 126, and communication subsystem 128. Of course, in other embodiments, computing device 100 may include other or additional components, such as those typically found in a server (e.g., various input / output devices). In addition, in some embodiments, one or more of the exemplary components may be incorporated into another component, or otherwise form part of another component. For example, in some embodiments, memory 124 or portions thereof may be incorporated into processor 120.

[0013] The processor 120 may be embodied as any type of processor capable of performing the functions described herein. For example, the processor 120 may be embodied as (single-core or multi-core processors, digital signal processors, microcontrollers, or other processors or processing / control circuits. Similarly, the memory 124 may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory 124 may store various data and software used during the operation of the computing device 100, such as operating systems, applications, programs, libraries, and drivers. The memory 124 may be communicatively coupled to the processor 120 via an I / O subsystem 122, which may be embodied as circuit systems and / or components for facilitating input / output operations with the processor 212, the memory 124, and other components of the computing device 100. For example, I / O subsystem 122 may be embodied as or otherwise include a memory controller hub, an input / output control hub, a firmware device, communication links (i.e., point-to-point links, bus links, wires, cables, optical guides, printed circuit board traces, etc.), and / or other components and subsystems for facilitating input / output operations. In some embodiments, I / O subsystem 122 may form part of a system on a chip (SoC) and may be combined on a single integrated circuit chip with processor 120, memory 124, and other components of computing device 100.

[0014] The data storage device 126 may be embodied as any type of device configured for short-term or long-term storage of data, such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. As further described below, the data storage device 126 may include partitions or other areas accessible by the manageability controller 130, and / or the manageability controller 130 may access a dedicated non-volatile storage device.

[0015] The communication subsystem 128 of the computing device 100 may be embodied as any communication circuit, device, or collection thereof that enables communication between the computing device 100 and other remote devices over a network. The communication subsystem 128 may be configured to use any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., Ethernet, WiMAX, etc.) to achieve such communications.

[0016] As shown, the computing device 100 may also include a manageability controller 130 and one or more peripheral devices 132. The manageability controller 130 may be embodied as any hardware component(s) or circuit system capable of providing manageability and security-related services to the computing device 100. In particular, the manageability controller 130 may include a microprocessor, microcontroller, or other embedded controller capable of independently and securely executing firmware and / or other code distinct from the processor 120. For example, the manageability controller 130 may be embodied as a manageability engine (ME), a converged security and manageability engine (CSME), Innovation Engine (IE), Board Management Controller (BMC), Embedded Controller (EC), or other independent controller. Therefore, the manageability controller 130 can be used to establish a trusted execution environment for the computing device 100. The manageability controller 130 can communicate with the processor 120 and / or other components of the computing device 100 through a dedicated bus (such as a host embedded controller interface (HECI)). In addition, in some embodiments, the manageability controller 130 is also able to communicate using the communication subsystem 128 or a dedicated communication circuit independently of the state of the computing device 100 (for example, independent of the state of the main processor 120), which is also referred to as "out-of-band" communication. Exemplarily, the manageability controller 130 is embodied as an IE incorporated in the I / O subsystem 122; however, in some embodiments, the manageability controller 130 may be included in the system on chip (SoC) of the computing device 100 or in different components of the computing device 100, or may be embodied as a separate component.

[0017] Peripherals 132 may include any number of additional input / output devices, interface devices, and / or other peripherals. For example, in some embodiments, peripherals 132 may include a display, a touch screen, graphics circuitry, a keyboard, a mouse, a speaker system, a microphone, a network interface, and / or other input / output devices, interface devices, and / or peripherals. Of course, in some embodiments, computing device 100 may be headless, without a physical display or human input device, and in some embodiments without a graphics controller circuitry.

[0018] View now Figure 2In an exemplary embodiment, computing device 100 establishes environment 200 during operation. Exemplary environment 200 includes platform firmware 202, operating system 208, runtime manager 212, platform reset manager 214, graphics manager 216, and recovery manager 222. As shown, platform firmware 202 further includes frame buffer manager 204 and graphics protocol driver 206. The components of environment 200 may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of environment 200 may be embodied as circuitry or a collection of electronic devices (e.g., frame buffer manager circuitry 204, runtime manager circuitry 212, platform reset manager circuitry 214, graphics manager circuitry 216, and / or recovery manager circuitry 222). It should be appreciated that in such embodiments, one or more of frame buffer manager circuitry 204, runtime manager circuitry 212, platform reset manager circuitry 214, graphics manager circuitry 216, and / or resume manager circuitry 222 may form part of one or more of processor 120, I / O subsystem 122, manageability controller 130, or other components of computing device 100. Additionally, in some embodiments, one or more of the exemplary components may form part of another component, and / or one or more of the exemplary components may be independent of one another.

[0019] The platform firmware 202 may be embodied as UEFI BIOS firmware, ACPI BIOS firmware, or other firmware environment executed by the host processor 120 of the computing device 100. The platform firmware 202 may establish a pre-boot firmware execution environment in response to a platform reset (e.g., a cold boot, a warm boot, or other platform reset) of the computing device 100. As shown, the platform firmware 202 includes a frame buffer manager 204 and a graphics protocol driver 206.

[0020] The frame buffer manager 204 is configured to allocate a frame buffer in the main memory 124 of the computing device 100. The frame buffer manager 204 is further configured to load a graphics protocol driver 206 to provide a frame buffer to the operating system 208. The graphics protocol driver 206 may be embodied as any firmware driver, firmware application, or other component that provides an interface for supporting rendering of graphics to a software frame buffer. For example, the graphics protocol driver 206 may implement a UEFI graphics output protocol (GOP) or other firmware graphics driver interface for providing a frame buffer to the operating system 208.

[0021] The operating system 208 may be embodied as any operating system, hypervisor, virtual machine monitor, and / or other component of the computing device 100 that controls the computing device 100 at runtime. At runtime, the operating system 208 may manage the execution of one or more applications, system frameworks, drivers, virtual machines, or other workloads executed by the computing device 100. As shown, the operating system 208 includes a graphics driver 210. The graphics driver 210 is configured to output graphics data (e.g., text, graphics, or other graphical user interface data) to a frame buffer. Although illustrated as a component of the operating system 208, it should be understood that in some embodiments, the graphics driver 210 may be part of the platform firmware 202.

[0022] The runtime manager 212 is configured to load the operating system 208 in response to allocating the frame buffer and loading the graphics protocol driver 206. The runtime manager 212 is further configured to render a graphics image to the frame buffer by the operating system 208 using the graphics driver 210. The graphics image may include a graphical user interface, a text interface, or other primary graphics output of the operating system 208.

[0023] As shown, the graphics manager 216 and the recovery manager 222 are established or otherwise executed by the manageability controller 130. The graphics manager 216 is configured to read a graphics image from a frame buffer by the manageability controller 130. The manageability controller 130 may perform a direct memory access (DMA) operation on the memory 124 to read the graphics image. In some embodiments, the graphics manager 216 may be further configured to transmit the graphics image to a remote computing device via a network connection by the manageability controller 130. In some embodiments, the graphics manager 216 may be further configured to determine by the manageability controller 130 whether a fatal error of the computing device 100 has occurred. The graphics manager 216 may be further configured to read the frame buffer if a fatal error has occurred and store the graphics image from the frame buffer in a non-volatile storage device coupled to the manageability controller 130. The graphics manager 216 may be further configured to store additional crash information in the non-volatile storage device by the manageability controller 130 if a fatal error has occurred. In some embodiments, those functions may be performed by one or more subcomponents, such as remote console manager 218 and / or crash log manager 220 .

[0024] The platform reset manager 214 is configured to assert a host reset signal from the host processor 120 to the manageability controller 130 in response to a fatal error of the computing device 100. The platform reset manager 214 is further configured to determine, by the host processor 120, whether an acknowledgement of the host reset signal has been received from the manageability controller 130. The platform reset manager 214 is further configured to reset the computing device 100 by the host processor 120 in response to receiving an acknowledgement of the host reset signal from the manageability controller 130.

[0025] The recovery manager 222 is configured to determine, by the manageability controller 130, whether the host reset signal has been asserted by the host processor 120. The recovery manager 222 is further configured to send an acknowledgement of the host reset signal to the host processor 120 in response to storing the graphics image from the frame buffer in the non-volatile memory by the manageability controller 130. The acknowledgement of the host reset signal may also be sent if no fatal error has occurred.

[0026] View now Figure 3 In use, the computing device 100 may execute the method 300 for the manageable server to perform. In particular, the method 300 may be executed by the processor 120 of the computing device 100. It should be understood that in some embodiments, the operations of the method 300 may be performed by, for example, Figure 2 The method 300 begins at block 302, where the computing device 100 boots into the platform firmware 202. The computing device 100 may boot into the platform firmware 202 in response to a platform reset (e.g., when initially starting the computing device 100) or in response to a reboot. During booting, the platform firmware 202 may initialize the hardware of the computing device 100. The platform firmware 202 may also load one or more firmware drivers and / or firmware applications, and otherwise initialize the firmware execution environment.

[0027] In block 304, the platform firmware 202 loads the graphics output protocol (GOP) driver 206. The graphics protocol driver 206 may be embodied as any firmware driver or other component that implements the graphics output protocol (GOP) software interface defined by one or more UEFI specifications. In block 306, the GOP driver 206 allocates a frame buffer in the main memory 124 of the computing device 100. The frame buffer may be embodied as a continuous area of ​​the memory 124. In some embodiments, the platform firmware 202 may reserve the frame buffer for use by the platform firmware 202, preventing the operating system 208 from accessing the frame buffer. For example, the frame buffer may be excluded from the system memory mapping provided by the platform firmware 202 to the operating system 208. The graphics protocol driver 206 uses a firmware interface (such as a UEFI GOP interface) to provide the frame buffer in the memory 124 to the operating system 208. As further described below, the operating system 208 may use the frame buffer as a software frame buffer (e.g., as a software BLT buffer for storing graphics pixel data). The platform firmware 202 may use the graphics protocol driver 206 as a default graphics output. Additionally or alternatively, although illustrated as a UEFI GOP driver, it should be understood that in other embodiments, the graphics protocol driver 206 may implement a different graphics driver interface and / or may be part of a different pre-boot environment.

[0028] In block 308, the graphics protocol driver 206 sends the address of the frame buffer to the manageability controller 130. The graphics protocol driver 206 and / or other components of the platform firmware 202 may use any technique to send the address to the manageability controller 130. For example, the platform firmware 202 may send the address using a dedicated bus, such as a host embedded controller interface (HECI) bus. As another example, the platform firmware 202 may send the address using a network connection.

[0029] In block 310, the platform firmware 202 loads the operating system 208. The platform firmware 202 may stop executing the pre-boot firmware environment, for example, by calling an ExitBootServices() function, and then load the operating system 208. The platform firmware 202 may execute a boot loader or other boot target to load the operating system 208. The graphics protocol driver 206 may be unloaded when boot services exit and the operating system 208 is loaded.

[0030] After the operating system 208 is loaded, in block 312, the computing device 100 uses the graphics driver 210 to render primary graphics to a frame buffer in the memory 124. Any graphics generated by the operating system 208, applications, system frameworks, virtual machines, or other workloads executed by the computing device 100 may be directed to the graphics driver 210, which renders the graphics to the frame buffer in the memory 124. Thus, the computing device 100 may generate graphics at runtime without using a dedicated graphics controller or other video hardware. The method 30 returns to block 312 to continue rendering graphics to the frame buffer during normal operation of the computing device 100.

[0031] As shown, in the event of an operating system crash or other fatal error, method 300 may branch from box 312 to box 314. Computing device 100 may use any technique to detect a crash or fatal error. For example, in some embodiments, operating system 208 may detect a system crash or fatal error. As another example, in some embodiments, hardware of processor 120 may detect an error condition. As a further example, a watchdog timer may be used to detect an error condition. In box 314, computing device 100 asserts a host reset signal to manageability controller 130. Computing device 100 may use any technique to assert a host reset signal, such as asserting a host reset signal to manageability controller 130 via an electrical connection and / or asserting a host reset signal with an equivalent connection such as a HECI bus or a network connection.

[0032] In block 316, computing device 100 monitors for an acknowledgement sent from manageability controller 130. Figure 4 As described, in response to the host reset signal, the manageability controller 130 may store crash information in non-volatile storage or perform other crash recovery operations, and then send a confirmation when the crash recovery operation is completed. Therefore, the manageability controller 130 may delay the platform reset until the error message or other crash-related information is stored in non-volatile storage for later viewing. In box 318, the computing device 100 determines whether a confirmation has been received from the manageability controller 130. If not, the method 300 returns to box 316 to continue monitoring for confirmation. If a confirmation has been received, the method 300 proceeds to box 320, where the computing device 100 performs a platform reset. After performing the platform reset, the method 300 may restart and boot the platform firmware 202 in box 302.

[0033] View now Figure 4In use, the computing device 100 may perform the method 400 for server manageability and autonomous logging. In particular, the method 400 may be performed by the manageability controller 130 of the computing device 100. It should be understood that in some embodiments, the operations of the method 400 may be performed by, for example, Figure 2 100. The method 400 begins at block 402, where the manageability controller 130 determines whether to perform keyboard, video, and mouse redirection (KVMr). The manageability controller 130 may perform KVMr, for example, when the manageability controller 130 is configured to provide remote console access to one or more remote computing devices for system management or other manageability purposes. If the manageability controller 130 determines not to perform KVMr, the method 400 branches forward to block 412 as described below. If the manageability controller 130 determines to perform KVMr, the method 400 proceeds to block 404.

[0034] In block 404, the manageability controller 130 reads the contents of the frame buffer from the memory 124 that are reserved by the graphics protocol driver 206. As described above in connection with block 306, the frame buffer may be embodied as an area in the memory 124 that has been reserved for use as a frame buffer and that is otherwise inaccessible to the operating system 208. As described above in connection with block 312, at runtime, the primary graphics of the computing device 100 are rendered to the frame buffer using the graphics driver 210. Thus, the frame buffer includes pixel data corresponding to the current primary graphics output of the computing device 100. The manageability controller 130 may use any technique to read the frame buffer data. The frame buffer data may be copied to a dedicated memory of the manageability controller 130, such as an internal SRAM or an external low-power DRAM module. In some embodiments, in block 406, the manageability controller 130 may perform a direct memory access (DMA) operation to read the contents of the frame buffer. Thus, the manageability controller 130 may read the frame buffer without involving the processor 120.

[0035] In block 408, the manageability controller 130 transmits the image data read from the frame buffer to one or more remote console devices. The manageability controller 130 may transmit the image data using any remote access protocol (e.g., RFB, VNC, RDP, or other protocols). The image data may be transmitted using the out-of-band networking capabilities of the manageability controller 130, and thus may be transmitted without involving the processor 120. In some embodiments, in block 410, the manageability controller 130 may also transmit keyboard and / or mouse input to one or more remote console devices. Thus, the manageability controller 130 may provide remote control for the computing device 100 using KVMr.

[0036] In block 412, manageability controller 130 monitors the host reset signal received from processor 120. Figure 3 As described in block 314 of , the host reset signal may be asserted in response to a system crash or fatal error of the computing device 100. The host reset signal may also be asserted in response to a normal platform reset request (such as a user-initiated reboot). As described above, the host reset signal may be asserted using any appropriate technique, such as asserting through an electrical connection from the processor 120 to the manageability controller 130 and / or asserting through an equivalent connection such as a HECI bus or a network connection. In block 414, the manageability controller 130 determines whether a host reset signal has been received. If not, the method 400 loops back to block 402 to continue performing KVMr redirection (if configured). If a host reset signal has been received, the method 400 proceeds to block 416.

[0037] In block 416, the manageability controller 130 checks for a system crash or fatal error. The manageability controller 130 may use any suitable technique to check for a system crash or fatal error. For example, the manageability controller 130 may determine whether a monitoring timer has expired. In some embodiments, in block 418, the manageability controller 130 may check the IERR status of the processor 120. The IERR status may be set by the processor 120 in response to certain fatal errors (such as certain internal processor error conditions or certain external events). In order to check the IERR status of the processor 120, the manageability controller 130 may read one or more registers of the processor 120 through the PECI interface. In block 420, the manageability controller 130 determines whether a crash or fatal error has occurred. If not, the method 400 branches forward to block 430 as described below. If a crash or fatal error has occurred, the method 400 proceeds to block 422.

[0038] In block 422, the manageability controller 130 reads the contents of the frame buffer retained by the graphics protocol driver 206 from the memory 124. As described above, the frame buffer includes pixel data corresponding to the current primary graphics output of the computing device 100. Therefore, after a crash or fatal error, the frame buffer may include error messages or other information displayed with the primary graphics at the time of the crash. For example, the frame buffer may include the contents of a "blue screen," "kernel error," or other error message displayed by the operating system 208 at the time of the crash. This error information may be useful to a system administrator to determine the cause of the crash. The manageability controller 130 may use any technique to read the frame buffer data. In some embodiments, in block 424, the manageability controller 130 may perform a direct memory access (DMA) operation to read the contents of the frame buffer. Therefore, the manageability controller 130 may read the frame buffer without involving the processor 120, which may be unavailable or in an inconsistent state due to the crash.

[0039] In block 426, the manageability controller 130 stores the image data read from the frame buffer in a non-volatile storage device. For example, the manageability controller 130 may store the image data in a flash memory device (e.g., SPI flash, eMMC flash, NVMe flash, or other non-volatile memory device) accessible to the manageability controller 130. After being stored, the image data may be checked by an administrator or other user later (e.g., after a platform reset). In some embodiments, in block 428, the manageability controller 130 may also store additional crash information in the non-volatile storage. For example, the manageability controller 130 may store timestamp data or other crash dump data in the non-volatile storage. Additionally or alternatively, although illustrated as storing image data only in response to a system crash or fatal error, in some embodiments, the manageability controller 130 may store image data before each platform reset. Therefore, in those embodiments, image data may be stored even for crash events (e.g., certain software crashes) that the manageability controller 130 cannot detect.

[0040] In block 430, manageability controller 130 signals confirmation of the host reset to host processor 120. Manageability controller 130 may send the confirmation using any technique, such as sending the confirmation over an electrical connection or an equivalent such as a HECI bus or a network connection. After sending the confirmation, computing device 100 performs a platform reset in block 432. After performing the platform reset, method 400 may be restarted.

[0041] Despite Figure 3 and Figure 4100 is illustrated as performing both KVMr and autonomous crash logging functions, it should be understood that in some embodiments, computing device 100 may perform those functions separately. For example, in some embodiments, computing device 100 may perform KVMr without autonomous crash logging, and / or computing device 100 may perform autonomous crash logging without KVMr.

[0042] It should be understood that in some embodiments, the methods 300 and / or 400 may be embodied as various instructions stored on a computer-readable medium, which may be executed by the processor 120, the manageability controller 130, and / or other components of the computing device 100 to cause the computing device 100 to perform the corresponding methods 300 and / or 400. The computer-readable medium may be embodied as any type of medium that can be read by the computing device 100, including but not limited to the memory 124 of the computing device 100, the data storage device 126, the firmware device, other memory or data storage device, the portable medium readable by the peripheral device 132 of the computing device 100, and / or other media.

[0043] Example

[0044] The following provides illustrative examples of the techniques disclosed herein. Embodiments of these techniques may include any one or more of the examples described below and any combination thereof.

[0045] Example 1 includes a computing device for system manageability, the computing device comprising: a host processor for executing a firmware environment, the firmware environment including a frame buffer manager for: (i) allocating a frame buffer in a main memory of the computing device, and (ii) loading a graphics protocol driver to provide the frame buffer to an operating system; a runtime manager for (i) loading an operating system in response to allocating the frame buffer and loading the graphics protocol driver, and (ii) rendering a graphics image to the frame buffer in response to providing the frame buffer to the operating system; and a manageability controller including a graphics manager for reading a graphics image from the frame buffer.

[0046] Example 2 includes the subject matter of Example 1, and wherein reading the graphics image from the frame buffer comprises performing a direct memory access operation by the manageability controller.

[0047] Example 3 includes the subject matter of any of Examples 1 and 2, and wherein the graphics manager is further for transmitting the graphics image to a remote computing device via a network connection.

[0048] Example 4 includes the subject matter of any of Examples 1-3, and wherein the graphics manager is further for: determining whether a fatal error of the computing device has occurred; and storing the graphics image from the frame buffer in a non-volatile storage device coupled to the manageability controller; wherein reading the graphics image from the frame buffer comprises reading the graphics image from the frame buffer in response to determining that a fatal error of the computing device has occurred.

[0049] Example 5 includes the subject matter of any of Examples 1-4, and wherein determining whether a fatal error has occurred comprises determining whether an internal processor error condition of the host processor is set.

[0050] Example 6 includes the subject matter of any of Examples 1-5, and wherein the graphics manager is further to store crash information in a non-volatile storage device in response to determining that a fatal error of the computing device has occurred.

[0051] Example 7 includes the subject matter of any of Examples 1-6, and wherein the crash information includes timestamp information.

[0052] Example 8 includes the subject matter of any of Examples 1-7, and further includes a platform reset manager to: assert a host reset signal from a host processor to a manageability controller in response to a fatal error; determine whether an acknowledgement of the host reset signal has been received from the manageability controller; and reset the computing device in response to determining that an acknowledgement of the host reset signal has been received from the manageability controller.

[0053] Example 9 includes the subject matter of any of Examples 1-8, and wherein the manageability controller further includes a recovery manager to: determine whether the host processor has asserted a host reset signal; and send an acknowledgment of the host reset signal to the host processor in response to storing the graphics image from the frame buffer to the non-volatile storage or in response to determining that a fatal error has not occurred; wherein determining whether a fatal error has occurred includes determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

[0054] Example 10 includes the subject matter of any of Examples 1-9, and wherein the manageability controller further comprises a controller to execute firmware independent of the host processor.

[0055] Example 11 includes the subject matter of any of Examples 1-10, and wherein the computing device includes an I / O subsystem, and the I / O subsystem includes a manageability controller.

[0056] Example 12 includes the subject matter of any of Examples 1-11, and wherein the computing device comprises an innovation engine, and the innovation engine comprises a manageability controller.

[0057] Example 13 includes a method for system manageability, the method comprising: allocating, by a computing device, a frame buffer in a main memory of the computing device, the computing device comprising a host processor for executing a firmware environment; loading, by the computing device, a graphics protocol driver to provide the frame buffer to an operating system of the computing device; loading, by the computing device, the operating system in response to allocating the frame buffer and loading the graphics protocol driver; rendering, by the computing device, a graphics image to the frame buffer in response to providing the frame buffer to the operating system; and reading, by a manageability controller of the computing device, the graphics image from the frame buffer.

[0058] Example 14 includes the subject matter of Example 13, and wherein reading the graphics image from the frame buffer comprises performing, by the manageability controller, a direct memory access operation.

[0059] Example 15 includes the subject matter of any of Examples 13 and 14, and further includes transmitting, by the manageability controller, the graphical image to the remote computing device via the network connection.

[0060] Example 16 includes the subject matter of any of Examples 13-15, and further includes: determining, by a manageability controller, whether a fatal error of a computing device has occurred; and storing, by the manageability controller, a graphics image from a frame buffer to a non-volatile storage device coupled to the manageability controller; wherein reading the graphics image from the frame buffer includes reading the graphics image from the frame buffer in response to determining that a fatal error of the computing device has occurred.

[0061] Example 17 includes the subject matter of any of Examples 13-16, and wherein determining whether a fatal error has occurred comprises determining whether an internal processor error condition of the host processor has been asserted.

[0062] Example 18 includes the subject matter of any of Examples 13-17, and further comprises storing, by the manageability controller in a non-volatile storage device in response to determining that a fatal error of the computing device has occurred, crash information.

[0063] Example 19 includes the subject matter of any of Examples 13-18, and wherein the crash information includes timestamp information.

[0064] Example 20 includes the subject matter of any of Examples 13-19, and further includes: asserting a host reset signal from a host processor to a manageability controller in response to a fatal error; determining whether an acknowledgement of the host reset signal has been received from the manageability controller; and resetting the computing device in response to determining that an acknowledgement of the host reset signal has been received from the manageability controller.

[0065] Example 21 includes the subject matter of any of Examples 13-20, and further includes: determining, by a manageability controller, whether a host processor has asserted a host reset signal; and sending, by the manageability controller, an acknowledgment of the host reset signal to the host processor in response to storing a graphics image from a frame buffer to non-volatile storage or in response to determining that a fatal error has not occurred; wherein determining whether a fatal error has occurred includes determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

[0066] Example 22 includes the subject matter of any of Examples 13-21, and wherein the manageability controller further comprises a controller to execute firmware independent of the host processor.

[0067] Example 23 includes the subject matter of any of Examples 13-22, and wherein the computing device includes an I / O subsystem, and the I / O subsystem includes a manageability controller.

[0068] Example 24 includes the subject matter of any of Examples 13-23, and wherein the computing device comprises an innovation engine, and the innovation engine comprises a manageability controller.

[0069] Example 25 includes a computing device comprising: a processor; and a memory having a plurality of instructions stored therein, which when executed by the processor cause the computing device to perform the method of any of Examples 13-24.

[0070] Example 26 includes one or more non-transitory computer-readable storage media including a plurality of instructions stored thereon that, in response to being executed, cause a computing device to perform the method of any of Examples 13-24.

[0071] Example 27 includes a computing device including means for performing the method of any of Examples 13-24.

[0072] Example 28 includes a computing device for system manageability, the computing device comprising: means for allocating a frame buffer in a main memory of the computing device, the computing device comprising a host processor for executing a firmware environment; means for loading a graphics protocol driver to provide the frame buffer to an operating system of the computing device; means for loading the operating system in response to allocating the frame buffer and loading the graphics protocol driver; means for presenting a graphics image to the frame buffer in response to providing the frame buffer to the operating system; and means for reading the graphics image from the frame buffer by a manageability controller of the computing device.

[0073] Example 29 includes the subject matter of Example 28, and wherein means for reading the graphics image from the frame buffer comprises means for performing, by the manageability controller, a direct memory access operation.

[0074] Example 30 includes the subject matter of any of Examples 28 and 29, and further comprising means for transmitting, by the manageability controller, the graphical image to the remote computing device via the network connection.

[0075] Example 31 includes the subject matter of any of Examples 28-30, and further includes: means for determining, by a manageability controller, whether a fatal error of a computing device has occurred; and means for storing, by the manageability controller, a graphics image from a frame buffer to a non-volatile storage device coupled to the manageability controller; wherein the means for reading the graphics image from the frame buffer includes means for reading the graphics image from the frame buffer in response to determining that a fatal error of the computing device has occurred.

[0076] Example 32 includes the subject matter of any of Examples 28-31, and wherein means for determining whether a fatal error has occurred comprises means for determining whether an internal processor error condition of the host processor is set.

[0077] Example 33 includes the subject matter of any of Examples 28-32, and further comprising means for storing, by the manageability controller in response to determining that a fatal error of the computing device has occurred, crash information in a non-volatile storage device.

[0078] Example 34 includes the subject matter of any of Examples 28-33, and wherein the crash information includes timestamp information.

[0079] Example 35 includes the subject matter of any of Examples 28-34, and further includes: means for asserting a host reset signal from a host processor to a manageability controller in response to a fatal error; means for determining whether an acknowledgement of the host reset signal has been received from the manageability controller; and means for resetting the computing device in response to determining that an acknowledgement of the host reset signal has been received from the manageability controller.

[0080] Example 36 includes the subject matter of any of Examples 28-35, and further includes: means for determining, by a manageability controller, whether a host processor has asserted a host reset signal; and means for sending, by the manageability controller, an acknowledgment of the host reset signal to the host processor in response to storing a graphics image from a frame buffer to non-volatile storage or in response to determining that a fatal error has not occurred; wherein the means for determining whether a fatal error has occurred includes means for determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

[0081] Example 37 includes the subject matter of any of Examples 28-36, and wherein the manageability controller further comprises a controller for executing firmware independent of the host processor.

[0082] Example 38 includes the subject matter of any of Examples 28-37, and wherein the computing device includes an I / O subsystem, and the I / O subsystem includes a manageability controller.

[0083] Example 39 includes the subject matter of any of Examples 28-38, and wherein the computing device comprises an innovation engine, and the innovation engine comprises a manageability controller.

Claims

1. A computing device for system manageability, the computing device comprising: a host processor for executing a firmware environment including a frame buffer manager for: (i) allocating a frame buffer in a main memory of the computing device, and (ii) loading a graphics protocol driver to provide the frame buffer to an operating system; a runtime manager to (i) load the operating system in response to allocating the frame buffer and loading the graphics protocol driver, and (ii) render a graphics image to the frame buffer in response to providing the frame buffer to the operating system; as well as A manageability controller includes a graphics manager for (i) determining whether a fatal error of the computing device has occurred, and (ii) reading the graphics image from the frame buffer in response to determining that the fatal error of the computing device has occurred.

2. The computing device of claim 1, wherein: Reading the graphics image from the frame buffer includes performing a direct memory access operation by the manageability controller.

3. The computing device of claim 1, wherein: The graphics manager is further configured to transmit the graphics image to a remote computing device via a network connection.

4. The computing device of claim 1, wherein: The graphics manager is further configured to: The graphics image is stored from the frame buffer in a non-volatile storage device coupled to the manageability controller.

5. The computing device of claim 4, wherein: Determining whether the fatal error has occurred includes determining whether an internal processor error condition of the host processor is set.

6. The computing device of claim 4, wherein: The graphics manager is further for storing crash information in the non-volatile storage device in response to determining that the fatal error of the computing device has occurred.

7. The computing device of claim 6, wherein: The crash information includes timestamp information.

8. The computing device of claim 4, further comprising a platform reset manager, the platform reset manager configured to: asserting a host reset signal from the host processor to the manageability controller in response to the fatal error; determining whether an acknowledgement of the host reset signal has been received from the manageability controller; as well as The computing device is reset in response to determining that the acknowledgement of the host reset signal has been received from the manageability controller.

9. The computing device of claim 8, wherein: The manageability controller further includes a recovery manager, the recovery manager being configured to: determining whether the host processor has asserted the host reset signal; and sending an acknowledgement of the host reset signal to the host processor in response to storing the graphics image from the frame buffer into the non-volatile storage or in response to determining that a fatal error has not occurred; Wherein determining whether a fatal error has occurred comprises determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

10. The computing device of claim 1, wherein: The manageability controller further includes a controller for executing firmware independent of the host processor.

11. The computing device of claim 1, wherein: The computing device includes an I / O subsystem, and the I / O subsystem includes the manageability controller.

12. A method for system manageability, the method comprising: allocating, by a computing device, a frame buffer in a main memory of the computing device, the computing device comprising a host processor for executing a firmware environment; loading, by the computing device, a graphics protocol driver to provide the frame buffer to an operating system of the computing device; loading, by the computing device, the operating system in response to allocating the frame buffer and loading the graphics protocol driver; rendering, by the computing device, a graphics image to the frame buffer in response to providing the frame buffer to the operating system; determining, by a manageability controller of the computing device, whether a fatal error of the computing device has occurred; as well as The graphics image is read from the frame buffer by the manageability controller in response to determining that the fatal error of the computing device has occurred.

13. The method according to claim 12, characterized in that Reading the graphics image from the frame buffer includes performing a direct memory access operation by the manageability controller.

14. The method according to claim 12, characterized in that Further included transmitting, by the manageability controller, the graphical image to a remote computing device via a network connection.

15. The method of claim 12, further comprising: The graphics image is stored from the frame buffer by the manageability controller in a non-volatile storage device coupled to the manageability controller.

16. The method according to claim 15, characterized in that Further included storing, by the manageability controller in response to determining that the fatal error of the computing device has occurred, crash information in the non-volatile storage device.

17. The method of claim 15, further comprising: asserting a host reset signal from the host processor to the manageability controller in response to the fatal error; determining whether an acknowledgement of the host reset signal has been received from the manageability controller; as well as The computing device is reset in response to determining that the acknowledgement of the host reset signal has been received from the manageability controller.

18. The method of claim 17, further comprising: determining, by the manageability controller, whether the host processor has asserted the host reset signal; as well as sending, by the manageability controller, an acknowledgement of the host reset signal to the host processor in response to storing the graphics image from the frame buffer to the non-volatile storage or in response to determining that a fatal error has not occurred; Wherein determining whether a fatal error has occurred comprises determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

19. A computing device for system manageability, the computing device comprising: means for allocating a frame buffer in a main memory of the computing device, the computing device comprising a host processor for executing a firmware environment; means for loading a graphics protocol driver to provide the frame buffer to an operating system of the computing device; means for loading the operating system in response to allocating the frame buffer and loading the graphics protocol driver; means for rendering a graphics image to the frame buffer in response to providing the frame buffer to the operating system; means for determining, by a manageability controller of the computing device, whether a fatal error of the computing device has occurred; as well as Means for reading, by the manageability controller, the graphics image from the frame buffer in response to determining that the fatal error of the computing device has occurred.

20. The computing device of claim 19, wherein: Means for reading the graphics image from the frame buffer includes means for performing a direct memory access operation by the manageability controller.

21. The computing device of claim 19, wherein: Further included is means for transmitting, by the manageability controller, the graphical image to a remote computing device via a network connection.

22. The computing device of claim 19, further comprising: Means for storing, by the manageability controller, the graphics image from the frame buffer in a non-volatile storage device coupled to the manageability controller.

23. The computing device of claim 22, wherein: Further included is means for storing, by the manageability controller in response to determining that the fatal error of the computing device has occurred, crash information in the non-volatile storage device.

24. The computing device of claim 22, further comprising: means for asserting a host reset signal from the host processor to the manageability controller in response to the fatal error; means for determining whether an acknowledgement of the host reset signal has been received from the manageability controller; as well as Means for resetting the computing device in response to determining that the acknowledgement of the host reset signal has been received from the manageability controller.

25. The computing device of claim 24, further comprising: means for determining, by the manageability controller, whether the host processor has asserted the host reset signal; as well as means for sending, by the manageability controller, an acknowledgement of the host reset signal to the host processor in response to storing the graphics image from the frame buffer to the non-volatile storage or in response to determining that a fatal error has not occurred; Wherein the means for determining whether a fatal error has occurred comprises means for determining whether a fatal error has occurred in response to determining whether the host reset signal has been asserted.

Images