Computer system, computer server and startup method thereof

Abstract

A computer system, a computer server, and a startup method thereof are used to adjust settings so that a reboot can proceed even when a hardware component fails. The system includes a management controller that stores a system error log. The computer system includes hardware components that communicate with the management controller. A basic input / output system (BIOS) includes a startup routine that successfully completes when all hardware components are operational. The startup routine determines, based on the system error log, that a hardware component has failed. The routine shuts down the hardware component. The routine then completes a power-on self-test routine.

Description

Technical Field

[0001] In general, the present disclosure relates to routines for improving the reliability of computer system operations. Specifically, various aspects of the present disclosure relate to a routine for shutting down faulty components during boot-up rather than shutting down the computer system for troubleshooting purposes. Background Art

[0002] Servers are used extensively in high-demand applications, such as network-based systems or data centers. The emergence of cloud computing applications has increased the demand for data centers. Data centers contain a large number of servers that store data and run applications, accessed by users on remote computer devices. A typical data center consists of physical racks with power and communication connections. Each rack can hold multiple computing and storage servers. Generally, each server includes hardware components such as a processor, memory devices, network interface cards, power supplies, and other specialized hardware. Each server typically includes a baseboard management controller (BMC) that manages the server's operations and communicates operational data to a central management station, which manages the servers in the rack. The BMC frees the server's central processing unit (CPU) from having to monitor server operations. Like all computer systems, servers have a basic input / output system (BIOS), typically a flash memory chip. The BIOS is executed before the server boots up to test the basic input and output of the server's components.

[0003] When errors occur in the memory, CPU, peripherals, or other components of a computer system, the system may crash. Following a crash, the error must be analyzed to determine the likely damaged or faulty component so that the damaged component can be replaced. This process is often time-consuming and tedious for computer system operators. For example, a computer system may unexpectedly crash due to a catastrophic error event in its CPU. If the faulty CPU remains in the computer system, the computer system will be unable to boot up on subsequent boot attempts. Consequently, the computer system cannot boot properly. Conventional techniques involve shutting down the computer system, performing debugging procedures, and then replacing the faulty CPU on-site at the data center. However, this procedure results in costly downtime, as the server is inoperable during this period.

[0004] Another approach to resolving certain catastrophic errors is to provide an update to the BIOS to facilitate debugging. In this example, a technician would shut down the computer system and use a supporting BMC to update a debug BIOS for debugging purposes. In this case, if the BMC does not support BIOS updates, the computer system will still be unable to boot into the operating system (OS). The only way to update the BIOS to enable debugging is to replace the active BIOS chip with a debug BIOS chip. This technique is not suitable for remote solutions, such as those required in data centers, because technicians must be on-site to replace the BIOS chip. Even if this solution is feasible, it is inconvenient and time-consuming.

[0005] Figure 1 A flowchart is provided showing a process that is initiated during a known shutdown of a computer system, allowing a technician to troubleshoot the computer system. This process is triggered when an error occurs in a hardware component (such as a CPU, memory, or peripheral device) (step 10). During the power-on self-test (POST) routine, the computer system detects the error and shuts down the computer system (step 12). The technician must then analyze the possible causes of the error (step 14). The technician then addresses the possible faulty component by repairing or replacing it (step 16). The aforementioned process is repeated to attempt to debug the system (step 18). When the possible faulty component is repaired, the troubleshooting process is complete (step 20). The system can then be successfully restarted (step 22). However, this process from the system shutdown stage 12 to the troubleshooting stage 20 is very time-consuming and can result in downtime for the server.

[0006] Therefore, there is a need for a BIOS for a computer system that automatically shuts down components that prevent the system from booting up, allowing the system to operate. There is also a need for a routine that can perform debugging without having to update the BIOS. Summary of the Invention

[0007] The word "embodiment" and similar words are intended to refer broadly to all subject matter of the present disclosure and claims. Statements containing such words should be understood as not limiting the subject matter described in this specification or limiting the meaning or scope of the claims. The embodiments covered by this disclosure are defined by the claims, not by this section. This section provides a general overview of the various aspects of the disclosure and introduces some concepts that will be further described in the "Implementation Methods" section. This section is not intended to identify key or essential features of the claimed subject matter; nor is it intended to be used alone to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the full text of this disclosure, any or all of the drawings, and each claim.

[0008] A disclosed example is a computer system that can avoid crashes caused by faulty components. The system includes a management controller that stores a system error log. The system includes a plurality of hardware components, each of which communicates with the management controller. The system includes a basic input / output system (BIOS), the BIOS including a startup routine configured to successfully complete when all of the hardware components are operational. The BIOS is operable to determine an error recorded in the system error log from one of the hardware components. The BIOS shuts down the hardware component corresponding to the recorded error. The BIOS adjusts the startup routine to avoid the shut-down hardware component. The BIOS then completes a power-on self-test routine.

[0009] A further implementation of the example computer system is an embodiment wherein the management controller is a baseboard management controller. Another implementation is wherein the computer system is a server. Another implementation is wherein the hardware components include at least one of the following: a processor, a memory device, a storage device, and an expansion card. Another implementation is wherein the BIOS includes a non-volatile random access memory (NVRAM) configured to store an instruction for shutting down the hardware component. Another implementation is wherein the management controller stores an image of the BIOS before the hardware component is shut down, the BIOS including the hardware components. Another implementation is wherein the management controller is configured to detect a case open event. The management controller is configured to load the stored BIOS image when the case open event is detected. Another implementation is wherein the stored BIOS image is used in the boot routine. Another implementation is wherein the management controller sends a signal to a general purpose input / output (GPIO) pin to enable the BIOS to shut down the hardware component.

[0010] Another example disclosed is a method for booting a computer system having multiple hardware components. A boot routine of a basic input / output system (BIOS) analyzes a system error log of a management controller to determine an error logged by one of the hardware components. The hardware component corresponding to the logged error is shut down. The boot routine is adjusted to bypass the shut down hardware component. A power-on self-test routine is performed.

[0011] Another embodiment of the exemplary method is wherein the management controller is a baseboard management controller and the computer system is a server. Another embodiment is wherein the hardware components include at least one of the following: a processor, a memory device, a storage device, and an expansion card. Another embodiment is wherein the BIOS includes a non-volatile random access memory (NVRAM) configured to store an instruction to shut down the hardware component. Another embodiment is wherein the method further includes storing an image of the BIOS before the hardware component is shut down, the BIOS including the hardware components. Another embodiment is wherein the method includes detecting a case opening event. When the case opening event is detected, the stored BIOS image is loaded. Another embodiment is wherein the stored BIOS image is used in the boot routine. Another embodiment is wherein the management controller sends a signal to a general purpose input / output (GPIO) pin to enable the BIOS to shut down the hardware component.

[0012] Another example disclosed is a computer server having a processor, a series of dual in-line memory modules, and an expansion card. A baseboard management controller is coupled to the processor, the dual in-line memory modules, and the expansion card. The baseboard management controller stores a system error log having an error recorded for at least one of the processor, the memory module, or the expansion card. A basic input / output system (BIOS) includes a boot routine that successfully completes when all of the hardware components are operational. The BIOS determines an error recorded in the system error log from one of the processor, the dual in-line memory module, and the expansion card. The BIOS shuts down the processor, dual in-line memory module, or expansion card corresponding to the recorded error. The BIOS adjusts the boot routine to avoid the shut-down processor, dual in-line memory module, or expansion card. The BIOS performs a power-on self-test routine.

[0013] The foregoing content in this section is not intended to represent every embodiment or aspect of the present disclosure. Rather, it merely provides examples of some of the novel aspects and features described in this specification. The aforementioned features and advantages, as well as other features and advantages of the present disclosure, will become apparent after reading the following detailed description of representative embodiments and modes for implementing the present disclosure in conjunction with the accompanying drawings and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The following exemplary embodiments are described with reference to the accompanying Figure 1 After reading together, you can reach a better understanding of the present disclosure. Among them:

[0015] Figure 1 is a flow chart showing a prior art routine for shutting down a computer system for troubleshooting purposes;

[0016] Figure 2 is a block diagram showing an example computer system having a routine that allows components to be shut down without shutting down the system;

[0017] Figure 3 A flow chart showing the maintenance of Figure 2 The general procedures for the operation of the example computer system shown;

[0018] Figure 4 A flowchart showing the startup routine used to shut down the system after a system crash Figure 2 Components of the computer system shown;

[0019] Figure 5 is a flow chart showing a procedure for shutting down components so that the POST routine can be successfully executed; and

[0020] Figure 6 A flow chart showing the process of restarting a computer system to allow shutdown or replacement of components to be performed.

[0021] The present disclosure is susceptible to numerous modifications and alternative forms. Some representative embodiments are shown as examples in the accompanying drawings and are described in detail throughout this specification. However, it should be noted that the present disclosure is not intended to be limited to the particular forms disclosed. On the contrary, the present disclosure is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure, as defined by the appended claims.

[0022]

Explanation of symbols

[0023] 10, 12, 14, 16, 18, 20, 22: Steps

[0024] 100: Computer Systems

[0025] 110, 112: Central Processing Unit (CPU)

[0026] 114: Dual In-line Memory Module (DIMM)

[0027] 116: Platform Path Controller (PCH)

[0028] 120:Serial Advanced Technology Attachment (SATA) device

[0029] 122: Open Computing Project (OCP) device

[0030] 124: Universal Serial Bus (USB) device

[0031] 126: Peripheral Component Interconnect Express (PCIe) device

[0032] 130: Baseboard Management Controller (BMC)

[0033] 132: BMC memory device

[0034] 134:BIOS memory device

[0035] 136: System Event Log (SEL)

[0036] 138:Sensor data recording

[0037] 140: BMC field replacement unit (FRU) information record

[0038] 150:BIOS image

[0039] 152: Start block

[0040] 154: Main Block

[0041] 156: Non-volatile random access memory (NVRAM) block

[0042] 158: Management Engine (ME) block

[0043] 160: Channel

[0044] 162: General-purpose input / output (GPIO) pins

[0045] 310, 312, 314, 316: Steps

[0046] 410, 412, 414, 416: Steps

[0047] 510-532: Steps

[0048] 610-646: Steps DETAILED DESCRIPTION

[0049] The present invention can be implemented in many different forms. Representative embodiments are shown in the accompanying drawings and will be described in detail in this specification. The present disclosure is an example or illustration of its principles and is not intended to limit the broad aspects of the present disclosure to the embodiments shown. In this regard, elements and limitations disclosed in sections such as "Abstract," "Summary," and "Implementation Methods" but not explicitly stated in the claims should not be incorporated into the claims, individually or collectively, by implication, inference, or otherwise. For the convenience of this section, unless otherwise stated, singular words include plural words and vice versa; the word "including" means "including but not limited to." In addition, words indicating approximation, such as "approximately," "nearly," "substantially," "close to," etc., may mean, for example, "at," "close to," or "approximately," or "within a 3-5% error range," or "within an allowable manufacturing error range," or any logical combination of the above ranges in this specification.

[0050] The present disclosure relates to a routine that allows a computer system to successfully boot up even if one or more hardware components are not functioning properly. During startup, the example routine prevents the computer system from crashing if it encounters an error in a memory device, PCIe device, or CPU. The routine shuts down the faulty hardware component via remote control of the computer system. This configuration enables the computer system (e.g., a remote server) to automatically and successfully boot up without requiring intervention from a data center operator.

[0051] Figure 2 1 is a block diagram showing components of a computer system 100 that runs a routine that allows the computer system 100 to boot up even if the computer system 100 has faulty hardware components. In this example, the computer system 100 is a server, but any suitable computer device may incorporate the principles disclosed herein. The computer system 100 has two central processing units (CPUs) 110 and 112. The two CPUs 110 and 112 can access a dual in-line memory module (DIMM) 114. Although only two CPUs are shown, the computer system 100 may also support additional CPUs. Specialized functions may be performed by dedicated processors, such as a graphics processing unit (GPU) or a field programmable gate array (FPGA), installed on the computer system 100 motherboard or on expansion cards.

[0052] Platform path controller (PCH) 116 facilitates communication between CPUs 110 and 112 and other hardware components, such as Serial Advanced Technology Attachment (SATA) devices 120, Open Compute Project (OCP) devices 122, and Universal Serial Bus (USB) devices 124. SATA devices 120 may include hard disk drives (HDDs). Alternatively, other memory storage devices may be used, such as solid-state drives (SSDs). Other hardware components, such as Peripheral Component Interconnect Express (PCIe) devices 126, can be directly accessed by CPUs 110 or 112 via expansion slots (not shown). Additional PCIe devices 126 may include network interface cards (NICs), disk array array (RAID) cards, field programmable gate array (FPGA) cards, and processor cards, such as graphics processing units (GPU) cards.

[0053] The hardware components of computer system 100 must be functioning properly when checked by the startup routine in the computer system 100's BIOS for the system to successfully boot. Therefore, the BIOS initializes and trains the memory devices and PCIe devices 126. The BIOS also allocates necessary resources for use by the PCIe devices 126. A crash may occur during the BIOS's initialization, training, or resource allocation operations for each of these hardware components. Alternatively, a fatal and uncorrectable error may directly cause a system crash. Additional hardware components may also be functioning properly, allowing the BIOS to successfully boot computer system 100.

[0054] Baseboard management controller (BMC) 130 manages computer system 100 operations, such as power management and thermal management. BMC 130 accesses a dedicated BMC memory device 132, which may be a flash memory device. A separate BIOS memory device 134 is non-volatile memory, such as flash memory BIOS firmware. Memory device 134 may be a BIOS chip. Both memory devices 132 and 134 are accessible via PCH 116.

[0055] In this example, BMC memory device 132 stores a system event log (SEL) 136, a sensor data log 138, and a BMC field replacement unit (FRU) information log 140. BIOS memory device 134 may include a BIOS image 150, a boot block 152, a main block 154, a non-volatile random access memory (NVRAM) block 156 for storing BIOS configuration data, and a management engine (ME) block 158. These blocks in BIOS memory device 134 facilitate the boot routine of computer system 100.

[0056] In this example, BMC 130 communicates with PCH 116 via various channels 160, which may include the System Management Bus (SMbus), the Low Pin Count Bus (LPC), PCIe, and USB lines. PCH 116 includes a series of general-purpose input / output (GPIO) pins 162 for communicating with BMC 130 and BIOS memory device 134. BMC 130 includes firmware that receives error messages from hardware components in computer system 100. These error messages are stored in system event log 136.

[0057] BIOS 134 includes a routine that determines a failed hardware component and shuts down the failed hardware component. This routine allows computer system 100 to operate until the failed hardware component is replaced or repaired. When a hardware component fails, BMC 130 retrieves information associated with the failed component stored in system event log (SEL) 136. On a subsequent boot, SEL 136 contains information about the failed hardware component, and BMC 130 transmits information about the failed component to BIOS 134, which shuts down the failed hardware component.

[0058] Figure 3 A flowchart showing the general process of Figure 2 The computer system 100 in the example embodiment remains operational even when a hardware component fails. An error occurs in one of the hardware components (step 310). The example routine then shuts down the failed hardware component (step 312). The computer system 100 can then be started up (step 314). The user is then notified of the hardware component failure, allowing the failed hardware component to be repaired or replaced at a future time, and the computer system 100 remains operational until the repair or replacement is performed (step 316).

[0059] Figure 4 4 is a flowchart illustrating an example routine that allows a computer system 100 to complete a power-on self-test (POST) routine even if a hardware component (e.g., a SATA device, a PCIe device, a DIMM, or a CPU) fails. First, the power is turned on (step 410). The failed component causes the computer system 100 to crash while executing the POST routine (step 412). The computer system 100 can then be restarted (step 410). When the system is restarted from the crash, the example routine shuts down the failed hardware component (step 414). Because the failed hardware component is shut down, the POST routine can successfully complete (step 416) without requiring a technician to physically replace the failed component.

[0060] The example routine allows the computer system 100 to recover by shutting down faulty hardware components, such as a damaged CPU, memory, or PCIe add-in card, allowing the computer system 100 to boot correctly. This allows the computer system 100 to subsequently boot successfully, eliminating the current need to physically remove or replace the faulty hardware component. The example routine has three parts: classifying the faulty hardware component, restoring the computer system by shutting down the faulty hardware component, and BMC 130 notifying BIOS 134 to prevent access to any faulty hardware component. BIOS 134 can then successfully boot the computer system 100 and complete the POST routine.

[0061] Detection of the faulty hardware component relies on the classification of the system event log 136 managed by the BMC 130. For example, processor corruption typically results in a processor internal error (IERR) or catastrophic error (CATERR) being logged, while memory corruption results in an uncorrectable error, training failure, or machine check architecture (MCA) error being logged.

[0062] Computer system 100 recovers during the subsequent boot-up routine by shutting down each faulty hardware component detected during startup. Different hardware components require different shutdown procedures, each with its own dedicated procedure. For example, if a CPU core fails, BIOS 134 transmits a hexadecimal word core disable bitmap to shut down the faulty core(s) in the CPU. This bitmap can be provided, with each bit representing a core in the CPU. For example, if a CPU has eight cores, the bitmap for the eight cores would indicate which of the cores is faulty. As described below, BMC 130 transmits an OEM (Original Equipment Manufacturer) IPMI (Intelligent Platform Management Interface) command to BIOS 134 to shut down the faulty core identified in the bitmap. Thus, in a system with multiple CPUs (each with multiple cores), a corresponding bitmap for each CPU can be provided, and the individual faulty cores can be identified. By providing slot and channel data, enabling a bit in a hexadecimal bitmask representing a faulty memory device, the memory device can be disabled. For example, a CPU may have multiple channels. Each channel allows the CPU to access multiple DIMMs. Individual DIMMs have a series of ranks. The bitmask can be configured to indicate the faulty memory device by channel and rank. As described below, BMC 130 sends an OEM IPMI command to BIOS 134 to disable the faulty memory device identified in the bitmask. Expansion cards (e.g., installed in expansion slots) can be disabled by disabling the PCIe root port.

[0063] The BMC 130 filters out the faulty hardware components based on the information in the SEL 136. The BMC 130 may send a signal via the GPIO pin 162 to notify the BIOS 134 to avoid using the faulty hardware component and shut down the faulty hardware component.

[0064] Figure 5 is a flow chart 500 showing an example startup routine that can be performed by Figure 2 The interaction between the BMC 130, PCH 116 and BIOS memory device 134 in the system can identify and avoid faulty hardware components. Figure 2 The computer system 100 in the example is powered on (step 510). The routine encounters a situation where the computer system 100 cannot boot properly, such as a hardware component failure or a catastrophic error during BIOS operation (step 512). The routine then checks whether the system event log 136 indicates an error from a failed hardware component (step 514). The routine determines whether the system event log 136 indicates at least one specific failed hardware component based on the logged errors (step 516). For example, the logged errors may include IERR / CATERR of the CPU, MCE errors or memory training failures of memory devices, or PCIe out-of-resource errors of PCIe devices.

[0065] If a defective component is found (step 516), the BMC 130 stores the current BIOS settings in the BMC self-storage that constitutes the BMC memory device (step 518). The BMC 130 then uses the OEM IPMI remote command to transmit data regarding the defective component to the BIOS 134 (step 520). The stored remote command includes data appropriate for the defective hardware component (e.g., a CPU, DIMM, or add-in card). The BMC 130 also sets the GPIO pin 162 to transmit an assert signal to the PCH 116 (step 522). The BIOS memory device 134 detects the GPIO assert signal from the PCH 116 (step 524). The BIOS memory device 134 then writes the data regarding the defective hardware component from the BMC 130 to the NVRAM block 156 of the BIOS memory device 134 (step 526). The routine then begins a power-up cycle, including a POST routine with an adjusted BIOS that disables the faulty hardware component based on data stored in NVRAM block 156. The routine then checks to see if the computer system 100 can properly boot after the power-up cycle (step 528). If the power-up routine is successful, the routine reaches the end of the POST routine (step 530). If the power-up does not proceed properly (step 528) or the BMC 130 cannot locate the specific faulty hardware component (step 516), the system will determine that the cause of the crash is another problem related to the firmware, the motherboard, or an unknown issue (step 532).

[0066] When a technician opens the computer system 100 and replaces a faulty hardware component, the BMC 130 can use the chassis open event in the SEL 136 to check the computer system 100. In this example, the computer system 100 switches from the adjusted BIOS settings that disable the faulty hardware component in the NVRAM 156 block to the previously stored BIOS settings, allowing the computer system 100 to restart normally.

[0067] The example system 100 also has a retry mechanism. Therefore, if the example routine shuts down some faulty hardware components, the retry mechanism will attempt to restart the computer several times. If the retries fail several times, the computer system 100 will determine that the cause of the crash is another problem related to the firmware, the motherboard, or an unknown issue.

[0068] Figure 6 6 is an example of a routine 600, which is another example routine that allows the computer system 100 to perform a boot process that is responsible for handling the case being opened (when a technician replaces a component) and a retry mechanism. Figure 2The computer system 100 in the example is first powered on (step 610). The routine encounters a situation where the computer system 100 cannot boot properly and crashes (step 612). When the crash occurs, a Fault Resilient Boot 2 (FRB-2) timeout occurs, and the current BIOS settings are stored in the BMC 130. In this example, the current BIOS settings are user-defined default BIOS settings. Generally, the adjusted options of the BIOS are stored in NVRAM. When the computer system 100 undergoes an alternating current (AC) or direct current (DC) power cycle, the options in the BIOS setup menu are still stored. When a debugging procedure, such as flashing a new BIOS chip, occurs, the BIOS settings roll back to the initial settings, and the user must provide the previously adjusted BIOS setup options. In this example, the adjusted BIOS setup options are stored as user-defined default BIOS settings.

[0069] Upon reboot (step 610), the routine analyzes the system event log 136 to determine any errors from a faulty hardware component (step 614). The routine determines whether the system event log 136 indicates at least one faulty hardware component (step 616). The BMC 130 then determines whether the computer system 100's chassis has been opened (step 618). An open chassis then indicates that a technician has replaced the faulty hardware component. If the chassis has been opened (step 618), the BMC 130 turns off the GPIO pin 162 (step 620). The BMC 130 sends a "load user default BIOS settings" command to the BIOS 134 (step 622). The BIOS memory device 134 performs a power cycle routine using the loaded user default BIOS settings from the BMC 130 (step 624). In this way, the user default BIOS settings are stored and loaded, eliminating the need for a user to set the BIOS in the previous system. Therefore, if a user changes a large number of BIOS settings, storing the user default BIOS settings can avoid lengthy procedures in the data center.

[0070] The routine then determines whether the computer system 100 can be booted (step 626). If the computer system 100 is successfully booted, the POST routine ends (step 628). The operating system can then be run (step 630). If the computer system 100 cannot be booted, the routine returns to the boot process (step 610).

[0071] If the chassis is not open, the BMC 130 sends an OEM IPMI remote command to transmit the data corresponding to the faulty hardware component (step 632). The BMC 130 stores the data of the faulty hardware component in the BMC memory device 134 (step 634). The BMC 130 also sets one of the GPIO outputs to transmit an active signal (step 636). When the GPIO active signal is received, the BIOS memory device 134 reads the data of the faulty hardware component from the BMC 130 (step 638). The routine then begins a boot cycle, including a POST routine with an adjusted BIOS, wherein the adjusted BIOS disables the faulty hardware component based on adjusted settings that incorporate the data of the faulty hardware component. The routine then checks whether the computer system 100 can boot properly after the boot cycle (step 640). If the boot routine is successful, the routine reaches the end of the POST routine (step 630).

[0072] If the boot process fails (step 640), the computer system 100 retries several times in an attempt to perform a successful boot cycle (step 642). If one of these boot cycles succeeds, the BMC 130 turns off the GPIO pin 162 and performs the boot cycle routine (step 644). If these retries do not result in a successful boot, the computer system 100 determines that the cause of the crash is another problem related to the firmware, the motherboard, or an unknown issue (step 646).

[0073] Figure 5 and Figure 6 The flowchart in the figure represents example machine readable instructions for enabling the POST routine to complete successfully even if Figure 2 The computer system 100 in has a faulty hardware component. In this example, the machine-readable instructions include an algorithm for execution by: (a) a processor; (b) a controller; and / or (c) one or more other suitable processing devices. The algorithm may be implemented as software stored in a tangible medium (e.g., flash memory, CD-ROM, floppy disk, DVD, or other memory device). However, those skilled in the art will readily recognize that the algorithm, in whole and / or in part, may also be executed by a device other than a processor, and / or implemented in a known manner in firmware or dedicated hardware (e.g., it may be implemented in an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), discrete logic gates, etc.). For example, any or all of the components of such interfaces may be implemented in software, hardware, and / or firmware. Furthermore, some or all of the machine-readable instructions represented by such flow charts may be implemented manually. Furthermore, although the example algorithm is described with reference to Figure 5 and Figure 6Although the present invention is described with reference to the flowchart in the figure, those skilled in the art will readily recognize that many other methods of implementing the example machine-readable instructions may also be used. For example, the execution order of the blocks may be changed, and / or some of the blocks may be changed, removed, or combined.

[0074] The principles disclosed above can avoid the lengthy process of replacing hardware components immediately to avoid downtime of the computer system. The exemplary routine enables the computer system to operate without reducing performance and provides remote debugging information to technicians.

[0075] As used in this patent application document, "component," "module," "system," or similar terms generally refer to a computer-related entity, which may be hardware (e.g., circuitry), a combination of hardware and software, software, or an entity associated with an operating machine that performs one or more specific functions. For example, a component may be, but is not limited to, a program, a processor, an object, an executable file, a thread, a program, and / or a computer running on a processor (e.g., a digital signal processor). For example, an application running on a controller and the controller may both be a component. One or more components may be located within a program and / or a thread, and a component may be located within a computer and / or distributed between two or more computers. Furthermore, a "device" may be implemented in the form of specially designed hardware, specialized general-purpose hardware (with software executed on the hardware to enable the hardware to perform specific functions), software stored on a computer-readable medium, or a combination of the above entities.

[0076] Although a number of embodiments of the present invention have been described above, it should be noted that the embodiments are presented for illustrative purposes only and are not limiting. Although one or more implementations of the present invention have been illustrated and described, those skilled in the art will recognize equivalent modifications or improvements after reading and understanding this specification and the accompanying drawings. In addition, although a particular feature of the present invention may be disclosed in only one of several implementations, if it is desired or advantageous for any given or specific application, the feature may also be combined with other features in one or more other implementations. Therefore, the breadth and scope of the present invention should not be limited to any of the aforementioned embodiments. Instead, the scope of the present invention should be defined in accordance with the following claims and their equivalents.

[0077] The terms used in this specification are for describing specific embodiments only and are not intended to limit the present invention. Unless otherwise specified, the singular terms "a," "an," and "the" used in this specification are intended to include the plural terms. In addition, the terms "including," "comprising," "having," and "having" used in "embodiments" and / or claims are intended to have an inclusive meaning, similar to the word "comprising."

[0078] Unless otherwise defined, all terms (including technical and scientific terms) used in this specification have the same meanings as those commonly understood by persons skilled in the art to which this invention belongs. Furthermore, unless otherwise explicitly defined in this specification, terms that are defined in commonly used dictionaries, for example, should be interpreted as having the same meaning as in the context of the relevant art and should not be interpreted in an idealized or overly formal manner.

Claims

1. A computer system capable of avoiding shutdown due to a faulty component, the system comprising: Management controller, storage system error log; a plurality of hardware components, each hardware component in communication with the management controller; The Basic Input / Output System (BIOS), including the boot routine, is configured to successfully complete when all of the described hardware components are operational. The BIOS is operable to: determining an error recorded in the system error log from the hardware component; shutting down the hardware component corresponding to the recorded error; Adjusting the startup routine to not access the hardware component that has been turned off; as well as Complete the power-on self-test routine.

2. The system of claim 1, wherein the BIOS includes a non-volatile random access memory (NVRAM) configured to store instructions for shutting down the hardware component.

3. The system of claim 1 , wherein: The management controller is configured to store an image of the BIOS before the hardware component is shut down, the BIOS including settings of the hardware component; The management controller is configured to detect a chassis opening event; as well as The management controller is configured to load a stored BIOS image when the chassis opening event is detected; The stored BIOS image is used in the boot routine.

4. The system of claim 1, wherein the management controller sends a signal to a general purpose input / output (GPIO) pin to enable the BIOS to shut down the hardware component.

5. A method for starting a computer system having a plurality of hardware components, the method comprising: analyzing a system error log of a management controller using a startup routine of a basic input / output system (BIOS) to determine an error logged from the hardware component; shutting down the hardware component corresponding to the recorded error; Adjusting the startup routine to not access the hardware component that has been turned off; as well as Complete the power-on self-test routine.

6. The method of claim 5, wherein the BIOS includes a non-volatile random access memory (NVRAM) configured to store instructions for shutting down the hardware component.

7. The method of claim 5, further comprising: storing an image of the BIOS before shutting down the hardware component, the BIOS including the hardware component; Detecting the case opening event; as well as When the chassis opening event is detected, the stored BIOS image is loaded; The stored BIOS image is used in the boot routine.

8. The method of claim 5, wherein the management controller sends a signal to a general purpose input / output (GPIO) pin to enable the BIOS to shut down the hardware component.

9. A computer server comprising: A plurality of hardware components, the plurality of hardware components comprising: a processor, a serial dual in-line memory module, and an expansion card; a baseboard management controller coupled to the processor, the dual in-line memory module, and the expansion card, the baseboard management controller being configured to store a system error log having errors recorded for at least one of the processor, the memory module, or the expansion card; A basic input / output system (BIOS) includes a startup routine that is successfully completed when the plurality of hardware components are operational. The BIOS is operable to: determining errors recorded in the system error log from the processor, the dual inline memory module, and the expansion card; shutting down the processor, dual inline memory module, or expansion card corresponding to the logged error; adjusting the boot routine to not access the processor, dual inline memory module, or expansion card that has been powered off; and Complete the power-on self-test routine.

Images