A method, apparatus and storage medium for collecting memory fault information

Abstract

This application provides a method, apparatus, and storage medium for collecting memory fault information, relating to the field of data storage, and capable of preventing missed fault information reports. The method is applied to a server, which includes memory, an out-of-band controller, and an in-band controller. The method includes: during server operation, the in-band controller performs fault detection on the memory and sends the detected fault information to the out-of-band controller; during server restart, if the server's startup mode is a cold restart, the in-band controller determines whether new fault information exists in the memory, wherein the new fault information is fault information not stored in the out-of-band controller; if new fault information exists in the memory, the in-band controller sends the new fault information to the out-of-band controller.

Description

Technical Field

[0001] This application relates to the field of data storage, and in particular to a method, apparatus and storage medium for collecting memory fault information. Background Technology

[0002] As internet services become increasingly complex, the failure rate of memory in servers is also rising. Therefore, how to collect memory failure information has become a key focus in this field.

[0003] Existing methods for collecting memory fault information cannot collect fault information that occurred in the memory before the server where the memory is located underwent a cold restart, resulting in the omission of some fault information that occurred in the memory. Summary of the Invention

[0004] This application provides a method, apparatus, and storage medium for collecting memory fault information, which can prevent the omission of fault information.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a method for collecting memory fault information. This method is applied to a server, which includes memory, an out-of-band controller, and an in-band controller. The method includes: during server operation, the in-band controller performs fault detection on the memory and sends the detected fault information to the out-of-band controller; during server restart, if the server's startup mode is a cold restart, the in-band controller determines whether there is any newly added fault information in the memory, wherein the newly added fault information is fault information not stored in the out-of-band controller; if there is newly added fault information in the memory, the in-band controller sends the newly added fault information to the out-of-band controller.

[0007] The memory fault information collection method provided in this application embodiment involves the in-band controller detecting memory faults during server operation and sending the detected fault information to the out-of-band controller. During server restart, if the server's startup mode is a cold restart, the in-band controller determines the newly added fault information in the memory and sends the newly added fault information to the out-of-band controller so that the out-of-band controller can collect the newly added fault information, thereby avoiding missed fault information reports.

[0008] In one possible implementation, the aforementioned memory includes persistent memory (DCPMM).

[0009] By identifying the fault information in the server as DCPMM, even if the server experiences a cold restart, the fault information stored in memory will not be reset, thus ensuring that new fault information is not lost. This allows the in-band controller to identify new fault information from the DCPMM and send it to the out-of-band controller so that the out-of-band controller can collect the new fault information, thereby solving the problem of avoiding missed fault information.

[0010] In one possible implementation, during the server restart process, if the server's startup mode is a cold restart, the in-band controller determines whether there is any new fault information in the memory. This includes: during the server restart process, if the server's startup mode is a cold restart and the asynchronous refresh ADR function of the DCPMM is enabled, the in-band controller determines whether there is any new fault information in the memory.

[0011] The memory fault information collection method provided in this application embodiment, during server restart, if the server's startup mode is cold restart and the asynchronous refresh ADR function of the aforementioned DCPMM is enabled, then the in-band controller determines the newly added fault information in the memory and sends the newly added fault information to the out-of-band controller so that the out-of-band controller can collect the newly added fault information; thereby avoiding the in-band controller executing the memory fault information collection method provided in this application embodiment when the server experiences a cold restart (at this time, the cold restart that occurs is a normal cold restart, not a cold restart caused by a crash fault) when the ADR function of DCPMM is disabled, thus saving the computing resources of the in-band controller.

[0012] In one possible implementation, if the ADR function of DCPMM is disabled during server restart and the server restart type is a crash restart, the in-band controller determines whether there is any new fault information in memory.

[0013] The memory fault information collection method provided in this application embodiment, during server restart, if the ADR function of DCPMM is turned off (i.e., during a hot restart after a crash), the in-band controller determines the newly added fault information in the memory and sends the newly added fault information to the out-of-band controller so that the out-of-band controller can collect the newly added fault information, thereby avoiding the server from missing fault information during a hot restart after a crash.

[0014] In one possible implementation, during server restart, the method further includes: the in-band controller obtaining the ADR function's on / off status from the DCPMM; the ADR function's on / off status includes being on or off.

[0015] In one possible implementation, the fault information includes a fault identifier, which indicates the chronological order in which memory faults occur; the memory fault is a fault that has occurred in the server's memory.

[0016] In one possible implementation, during server operation, the in-band controller performs memory fault detection and sends the detected fault information to the out-of-band controller; this includes: during server operation, when a non-crash fault occurs in the memory, the in-band controller sends the non-crash fault information to the out-of-band controller, so that the out-of-band controller stores the fault identifier in the non-crash fault information.

[0017] The memory fault information collection method provided in this application embodiment is that during the server operation phase, when a non-crash fault occurs in the memory, the in-band controller directly sends the non-crash fault information to the out-of-band controller, so that the out-of-band controller can complete the collection of the non-crash fault, thereby improving the efficiency of the out-of-band controller in collecting memory faults.

[0018] In one possible implementation, the in-band controller determines whether new fault information is stored in the memory by: the in-band controller obtaining a first fault identifier from the out-of-band controller; wherein the first fault identifier is a fault identifier of a memory fault stored in the out-of-band controller; the in-band controller obtaining a second fault identifier from the memory's fault register; wherein the second fault identifier is a fault identifier of a memory fault that has already occurred; and the in-band controller determining whether new fault information is stored in the memory based on the first fault identifier and the second fault identifier.

[0019] Because the DCPMM is a non-volatile memory, the fault information stored in the DCPMM's fault register will not be lost regardless of whether the server experiences a cold restart, a warm restart, or is running. The aforementioned second fault identifier is obtained from this fault register, so even if the server experiences a cold restart, the second fault identifier can still be retrieved from it. Then, based on this second fault identifier and the first fault identifier stored in the out-of-band controller, new fault information is determined, and the out-of-band controller collects this new fault information; thus solving the problem of preventing missed fault reports.

[0020] In one possible implementation, the first fault identifier is the fault identifier of the memory fault that occurred latest among the memory faults backed up by the out-of-band controller; the second fault identifier is the fault identifier of the memory fault that occurred latest in memory.

[0021] Compared to the approach of storing all collected memory fault identification information in the out-of-band controller, the memory fault information collection method provided in this application embodiment stores the fault identification of the last memory fault collected by the out-of-band controller in the out-of-band controller, thereby reducing the occupation of the storage resources of the out-of-band controller.

[0022] Secondly, a memory fault information collection device is provided. In one example, the device may be an in-band controller. The device includes: a detection unit, a transceiver unit, and a determination unit; the detection unit is used to perform memory fault detection during server operation; the transceiver unit is used to send the detected fault information to an out-of-band controller; the determination unit is used to determine whether there is any new fault information in the memory during server restart, if the server's startup mode is a cold restart, wherein the new fault information is fault information not stored in the out-of-band controller; the transceiver unit is also used to send the new fault information to the out-of-band controller if there is new fault information in the memory.

[0023] In one possible implementation, the aforementioned memory includes persistent memory (DCPMM).

[0024] In one possible implementation, the aforementioned determining unit is specifically used to determine whether there is any new fault information stored in memory during the server restart process, if the server's startup mode is a cold restart and the asynchronous refresh ADR function of DCPMM is enabled.

[0025] In one possible implementation, the aforementioned determining unit is further configured to determine whether there is any new fault information stored in memory during the server restart process if the ADR function of DCPMM is disabled and the server restart type is a crash restart.

[0026] In one possible implementation, the aforementioned transceiver unit is used to obtain the ADR function's on / off status from the DCPMM during server restart; the ADR function's on / off status includes whether it is on or off.

[0027] In one possible implementation, the fault information includes a fault identifier, which indicates the chronological order in which memory faults occurred; the memory fault refers to a fault that has occurred in the server's memory.

[0028] In one possible implementation, the transceiver unit is used to send non-crash fault information to the out-of-band controller when a non-crash fault occurs in the memory during server operation, so that the out-of-band controller stores the fault identifier in the non-crash fault information.

[0029] In one possible implementation, the transceiver unit is used to obtain a first fault identifier from the out-of-band controller; wherein the first fault identifier is a fault identifier of a memory fault stored in the out-of-band controller; the transceiver unit is also used to obtain a second fault identifier from the memory fault register; wherein the second fault identifier is a fault identifier of a memory fault that has occurred in the memory; the determining unit is used to determine whether there is new fault information stored in the memory based on the first fault identifier and the second fault identifier.

[0030] In one possible implementation, the first fault identifier is the fault identifier of the memory fault that occurred latest among the memory faults backed up by the out-of-band controller; the second fault identifier is the fault identifier of the memory fault that occurred latest in memory.

[0031] Thirdly, a server is provided, comprising: memory, an in-band controller, and an out-of-band controller. The in-band controller, in cooperation with the memory and the out-of-band controller, performs any of the methods provided in the first aspect.

[0032] Fourthly, a computer device is provided, comprising: a processor and a memory, the processor being connected to the memory. The memory stores computer-executable instructions, and the processor executes the computer-executable instructions stored in the memory, thereby implementing any of the methods provided in the first aspect. In one example, the processor here may be an in-band controller.

[0033] Fifthly, a chip is provided, for example, a chip including an in-band controller, the chip comprising: a processor and an interface circuit; the interface circuit for receiving code instructions and transmitting them to the processor; and the processor for executing the code instructions to perform any of the methods provided in the first aspect above.

[0034] Sixthly, a computer-readable storage medium is provided, storing computer-executable instructions that, when executed on a computer, cause the computer to perform any of the methods provided in the first aspect above.

[0035] In a seventh aspect, a computer program product is provided, including computer execution instructions that, when executed on a computer, cause the computer to perform any of the methods provided in the first aspect above.

[0036] The technical effects of any of the design methods in aspects two through seven can be found in the technical effects of different design methods in aspect one, and will not be repeated here. Attached Figure Description

[0037] Figure 1 An architecture diagram of a server provided for an embodiment of this application;

[0038] Figure 2 A flowchart illustrating a memory fault information collection method provided in this application embodiment. Figure 1 ;

[0039] Figure 3 A flowchart illustrating a method for collecting memory fault information during server operation, provided in an embodiment of this application;

[0040] Figure 4 A flowchart illustrating a memory fault information collection method provided in this application embodiment. Figure 2 ;

[0041] Figure 5 A flowchart illustrating a memory fault information collection method provided in this application embodiment. Figure 3 ;

[0042] Figure 6 A flowchart illustrating a memory fault information collection method provided in this application embodiment. Figure 4 ;

[0043] Figure 7 This is a schematic diagram of a memory fault information collection device provided in an embodiment of this application. Detailed Implementation

[0044] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0045] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first fault identifier" and "second fault identifier," etc., are used to distinguish different fault identifiers, not to describe a specific order of fault identifiers.

[0046] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0047] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0048] First, some concepts involved in the memory fault information collection method, apparatus and storage medium provided in the embodiments of this application will be explained.

[0049] Cold reboot: The process by which an electronic device restarts after the power is cut off. During a cold reboot, a hardware self-test is performed, which initializes the memory in the electronic device, thus resetting the data stored in volatile memory.

[0050] Warm reboot: This is the process of restarting an electronic device without disconnecting its power supply. During a warm reboot, the hardware self-test is not performed, so the data stored in volatile memory is not reset.

[0051] Data center persistent memory module (DCPMM): This is either non-volatile or persistent memory. The DCPMM includes both volatile and non-volatile storage areas. When the electronic device containing the DCPMM undergoes a cold restart, the device no longer provides power to the DCPMM. At this time, the DCPMM's built-in power supply will power the DCPMM, enabling it to store the data in the volatile storage area (referred to as volatile data) into the non-volatile storage area, thus completing the persistence of the volatile data. This process is called the DCPMM's asynchronous dynamic random access memory refresh (ADR) procedure.

[0052] The fault register in memory stores memory fault information. This information can include uncorrectable errors (UCEs) and correctable errors (CEs). If the server hardware detects a UCE, it may cause the server to crash and restart. If the server hardware detects a CE, it will use some resources to self-repair it. However, when the number of CEs in memory accumulates to an excessive level (e.g., the number of CEs is greater than or equal to a preset value), and self-repair is no longer possible, a UCE will be generated, causing the server to crash and restart.

[0053] In the following examples, embodiments of this application provide a method for collecting memory fault information. The method includes: during server operation, an in-band controller performs fault detection on the memory and sends the detected fault information to the out-of-band controller; during server restart, if the server's startup mode is a cold restart, the in-band controller determines new fault information in the memory and sends the new fault information to the out-of-band controller so that the out-of-band controller can collect the new fault information; thereby avoiding missed fault information.

[0054] like Figure 1 The diagram shown is a schematic representation of a system architecture provided in an embodiment of this application. This system architecture diagram is an example illustration of a computer device. (Reference) Figure 1 The hardware of this computer device mainly includes an in-band controller, an out-of-band controller, and memory. The software mainly includes an out-of-band management module, processor firmware, and an operating system (OS) management unit. The out-of-band management module is located within the out-of-band controller, the OS management unit is located within the in-band controller, and the processor firmware can be located within the in-band controller (e.g.,...). Figure 1 (As shown), or, the processor firmware can also be located on a firmware chip outside the in-band controller (as shown). Figure 1 (Not shown in the image) The in-band controller can be a central processing unit (CPU). The out-of-band management module can be a management unit for non-business modules. For example, the out-of-band management module can remotely maintain and manage the computer equipment through a dedicated data channel. This out-of-band management module is completely independent of the computer equipment's operating system and can communicate with the BIOS and OS (or OS management unit) through the computer equipment's out-of-band management interface.

[0055] For example, an out-of-band management module may include an external monitoring and management unit of the computer device, a management system in a management chip outside the in-band controller, a computer device BMC, or an intelligent management unit (IMU), a system management mode (SMM), etc. It should be noted that the specific form of the out-of-band management module in this application is not limited; the above is merely illustrative. In the following embodiments, only a BMC is used as an example of an out-of-band management module for explanation.

[0056] For example, processor firmware (also known as processor firmware program) can be firmware, BIOS, management engine (ME), microcode, etc. It should be noted that the specific form of the processor firmware in this application embodiment is not limited; the above is merely illustrative. In the following embodiments, only BIOS as the processor firmware is used as an example for explanation.

[0057] It should be noted that the execution of a certain step by the in-band controller (such as S110-S130 below) described in the following embodiments can be understood as: the in-band controller calling the processor firmware to execute the step.

[0058] The memory, also known as internal memory or main memory, includes volatile and non-volatile memory installed in memory slots on the motherboard of a computer device. The memory communicates with the memory controller via memory channels. The memory has a fault register, which stores fault information when a memory failure occurs.

[0059] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0060] This application provides a method for collecting memory fault information. This method is applied to a server, which includes memory, an out-of-band controller, and an in-band controller. Figure 2 As shown, the method includes: S110-S130.

[0061] S110. During server operation, the in-band controller performs memory fault detection and sends the detected fault information to the out-of-band controller.

[0062] The aforementioned memory includes: dynamic random access memory (DRAM) or DCPMM.

[0063] The above fault information includes: a fault identifier, which indicates the chronological order in which memory faults occurred; the memory fault refers to a fault that has already occurred in the server's memory.

[0064] It should be noted that the above fault identifier can be the fault sequence number of the above memory fault or the fault occurrence timestamp of the above memory fault. Specifically, this application limits the specific manifestation of the above first fault identifier.

[0065] The specific implementation of the above 110 is as follows: Figure 3 As shown, it includes: S110a-S110e.

[0066] S110a, the in-band controller acquires non-crash fault information when a non-crash fault occurs in the memory during server operation.

[0067] It should be understood that when a non-crash failure occurs in the memory during server operation, the aforementioned in-band controller can directly obtain the non-crash failure information.

[0068] It should be noted that the above-mentioned non-downtime faults are memory faults that will not cause the server to crash; these memory faults refer to faults that have already occurred in the server's memory. The above-mentioned non-downtime faults can be read / write timeout faults within the CE (Continuous Error Correction) category.

[0069] S110b: The in-band controller sends non-downtime fault information to the out-of-band controller.

[0070] It should be noted that the in-band controller sends the detected fault information to the out-of-band controller, which is essentially the out-of-band controller collecting the detected fault information. In one implementation, the out-of-band controller collects the detected fault information to parse it and output it, so that the user can promptly understand and handle the fault.

[0071] S110c, the out-of-band controller determines whether a first fault indicator exists locally.

[0072] The aforementioned first fault identifier is the fault identifier of the memory fault that has been stored in the out-of-band controller. In other words, the out-of-band controller will store the fault identifiers in the collected fault information locally; these fault identifiers stored locally are collectively referred to as the first fault identifier.

[0073] When a backup fault identifier exists in the out-of-band controller, it indicates that the server where the out-of-band controller is located is not executing the memory fault information collection method provided in this application embodiment for the first time. At this time, the out-of-band controller executes the following S110d.

[0074] When there is no backup fault identifier in the out-of-band controller, it indicates that the server where the out-of-band controller is located is executing the memory fault information collection method provided in this application embodiment for the first time. At this time, the out-of-band controller executes the following S110e.

[0075] S110d, the out-of-band controller updates the first fault identifier based on the fault identifier of the non-downtime fault.

[0076] The specific implementation of S110d above is that the out-of-band controller stores the fault identifier of the non-crash fault based on the first fault identifier, so that the first fault identifier includes the fault identifier of the non-crash fault.

[0077] For example, suppose the fault identifier is a fault sequence number, and the fault sequence number increments sequentially according to the order in which the faults occur; the out-of-band controller has already stored fault sequence number 1 and fault sequence number 2, meaning that fault sequence number 1 and fault sequence number 2 are both the first fault identifier; the fault sequence number for the aforementioned non-crash fault is fault sequence number 3. Then, the out-of-band controller stores fault sequence number 3 based on fault sequence number 1 and fault sequence number 2, so that the locally stored fault sequence number is fault sequence number 1-3; at this time, the first fault identifier is fault sequence number 1-3.

[0078] Optionally, when the first fault identifier is the fault identifier of the memory fault that occurred latest among the memory faults stored in the out-of-band controller, the specific implementation of S110d is: the out-of-band controller updates the first fault identifier to the fault identifier of a non-crash fault.

[0079] For example, suppose the fault identifier is a fault sequence number, which increments sequentially according to the order in which the faults occur; the out-of-band controller has collected fault 1 and fault 2, where the fault sequence number 1 corresponding to fault 1 is less than the fault sequence number 2 corresponding to fault 2, so fault sequence number 2 is determined as the first fault identifier and stored in the out-of-band controller; the fault sequence number of the above non-crash fault is fault sequence number 3; then the out-of-band controller updates the first fault identifier from fault sequence number 2 to fault sequence number 3; at this time, the first fault identifier is fault sequence number 3.

[0080] S110e, out-of-band controller stores fault identifiers for non-downtime faults.

[0081] For example, suppose the above fault identifier is a fault sequence number, where the fault sequence number increases sequentially according to the order in which the faults occur; the fault sequence of the above non-downtime fault is 3, then the out-of-band controller stores the fault identifier with fault sequence number 3 locally; at this time, the first fault identifier is fault sequence 3.

[0082] The memory fault information collection method provided in this application embodiment is that during the server operation phase, when a non-crash fault occurs in the memory, the in-band controller directly sends the non-crash fault information to the out-of-band controller, so that the out-of-band controller can complete the collection of the non-crash fault, thereby improving the efficiency of the out-of-band controller in collecting memory faults.

[0083] S120. During the server restart process, if the server's startup mode is cold restart, the in-band controller determines whether there is any new fault information stored in the memory.

[0084] The above-mentioned server startup modes include cold restart, which includes normal cold restart of the server (such as: the user manually powering off the server) and cold restart caused by server downtime failure.

[0085] The newly added fault information mentioned above is fault information that is not stored in the out-of-band controller. In other words, the newly added fault information is fault information that has occurred in memory but has not been collected by the out-of-band controller. That is, the out-of-band controller does not store the fault identifier of the newly added fault information.

[0086] It should be noted that the above-mentioned newly added fault information includes at least one of the following: the serial number of the newly added fault, the timestamp of the occurrence of the newly added fault, and the location of the occurrence of the newly added fault, and may also include other fault information.

[0087] S130. If there is new fault information in the memory, the in-band controller will send the new fault information to the out-of-band controller.

[0088] It should be noted that the in-band controller sends the new fault information to the out-of-band controller so that the out-of-band controller can collect the new fault information and store the fault identifier of the new fault information locally.

[0089] The memory fault information collection method provided in this application embodiment involves the in-band controller detecting memory faults during server operation and sending the detected fault information to the out-of-band controller. During server restart, if the server's startup mode is a cold restart, the in-band controller determines the newly added fault information in the memory and sends the newly added fault information to the out-of-band controller so that the out-of-band controller can collect the newly added fault information, thereby avoiding missed fault information reports.

[0090] Based on the memory fault information collection method described in S120-S130 above, this application provides two specific embodiments of the memory fault information collection method, namely Embodiments 1-2, as follows:

[0091] Example 1

[0092] This application provides a method for collecting memory fault information, which is applied during a server cold restart; such as Figure 4 As shown, the method includes: S310-S360.

[0093] S310, The in-band controller obtains the first fault identifier from the out-of-band controller.

[0094] The aforementioned first fault identifier is the fault identifier of memory faults stored in the out-of-band controller; that is, the fault identifiers of all memory faults stored in the aforementioned out-of-band controller are the first fault identifiers.

[0095] For example, suppose that fault 1 and fault 2 occur in memory respectively. When the out-of-band controller of the server where the memory is located has collected the information of fault 1-2, the fault identifier of fault 1 is fault sequence number 1, and the fault identifier of fault 2 is fault sequence number 2. At this time, fault sequence number 1 and fault sequence number 2 are both the first fault identifier.

[0096] The specific implementation of S310 above includes: one implementation method: the in-band controller sends a request to the out-of-band controller to obtain the first fault identifier, and then the out-of-band controller responds to the request by sending the first fault identifier to the in-band controller. Another implementation method: the out-of-band controller actively sends the first fault identifier to the in-band controller.

[0097] It should be noted that the first fault identifier stored in the out-of-band controller is persistent data. Even if the server where the out-of-band controller is located undergoes a cold restart, the stored first fault identifier will still exist in the out-of-band controller.

[0098] S320: The in-band controller retrieves the second fault identifier from the fault register in memory.

[0099] The memory mentioned above is DCPMM.

[0100] It should be noted that the aforementioned fault register is used to store fault information immediately upon a memory failure. In other words, after a memory failure, the fault information is first stored in the fault register in memory and then collected by the out-of-band controller. This fault information includes: a fault sequence number, a fault occurrence timestamp, and the location of the fault. Specifically, the fault information stored in the fault register includes: fault information already collected by the out-of-band controller; or, fault information already collected by the out-of-band controller and fault information not yet collected by the out-of-band controller.

[0101] It should be understood that the aforementioned fault information not collected by the out-of-band controller occurred after a memory crash, when the server restarted before the out-of-band controller had collected the fault information.

[0102] The aforementioned second fault identifier is the fault identifier of a memory fault that has occurred in memory; that is, all memory fault identifiers stored in the fault register are the second fault identifiers.

[0103] For example, based on the example in S310 above, suppose that after fault 1 and fault 2, fault 3 and fault 4 occur in the memory; then, the fault register stores the information of fault 3 and fault 4 based on the information of fault 1 and fault 2; wherein, the fault identifier of fault 3 is fault sequence number 3 and the fault identifier of fault 4 is fault sequence number 4. At this time, fault sequence numbers 1-4 are all second fault identifiers.

[0104] S330, the in-band controller determines whether there is new fault information stored in the memory based on the first fault identifier and the second fault identifier.

[0105] It should be noted that the newly added fault identifiers are fault identifiers for memory faults that have occurred but have not been collected by the out-of-band controller. In other words, the newly added fault identifiers are fault identifiers for memory faults that are not stored in the out-of-band controller. Since the first fault identifier is an identifier for memory faults that have been collected by the out-of-band controller, and the second fault identifier is an identifier for memory faults that have occurred in the server, the newly added fault identifiers are therefore the difference between the second fault identifier and the first fault identifier.

[0106] For example, based on the example in S320 above, assuming that neither fault 3 nor fault 4 is collected by the out-of-band controller, the first fault identifier includes: fault sequence number 1 and fault sequence 2; the second fault identifier includes: fault sequence number 1, fault sequence number 2, fault sequence number 3 and fault sequence 4; then, the in-band controller determines the difference between the second fault identifier and the first fault identifier (i.e., fault sequence number 3 and fault sequence 4) as the newly added fault identifier.

[0107] When the above-mentioned newly added fault identifier is empty, it is determined that there is no new fault information in memory, and the in-band controller performs a termination action to allow the server to continue starting.

[0108] When the above-mentioned newly added fault identifier is not empty, the controller determines that there is newly added fault information in memory and executes the following S340.

[0109] S340: The in-band controller sends the new fault information represented by the new fault identifier to the out-of-band controller.

[0110] It should be noted that the above-mentioned newly added fault information includes at least one of the following: the serial number of the newly added fault, the timestamp of the occurrence of the newly added fault, and the location of the occurrence of the newly added fault, and may also include other fault information.

[0111] S350: The out-of-band controller receives new fault information sent by the in-band controller.

[0112] After the out-of-band controller receives the new fault information, it essentially collects the new fault information. In one implementation, the purpose of collecting the new fault information is to parse the fault information and output the new fault information so that the user can understand and handle the fault in a timely manner.

[0113] S360, out-of-band controller stores newly added fault information.

[0114] The aforementioned backup of newly added fault information is essentially the out-of-band controller storing the fault identifier (i.e., the newly added fault identifier) ​​in the newly added fault information based on the aforementioned first fault identifier. At this time, the first fault identifier includes the newly added fault identifier.

[0115] For example, based on the above S330, the example out-of-band controller stores fault sequence number 3 and fault sequence number 4 on the basis of the already stored fault sequence number 1 and fault sequence number 2; at this time, the first fault identifier includes: fault sequence number 1, fault sequence number 2, fault sequence number 3 and fault sequence number 4.

[0116] Because the DCPMM is a non-volatile memory, the fault information stored in the DCPMM's fault register will not be lost regardless of whether the server experiences a cold restart, a warm restart, or is running. The aforementioned second fault identifier is obtained from this fault register, so even if the server experiences a cold restart, the second fault identifier can still be retrieved from it. Then, based on this second fault identifier and the first fault identifier stored in the out-of-band controller, new fault information is determined, and the out-of-band controller collects this new fault information; thus solving the problem of preventing missed fault reports.

[0117] Example 2

[0118] Because memory failures are relatively frequent, a large number of first fault indicators may exist in the out-of-band controller, resulting in high storage resource consumption. Therefore, this application provides another method for collecting memory fault information, such as... Figure 5 As shown, the method includes: S410-S460.

[0119] S410, the in-band controller obtains the first fault identifier from the out-of-band controller.

[0120] The aforementioned first fault identifier is the fault identifier of the memory fault that occurred most recently among the memory faults stored in the out-of-band controller. In other words, the first fault identifier is the fault identifier of the memory fault that was most recently collected by the out-of-band controller. The memory fault refers to the fault that has occurred in the memory of the server.

[0121] It should be noted that the aforementioned fault identifier is used to characterize the chronological order in which memory faults occur. The aforementioned fault identifier can be the fault sequence number of the aforementioned memory fault, or it can be the timestamp of the occurrence of the aforementioned memory fault. Specifically, this application defines the specific form of the aforementioned first fault identifier.

[0122] For example, suppose fault 1 and fault 2 occur in memory, and the out-of-band controller of the server containing the memory has collected fault 1-2. Fault 1 is identified by fault sequence number 1, and fault 2 is identified by fault sequence number 2. The fault sequence numbers increase sequentially with the order in which the faults occur. In this case, when fault sequence number 1 is greater than fault sequence number 2, fault sequence number 1 is the first fault identifier; when fault sequence number 2 is greater than fault sequence number 1, fault sequence number 2 is the first fault identifier.

[0123] It should be noted that the data stored in the out-of-band controller is persistent data. Even if the server where the out-of-band controller is located undergoes a cold restart, the data stored in the out-of-band controller will still exist in the out-of-band controller.

[0124] The specific implementation of S410 above includes: one implementation: the in-band controller sends a request to the out-of-band controller to obtain the first fault identifier, and then the out-of-band controller responds to the request, and the in-band controller sends the first fault identifier. Another implementation: the out-of-band controller actively sends the first fault identifier to the in-band controller.

[0125] S420: The in-band controller retrieves the second fault identifier from the fault register in memory.

[0126] The memory mentioned above is DCPMM.

[0127] It should be noted that the function of the fault register in S420 is the same as that of the fault register in S320. For a detailed description of the function of the fault register in S420, please refer to the relevant description of S320 above, which will not be repeated here.

[0128] The aforementioned second fault identifier is the fault identifier of the memory fault that occurred most recently in the memory; that is, the aforementioned second fault identifier is the fault identifier of the memory fault that occurred most recently from the current time.

[0129] For example, based on the example in S410 above, assume that after fault 1 and fault 2, the memory experiences fault 3 and fault 4; wherein the fault identifier for fault 1 is fault sequence number 1, the fault identifier for fault 2 is fault sequence number 2, the fault identifier for fault 3 is fault sequence number 3, and the fault identifier for fault 4 is fault sequence number 4, with the fault sequence number increasing sequentially according to the order of the faults. In this case, when fault sequence number 3 is greater than fault sequence number 4, fault sequence number 3 is the second fault identifier; when fault sequence number 4 is greater than fault sequence number 3, fault sequence number 4 is the second fault identifier.

[0130] S430, the in-band controller determines whether there is new fault information stored in the memory based on the first fault identifier and the second fault identifier.

[0131] It should be noted that the newly added fault identifiers are fault identifiers for memory faults that have occurred but have not been collected by the out-of-band controller. In other words, the occurrence time of the memory faults represented by the newly added fault identifiers is longer than the occurrence time of the memory faults represented by the first fault identifier.

[0132] The specific implementation of S430 above is as follows: Based on the difference between the second fault identifier and the first fault identifier, the fault identifier of the memory fault that occurred in the fault register at a time greater than the occurrence time of the first fault information is determined as the new fault identifier, wherein the first fault information is the memory fault represented by the first fault identifier; specifically as follows:

[0133] When the second fault identifier and the first fault identifier are the second fault sequence number and the first fault sequence number, respectively, the fault sequence number of the memory fault in the memory fault register that is greater than the first fault sequence number and less than or equal to the second fault sequence number is used as the new fault sequence number (i.e., the new fault identifier).

[0134] For example, assume that neither fault 3 nor fault 4 is collected by the out-of-band controller, the fault sequence number of fault 1 is 1, the fault sequence number of fault 2 is 2, the fault sequence number of fault 3 is 3, and the fault sequence number of fault 4 is 4, where the first fault identifier is fault sequence number 2 and the second fault identifier is fault sequence number 4. Then, the difference between fault sequence number 4 and fault sequence number 2 is 2, that is, fault sequence number 3 of fault 3 and fault sequence number 4 of fault 4 are determined as new fault sequence numbers (i.e., new fault identifiers).

[0135] The newly added fault identifier is used to characterize the newly added fault information.

[0136] When the above-mentioned newly added fault identifier is empty, it is determined that there is no new fault information in memory, and the in-band controller performs a termination action to allow the server to continue starting.

[0137] When the above-mentioned newly added fault identifier is not empty, the controller in the in-band determines that there is newly added fault information in the memory and executes the following S440.

[0138] S440: The in-band controller sends the new fault information represented by the new fault identifier to the out-of-band controller.

[0139] S450: The out-of-band controller receives new fault information sent by the in-band controller.

[0140] It should be noted that the implementation methods of S440-S450 are the same as those of S340-S350. For a detailed description of S440-S450, please refer to the relevant descriptions of S340-S350 above. They will not be repeated here.

[0141] S460, the out-of-band controller updates the first fault identifier to the second fault identifier.

[0142] For example, based on the example of S330 above, the out-of-band controller updates the currently stored fault sequence number 2 to fault sequence number 4. At this time, the first fault identifier backed up in the out-of-band controller is the fault sequence number with fault sequence number 4.

[0143] Compared to the approach of storing all collected memory fault identification information in the out-of-band controller, the memory fault information collection method provided in this application embodiment stores the fault identification of the last memory fault collected by the out-of-band controller in the out-of-band controller, thereby reducing the occupation of the storage resources of the out-of-band controller.

[0144] Optional, combined Figure 2 ,like Figure 6 As shown, this application embodiment improves another method for collecting memory fault information. This method is applied to a server, which includes memory, an out-of-band controller, and an in-band controller; as... Figure 6 As shown, the method includes the following steps.

[0145] S610. During server operation, the in-band controller performs memory fault detection and sends the detected fault information to the out-of-band controller.

[0146] The memory mentioned above is DCPMM.

[0147] It should be noted that the implementation method of S610 is the same as that of S110. For a detailed description of S610, please refer to the relevant description of S110 above. It will not be repeated here.

[0148] S620: The in-band controller obtains the ADR function enable status of the DCPMM from the DCPMM.

[0149] It should be noted that the specific implementation of S620 above includes: one implementation: the in-band controller sends a request to the DCPMM to obtain the ADR function enable status of the DCPMM, and then the DCPMM responds to the request and sends the ADR function enable status of the DCPMM to the in-band controller. Another implementation: the DCPMM actively sends its own ADR function enable status to the in-band controller. Specifically, this application embodiment does not limit the specific implementation method of the in-band controller obtaining the ADR function enable status of the DCPMM.

[0150] The ADR function of the DCPMM mentioned above is either enabled or disabled.

[0151] It's important to note that when DCPMM's ADR function is enabled, in the event of a server crash leading to a warm restart, DCPMM's ADR function will switch the server's restart mode from warm restart to cold restart. In other words, when DCPMM's ADR function is enabled, the server will only undergo a cold restart. When DCPMM's ADR function is disabled, it will not switch the server's restart mode.

[0152] When the ADR function of the DCPMM is enabled, the in-band controller executes S630 and S650 as follows.

[0153] When the ADR function of the DCPMM is off, the in-band controller executes the following S640-S650.

[0154] S630. During server restart, if the server's startup mode is cold restart, the in-band controller determines whether there is any new fault information stored in memory.

[0155] It should be understood that when the above-mentioned memory DCPMM is in the ADR function enabled state, the cold restart that occurs on the server includes: normal server cold restart (such as: the user manually powering off the server) and cold restart due to server crash failure (such as: memory UCE).

[0156] It should be noted that the implementation method of the in-band controller in the above S630 to determine whether there is new fault information in the memory can be referred to the specific implementation method of S310-S330 or S410-S430, which will not be repeated here.

[0157] S640. During server restart, if the server restart type is a crash restart, the in-band controller determines whether there is any new fault information in the memory.

[0158] It should be noted that when the ADR function of DCPMM is disabled, the server will restart in a hot restart mode when the server crashes and restarts.

[0159] It should be noted that the implementation method of the in-band controller in the above S640 to determine whether there is new fault information in the memory can be referred to the specific implementation method of S310-S330 or S410-S430, which will not be repeated here.

[0160] Optionally, if the ADR function of the memory DCPMM is disabled during the server restart process and the server restart type is non-crash restart, the in-band controller above will perform a termination action to allow the server to continue restarting.

[0161] S650: If new fault information is stored in memory, the in-band controller will send the new fault information to the out-of-band controller.

[0162] The implementation method of sending new fault information from the in-band controller to the out-of-band controller in the above S650 is similar to the specific implementation method of S340-S360 or S440-S460, and will not be repeated here.

[0163] It should be noted that after the in-band controller completes the above S650 process, it performs a termination action to allow the server to continue starting.

[0164] Optionally, the memory fault information collection methods corresponding to S310-S360 and S410-S460 mentioned above can also be applied during the server's operation phase.

[0165] The memory fault information collection method provided in this application embodiment, during server restart, when the server's startup mode is cold restart and the ADR function of the aforementioned DCPMM is enabled, or when the ADR function of the DCPMM is disabled and the server restart type is crash restart, allows the in-band controller to determine the newly added fault information in the memory and send the newly added fault information to the out-of-band controller so that the out-of-band controller can collect the newly added fault information; thereby avoiding the in-band controller executing the memory fault information collection method provided in this application embodiment during a normal cold restart of the server when the ADR function of the DCPMM is disabled, thus saving the computing resources of the in-band controller.

[0166] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the memory fault information collection device (such as an in-band controller) includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0167] This application embodiment can, based on the above method, exemplarily divide a memory fault information collection device (such as an in-band controller) into functional modules. For example, the memory fault information collection device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0168] like Figure 7 A schematic diagram of a memory fault information collection device is shown; the memory fault information collection device includes: a checking unit 701, a transceiver unit 702, and a determination unit 703.

[0169] The inspection unit 701 is used to perform memory fault detection during server operation; the transceiver unit 702 is used to send the detected fault information to the out-of-band controller; for example, to perform step S110 in the above method embodiment.

[0170] The determining unit 703 is used to determine whether there is new fault information in memory during the server restart process if the server's startup mode is cold restart; for example, by executing step S120 in the above method embodiment.

[0171] The transceiver unit 702 is also used to send new fault information to the out-of-band controller if new fault information is stored in the memory; for example, by executing step S130 in the above method embodiment.

[0172] Optionally, the transceiver unit 702 is used to determine whether there is new fault information in memory during the server restart process if the server's startup mode is cold restart and the asynchronous refresh ADR function of DCPMM is enabled; for example, by executing step S630 in the above method embodiment.

[0173] Optionally, during server restart, if the ADR function of DCPMM is disabled and the server restart type is a crash restart, determine whether there is any new fault information in memory; for example, execute step S640 in the above method embodiment.

[0174] Optionally, the transceiver unit 702 is also used to obtain the ADR function's enabled status from the DCPMM during server restart; for example, by performing step S620 in the above method embodiment.

[0175] Optionally, the transceiver unit 702 is used to send non-crash fault information to the out-of-band controller when a non-crash fault occurs in the memory during server operation; for example, by performing step S110b in the above method embodiment.

[0176] Optionally, the transceiver unit 702 is used to obtain a first fault identifier from the out-of-band controller; for example, by performing step S310 or S410 in the above method embodiments.

[0177] The transceiver unit 702 is also used to obtain a second fault identifier from the fault register in memory; for example, by performing step S320 or S420 in the above method embodiment.

[0178] The determining unit 703 is used to determine whether there is new fault information in the memory based on the first fault identifier and the second fault identifier; for example, by executing step S330 or S430 in the above method embodiment.

[0179] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the memory fault information collection devices provided above, as well as the description of their beneficial effects, can be found in the corresponding method embodiments described above, and will not be repeated here.

[0180] This application also provides a computer device, which includes memory, an in-band controller, and an out-of-band controller. This application does not limit the specific form of the computer device. For example, the computer device can be a terminal device or a network device. The terminal device can be referred to as: terminal, user equipment (UE), access terminal, user unit, user station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user equipment, etc. The terminal device can specifically be a mobile phone, augmented reality (AR) device, virtual reality (VR) device, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. The network device can specifically be a server, etc. The server can be a single physical or logical server, or two or more physical or logical servers sharing different responsibilities and cooperating to achieve the various functions of the server.

[0181] This application embodiment also provides a server, which includes memory, an out-of-band controller, and an in-band controller, wherein the memory, the out-of-band controller, and the in-band controller are coupled; the memory is used to store computer program code, and the in-band controller, in cooperation with the memory and the out-of-band controller, executes the above-mentioned code. Figures 2-6 Any of the methods provided.

[0182] This application also provides a computer device, including a processor and a memory, with the processor connected to the memory. The memory stores computer execution instructions, and the processor executes the computer execution instructions stored in the memory to achieve the above-mentioned functions. Figures 2-6 Any of the methods provided. In one example, the computer device could be a server. In one example, the processor could be an in-band processor.

[0183] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the methods executed by any of the computer devices described above.

[0184] For explanations of the relevant content and descriptions of the beneficial effects in any of the computer-readable storage media provided above, please refer to the corresponding embodiments described above, which will not be repeated here.

[0185] This application also provides a chip, for example, a chip containing processor firmware. This chip integrates control circuitry for implementing the functions of the aforementioned computer device and one or more ports. Optionally, the functions supported by this chip can be referred to above, and will not be repeated here. Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, random access memory, etc. The aforementioned processing unit or processor can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (digital signal processor, DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0186] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform any of the methods described in the above embodiments. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or may include one or more data storage devices such as servers or data centers that can be integrated with the medium. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., SSD), etc.

[0187] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of this application, such as but not limited to the memory, computer-readable storage medium and communication chip, are all non-transitory.

[0188] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0189] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0190] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0191] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0192] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0193] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0194] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for collecting memory fault information, characterized in that, Applied to a server, the server including a persistent memory DCPMM, an out-of-band controller, and an in-band controller, the method includes: During the operation of the server, the in-band controller performs fault detection on the DCPMM and sends the detected fault information to the out-of-band controller; During the server restart process, if the server's startup mode is cold restart and the asynchronous refresh ADR function of the DCPMM is enabled, the in-band controller determines whether there is any new fault information in the DCPMM. During the server restart process, if the ADR function of the DCPMM is disabled and the server restart type is a crash restart, the in-band controller determines whether there is any new fault information in the DCPMM; wherein, the new fault information is fault information not stored in the out-of-band controller. If the newly added fault information is stored in the DCPMM, the in-band controller will send the newly added fault information to the out-of-band controller.

2. The method according to claim 1, characterized in that, During the server restart process, the method further includes: The in-band controller obtains the ADR function's on / off status from the DCPMM; the ADR function's on / off status includes on or off.

3. The method according to claim 1 or 2, characterized in that, The fault information includes a fault identifier, which indicates the chronological order in which memory faults occurred; the memory fault is a fault that has occurred in the server's DCPMM.

4. The method according to claim 3, characterized in that, During the operation of the server, the in-band controller performs fault detection on the DCPMM and sends the detected fault information to the out-of-band controller; including: During the operation of the server, when a non-downtime fault occurs in the DCPMM, the in-band controller sends the non-downtime fault information to the out-of-band controller so that the out-of-band controller stores the fault identifier in the non-downtime fault information.

5. The method according to claim 4, characterized in that, The in-band controller determines whether there is new fault information in the DCPMM, including: The in-band controller obtains a first fault identifier from the out-of-band controller; wherein the first fault identifier is a memory fault identifier stored in the out-of-band controller; The in-band controller obtains a second fault identifier from the fault register of the DCPMM; wherein the second fault identifier is a fault identifier of a memory fault that has occurred in the DCPMM; The in-band controller determines whether there is any new fault information in the DCPMM based on the first fault identifier and the second fault identifier.

6. The method according to claim 5, characterized in that, The first fault identifier is the fault identifier of the memory fault that occurred latest among the memory faults stored by the out-of-band controller; The second fault identifier is the fault identifier of the memory fault that occurred latest in the DCPMM.

7. A server, characterized in that, It includes a DCPMM, an out-of-band controller, and an in-band controller, wherein the DCPMM, the out-of-band controller, and the in-band controller are coupled; the in-band controller cooperates with the DCPMM and the out-of-band controller to perform the method as described in any one of claims 1 to 6.

Images