Abstract:
Methods and systems are disclosed for using a server management program for an error configuration table, wherein a user loads the management program, which receives a Hardware Error Configuration Table (HECT) from baseboard management controller (BMC) firmware, the HECT table containing error control parameters for a hardware error event table. A replica of the HECT is maintained in SRAM using BMC firmware. The HECT is sent via the basic input output system (BIOS) during system power up. An interface is set up to allow the user to configure error event thresholds. The user can set preferred threshold of a system management requirement without rebooting system. If the user makes changes to the HECT, the management program sends the new HECT to BMC firmware to feedback the completion. A software SMI is issued to inform BIOS of HECT changes during the BMC completion. BIOS informs the operating system (OS) to discard and reload the new HECT.

Description:
TECHNICAL FIELD  
       [0001]    The techniques described herein relate to a method and system for using a server management program for an error configuration table, and particularly to making changes to a hardware error configuration table without rebooting the system. 
       BACKGROUND  
       [0002]    As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
         [0003]    Current information handling systems run through considerable initialization code stored in a basic input output system (BIOS) when a computer is powered on and boots up. Coordination of component operations is typically performed with the BIOS and an operating system, such as WINDOWS. The system sends a primary central processing unit (CPU), which is a pre-designated boot strap processor (BSP), an INIT-SIPI command for initialization, at which time the BSP begins running the BIOS software code. During the boot process, the BIOS typically discovers, maps, and initializes all the processors in a system. The various component operations typically include error handling functions that manage errors that arise during operations. Correctable errors can be corrected and uncorrectable errors may be classified as fatal or non-fatal errors. Hardware error handling systems may include variable and fixed threshold limits for identification and classification of a hardware error event. Typically to make changes to the tables that contain such, a system reboot is required. Thus, making such changes requires the time, complexity and down time of a system reboot. 
         [0004]    For example, current art methods, such as a single bit error-correction coding (ECC) handling, for example, have a fixed threshold which is usually set for Dual Inline Memory Module (DIMM) fatal error prediction. Some methods address the requirement of variable threshold and provide an interface in a basic input output system (BIOS) setup to configure the threshold value which is a time setting and requires system reboot. PCI-Express fatal error prediction also requires variable threshold to enrich functionality. Many other hardware events may have threshold limits that it would be desirable to change, and the disclosure provided herein in not limited to these exemplary error events. 
         [0005]    A baseboard management controller (BMC) is a specialized microcontroller embedded on a motherboard of a computer or server. The BMC is the intelligence in the Intelligent Platform Management Interface (IPMI) architecture, which defines a set of common interfaces to computer hardware and firmware that system administrators can use to monitor system health and manage the system. The BMC manages the interface between system management software and platform hardware. What is needed is a method of using a server management program for an error configuration table, wherein changes can be made to a hardware error configuration table without rebooting the system 
       SUMMARY  
       [0006]    The techniques described herein provide a method and system for using a server management program for an error configuration table by loading the management program, wherein the management program receives a hardware error configuration table (HECT) from the BMC, the HECT table containing error control parameters for a hardware error event table. A replica of a HECT table is maintained in SRAM using BMC firmware. The HECT table is sent by a basic input output system (BIOS) during system power up. An interface is set up to allow a user to configure error event thresholds, wherein the user can set preferred threshold of a system management requirement without rebooting the system. 
         [0007]    Another aspect of the techniques described herein provide an information handling system having a basic input output system (BIOS), comprising a central processing unit (CPU) configured for using a server management program for an error configuration table by loading the management program, wherein the management program receives a hardware error configuration table (HECT) from the BMC, the HECT table containing error control parameters for a hardware error event table. A replica of a HECT table is maintained in SRAM using BMC firmware. The HECT table is sent by a basic input output system (BIOS) during system power up. An interface is set up to allow a user to configure error event thresholds, wherein the user can set preferred threshold of a system management requirement without rebooting the system. As described below, other features and variations can be implemented, if desired, and a related method can be utilized, as well. 
     
    
     
       DESCRIPTION OF THE DRAWINGS  
         [0008]    It is noted that the appended drawings illustrate only exemplary embodiments of the techniques described herein and are, therefore, not to be considered limiting of its scope, for the techniques may admit to other equally effective embodiments. 
           [0009]      FIG. 1A  is a block diagram for an information handling system according to the techniques described herein; 
           [0010]      FIG. 1B  is a flowchart of general steps involved in using a server management program for an error configuration table; 
           [0011]      FIG. 2  is a flowchart of a basic input output system (BIOS) power-on self test (POST) flow of hardware error configuration table (HECT) handling; 
           [0012]      FIG. 3  is a flowchart of a management program acquiring HECT information with BMC firmware; 
           [0013]      FIG. 4A  is a flowchart of the management program updating HECT change information to BMC firmware; and 
           [0014]      FIG. 4B  is a flowchart of BIOS updating HECT information from BMC firmware. 
       
    
    
     DETAILED DESCRIPTION  
       [0015]    For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a server computer system, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components. 
         [0016]    The techniques described herein relate to a method and system for using a server management program for an error configuration table, and particularly to making changes to a hardware error configuration table without rebooting the system. 
         [0017]    Example embodiments for the techniques described herein will now be discussed with respect to the drawings.  FIG. 1A  provides a block diagram of an information handling system configured for using a server management program for an error configuration table, and more particularly to making changes to a hardware error configuration table without rebooting the system.  FIG. 1B  provides a general overview of using a server management program for an error configuration table.  FIG. 2  provides an example process flow diagram for basic input output system (BIOS) power-on self test (POST) flow of HECT handling, according to the techniques described herein.  FIG. 3  provides an example process flow diagram of management program acquiring HECT information with BMC firmware, according to the techniques described herein.  FIG. 4A  provides an example process flow diagram of management program updating HECT change information to BMC firmware, and  FIG. 4B  provides an example process flow diagram of BIOS updating HECT information from BMC firmware, according to the techniques described herein. 
         [0018]      FIG. 1A  is a block diagram  100 A for an information handling system  150  according to the techniques described herein. In the embodiment depicted, the information handling system  150  includes a central processing unit (CPU)  124 , BIOS (basic input output system)  102 , an input device  120  and a display  122 . In addition, the information handling system  150  includes a number of devices that could potentially be used to boot the system. These devices include CDROM drive  106 , network interface card (NIC)  108 , a first USB (universal serial bus) drive (USB  1 )  110 , hard drive  112 , and memory  114 . Interconnection  125  connects the devices and the other blocks within the information handling system  150  and represents one or more busses and related connection circuitry that allows communications among these elements of the information handling system  150 . 
         [0019]    The BIOS  102  is in communication with the CPU  124 , wherein the BIOS  102  is configured to operate during initialization of the information handling system to use a management program for an error configuration table. The management program is loaded, wherein the management program receives a hardware error configuration table (HECT) from BMC. A replica of the HECT table is maintained in SRAM using BMC firmware, the HECT table being sent by the BIOS  102  during system power up. An interface is set up to allow a user to configure, wherein the user can set preferred threshold of a system management requirement without rebooting the system. For example, the user can also set a preferred threshold of DIMM reliability measuring without rebooting the system. Likewise, PCI-Express fatal error prediction thresholds may be set. Many other hardware events may have threshold limits that it would be desirable to change, and the disclosure provided herein in not limited to these exemplary error events. 
         [0020]      FIG. 1B  is a flowchart  100 B of the general steps involved in using a management program for an error configuration table. The process begins when the system is booted up, step  150 . A new hardware error configuration table (HECT) is updated to BMC, step  152 . The new HECT table can be backed up to NVRAM or Flash. The system BIOS is informed of the HECT table update, step  154 , then the booting process is completed, step  156 . At this point, a user can make changes to the HECT table. HECT table changes can be saved to SRAM. A determination is made regarding whether a user has updated the HECT table, step  158 . If No, the process returns to the determination step  158  to wait for the user to update the HECT table. If Yes, a management program receives the HECT table from BMC, step  160 . The management program can receive the HECT table from SRAM at the BMC. A software SMI can be generated to inform the system BIOS of HECT table changes. The user sends the HECT table changes from the management program to BMC, step  162 . System memory is updated and the HECT table is backed up to non-volatile memory, step  164 , then the process returns to the determination step  158  to wait for the user to update the HECT table further. 
         [0021]      FIG. 2  is a flowchart  200  of the BIOS POST flow of HECT handling. The process begins when the system boots, step  202 . After power-on self test (POST), step  203 , which is a pre-boot sequence, initial error logging, step  204 , occurs. Then, the previous configuration table is retrieved from NVRAM or Flash, step  206 . A determination is made regarding whether the HECT table is validated, step  208 . If Yes, a determination is made regarding whether a new component is found, step  212 . If Yes, the HECT table is updated to system memory, step  214 , and the new HECT table is backed up to NVRAM or Flash, step  216 . If No, a new error source is not found, then the new HECT table information is updated to BMC firmware, step  218 . 
         [0022]    Returning to the determination in step  208 , if No, the HECT table is not validated, then a new HECT is loaded in system memory, step  210 , by copying from the error source table. Then, the new HECT table is backed up to NVRAM or Flash, step  216 , and the new HECT table information is updated to BMC firmware, step  218 . 
         [0023]    The process continues from step  218 , via a KCS command/data port to BMC firmware  220 , wherein a determination is made regarding whether BIOS has requested HECT update, step  222 . If Yes, HECT changes are saved to SRAM, step  224 , then parameters are adjusted accordingly, step  228 , and response error code is sent to system BIOS, step  230 . It is understood that a replica of HECT is maintained in SRAM using BMC firmware, the HECT being sent by a basic input output system (BIOS) during system power up. If No at step  228 , BIOS has not requested HECT update, then the process skips to a step wherein response complete code is sent to system BIOS, step  230 . Then, a determination is made regarding whether complete code is received from BMC firmware, step  232 . If No, the complete code has not been received from the BMC firmware, the process repeats the determination step  232 , regarding whether complete code is received from BMC firmware. If Yes, the process boots, step  234 . 
         [0024]      FIG. 3  is a flowchart  300  of a management program acquiring HECT information with BMC firmware. The process begins with a management program, step  302  sending HECT table query command to BMC, step  304  via KCS command/data port. The HECT table is queried, step  308 , using BMC firmware, step  306 . HECT table is retrieved from SRAM, step  310 , then the HECT table is returned to the management program, step  312 . A determination is made regarding whether the HECT table is received from BMC, step  314 . If Yes, the process ends, step  316 . If No, the process repeats the step  314 , of determining whether the HECT table is received from BMC. 
         [0025]      FIG. 4A  is a flowchart  400 A of a management program updating HECT change information to the BMC firmware. The process begins with a management program, step  402 , wherein user changes are made to a HECT table, step  404 . The HECT table data changes command/data are sent to BMC, step  406 , via KCS command/data port, and are received in BMC firmware, step  408 . Then, the data changes are saved into SRAM, step  410 . Parameters are adjusted accordingly, step  412 , and response complete code is sent to management program, step  414 . A determination is made regarding whether complete code is received from BMC, step  416 . If No, the determination step is repeated regarding whether complete code is received from BMC, step  416 . If Yes, a software SMI is generated to inform system BIOS of HECT table changes, step  418 , and the process ends, step  420 . 
         [0026]      FIG. 4B  is a flowchart  400 B of BIOS updating HECT information from BMC firmware. The process begins in SMI handler, step  430 , when HECT table is changed, step  432 . The HECT table is received from BMC, step  434 , via a KCS command/data port, step  436 . The HECT table command is received in BMC firmware, step  438 . The HECT information is received from SRAM, step  440 . The HECT table is returned, step  442 . Then, a determination is made regarding whether the HECT change information is received, step  444 . If No, the determination step is repeated regarding whether the HECT change information is received, step  444 . If Yes, the HECT table is updated in system memory, step  446 , and the HECT table is backed up into NVRAM or Flash, step  448 , and the process ends by exiting SMI, step  450 . 
         [0027]    Further modifications and alternative embodiments of the techniques described herein will be apparent to those skilled in the art in view of this description. It will be recognized, therefore, that the techniques described herein are not limited by these example arrangements. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the manner of carrying out the techniques described herein. It is to be understood that the forms of the techniques described herein shown and described are to be taken as the presently preferred embodiments. Various changes may be made in the implementations and architectures. For example, equivalent elements may be substituted for those illustrated and described herein and certain features of the techniques described herein may be utilized independently of the use of other features, all as would be apparent to one skilled in the art after having the benefit of this description of the techniques.