A server firmware program error correction self-checking method and system

Abstract

The application belongs to the technical field of firmware exception monitoring, and specifically provides a server firmware program error correction self-checking method and system. The method comprises the following steps: monitoring the running of a BMC process; when an abnormal BMC process is monitored, making the server operating system aware of the information of the abnormal process according to a set communication principle; the server operating system sends a GDB debugging program corresponding to the BMC software to the BMC according to the information of the abnormal process, and notifies the BMC to execute the GDB debugging program; the running of the GDB debugging program is continuously monitored, when the BMC again has a process exception, the server operating system is made aware of the error stack information according to the set communication principle; the server operating system directly locates the abnormal process according to the error stack information and outputs prompt information. The server operating system sends a modified process, modifies a configuration start script, and after the BMC is restarted or powered off, a new process is called to complete error correction.

Description

Technical Field

[0001] This invention relates to the field of server firmware anomaly monitoring technology, specifically to a server firmware program error correction self-testing method and system. Background Technology

[0002] The Baseboard Management Controller (BMC) is a remote management controller for servers. It performs server control and information monitoring functions, serving as a platform for intuitively presenting server information. Server clients can access the BMC via web, ipmitool, SNMP tools, etc., to obtain server information. Essentially, the BMC is an embedded system; therefore, due to coding standards and shared code across multiple projects, application software may inevitably experience crashes and other anomalies during actual operation, leading to malfunctions. Identifying and eliminating potential program problems in embedded systems is challenging. Traditionally, tracing observed crashes, hangs, or other unplanned behaviors to their root causes requires significant manpower and time.

[0003] Developers typically use traditional methods to address program crashes, such as collecting logs, adding debug information, rolling back code to narrow down the scope of impact, and upgrading to a debug version to reproduce the issue. These methods require repeated troubleshooting and analysis. For problems that remain unresolved, the usual approach is to use GDB for debugging, leveraging the GDB tool to analyze core information and obtain error messages. However, the compiled program size for GDB debugging is significantly larger than the program without added debug information. In practical system use, due to limitations such as flash memory and memory size, it's not suitable to release a package containing debug information for embedded systems. Developers must first analyze the possible causes of the problem, add the corresponding information, recompile and upgrade, and then retrieve and analyze the information locally in the BMC (Browser Control Center).

[0004] Traditional program anomaly troubleshooting requires developers to spend a significant amount of time and effort investigating. Once an issue occurs, the scope is too broad, making it difficult to pinpoint the problem immediately, resulting in slow response times. It necessitates upgrading the debug version for verification and testing based on the analysis results. From the customer's perspective, they also dislike repeated upgrades to find the root cause of the problem, and even after the issue is identified and resolved, the BMC (Browser Management System) still needs to be upgraded. Summary of the Invention

[0005] Traditional troubleshooting methods for program anomalies require developers to spend a significant amount of time and effort investigating, as the scope of problems is often too broad to pinpoint immediately, resulting in slow response times. Furthermore, upgrading to a debug version is necessary based on analysis results for verification and testing. From a customer's perspective, repeated upgrades to find the root cause are undesirable, especially considering the need for a BMC upgrade even after the problem is identified and resolved. This invention provides a server firmware program error correction and self-inspection method and system.

[0006] In a first aspect, the present invention provides a server firmware program error correction self-test method, comprising the following steps:

[0007] Monitor the operation of the BMC process;

[0008] When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles.

[0009] The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program.

[0010] Continue to monitor the operation of the GDB debugger. When the BMC process exception occurs again, the server operating system will be informed of the error stack information according to the set communication principles.

[0011] The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message.

[0012] The modified process is distributed through the server operating system, and the startup script is modified. After the BMC restarts or is powered off, the new process is called to complete the error correction.

[0013] Preferably, the step of monitoring the execution of the BMC local process includes:

[0014] Check if BMC has a monitoring and management plugin;

[0015] If so, execute the monitoring and management plugin, and follow these steps: monitor the operation of the BMC process;

[0016] If not, the monitoring and management plugin will be deployed to BMC for execution. The execution steps are: monitor the operation of the BMC process.

[0017] Preferably, when the communication principle is set to master-slave mode communication, the step of enabling the server operating system to obtain information about the abnormal process according to the set communication principle when an abnormality of the BMC process is detected includes:

[0018] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

[0019] Preferably, when the communication principle is set to master-slave mode communication, the step of enabling the server operating system to obtain error stack information according to the set communication principle when the BMC experiences another process exception includes:

[0020] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process can be reproduced.

[0021] If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

[0022] Preferably, when the communication principle is set to peer-to-peer communication, the step of enabling the server operating system to obtain information about the abnormal process according to the set communication principle when an abnormality is detected in the BMC process includes:

[0023] When an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

[0024] Preferably, when the communication principle is set to peer-to-peer communication, the step of enabling the server operating system to obtain error stack information according to the set communication principle when the BMC experiences another process exception includes:

[0025] When the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

[0026] Preferably, the method further includes: setting the monitoring and management plugin to be automatically deleted after the BMC restarts.

[0027] Preferably, the steps of issuing a modified process through the server operating system, modifying the configuration startup script, and calling the new process to complete the error correction after the BMC restarts or loses power include:

[0028] Modify the abnormal process based on the output prompts;

[0029] The modified process is distributed to the monitoring and management plugin via the server operating system.

[0030] The monitoring and management plugin saves the received modified processes to flash memory;

[0031] Modify the startup script to call a new process to complete the error correction after the BMC restarts or is powered off.

[0032] Secondly, the technical solution of the present invention also provides a server firmware program error correction self-testing system, including a server operating system and a BMC;

[0033] The server operating system contains a plugin package; the plugin package includes the main program executed by the system, the monitoring and management plugin executed by BMC, and the GDB debugging program for the corresponding BMC software.

[0034] When performing a self-test to correct errors in the server firmware program, the monitoring and management plugin program is sent to the BMC for execution;

[0035] The monitoring and management plugin is used to monitor and manage the running status of the BMC process and report abnormal information;

[0036] The server operating system sends the corresponding GDB debugging program of the BMC software to the BMC in response to the reported abnormal information, and notifies the BMC monitoring and management plugin to abandon the original process and execute the GDB debugging program.

[0037] The monitoring and management plugin is used to continuously monitor the running status of the GDB debugger. When a process exception occurs again, the monitoring and management plugin will transmit the generated error stack information to the server operating system.

[0038] The server operating system is used to output abnormal process prompts based on the received error stack information; after modifying the abnormal process according to the prompts, the modified process is then issued through the server operating system.

[0039] The monitoring and management plugin saves the modified process file to flash, modifies the configuration startup script, and calls the new process to complete the error correction after the BMC restarts or is powered off.

[0040] Preferably, the monitoring and management plugin communicates with the server operating system via a master-slave KCS mode or a peer-to-peer mode via a LAN network.

[0041] When the communication principle is set to master-slave mode, the server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

[0042] Correspondingly, the server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process is reproduced.

[0043] If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

[0044] When the communication principle is set to peer-to-peer communication, when an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

[0045] Correspondingly, when the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

[0046] As can be seen from the above technical solution, this invention has the following advantages: Through plugin interaction between BMC and OS, programs containing GDB preprocessing debugging information can be directly sent to BMC. After collecting the information, the BMC plugin returns the error information to the OS administrator. Developers can directly use GDB to find the specific code errors in this version of BMC based on the information. After the problem is solved, the OS sends the modified correct program to BMC. BMC saves and modifies configuration files, and then executes the new process to ensure the program returns to normal. Through automatic interaction, sending, and execution between OS and BMC, the cause of the problem can be quickly and automatically located and uploaded. This greatly increases the speed of problem solving and eliminates the need for traditional methods of repeatedly upgrading to locate program crashes. It provides more efficient service to R&D personnel and avoids the version upgrade problem after the program crash problem is solved.

[0047] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects.

[0048] Therefore, it is evident that the present invention has outstanding substantive features and significant progress compared with the prior art, and the beneficial effects of its implementation are also obvious. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0051] Figure 2 This is a schematic block diagram of an apparatus according to an embodiment of the present invention. Detailed Implementation

[0052] Developers typically use traditional methods to address program crashes, such as collecting logs, adding debug information, rolling back code to narrow down the scope of impact, and upgrading to a debug version to reproduce the issue. These methods require repeated troubleshooting and analysis. For problems that remain unresolved, the usual approach is to use GDB for debugging, leveraging the GDB tool to analyze core information and obtain error messages. However, the compiled program size for GDB debugging is significantly larger than the program without added debug information. In practical system use, due to limitations such as flash memory and memory size, it's not suitable to release a package containing debug information for embedded systems. Developers must first analyze the possible causes of the problem, add the corresponding information, recompile and upgrade, and then retrieve and analyze the information locally in the BMC (Browser Control Center).

[0053] Traditional program anomaly troubleshooting requires developers to spend a significant amount of time and effort investigating. Once a problem occurs, the scope is too broad, making it difficult to pinpoint the issue immediately, resulting in slow response times. It necessitates upgrading the debug version for verification and testing based on the analysis results. From the customer's perspective, repeated upgrades to find the cause of the problem are undesirable, and even after the problem is located and resolved, the BMC still needs to be upgraded. To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0054] like Figure 1 As shown, this embodiment of the invention provides a server firmware program error correction self-test method, including the following steps:

[0055] Step 1: Monitor the operation of the BMC process;

[0056] Step 2: When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles.

[0057] Step 3: The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program.

[0058] Step 4: Continue to monitor the operation of the GDB debugger. When the BMC process exception occurs again, the server operating system will be informed of the error stack information according to the set communication principles.

[0059] Step 5: The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message;

[0060] The server operating system and BMC (Browser Management Center) implement automatic error correction through the distribution of monitoring and management plugins. These plugins monitor BMC system information and manage BMC process execution.

[0061] For abnormal BMC system processes, such as web processes, the server operating system automatically distributes the corresponding BMC software's GDB debugger and notifies the BMC monitoring and management plugin to execute the GDB debugger and collect relevant information. Error stack information from the GDB debugger is reported to the server operating system, allowing developers to directly locate the problem, eliminating the need for analysis, on-site troubleshooting, and repeated upgrades. The server operating system can also distribute a new, modified BMC process for BMC execution, resolving live network issues without requiring an upgrade.

[0062] This invention provides a server firmware program error correction self-test method, comprising the following steps:

[0063] S1: Check if BMC has a monitoring and management plugin;

[0064] If yes, proceed to step S2; if no, proceed to step S3.

[0065] S2: Execute the monitoring and management plugin to monitor the operation of the BMC process; proceed to step S4;

[0066] S3: Distribute the monitoring and management plugin to BMC to monitor the operation of BMC processes; proceed to step S4.

[0067] S4: When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles.

[0068] S5: The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program.

[0069] S6: Continue to monitor the operation of the GDB debugger. When the BMC experiences another process exception, communicate the error stack information to the server operating system according to the established communication principles.

[0070] S7: The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message;

[0071] The server operating system and BMC (Browser Management Center) implement automatic error correction through the distribution of monitoring and management plugins. These plugins monitor BMC system information and manage BMC process execution.

[0072] This invention provides a server firmware program error correction self-test method, comprising the following steps:

[0073] S1: Check if BMC has a monitoring and management plugin;

[0074] If yes, proceed to step S2; if no, proceed to step S3.

[0075] S2: Execute the monitoring and management plugin to monitor the operation of the BMC process; proceed to step S4;

[0076] S3: Distribute the monitoring and management plugin to BMC to monitor the operation of BMC processes; proceed to step S4.

[0077] S4: When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles.

[0078] S5: The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program.

[0079] S6: Continue to monitor the operation of the GDB debugger. When the BMC experiences another process exception, communicate the error stack information to the server operating system according to the established communication principles.

[0080] S7: The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message; administrators then modify the code of the abnormal process based on the prompt message.

[0081] S8: The modified process is distributed through the server operating system, the configuration startup script is modified, and the new process is called to complete the error correction after the BMC restarts or loses power.

[0082] It should be noted that step S8, which involves distributing the modified process through the server operating system, modifying the configuration startup script, and calling the new process to complete the error correction after the BMC restarts or loses power, includes the following steps:

[0083] S81: Modify the abnormal process based on the output prompt information;

[0084] S82: Distribute the modified process to the monitoring and management plugin via the server operating system;

[0085] S83: The monitoring and management plugin saves the received modified processes to flash;

[0086] S84: Modify the configuration startup script to call a new process to complete error correction after the BMC restarts or loses power. It should be noted that when the communication principle is set to master-slave mode, the steps for informing the server operating system of the abnormal process information according to the set communication principle when an abnormal BMC process is detected include:

[0087] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

[0088] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process can be reproduced.

[0089] If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

[0090] Furthermore, when the communication principle is set to peer-to-peer communication, the step of informing the server operating system of the abnormal process information according to the set communication principle when an abnormality is detected in the BMC process includes:

[0091] When an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

[0092] When the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

[0093] Specifically, the plugin package contains the main program executed by the system, the monitoring and management plugin executed by BMC, and the corresponding BMC software's GDB debugger version code. It consists of the main debug process files generated by GDB, such as the BMC main process and web process files.

[0094] Monitoring and Management Plugin: The monitoring and management program executed by the BMC system, responsible for monitoring and managing the BMC system process status and reporting abnormal information;

[0095] 1. The system administrator distributes the monitoring and management plugin program to the BMC for execution. The distribution method can be either the KCS master-slave mode or a peer-to-peer mode via a LAN network. Both can be implemented using existing technologies.

[0096] 2. The BMC local execution monitoring and management plugin program detects the running status of local processes.

[0097] 3. When the BMC program crashes due to an exception, the OS system can obtain information about the abnormal program based on the master-slave and peer-to-peer communication principles.

[0098] 4. The server OS sends the corresponding GDB debugging program process to the BMC for the reported abnormal information, and notifies the BMC monitoring and management program to abandon the original process and execute this debug version process.

[0099] 5. The BMC monitoring and management plugin continuously records logs and other relevant information. When a process crash occurs again, BMC will transmit the generated core dump information and collected information to the OS.

[0100] 6. The OS notifies the system administrator to use the core dump's EPC and RA values, along with memory mapping addresses from maps and other collected information, to directly locate the specific error code using GDB tools or other available information.

[0101] 7. After the problem is resolved, the modified process is distributed through the OS. The BMC management plugin saves this process file to flash, modifies the startup script, and calls the new process after the BMC restarts or is powered off. The problem-solving process does not require an upgrade, achieving the purpose of automatic error correction and self-checking.

[0102] This invention provides a server firmware program error correction self-test method, comprising the following steps:

[0103] SS1: Distribute the monitoring and management plugin to BMC to monitor the operation of BMC processes; proceed to step SS3.

[0104] SS2: When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles.

[0105] SS3: The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program.

[0106] SS4: Continue to monitor the operation of the GDB debugger. When the BMC experiences another process exception, communicate the error stack information to the server operating system according to the established communication principles.

[0107] SS5: The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message; administrators then modify the code of the abnormal process based on the prompt message.

[0108] SS6: The modified process is distributed through the server operating system, the configuration startup script is modified, and the new process is called to complete the error correction after the BMC restarts or loses power.

[0109] It should be noted that when the communication principle is set to master-slave mode, the steps for informing the server operating system of the abnormal process information according to the set communication principle when an abnormality is detected in the BMC process include:

[0110] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

[0111] The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process can be reproduced.

[0112] If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

[0113] Furthermore, when the communication principle is set to peer-to-peer communication, the step of informing the server operating system of the abnormal process information according to the set communication principle when an abnormality of the BMC process is detected includes:

[0114] When an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

[0115] When the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

[0116] It should be noted that in this embodiment, the monitoring and management plugin is set to be automatically deleted after the BMC restarts. Each time a test is performed, the server operating system sends the monitoring and management plugin of the plugin package to the BMC for execution.

[0117] It should be further explained that the steps involved in distributing the modified process through the server operating system, modifying the configuration startup script, and then calling the new process to complete the error correction after a BMC restart or power outage include:

[0118] Modify the abnormal process based on the output prompts;

[0119] The modified process is distributed to the monitoring and management plugin via the server operating system.

[0120] The monitoring and management plugin saves the received modified processes to flash memory;

[0121] Modify the startup script to call a new process to complete the error correction after the BMC restarts or is powered off.

[0122] This invention also provides a server firmware program error correction self-test system, including a server operating system and a BMC;

[0123] The server operating system contains a plugin package; the plugin package includes the main program executed by the system, the monitoring and management plugin executed by BMC, and the GDB debugging program for the corresponding BMC software.

[0124] When performing a self-test to correct errors in the server firmware program, the monitoring and management plugin program is sent to the BMC for execution;

[0125] The monitoring and management plugin is used to monitor and manage the running status of the BMC process and report abnormal information;

[0126] The server operating system sends the corresponding GDB debugging program of the BMC software to the BMC in response to the reported abnormal information, and notifies the BMC monitoring and management plugin to abandon the original process and execute the GDB debugging program.

[0127] The monitoring and management plugin is used to continuously monitor the running status of the GDB debugger. When a process exception occurs again, the monitoring and management plugin will transmit the generated error stack information to the server operating system.

[0128] The server operating system is used to output abnormal process prompts based on the received error stack information; after modifying the abnormal process according to the prompts, the modified process is then issued through the server operating system.

[0129] The monitoring and management plugin saves the modified process file to flash, modifies the configuration startup script, and calls the new process to complete the error correction after the BMC restarts or is powered off.

[0130] It should be noted that, as Figure 2 As shown, the monitoring and management plugin communicates with the server operating system (OS) via a master-slave KCS mode or a peer-to-peer mode via a LAN network.

[0131] When the communication principle is set to master-slave mode, the server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

[0132] Correspondingly, the server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process is reproduced.

[0133] If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

[0134] When the communication principle is set to peer-to-peer communication, when an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

[0135] Correspondingly, when the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

[0136] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the invention should also be covered within the protection scope of the invention. Therefore, the protection scope of the invention should be determined by the scope of the claims.

Claims

1. A self-test method for error correction in server firmware programs, characterized in that, Includes the following steps: Monitor the operation of the BMC process; When an abnormality is detected in the BMC process, the server operating system is informed of the abnormal process information according to the set communication principles. The set communication principles are either the master-slave KCS mode or a peer-to-peer mode via a LAN network. The server operating system sends the corresponding BMC software's GDB debugging program to the BMC based on the information of the abnormal process, and notifies the BMC to execute the GDB debugging program. Continue to monitor the operation of the GDB debugger. When the BMC process exception occurs again, the server operating system will be informed of the error stack information according to the set communication principles. The server operating system directly locates the abnormal process based on the error stack information and outputs a prompt message. Before monitoring the execution of BMC local processes, the following steps are included: Check if BMC has a monitoring and management plugin; If so, execute the monitoring and management plugin, and follow these steps: monitor the operation of the BMC process; If not, the monitoring and management plugin will be deployed to BMC for execution. The execution steps are: monitor the operation of the BMC process.

2. The server firmware program error correction self-test method according to claim 1, characterized in that, When the communication principle is set as master-slave mode communication, the steps for informing the server operating system of the abnormal process information according to the set communication principle when an abnormality of the BMC process is detected include: The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to obtain information about abnormal processes.

3. The server firmware program error correction self-test method according to claim 2, characterized in that, When the communication principle is set to master-slave mode communication, the steps for enabling the server operating system to obtain error stack information according to the set communication principle when the BMC experiences another process exception include: The server operating system periodically queries the running status of the BMC process monitored by the monitoring and management plugin to determine whether the information of the abnormal process can be reproduced. If the abnormal process information is reproduced, obtain the error stack information generated by the monitoring and management plugin.

4. The server firmware program error correction self-test method according to claim 1, characterized in that, When the communication principle is set to peer-to-peer communication, the steps for informing the server operating system of the abnormal process information according to the set communication principle when an abnormality is detected in the BMC process include: When an abnormality is detected in the BMC process, the abnormal process information is proactively reported to the server operating system.

5. The server firmware program error correction self-test method according to claim 4, characterized in that, When the communication principle is set to peer-to-peer communication, the steps for enabling the server operating system to obtain error stack information according to the set communication principle when the BMC experiences another process exception include: When the BMC experiences another process exception, it collects and reports the error stack information to the server operating system.

6. The server firmware program error correction self-test method according to claim 3 or 5, characterized in that, The method also includes: The modified process is distributed through the server operating system, and the startup script is modified. After the BMC restarts or is powered off, the new process is called to complete the error correction.

7. The server firmware program error correction self-test method according to claim 6, characterized in that, The steps involved in correcting errors by issuing a modified process through the server operating system, modifying the configuration startup script, and calling the new process after a BMC restart or power outage include: Modify the abnormal process based on the output prompts; The modified process is distributed to the monitoring and management plugin via the server operating system. The monitoring and management plugin saves the received modified processes to flash memory; Modify the startup script to call a new process to complete the error correction after the BMC restarts or is powered off.

8. A server firmware program error correction self-testing system, characterized in that, Including the server operating system and BMC; The server operating system contains a plugin package; the plugin package includes the main program executed by the system, the monitoring and management plugin executed by BMC, and the GDB debugging program for the corresponding BMC software. When performing a self-test to correct errors in the server firmware program, the monitoring and management plugin program is sent to the BMC for execution; The monitoring and management plugin is used to monitor and manage the running status of the BMC process and report abnormal information; The server operating system sends the corresponding GDB debugging program of the BMC software to the BMC in response to the reported abnormal information, and notifies the BMC monitoring and management plugin to abandon the original process and execute the GDB debugging program. The monitoring and management plugin is used to continuously monitor the running status of the GDB debugger. When a process exception occurs again, the monitoring and management plugin will transmit the generated error stack information to the server operating system. The server operating system is used to output abnormal process prompts based on the received error stack information; The monitoring and management plugin communicates with the server operating system via a master-slave KCS mode or a peer-to-peer mode via a LAN network.

Images