Hardware fault detection method based on CPU and BMC platform

Abstract

The invention relates to the technical field of hardware fault detection, and discloses a hardware fault detection method based on a CPU and a BMC platform, and the method comprises the steps that a BMC regularly sends a predefined instruction to the CPU for checking a system state; after a predefined instruction is received, a corresponding code is returned according to the current state; when an unrecoverable error occurs, a signal connected with the BMC is pulled down so as to inform the BMC of the occurrence of the fault; and after the change of the GPIO signal is detected, a query instruction is sent to the CPU for acquiring key error information and recording a fault condition so as to ensure that detailed state information can be captured in time when a CPU fault occurs. According to the method, the key information of the server can be monitored and recorded in real time, health management of the multi-unit server is ensured, detailed error information display can be provided at the front end, fault diagnosis and analysis are supported, and the stability and maintenance efficiency of a server system are further improved.

Description

Technical Field

[0001] The present application relates to the technical field of hardware fault detection, for example, to a hardware fault detection method based on a CPU and BMC platform. Background Art

[0002] With the rapid development of information technology, computer servers are playing an increasingly important role in various fields of application, and their system structure is becoming more and more complex. In order to ensure the stable operation and efficient maintenance of server systems, fault detection and management become particularly important. In this regard, fault detection and management methods based on BMC (Baseboard Management Controller) play a key role.

[0003] The BMC chip is a microcontroller independent of the main CPU that monitors the hardware status of the server and can operate independently even when the main CPU is turned off. By communicating with the CPU and other hardware components, the BMC can monitor the operating status of the server in real time and take appropriate measures when a failure or abnormality occurs to ensure the stability and reliability of the server.

[0004] In modern server systems, with the increase in the number of CPU cores and the expansion of memory capacity, the monitoring of CPU C2C (Cache-to-Cache) errors and memory ECC (Error-Correcting Code) errors has become particularly important. C2C errors refer to errors that occur when data is exchanged between CPU cores, while memory ECC errors refer to situations where data stored in memory is erroneous but can be corrected by ECC. If these errors are not detected and handled in a timely manner, they may cause server performance degradation or even system crashes.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present application, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0006] In order to provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. The summary is not an extensive review, nor is it intended to identify key / critical components or delineate the scope of protection of these embodiments, but rather serves as a prelude to the detailed description that follows.

[0007] The embodiment of the present disclosure provides a hardware fault detection method based on a CPU and a BMC platform, the method comprising:

[0008] The BMC periodically sends predefined OEM instructions to the CPU via IPMB-I2C to check the system status of the CPU;

[0009] After receiving the predefined OEM instruction, the CPU returns the corresponding code according to the current status;

[0010] When an unrecoverable error occurs in the CPU, the CPU pulls down the GPIO signal connected to the BMC to notify the BMC of the fault.

[0011] After the BMC detects a change in the GPIO signal, it sends a query command to the CPU to obtain key error information and record the fault condition to ensure that detailed status information can be captured in a timely manner when a CPU fault occurs.

[0012] In some embodiments, after receiving the predefined OEM instruction, the CPU returns a corresponding code according to the current state, including:

[0013] After the CPU receives the predefined OEM instruction, if the system is normal, it returns a preset normal code; if a C2C error or memory ECC error is detected, it returns the corresponding error identification code; if communication fails, it returns a preset communication failure code.

[0014] In some embodiments, the method further comprises:

[0015] When the BMC receives the response code from the CPU, it parses the returned code;

[0016] If the returned code is the preset normal code, it means the system status is normal;

[0017] If the returned code is an error identification code, the BMC classifies the error information as an unrecoverable error, a serious error, or a warning error according to the severity of the error identification code, and registers the error information on the DBus bus to form an error log entry for access by other modules of the system.

[0018] In some embodiments, the method further comprises:

[0019] BMC obtains CPU and memory usage. When the CPU and memory usage are lower than the preset threshold, BMC increases the frequency of sending OEM instructions to the CPU to improve the timeliness of monitoring.

[0020] When the CPU and memory usage is higher than or equal to the preset threshold, the BMC reduces the frequency of sending OEM instructions to the CPU to ensure that system performance is not affected by the monitoring task.

[0021] In some embodiments, the method further comprises:

[0022] The BMC records the time when the error occurred, the hardware components involved, and the frequency of the error;

[0023] If the frequency of errors occurring within a preset time period is greater than the preset high-risk threshold, the BMC raises the alarm level of the corresponding error to ensure that the corresponding problem is handled in a timely manner;

[0024] If the frequency of errors occurring within a preset time period is less than the preset low-risk threshold, the BMC lowers the alarm level of the corresponding error to optimize the accuracy and responsiveness of alarm management.

[0025] In some embodiments, the method further comprises:

[0026] The front-end system periodically scans the DBus bus through the Redfish interface to check if there are any new error log entries;

[0027] When a new error log entry is detected, the front-end system prioritizes unrecoverable errors and serious errors, and displays error information that meets the preset conditions based on the alarm level.

[0028] In some embodiments, the method further comprises:

[0029] The front-end system extracts the error identification code and compares it with the specific error description according to the error identification table. It also distinguishes the colors of errors of different severity according to the alarm level.

[0030] The interface dynamically updates and displays the current system error status, error type, occurrence time, and the hardware components involved.

[0031] In some embodiments, the method further comprises:

[0032] The front-end system dynamically adjusts the alarm priority display according to the change of error frequency;

[0033] Errors that occur more frequently than the preset high-risk threshold within a preset time period are highlighted in the interface to remind users to pay special attention;

[0034] For errors whose frequency within a preset time period is less than the preset low-risk threshold, their display priority is reduced.

[0035] In some embodiments, the method further comprises:

[0036] The front-end system records all detected error information in a log file, which is used by the user to download the log file through the interface for detailed analysis. The log file contains complete error information, timestamp, hardware status, and communication records between the BMC and the CPU for subsequent fault diagnosis and maintenance.

[0037] The hardware fault detection method based on the CPU and BMC platform provided in the embodiments of the present disclosure can achieve the following technical effects:

[0038] Through the IPMB-I2C communication between the BMC and the CPU, real-time monitoring and recording of CPU C2C errors and memory ECC errors can be achieved, and the acquired error information can be reported to the DBus bus, and displayed and downloaded and analyzed on the front-end interface through the Redfish interface. It can not only monitor and record key information of the server in real time to ensure the healthy management of multi-unit servers, but also provide detailed error information display on the front end, support fault diagnosis and analysis, and further improve the stability and maintenance efficiency of the server system.

[0039] The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] One or more embodiments are exemplarily described by corresponding drawings, which do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements, and the drawings do not constitute a scale limitation, and wherein:

[0041] Figure 1 It is a flowchart of a hardware fault detection method based on a CPU and BMC platform provided by an embodiment of the present disclosure;

[0042] Figure 2 It is a flowchart of another hardware fault detection method based on CPU and BMC platform provided by an embodiment of the present disclosure;

[0043] Figure 3 is a schematic diagram of an error handling process provided by an embodiment of the present disclosure;

[0044] Figure 4 It is a structural diagram of a hardware fault detection system based on a CPU and BMC platform provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0045] In order to be able to understand the features and technical contents of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The attached drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the convenience of explanation, a full understanding of the disclosed embodiments is provided through multiple details. However, one or more embodiments can still be implemented without these details. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.

[0046] The terms "first", "second", etc. in the embodiments of the present disclosure are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so as to describe the embodiments of the present disclosure described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0047] Unless otherwise stated, the term "plurality" means two or more.

[0048] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B indicates: A or B.

[0049] The term "and / or" is a description of the association relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0050] The term "correspondence" may refer to an association relationship or a binding relationship. The correspondence between A and B means that there is an association relationship or a binding relationship between A and B.

[0051] The hardware fault detection method based on the CPU and BMC platform provided by the embodiment of the present disclosure is described below with reference to the accompanying drawings.

[0052] Figure 1 The present invention is a flowchart of a method for hardware fault detection based on a CPU and BMC platform provided by an embodiment of the present invention.

[0053] like Figure 1 As shown, the hardware fault detection method based on the CPU and BMC platform may include:

[0054] S01, BMC periodically sends predefined OEM instructions to the CPU through IPMB-I2C to check the system status of the CPU;

[0055] S02, after receiving the predefined OEM instruction, the CPU returns the corresponding code according to the current state;

[0056] S03, when an unrecoverable error occurs in the CPU, the CPU pulls down the GPIO signal connected to the BMC to notify the BMC of the occurrence of the fault;

[0057] S04, after detecting the change of the GPIO signal, the BMC sends a query instruction to the CPU to obtain key error information and record the fault condition to ensure that detailed status information can be captured in time when a CPU fault occurs.

[0058] Figure 2is a flowchart of another hardware fault detection method based on CPU and BMC platform provided by an embodiment of the present disclosure, Figure 3 This is a schematic diagram of an error handling process provided by an embodiment of the present disclosure, combined with Figure 2 and Figure 3 right Figure 1 The method is further described in .

[0059] In some embodiments, after receiving the predefined OEM instruction, the CPU returns a corresponding code according to the current state, including:

[0060] After the CPU receives the predefined OEM instruction, if the system is normal, it returns a preset normal code; if a C2C error or memory ECC error is detected, it returns the corresponding error identification code; if communication fails, it returns a preset communication failure code.

[0061] In some embodiments, Figure 1 The method may also include:

[0062] When the BMC receives the response code from the CPU, it parses the returned code;

[0063] If the returned code is the preset normal code, it means the system status is normal;

[0064] If the returned code is an error identification code, the BMC classifies the error information as an unrecoverable error, a serious error, or a warning error according to the severity of the error identification code, and registers the error information on the DBus bus to form an error log entry for access by other modules of the system.

[0065] In some embodiments, Figure 1 The method may also include:

[0066] BMC obtains CPU and memory usage. When the CPU and memory usage are lower than the preset threshold, BMC increases the frequency of sending OEM instructions to the CPU to improve the timeliness of monitoring.

[0067] When the CPU and memory usage is higher than or equal to the preset threshold, the BMC reduces the frequency of sending OEM instructions to the CPU to ensure that system performance is not affected by the monitoring task.

[0068] In some embodiments, Figure 1 The method may also include:

[0069] The BMC records the time when the error occurred, the hardware components involved, and the frequency of the error;

[0070] If the frequency of errors occurring within a preset time period is greater than the preset high-risk threshold, the BMC raises the alarm level of the corresponding error to ensure that the corresponding problem is handled in a timely manner;

[0071] If the frequency of errors occurring within a preset time period is less than the preset low-risk threshold, the BMC lowers the alarm level of the corresponding error to optimize the accuracy and responsiveness of alarm management.

[0072] In some embodiments, Figure 1 The method may also include:

[0073] The front-end system periodically scans the DBus bus through the Redfish interface to check if there are any new error log entries;

[0074] When a new error log entry is detected, the front-end system prioritizes unrecoverable errors and serious errors, and displays error information that meets the preset conditions based on the alarm level.

[0075] In some embodiments, Figure 1 The method may also include:

[0076] The front-end system extracts the error identification code and compares it with the specific error description according to the error identification table. It also distinguishes the colors of errors of different severity according to the alarm level.

[0077] The interface dynamically updates and displays the current system error status, error type, occurrence time, and the hardware components involved.

[0078] In some embodiments, Figure 1 The method may also include:

[0079] The front-end system dynamically adjusts the alarm priority display according to the change of error frequency;

[0080] Errors that occur more frequently than the preset high-risk threshold within a preset time period are highlighted in the interface to remind users to pay special attention;

[0081] For errors whose frequency within a preset time period is less than the preset low-risk threshold, their display priority is reduced.

[0082] In some embodiments, Figure 1 The method may also include:

[0083] The front-end system records all detected error information in a log file, which is used by the user to download the log file through the interface for detailed analysis. The log file contains complete error information, timestamp, hardware status, and communication records between the BMC and the CPU for subsequent fault diagnosis and maintenance.

[0084] In the present disclosure, through the IPMB-I2C communication between the BMC and the CPU, real-time monitoring and recording of the CPU's C2C errors and memory ECC errors can be achieved, the acquired error information can be reported to the DBus bus, and displayed and log downloaded and analyzed on the front-end interface through the Redfish interface. The present disclosure can not only monitor and record the key information of the server in real time to ensure the healthy management of multi-unit servers, but also provide detailed error information display on the front end, support fault diagnosis and analysis, and further improve the stability and maintenance efficiency of the server system.

[0085] In a specific example, Figure 1 The method may further include:

[0086] 1.BMC communicates with CPU:

[0087] 1) BMC command sending and CPU response

[0088] The BMC periodically sends predefined OEM instructions to the CPU via IPMB-I2C to check the system status. In order to ensure that the CPU performance is not affected, a dedicated register is designed to process instructions from the BMC. In this way, the communication between the BMC and the CPU will not affect the normal operation of the CPU.

[0089] 2) Error detection and dynamic adjustment of instruction frequency

[0090] After receiving the instruction, the CPU returns the corresponding code according to the current status: if the system is normal, it can return 0; if a C2C error or memory ECC error is detected, it returns a specific error identification code (such as 0x01 for C2C error, 0x02 for ECC error); if communication fails, it returns -1.

[0091] In addition, BMC can dynamically adjust the frequency of command transmission based on the CPU and memory usage. When the CPU and memory loads are low, BMC will increase the detection frequency to improve the timeliness of monitoring; when the load is high, BMC will appropriately reduce the transmission frequency to ensure that system performance is not affected by the monitoring task.

[0092] If the preset period t 预设周期 is 100s, when the CPU load rate λ CPU负载率 is 10%, memory load ratio β 内存负载率 20%, based on t 发送周期 =t 预设周期 ×λ CPU负载率 ×β 内存负载率 The sending period t can be determined 发送周期 Once every 2s.

[0093] 3) Unrecoverable error handling

[0094] When an unrecoverable serious error occurs in the CPU (such as an imminent crash), the CPU will pull down the GPIO signal connected to the BMC to notify the BMC of the fault. After the BMC detects the change in the GPIO signal, it will immediately send a query command to obtain key error information and record the fault to ensure that detailed status information can be captured in time when a CPU fault occurs.

[0095] 2. Error message processing:

[0096] 1) Error classification and recording

[0097] After receiving the response from the CPU, the BMC parses the returned code. If the returned code is 0, it means the system is in normal state; if the returned code is an error identification code, the BMC will classify the error information into unrecoverable error, serious error or warning error according to the severity of the error, and register the error information on the DBus bus to form an error log entry for access by other modules of the system.

[0098] 2) Dynamically adjust the alarm level

[0099] In addition to recording error information, BMC also records information such as the time when the error occurred, related hardware components, and the frequency of the error. If an error occurs frequently in a short period of time, BMC will automatically increase its alarm level to ensure that the problem is handled in a timely manner; for errors that occur less frequently, the alarm level will be reduced accordingly to optimize the accuracy and responsiveness of alarm management.

[0100] 3. Front-end error monitoring and display:

[0101] 1) Redfish interface scans DBus

[0102] The front-end system periodically scans the DBus bus through the Redfish interface to check for new error log entries. When new logs are detected, the front-end system will prioritize unrecoverable errors and serious errors, and display high-level error information first according to the alarm level.

[0103] 2) Dynamically update error information

[0104] The front-end system extracts the error identification code and compares it with the specific error description according to the error identification table. At the same time, it distinguishes the colors of errors of different severity according to the alarm level (such as red for unrecoverable errors, orange for serious errors, and yellow for warning errors). The interface dynamically updates and displays detailed information such as the current system error status, error type, occurrence time, and hardware components involved.

[0105] 3) Alarm priority adjustment

[0106] The front-end system dynamically adjusts the display priority of alarms according to the change of error frequency. Frequently occurring errors will be more prominent in the interface to remind users to pay attention; while for errors with low frequency or reduced frequency, the system will lower their display priority accordingly.

[0107] 4. Log recording and downloading:

[0108] 1) Log recording and analysis

[0109] The front-end system records all detected error information in log files, which users can download through the interface for detailed analysis. The log files contain complete error information, timestamps, hardware status, and communication records between the BMC and the CPU, which facilitates subsequent fault diagnosis and maintenance.

[0110] 2) Historical log query and diagnosis

[0111] Users can query historical error logs, download log files, and perform further diagnostic operations through the front-end interface. The detailed records in the log files help users quickly locate and resolve hardware failures, improving system maintenance efficiency.

[0112] 5. User interface interaction:

[0113] 1) The front-end interface not only displays the current system status and error information in real time, but also provides a user-friendly interface for users to query historical error logs, download log files, and perform further diagnostic operations.

[0114] 2) Users can quickly locate and resolve hardware failures based on the detailed error descriptions and log information provided by the front end, thereby improving system maintenance efficiency.

[0115] Through the above steps, the present invention can implement a hardware fault detection method based on a CPU and BMC platform, provide a server management system with the function of real-time monitoring and recording key error information, and further improve the stability and maintenance efficiency of the server system.

[0116] In a specific embodiment, based on the above description, Figure 1 The method in can be further understood as:

[0117] 1.BMC and CPU communication

[0118] 1) The BMC calls the sending function through the I2C interface to generate instructions in a specific format. The instruction content is encoded and contains the corresponding query operation code.

[0119] 2) The firmware embedded in the CPU will set different status flags in the specified registers and send them back to the BMC through the IPMB-I2C bus.

[0120] 3) BMC dynamically adjusts the sending interval by analyzing CPU load monitoring data (such as CPU occupancy, memory usage, etc.). The BMC firmware has a frequency adjustment module based on the formula t 发送周期 =t 预设周期 ×λ CPU负载率 ×β 内存负载率 The optimal sending period t can be calculated based on the load data 发送周期 .

[0121] If the preset period t 预设周期 is 100s, when the CPU load rate λ CPU负载率 is 10%, memory load ratio β 内存负载率 is 20%, the sending period t 发送周期 Once every 2s.

[0122] 4) When the GPIO level change is detected by the BMC, the BMC firmware will automatically trigger the query function and immediately send instructions containing higher-level diagnostic information to obtain the detailed status of the CPU.

[0123] 2. Error message handling

[0124] 1) The BMC firmware includes an error parsing module that maps received error codes to specific error types through a preset error code comparison table.

[0125] 2) BMC packages the error data into log entries in a specific format and uploads them to the DBus bus for other system modules to read.

[0126] 3) The BMC maintains an error frequency counter internally, records the number of times the error occurs, and dynamically adjusts the corresponding alarm strategy.

[0127] 3.DBus bus reporting and front-end display

[0128] 1) Through the DBus protocol interface, the BMC serializes the error information into a standard log entry format and transmits it to the system bus.

[0129] 2) The Redfish interface reads the log data in DBus through polling or event-driven mechanism, and displays the parsed error information on the front-end interface.

[0130] 3) The interface uses visual elements (such as color coding, alarm prompts, etc.) to distinguish errors of different severity and ensure that important error information is displayed first.

[0131] 4. Log Recording and Downloading

[0132] 1) The front-end system provides a log management module. Users can choose to download log files through the front-end interface. The system will package the logs into standard format files (such as JSON or TXT) for users to download.

[0133] 2) The front-end system provides a history query function. Users select a time range through the interface to query and display the error logs within that period.

[0134] Combination Figure 4 As shown, the embodiment of the present disclosure also provides a hardware fault detection system 400 based on the CPU and BMC platform, including a processor 404 and a memory 401. Optionally, the system may also include a communication interface 402 and a bus 403. Among them, the processor 404, the communication interface 402, and the memory 401 can communicate with each other through the bus 403. The communication interface 402 can be used for information transmission. The processor 404 can call the logic instructions in the memory 401 to execute the hardware fault detection method based on the CPU and BMC platform of the above embodiment.

[0135] In addition, the logic instructions in the memory 401 described above may be implemented in the form of software functional units and when sold or used as independent products, may be stored in a computer-readable storage medium.

[0136] The memory 401 is a computer-readable storage medium that can be used to store software programs and computer executable programs, such as program instructions / modules corresponding to the method in the embodiment of the present disclosure. The processor 404 executes the functional application and data processing by running the program instructions / modules stored in the memory 401, that is, the hardware fault detection method based on the CPU and BMC platform in the above embodiment is implemented.

[0137] The memory 401 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 401 may include a high-speed random access memory and may also include a non-volatile memory.

[0138] An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute a hardware fault detection method based on a CPU and a BMC platform.

[0139] The computer-readable storage medium mentioned above may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0140] The technical solution of the embodiment of the present disclosure can be embodied in the form of a software product, which is stored in a storage medium and includes one or more instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method of the embodiment of the present disclosure. The aforementioned storage medium may be a non-transient storage medium, including: a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a disk or an optical disk, and other media that can store program codes, or a transient storage medium.

[0141] The above description and the accompanying drawings fully illustrate the embodiments of the present disclosure so that those skilled in the art can practice them. Other embodiments may include structural, logical, electrical, process and other changes. The embodiments represent possible changes only. Unless explicitly required, separate components and functions are optional, and the order of operations may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. As used in the description of the embodiments, unless the context clearly indicates otherwise, the singular forms of "a", "an" and "the" are intended to include plural forms as well. Similarly, the term "and / or" as used in this application refers to any and all possible combinations of one or more associated listings. In addition, when used in this application, the term "comprise" and its variants "comprises" and / or including (comprising) refer to the existence of stated features, wholes, steps, operations, elements, and / or components, but do not exclude the existence or addition of one or more other features, wholes, steps, operations, elements, components and / or these groups. In the absence of further restrictions, the elements defined by the sentence "comprising a ..." do not exclude the existence of other identical elements in the process, method or device comprising the elements. In this article, each embodiment may focus on the differences from other embodiments, and the same or similar parts between the embodiments may refer to each other. For the methods, products, etc. disclosed in the embodiments, if they correspond to the method part disclosed in the embodiments, then the relevant parts can refer to the description of the method part.

[0142] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software may depend on the specific application and design constraints of the technical solution. Technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present disclosure. Technicians can clearly understand that for the convenience and simplicity of description, the specific working process of the systems, devices and units described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0143] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units can be only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to implement this embodiment. In addition, each functional unit in the embodiment of the present disclosure may be integrated in a processing unit, or each unit may exist physically alone, or two or more units may be integrated in one unit.

[0144] The flowchart and block diagram in the accompanying drawings show the possible architecture, functions and operations of the system, method and computer program product according to the embodiment of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and a part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. In some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, which can depend on the functions involved. In the description corresponding to the flowchart and block diagram in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in a different order from the order disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or may be implemented by a combination of dedicated hardware and computer instructions.

Claims

1. A hardware fault detection method based on CPU and BMC platform, characterized in that: The method comprises: The BMC periodically sends predefined OEM instructions to the CPU via IPMB-I2C to check the system status of the CPU; After receiving the predefined OEM instruction, the CPU returns the corresponding code according to the current status; When an unrecoverable error occurs in the CPU, the CPU pulls down the GPIO signal connected to the BMC to notify the BMC of the fault. After the BMC detects a change in the GPIO signal, it sends a query command to the CPU to obtain key error information and record the fault condition to ensure that detailed status information can be captured in a timely manner when a CPU fault occurs.

2. The method according to claim 1, characterized in that After receiving the predefined OEM instruction, the CPU returns a corresponding code according to the current state, including: After receiving the predefined OEM instruction, the CPU returns a preset normal code if the system is normal; returns a corresponding error identification code if a C2C error or a memory ECC error is detected; and returns a preset communication failure code if communication fails.

3. The method according to claim 1, characterized in that: The method further comprises: When the BMC receives the response code from the CPU, it parses the returned code; If the returned code is the preset normal code, it means the system status is normal; If the returned code is an error identification code, the BMC classifies the error information as an unrecoverable error, a serious error, or a warning error according to the severity of the error identification code, and registers the error information on the DBus bus to form an error log entry for access by other modules of the system.

4. The method according to claim 1, characterized in that: The method further comprises: BMC obtains CPU and memory usage. When the CPU and memory usage are lower than the preset threshold, BMC increases the frequency of sending OEM instructions to the CPU to improve the timeliness of monitoring. When the CPU and memory usage is higher than or equal to the preset threshold, the BMC reduces the frequency of sending OEM instructions to the CPU to ensure that system performance is not affected by the monitoring task.

5. The method according to claim 3, characterized in that: The method further comprises: The BMC records the time when the error occurred, the hardware components involved, and the frequency of the error; If the frequency of errors occurring within a preset time period is greater than the preset high-risk threshold, the BMC raises the alarm level of the corresponding error to ensure that the corresponding problem is handled in a timely manner; If the frequency of errors occurring within a preset time period is less than the preset low-risk threshold, the BMC lowers the alarm level of the corresponding error to optimize the accuracy and responsiveness of alarm management.

6. The method according to claim 3, characterized in that The method further comprises: The front-end system periodically scans the DBus bus through the Redfish interface to check if there are any new error log entries; When a new error log entry is detected, the front-end system prioritizes unrecoverable errors and serious errors, and displays error information that meets the preset conditions based on the alarm level.

7. The method according to claim 6, characterized in that The method further comprises: The front-end system extracts the error identification code and compares it with the specific error description according to the error identification table. It also distinguishes the colors of errors of different severity according to the alarm level. The interface dynamically updates and displays the current system error status, error type, occurrence time, and the hardware components involved.

8. The method according to claim 7, characterized in that The method further comprises: The front-end system dynamically adjusts the alarm priority display according to the change of error frequency; Errors that occur more frequently than the preset high-risk threshold within a preset time period are highlighted in the interface to remind users to pay special attention; For errors whose frequency within a preset time period is less than the preset low-risk threshold, their display priority is reduced.

9. The method according to claim 3, characterized in that: The method further comprises: The front-end system records all detected error information in a log file, which is used by the user to download the log file through the interface for detailed analysis. The log file contains complete error information, timestamp, hardware status, and communication records between the BMC and the CPU for subsequent fault diagnosis and maintenance.

Images