Fault monitoring method, device and equipment and readable storage medium
By collaborating with the out-of-band manager and the system management unit, server fault information can be automatically obtained using the remote management register window. This solves the problem of needing to manually restart the server to obtain fault logs in existing technologies, and achieves efficient fault location without environmental disruption.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-27
- Publication Date
- 2026-03-10
AI Technical Summary
In existing technologies, when a server crashes due to a hardware failure during the BIOS startup phase, it cannot transmit fault information to the BMC in real time. Maintenance personnel need to manually restart the server to obtain fault logs, resulting in high maintenance costs and low reliability.
Through collaboration between the out-of-band manager and the system management unit, monitoring requests and fault codes are written to the remote management register window to automatically identify and obtain server fault information. This includes writing monitoring requests to the remote management register window, receiving alarm information, reading and analyzing fault codes, and generating and writing a second fault code to obtain fault information.
Fault logs can be obtained without disrupting the faulty environment, reducing server maintenance costs and improving fault location efficiency.
Smart Images
Figure CN121636290A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of switches, and in particular to a fault monitoring method, apparatus, device, and readable storage medium. Background Technology
[0002] The BIOS is a crucial program for the storage server's Basic Input / Output System. During the boot phase before the server's BIOS setup (such as the Early POS and POST phases), the BIOS performs self-tests on hardware components such as the CPU and memory. If a CPU or memory failure occurs during this process, it can cause the server to crash.
[0003] If the server crashes, the BIOS cannot actively transmit fault information to the BMC in real time. It requires maintenance personnel to physically debug the system, restart the server, enter the BIOS setup, modify the debug mode, save the changes, and then restart the server a second time in order to capture the fault logs. There is also a risk that the fault cannot be reproduced after restarting. Summary of the Invention
[0004] In view of this, this specification provides a fault monitoring method, apparatus, electronic device, and readable storage medium to improve the problems mentioned above, such as the need to disrupt the fault environment, high maintenance costs, and low reliability in obtaining fault logs.
[0005] Specifically, the technical solution is as follows: This specification provides a fault monitoring method applied to an out-of-band manager, wherein the out-of-band manager is the server's out-of-band manager, and the method includes: A monitoring request is written to the remote management register window; the monitoring request is read by the system management unit to trigger the system management unit to read and analyze the first fault code stored in the first address of the remote management register window; the first fault code is associated with the server's fault information; Receive alarm information; the alarm information is a level signal generated by the output terminal of the alarm signal after the system management unit detects a change in the first fault code; In response to the alarm information, the system reads the second fault code in the remote management register window to obtain server fault information; the second fault code includes server fault information, which is generated by the system management unit based on changes in the first fault code; the second fault code is written by the system management unit to the second address in the remote management register window, which is an address readable by the out-of-band manager in the remote management register window.
[0006] Furthermore, writing the monitoring request into the remote management register window includes: writing the monitoring request into the remote management register window at preset time intervals; the preset time intervals are obtained from user settings.
[0007] This specification also provides a fault monitoring method applied to a system management unit, the method comprising: Access the remote management register window to read the monitoring request, and read and analyze the first fault code stored in the first address of the remote management register window according to the monitoring request; the first fault code is associated with the server's fault information; the monitoring request is written to the remote management register window by the out-of-band manager; Upon detecting a change in the first fault code, an alarm message is sent to the out-of-band manager, and a second fault code is written to the second address of the remote management register window; the second fault code is used to carry the fault information provided by the first fault code; the second address is an address readable by the out-of-band manager in the remote management register window.
[0008] Furthermore, the step of identifying a change in the first fault code and writing a second fault code to a second address of the remote management register window further includes: writing the second fault code to a log file in the out-of-band storage space.
[0009] This specification also provides a fault monitoring device, the device comprising: The out-of-band management module writes monitoring requests into the remote management register window; in response to alarm information, it reads the second fault code in the remote management register window to obtain server fault information; The system management unit is configured to read the monitoring request to trigger the system management unit to read and analyze the first fault code stored in the remote management register window; upon detecting a change in the first fault code, send an alarm message to the out-of-band manager and write the second fault code into the remote management register window; the first fault code is associated with server fault information, the second fault code includes server fault information, the fault information is generated by the system management unit based on the change in the first fault code, and the second fault code is written by the system management unit to a second address in the remote management register window.
[0010] Furthermore, the out-of-band management module includes: writing monitoring requests into the remote management register window at preset time intervals; the preset time intervals are obtained from user settings.
[0011] Furthermore, the system management unit also includes: writing the second fault code into a log file in the out-of-band storage space.
[0012] This specification also provides an electronic device, including a processor and a readable storage medium storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the aforementioned fault monitoring method.
[0013] This specification also provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned fault monitoring method.
[0014] The technical solutions provided in this specification offer at least the following beneficial effects: Fault logs can be obtained without disrupting the faulty environment, reducing server maintenance costs and improving fault location efficiency. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments of this specification or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this specification.
[0016] Figure 1 This is a flowchart of a fault monitoring method in one embodiment of this specification; Figure 2 This is a flowchart of a fault monitoring method in one embodiment of this specification; Figure 3 This is a flowchart of a fault monitoring method in one embodiment of this specification; Figure 4 This is a structural diagram of a fault monitoring device according to one embodiment of this specification; Figure 5 This is a hardware structure diagram of an electronic device according to one embodiment of this specification. Detailed Implementation
[0017] The terminology used in the embodiments described herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this specification. The singular forms “a,” “described,” and “the” as used in this specification and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.
[0018] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."
[0019] In server system architecture, the Basic Input / Output System (BIOS), as a low-level program embedded in the motherboard ROM chip, undertakes key functions such as hardware initialization, system configuration, and operating system booting. The basic hardware detection and initialization operations performed by the BIOS during server startup provide the necessary runtime environment for the subsequent normal loading of the operating system.
[0020] During the boot phase before server BIOS setup (such as Early POS and POST phases), the server performs a self-test. If a hardware failure such as a CPU or memory failure occurs during this time, it can cause the server to crash. In this case, maintenance personnel need to manually restart the server, enter the BIOS setup, modify the debug mode, save the changes, and then restart it a second time to capture the fault logs. This method has high maintenance costs and carries the risk that the problem cannot be reproduced after a restart.
[0021] In view of this, this specification provides a fault monitoring method, apparatus, electronic device, and readable storage medium to improve the problems mentioned above, such as the need to disrupt the fault environment, high maintenance costs, and low reliability in obtaining fault logs.
[0022] Specifically, the technical solution is described below.
[0023] In one embodiment, this specification provides a fault monitoring method applied to an out-of-band manager, wherein the out-of-band manager is the out-of-band manager of a server, the method comprising: A monitoring request is written to the remote management register window; the monitoring request is read by the system management unit to trigger the system management unit to read and analyze the first fault code stored in the first address of the remote management register window; the first fault code is associated with the server's fault information; Receive alarm information; the alarm information is a level signal generated by the output terminal of the alarm signal after the system management unit detects a change in the first fault code; In response to the alarm information, the system reads the second fault code in the remote management register window to obtain server fault information; the second fault code includes server fault information, which is generated by the system management unit based on changes in the first fault code; the second fault code is written by the system management unit to the second address in the remote management register window, which is an address readable by the out-of-band manager in the remote management register window.
[0024] like Figure 1 As shown, taking an AMD-based server as an example, one implementation includes the following steps: Step S11: Write the monitoring request to the remote management register window.
[0025] In one embodiment, the BMC (Baseboard Management Controller) is used as an example. As an out-of-band manager, the BMC writes monitoring requests to the RMI (Remote Management Interface) register via the APML (Advanced Platform Management Link) interface. The RMI register is encapsulated inside the CPU and can be used by the BMC and SMU (System Management Unit) to exchange commands and data.
[0026] In one embodiment, a monitoring request is used to be read by a system management unit to trigger the system management unit to read and analyze a first fault code stored in a first address of the remote management register window; the first fault code is associated with server fault information.
[0027] In one embodiment, writing the monitoring request to the remote management register window includes: writing the monitoring request to the remote management register window at preset time intervals; the preset time intervals are obtained from user settings.
[0028] Step S12: Receive alarm information.
[0029] The alarm message is sent by the system management unit upon detecting a change in the first fault code. The out-of-band management bus structure based on the SMBus / APM protocol is a master-slave model. The out-of-band manager, as the master device, can only obtain data from the slave device by initiating access requests; the system management unit, as the slave device, cannot actively push data to the out-of-band manager. The BMC receives the alarm message sent by the SMU upon detecting a fault. The alarm message informs the BMC that an event has occurred, triggering the BMC to handle the event, such as reading data stored in the second address of the RMI register. Step S13: In response to the alarm message, the second fault code in the remote management register window is read to obtain server fault information. The second fault code includes server fault information, which is generated by the system management unit based on the change in the first fault code. The second fault code is written by the system management unit to the second address of the remote management register window, which is a readable address of the out-of-band manager in the remote management register window.
[0030] In one embodiment, after the SMU obtains a first fault code from the first address of the RMI register, it identifies a fault. Based on the fault information carried by the first fault code, the SMU updates the data stored in the RMI register, that is, it writes a second fault code to the second address of the RMI register. The second address of the RMI register is a readable address by the BMC, and the second fault code carries fault information.
[0031] This manual also provides a fault monitoring method, such as Figure 2 As shown, this method is applied to the system control unit and includes the following steps: Step S21: Access the remote management register window to read the monitoring request, and read and analyze the first fault code stored in the first address of the remote management register window according to the monitoring request.
[0032] The first fault code is associated with the server's fault information; the monitoring request is written to the remote management register window by the out-of-band manager.
[0033] In one embodiment, the SMU reads the monitoring request written by the BMC from the RMI register and reads the first fault code from the RMI register according to the monitoring request.
[0034] Step S22: Upon detecting a change in the first fault code, an alarm message is sent to the out-of-band manager, and a second fault code is written to the second address of the remote management register window.
[0035] The second fault code is used to carry the fault information provided by the first fault code; the second address is an address readable by the out-of-band manager in the remote management register window.
[0036] In one embodiment, the SMU detects a change in a first fault code, indicating that a fault has occurred. In response to the detection, the SMU sends an alarm message to the BMC and writes a second fault code to the RMI register for the BMC to read.
[0037] In one embodiment, the step of identifying a change in the first fault code, writing alarm information to the remote management register window, and writing a second fault code to a second address of the remote management register window further includes writing the second fault code to a log file in out-of-band storage space.
[0038] In one embodiment, the log file is rewritable. After a system reboot, the log file is cleared and can be written to again for use in a new round of fault monitoring. When a second fault code is written to the log file, its format may be the same as or different from when it was written to the RMI register.
[0039] like Figure 3 As shown, taking an AMD-based server as an example, the BMC actively writes a monitoring request to the RMI register, enabling the monitoring request to be read by the SMU.
[0040] In one embodiment, the BMC writes monitoring requests to the RMI register at a user-defined frequency, such as at intervals of 50ms, 100ms, or 200ms. That is, the BMC polls the SMU via the RMI register.
[0041] In one embodiment, the BMC initiates a monitoring request by writing the request to the writable register index (such as SBRMI_x3, SBRMI_x5) of the SBRMI controller via the APML interface. The writable register index of the SBRMI controller can be mapped to the corresponding physical address in the RMI register.
[0042] After the monitoring request is read by the SMU, an IsrSbrmiSwInt interrupt is triggered on the SMU, notifying the SMU that a request needs to be processed. Upon receiving the IsrSbrmiSwInt interrupt, the SMU processes and parses the specific content of the monitoring request.
[0043] In one embodiment, after analyzing the monitoring request, the SMU retrieves the first fault code specified in the request from the RMI register. In practical scenarios, retrieving the first fault code does not increase BIOS boot time.
[0044] The first fault code carries specific information about the server crash and can indicate the reason for the server crash.
[0045] In one embodiment, the SMU obtains the first fault code from SBRMI_x39~x3C, and the obtained first fault code is a 32-bit parameter Data_In[31:0]. Among them, Bit[31:28] describes the fault level (e.g., 0x1 indicates a fault requiring warning, 0x2 indicates a serious fault); Bit[27:20] describes the hardware type (e.g., 0x01 indicates a fault occurring in the CPU, 0x02 indicates a fault occurring in memory); Bit[19:0] describes the detailed fault cause (e.g., describing the CPU core number, memory address, etc.).
[0046] If the first fault code changes, i.e., the first fault code indicates that a fault has occurred, the SMU sends an alarm to the BMC and writes the second fault code into the RMI register.
[0047] In one embodiment, the SMU drives the APML interface logic (setting SBRMI::Status[SwAlertSts] to 1) to generate the ALERT_L signal, notifying the BMC that the request has been processed.
[0048] The SMU writes a second fault code to the RMI register. This second fault code carries specific information about the server crash and can indicate the cause of the crash. In one embodiment, the SMU updates the data stored in RMI_x36 / 0x19 / 0x1B, where RMI_x36 / 0x19 / 0x1B is a BMC-readable address in the RMI register. If the BMC reads that the data in RMI_x36 / 0x19 / 0x1B has changed, it considers the server to have crashed and reports an error log.
[0049] For example, register 0x19 represents the GOP (Graphics Output Protocol Link) status, and 0x1B represents the PRR (Power Rail Regulation) status. When the data stored in 0x19 / 0x1B becomes non-zero, it indicates a fault. For instance, data in register 0x19 becoming 0x0001 might indicate a training failure of the relevant link; data in register 0x19 becoming 0x0002 might indicate a memory initialization timeout; data in register 0x1B becoming 0x8000 might indicate undervoltage of the memory power rail; data in register 0x1B becoming 0x4000 might indicate CPU VCore overcurrent, and so on. RMI_x36 becoming 0x02 indicates that the SMU has completed the request processing logic and identified the cause of the fault.
[0050] In one embodiment, the SMU also writes a second fault code to a log file in out-of-band storage. For example, the fault code is written to the APMLMailboxFile.txt file. This writing process is performed via APML and can be read by the user. In one embodiment, this file is refreshed upon server restart; that is, the log file in out-of-band storage is cleared upon restart for use in a new round of fault monitoring. The format of the second fault code written to the log file can be the same as or different from that written to the RMI register.
[0051] If the first fault code does not change, the SMU does not send an alarm message to the BMC. In one embodiment, the BMC continues to poll the SMU and repeats the above steps.
[0052] The fault monitoring methods provided in this manual ensure the acquisition of fault logs without disrupting the fault environment. Furthermore, they eliminate the need for manual maintenance to physically restart the server, reducing server maintenance costs and improving fault location efficiency.
[0053] This manual provides a fault monitoring device, such as... Figure 4 As shown, the device includes: The out-of-band management module 401 writes a monitoring request into the remote management register window; in response to an alarm message, it reads the second fault code in the remote management register window to obtain server fault information. System management unit 402 is used to read the monitoring request to trigger the system management unit to read and analyze the first fault code stored in the remote management register window; identify a change in the first fault code, send an alarm message to the out-of-band manager, and write the second fault code into the remote management register window; the first fault code is associated with the server's fault information, the second fault code includes the server's fault information, the fault information is generated by the system management unit based on the change in the first fault code, and the second fault code is written by the system management unit to a second address in the remote management register window.
[0054] In one embodiment, the fault monitoring device further includes: the out-of-band management module includes writing monitoring requests into the remote management register window at preset time intervals; the preset time intervals are obtained from user settings.
[0055] In one embodiment, the fault monitoring device further includes: the system management unit further includes: writing the second fault code into a log file in the out-of-band storage space.
[0056] The specific implementation of the fault monitoring device is the same as or similar to the corresponding fault monitoring method, and will not be described in detail here.
[0057] In one embodiment, this specification provides an electronic device 501, including a processor 502 and a machine-readable storage medium 503. The storage medium stores machine-executable instructions 504 that can be executed by the processor. The processor executes the machine-executable instructions to implement the aforementioned fault monitoring method. From a hardware perspective, a hardware architecture diagram can be found... Figure 5 As shown.
[0058] In one embodiment, this specification provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned fault monitoring method.
[0059] Here, a readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.
[0060] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.
[0061] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.
[0062] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0063] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments thereof. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0064] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0065] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0066] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0067] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.
Claims
1. A method of fault monitoring, characterized by, The method is applied to an out-of-band manager, which is an out-of-band manager of a server, and comprises the following steps: writing a monitoring request into a remote management register window; the monitoring request is used to be read by a system management unit to trigger the system management unit to read and analyze a first fault code stored in a first address of the remote management register window; the first fault code is associated with fault information of the server; receiving alarm information; the alarm information is a level signal generated by an output end of an alarm signal driven by the system management unit after the system management unit identifies that the first fault code has changed; in response to the alarm information, reading a second fault code in the remote management register window to obtain fault information of the server; the second fault code comprises the fault information of the server, and the fault information is generated by the system management unit according to the change of the first fault code; the second fault code is written into a second address of the remote management register window by the system management unit, and the second address is an address readable by the out-of-band manager in the remote management register window.
2. The method of claim 1, wherein, The step of writing the monitoring request into the remote management register window comprises the following steps: writing the monitoring request into the remote management register window at a preset time interval; the preset time interval is obtained from a user setting.
3. A method of fault monitoring, characterized by, The method is applied to a system management unit, and comprises the following steps: accessing the remote management register window to read a monitoring request, and reading and analyzing a first fault code stored in a first address of the remote management register window according to the monitoring request; the first fault code is associated with fault information of the server; the monitoring request is written into the remote management register window by an out-of-band manager; after identifying that the first fault code has changed, sending alarm information to the out-of-band manager, and writing a second fault code into a second address of the remote management register window; the second fault code is used to carry fault information provided by the first fault code; and the second address is an address readable by the out-of-band manager in the remote management register window.
4. The method of claim 3, wherein, The step of identifying that the first fault code has changed, writing alarm information into the remote management register window, and writing a second fault code into a second address of the remote management register window further comprises the following steps: writing the second fault code into a log file in an out-of-band storage space.
5. A fault monitoring device, characterized by The device comprises: an out-of-band management module, which writes a monitoring request into a remote management register window, and reads a second fault code in the remote management register window to obtain fault information of a server in response to alarm information; a system management unit, which reads the monitoring request to trigger the system management unit to read and analyze a first fault code stored in the remote management register window, identifies that the first fault code has changed, sends alarm information to the out-of-band manager, and writes the second fault code into the remote management register window; the first fault code is associated with fault information of the server, the second fault code comprises the fault information of the server, the fault information is generated by the system management unit according to the change of the first fault code, and the second fault code is written into a second address of the remote management register window by the system management unit.
6. The apparatus of claim 5, wherein, The out-of-band management module is further configured to perform: writing the monitoring request into the remote management register window according to a preset time interval; the preset time interval is obtained from a user setting.
7. The apparatus of claim 5, wherein, The system management unit is further configured to perform: writing the second fault code into a log file in an out-of-band storage space.
8. An electronic device, comprising: comprising: a processor and a readable storage medium, the readable storage medium storing machine executable instructions capable of being executed by the processor, the processor executing the machine executable instructions to implement the method of any one of claims 1-4.
9. A readable storage medium, characterized by, The readable storage medium stores machine executable instructions, and when the machine executable instructions are called and executed by a processor, the machine executable instructions cause the processor to implement the method of any one of claims 1-4.