Memory fault management system, method, server and electronic equipment

Abstract

This application discloses a memory fault management system, method, server, and electronic device, relating to the field of computer technology. It includes a hardware memory processing circuit with a hardware layer and a processor, the processor being further divided into a kernel layer, a user layer, and an input / output layer. Through the collaborative work of the hardware layer and various software layers, it achieves hierarchical detection, classification processing, and automatic isolation of memory error data, effectively preventing server downtime caused by memory fault data. Simultaneously, through the linkage mechanism between kernel mode and user mode, combined with visual display, it enhances the monitorability and maintainability of memory errors, facilitating rapid problem location and repair by maintenance personnel and reducing system maintenance costs.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory fault management system, method, server, and electronic device. Background Technology

[0002] With the development of technologies such as the Internet, cloud computing, the Internet of Things, and mobile Internet, data is growing rapidly, and the number of storage and computing nodes is increasing. As the scale of memory access grows larger, the failure rate is also increasing. Memory failures can easily lead to system crashes and server downtime.

[0003] In related technologies, most faults are discovered and located by combining the MCE (Machine Check Exception) log and the SEL (System Error Log) log recorded by the BMC (Baseboard Management Controller). The biggest problem with these methods is that they cannot detect memory problems in advance; they are often only discovered passively after the server crashes and restarts. Summary of the Invention

[0004] This application provides a memory fault management system, method, server, and electronic device to at least solve the problem in related technologies where the method of locating memory faults by recording logs cannot detect and avoid memory problems in advance, which can easily lead to server crashes.

[0005] This application provides a memory fault management system, including: a hardware memory processing circuit, on which a hardware layer and a processor are disposed; the hardware layer detects first erroneous data and second erroneous data of the hardware memory, wherein the first erroneous data is recoverable data and the second erroneous data is unrecoverable data; the processor is provided with a kernel layer, a user layer and an input / output layer, wherein the input / output layer classifies the second erroneous data to obtain first type data and second type data, wherein the first type data is non-fatal data and the second type data is fatal data, the second type data is isolated, and the first type data and the first erroneous data are reported to the kernel layer; the kernel layer integrates multiple driver components, uses the kernel-mode protection processing mechanism to process the first type data, and reports the first erroneous data and the processed first type data to the user layer; the user layer visualizes the first erroneous data and isolates the processed first type data in user mode.

[0006] This application also provides a server, including: the memory fault management system described in the above embodiments.

[0007] This application also provides a memory fault management method. The method is used in the processor of the memory fault management system of the above embodiment. The processor is configured to perform the following steps: obtaining first error data and second error data of hardware memory from the hardware layer, wherein the first error data is recoverable data and the second error data is unrecoverable data; at the input / output layer, classifying the second error data to obtain first type data and second type data, wherein the first type data is non-fatal data and the second type data is fatal data, isolating the second type data, and reporting the first type data and the first error data to the kernel layer; at the kernel layer, processing the first type data using the kernel-mode protection processing mechanism, and reporting the first error data and the processed first type data to the user layer; at the user layer, visualizing the first error data, and isolating the processed first type data in user mode.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described memory fault management methods when executing the computer program.

[0009] The memory fault management system of this application includes hardware memory processing circuitry, on which a hardware layer and a processor are mounted. The processor is further divided into a kernel layer, a user layer, and an input / output layer. The hardware layer detects first and second erroneous data in memory. The input / output layer classifies the second erroneous data into non-fatal first-type data and fatal second-type data, isolating the fatal data and reporting non-fatal and recoverable data to the kernel layer. The kernel layer, through integrated driver components, protects the non-fatal erroneous data in kernel mode and reports the first erroneous data and the processed non-fatal erroneous data to the user layer. The user layer is responsible for visualizing recoverable errors and further isolating the processed non-fatal erroneous data in user mode. Thus, through the collaborative work of the hardware layer and various software layers, hierarchical detection, classification, and automatic isolation of memory errors are achieved, improving system stability and reliability and effectively preventing system crashes caused by memory faults. Simultaneously, the linkage mechanism between kernel and user modes, combined with visual display, enhances the monitorability and maintainability of memory errors, facilitating rapid problem location and repair by maintenance personnel and reducing system maintenance costs. This solves the problem that the method of locating memory faults by recording logs in related technologies cannot detect and avoid memory problems in advance, which can easily lead to server crashes. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A block diagram of a memory fault management system provided in an embodiment of this application;

[0012] Figure 2 This is an architecture diagram of memory error detection and processing provided in one embodiment of this application;

[0013] Figure 3 A flowchart of a memory fault management method provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] Embodiments of this application provide a memory fault management system, such as... Figure 1 As shown, the system includes: a hardware memory processing circuit 10, a hardware layer 100 and a processor 200 are provided on the processing circuit 10, and the processor 200 is provided with a kernel layer 202, a user layer 203 and an input / output layer 201.

[0018] The hardware layer 100 detects first and second error data in the hardware memory. The first error data is recoverable, and the second error data is unrecoverable. The input / output layer 201 classifies the second error data to obtain first type data and second type data. The first type data is non-fatal, and the second type data is fatal. The second type data is isolated, and the first type data and the first error data are reported to the kernel layer 202. The kernel layer 202 integrates multiple driver components and uses the kernel-mode protection mechanism to process the first type data. The first error data and the processed first type data are reported to the user layer 203. The user layer 203 visualizes the first error data and isolates the processed first type data in user mode.

[0019] In this embodiment, the first error data CE (Correctable Error) refers to a memory error that can be automatically corrected by the system. The second error data UCE (Uncorrectable Error) refers to a serious memory error that cannot be corrected by existing methods. These types of errors typically lead to data loss or system instability. In this embodiment, the hardware layer 100 detects the first and second error data of the hardware memory and reports them to the input / output layer 201 (such as BIOS, Basic Input / Output System). The BIOS classifies the second error data into first-type data and second-type data. The first-type data can be understood as non-fatal data, which will not immediately cause system crashes or seriously affect system operation. The second-type data can be understood as fatal data, which may cause system crashes or prevent normal operation. For fatal second-type data, the input / output layer 201 will attempt to isolate it to prevent further impact on system stability. Specifically, to prevent the complete loss and unrecording of this fatal UCE error, the BIOS in this embodiment can synchronize error information to the BMC (Baseboard Management Controller). The BMC is a control unit independent of the main system, specifically used to monitor and manage system hardware status. Even if the operating system crashes, the UCE error information can be accurately recorded by the BMC, ensuring that no critical fault information is missed. In actual execution, if the aforementioned fatal type of UCE error occurs, the operating system will be forced to restart to attempt to restore normal operation. During the restart process, the BIOS will perform isolation measures on the specific memory module that caused the UCE. This means that the memory module will no longer be used by the system, thereby preventing the same error from being triggered again. Non-fatal first-type data and recoverable first-type error data will be reported to kernel layer 202 for further processing.

[0020] Furthermore, kernel layer 202 integrates multiple driver components (such as EDAC (Error Detection and Correction) driver) to process data from input / output layer 201. For non-fatal UCE data, kernel layer 202 executes a protection mechanism to prevent the kernel from consuming the first type of data, which could cause the server to crash. After processing this data, kernel layer 202 reports the first error data (CE) and the protected first type of data (non-fatal UCE) to user layer 203. User layer 203 is responsible for visualizing the received first error data (CE) for easy viewing and analysis by operations and maintenance personnel. Simultaneously, user layer 203 performs further isolation or repair operations on the processed first type of data (non-fatal UCE) in user space to ensure that these problems do not affect the normal operation of the system. Therefore, this embodiment of the application implements the function of memory fault reporting, while also isolating and repairing some fatal memory faults, reducing the probability of crashes, and achieving the purpose of identifying and managing memory errors.

[0021] In one embodiment of this application, the driver component copies a first type of data from the user address space to the kernel address space and returns an error code or the length copied.

[0022] Specifically, when the driver component (EDAC) detects non-fatal memory error data, directly processing this data, especially if the error occurs in user address space, could cause a kernel crash. Therefore, this embodiment utilizes uaccess interfaces such as `copy_from_user` and `get_user`, allowing the kernel to detect data containing a UCE error when attempting to copy data from user address space to kernel address space. According to the POSIX (Portable Operating System Interface) standard, the kernel will not continue processing potentially corrupted data in this situation, but will instead return the error code `EFAULT` or the length of the successfully copied data, thus preventing the kernel from crashing due to a UCE error.

[0023] In another embodiment, when a user-mode process invokes a system call (such as write(2), futex(2), etc.), it triggers a synchronization exception via the SVC instruction and enters kernel mode. The driver component (EDAC) executes the corresponding system call logic based on the system call number. This mechanism ensures that even if a memory error is encountered during processing, it can safely exit and return to the user layer 203, rather than crashing directly, reducing the possibility of system downtime and improving system availability and user experience.

[0024] In one embodiment of this application, the user layer 203 is provided with at least one of a daemon process, a monitoring process, and a main process. The daemon process is used to record the physical address information of the first error data and the second error data. After the monitoring process completes initialization during the startup phase of the operating system, it allocates a memory area for the main process and starts the main process.

[0025] Specifically, after detecting an error reported by the EDAC, daemon A classifies and processes it according to the specific error type. For CE errors, it records the number of errors and the specific address information, and determines the memory controller number (MC number), chip select row number (csrow number), channel number, and memory module number (DIMM number) based on the physical address information, and accumulates the count. Daemon A periodically counts and records the number of new CE errors for each MC number, csrow number, channel number, and DIMM number. When daemon A detects a UCE error reported by the EDAC, it records the error and resolves the physical address. Thus, this embodiment can not only monitor the current memory status in real time, but also store and analyze historical data. By statistically analyzing CE and UCE errors over a period of time, potential problems with memory modules can be predicted, allowing for proactive maintenance. For example, when the number of CE or UCE errors on a memory module exceeds a preset threshold, the system triggers an alarm mechanism to notify maintenance personnel to promptly check and replace the memory module, avoiding service interruptions due to memory failure.

[0026] Monitoring process B monitors the main process C. It starts during the operating system startup phase. After initializing itself, monitoring process B starts a large memory region E for the main process C and then starts the main process C. After process C initializes, it initializes memory region E, and all modules of the main process C will obtain memory data from memory region E. Details of memory region E are covered in a proprietary patent and will not be elaborated here. Simultaneously, monitoring process B monitors all memory mapping relationships of the main process, including the mapping relationship between virtual memory and physical addresses, obtained through the memory management mechanism provided by the Linux system. It also periodically notifies the main process C of CE error data from the daemon process. After initialization, the main process C periodically receives CE error data sent by the monitoring process. The main process C generates command-line output information from the CE error data and provides a command line to read historical data from daemon process A. Users can query real-time error information and historical data via the command line. When real-time data is updated, the GUI outputs the real-time data, which can be queried by operations and maintenance personnel in real time.

[0027] In one embodiment of this application, the main process is provided with multiple memory management modules, wherein the memory management modules are used to isolate the memory pages corresponding to the first type of data when the first type of data occurs in the memory region.

[0028] Specifically, the main process has multiple memory management modules configured internally. These modules are specifically responsible for managing and protecting memory resources. When a Type I data error (a non-fatal UCE error) is detected within the memory region allocated to the main process, the memory management module will isolate the memory page. This means marking the problematic memory page as unavailable, preventing it from being used further.

[0029] For example, suppose kernel layer 202 uploads non-fatal UCE error data, and this error occurs within memory region E used by main process C. When daemon process B detects the UCE error, it notifies main process C. Upon receiving the notification, the memory management module of main process C locates the memory page where the UCE occurred and isolates it. The isolated memory page will no longer be requested or used by any module, thus preventing further UCE errors and effectively protecting the system from memory failures.

[0030] In one embodiment of this application, certain types of fatal UCE memory errors can directly cause kernel crashes. To prevent this, the BIOS in this embodiment synchronizes with the BMC. The BMC records specific error information to ensure no UCEs are missed. When such a UCE occurs, the OS is forced to restart. The BIOS isolates the memory module that caused the UCE, resulting in a discrepancy between the current memory size and the memory size at the last boot. The adaptation module D can detect this inconsistency and notify the monitoring process B. The monitoring process B communicates with the BMC to obtain the UCE error and reports it to the cluster.

[0031] In one embodiment of this application, the memory fault management system further includes: an adapter component, which is used to identify and detect the current hardware platform and match the corresponding driver component according to the current hardware platform.

[0032] It is understood that in order to enable the memory fault management function on the supported platform, the corresponding hardware platform needs to support it. In order to facilitate management, the embodiments of this application will also have an adapter component to detect the hardware type and query the current number and size of memory modules. Since the CPUs of different platforms are different, the adapter component needs to detect the current hardware platform when the operating system starts up, and then load the EDAC driver corresponding to the platform in order to correctly obtain memory error data.

[0033] Furthermore, the driver component is used to: locate the corresponding physical memory slots for the first error data and the second error data through the target mapping file, wherein the target mapping file is a configuration file generated by the adapter component during the operating system startup phase, which stores the mapping relationship between the physical memory slots and the hardware identifiers corresponding to the error data, and the hardware identifiers include at least one of the memory controller number, chip select row number, channel number and memory module number.

[0034] The Engine Device Driver (EDAC) is a framework for error detection and correction in Linux systems. Its purpose is to detect and report hardware errors when they occur during Linux system operation. EDAC consists of a core (edac_core.ko) and multiple memory controller driver modules. Its subsystems include edac_mc, edac_device, and PCI busscanning, which are responsible for collecting errors reported by the memory controller, other controllers (such as the L3 cache controller), and PCI devices, respectively. Linux uses the sysfs filesystem to represent the hierarchy of kernel devices, and EDAC uses this to control and report device failures. EDAC uses an abstract memory controller model to locate the fault to the corresponding memory module, which is mainly related to the memory's arrangement in the system. Each MC (memory controller) device corresponding to the CPU controls a group of DIMM (Dual In-line Memory Module) memory modules. These modules are arranged in a chip-select row (csrowX) and channel (chX). There can be multiple csrows and multiple channels in the system.

[0035] Specifically, this embodiment utilizes an adapter component to determine the correspondence between each physical memory slot and the memory controller number (MC number), chip select row number (csrow number), channel number, and memory module number (DIMM number), and this correspondence is then written to the labels.db configuration file. When the EDAC receives a reported error, it parses the reported error type and address to clearly locate the MC number, csrow number, channel number, and DIMM number of the error. Based on the correspondence in labels.db, the corresponding slot number (e.g., CPU0_A, CPU0_B, CPU1_A, CPU1_B) can be determined. This slot number is also printed on the motherboard, facilitating maintenance personnel in locating the faulty memory and improving work efficiency. In practical applications, only the faulty slot needs to be replaced, reducing maintenance costs.

[0036] In one embodiment of this application, when the hardware layer 100 detects an error in the first type of data during a memory inspection operation, the driver component identifies the memory page where the first type of data is located, marks the memory page as an abnormal page, and removes the mapping of the virtual address space corresponding to the abnormal page.

[0037] The above embodiments illustrate memory errors detected during read / write operations. This application also addresses errors detected during memory inspection. When a CE (Error Detection) is detected, no special handling is required. When a UCE (Unique Memory Error) is detected, a UE (User Memory Error) interrupt is reported. Since this UE interrupt is not caused by process memory access behavior and is unrelated to the process context, it will not cause error propagation; therefore, immediate system crashes are not necessary. This application identifies the memory page containing the first type of data. The driver component only needs to mark this memory page as faulty and unmap the page table to ensure that subsequent memory accesses do not touch this problematic memory page, thereby preventing error propagation to other parts. If the faulty page is read during the lifecycle of a subsequent process, a SIGBUS signal is sent to the process when a page fault is triggered, enabling the system to take timely measures when encountering a problematic memory page, rather than crashing directly.

[0038] In actual execution, when a UCE error is detected, daemon B reports an alarm, notifying the main process C. Since the UCE address is obtainable, the MC number, csrow number, channel number, and DIMM number can be resolved, and the specific physical memory slot location can also be obtained. The main process then notifies the multi-controller cluster. Specifically, daemon B records the alarm and reports it again after a restart. Upon receiving the alarm, the multi-controller cluster uses a corresponding alarm mechanism (SMS, email, etc.) to notify the operations and maintenance personnel. Based on the specific slot location reported, the operations and maintenance personnel can replace the memory to prevent the UCE error from recurring. After replacing the memory, the operations and maintenance personnel use the multi-controller cluster's repair process to notify the corresponding node's main process C. Upon receiving the proactive repair operation from the operations and maintenance personnel, the main process C will notify daemon B to clear the alarm and will not report it again on the next startup.

[0039] In one embodiment of this application, if the first error data and the second error data are detected during read / write operations, they are reported to the Basic Input / Output Layer 201 via an MCE interrupt or a CMCI interrupt; if the first error data and the second error data are detected during inspection, they are reported to the Basic Input / Output Layer 201 via a UE interrupt.

[0040] It is understood that the embodiments of this application can select different interrupt mechanisms to report these error data according to the error data detection method (i.e., during read / write operations or during inspection). Specifically, when recoverable and unrecoverable data are detected during read / write operations, the embodiments of this application can report them to the Basic Input / Output Layer 201 through an MCE (Machine Check Exception) interrupt or a CMCI (Corrected Machine Check Interrupt) interrupt. The MCE interrupt is used to report serious hardware errors, typically involving unrecoverable errors (UCE), while the CMCI interrupt is used to report automatically recoverable errors (CE), which usually do not cause system crashes but require logging and monitoring. When the system detects an unrecoverable error (UCE) during memory inspection, it will report it to the Basic Input / Output Layer 201 through a UE (Uncorrectable Error) interrupt. This interrupt is usually independent of the process context and therefore will not immediately cause system crashes, but measures still need to be taken to prevent the error from spreading. Thus, the embodiments of this application can select an appropriate interrupt mechanism according to the error detection method, ensuring that errors are reported in a timely and accurate manner, thereby improving system stability.

[0041] In summary, the memory fault management system, through the collaborative efforts of hardware, BIOS, kernel, applications, and multi-controller clusters, accomplishes the functions of memory fault reporting, early warning, fault isolation, and maintenance. Hardware detects memory faults and reports them via interrupts; the BIOS coordinates the handling of memory faults, especially in the case of fatal faults; the kernel detects memory faults reported by the BIOS, classifies and statistically analyzes CE and UCE errors, and updates the sysfs log; an application-layer daemon process A monitors the corresponding sysfs logs in real time, reading and recording the reported error types, quantities, and detailed information; a monitoring process B is responsible for monitoring the error types, quantities, and detailed information reported by daemon process A; and a main process C provides multi-controller cluster services, including alarm and repair alarm functions. When a node experiences a memory fault, the hardware can detect the specific fault type and address, reporting an interrupt to the BIOS. The BIOS then transmits the error types that can be transparently identified to the kernel, which in turn uploads them to the final application process, thus achieving the purpose of identifying and managing memory faults.

[0042] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0043] The following is combined with Figure 2The system architecture for memory error detection and handling, shown below, details the interactions and data flow between different layers, from the hardware layer to the user layer, as follows:

[0044] 1) Hardware layer

[0045] Memory hardware monitoring resides at the hardware layer, responsible for real-time monitoring of memory status and triggering corresponding interrupts when memory errors are detected. These memory errors include Correctable Errors (CE), which are typically automatically corrected by hardware, and Uncorrectable Errors (UCE), which require handling by the operating system or higher layers. When a CE error is detected, a CMCI interrupt is triggered. This interrupt reports errors that can be automatically corrected but still require logging and monitoring. When a UCE error is detected, an MCE interrupt is triggered. This interrupt typically indicates a serious hardware error that may require immediate action, such as a system reboot.

[0046] Secondly, the BIOS prioritizes accepting errors reported by the hardware. The CPU notifies the BIOS via MCE or CMCI interrupts. The BIOS can determine the type of error data and synchronize fatal error data to the BMC. The BMC records the specific error information to ensure that no UCEs are missed. When such a UCE occurs, the operating system is forced to restart. The BIOS isolates the memory module that generated the UCE. Furthermore, in this embodiment, fatal error data can be reported to the kernel layer for processing.

[0047] 2) Kernel layer

[0048] The EDAC (Error Detection and Correction) driver resides in the kernel layer and is responsible for handling interrupts from the hardware layer. When a CMCI or MCE interrupt is triggered, the EDAC driver receives these interrupts and handles them accordingly. The EDAC driver analyzes the error information, determines the error type and location, and decides on the subsequent processing steps.

[0049] Updating the sysfs system / log: After the EDAC driver handles the interrupt, it updates the relevant information to the sysfs file system and log, ensuring that error information can be accessed and recorded by upper-layer software. The sysfs is a virtual file system that provides an interface to access kernel objects, allowing user-mode programs to read and modify kernel parameters; the system log records detailed error information, facilitating subsequent troubleshooting and analysis.

[0050] 3) User layer

[0051] User-space tools (such as memtool, edac-utils, etc.) can read error information from the sysfs file system and system logs, and perform further parsing and processing. The MCS (Memory Control System) service is responsible for collecting and aggregating data from multiple user-space tools. It integrates scattered error information into a unified view, facilitating centralized management and analysis. Finally, the memory error information is displayed to users in a visual manner through a graphical user interface (GUI), allowing operations and maintenance personnel to intuitively see the system's memory health status and promptly identify and address potential problems.

[0052] In summary, the memory fault management system of this application includes a hardware memory processing circuit with a hardware layer and a processor. The processor is further divided into a kernel layer, a user layer, and an input / output layer. The hardware layer detects first and second erroneous data in memory. The input / output layer classifies the second erroneous data into non-fatal first-type data and fatal second-type data, isolating the fatal data and reporting the non-fatal and recoverable data to the kernel layer. The kernel layer, through integrated driver components, protects the non-fatal erroneous data in kernel mode and reports the first erroneous data and the processed non-fatal erroneous data to the user layer. The user layer is responsible for visualizing recoverable errors and further isolating the processed non-fatal erroneous data in user mode. Thus, through the collaborative work of the hardware layer and various software layers, hierarchical detection, classification, and automatic isolation of memory errors are achieved, improving system stability and reliability and effectively preventing system crashes caused by memory faults. Meanwhile, by linking kernel and user modes and combining this with visual visualization, the monitorability and maintainability of memory errors are enhanced, making it easier for operations and maintenance personnel to quickly locate and fix problems, thus reducing system maintenance costs. This solves the problem that methods using logs to locate memory faults in related technologies cannot detect and avoid memory problems in advance, easily leading to server crashes.

[0053] Embodiments of this application also provide a server, including: the memory fault management system described in the above embodiments.

[0054] Secondly, embodiments of this application also provide a memory fault management method, the method being used in the processor of the memory fault management system described above, such as... Figure 3 As shown, the processor is configured to perform the following steps:

[0055] In step S101, the first error data and the second error data of the hardware memory are obtained from the hardware layer, wherein the first error data is recoverable data and the second error data is unrecoverable data.

[0056] In step S102, at the input / output layer, the second error data is classified and processed to obtain a first type of data and a second type of data. The first type of data is non-fatal data, and the second type of data is fatal data. The second type of data is isolated, and the first type of data and the first error data are reported to the kernel layer.

[0057] In step S103, at the kernel layer, the first type of data is processed using the kernel-mode protection processing mechanism, and the first error data and the processed first type of data are reported to the user layer.

[0058] In step S104, the first error data is visualized at the user level, and the processed first type of data is isolated in the user state.

[0059] It should be noted that the descriptions of the features in the embodiments of this application can be found in the relevant descriptions of the corresponding embodiments of the memory fault management system described above. To avoid redundancy, they will not be repeated here.

[0060] According to the memory fault management method provided in this application, the hardware layer detects first and second error data in memory. The input / output layer classifies the second error data into non-fatal first-type data and fatal second-type data, isolates the fatal data, and reports the non-fatal and recoverable data to the kernel layer. The kernel layer protects the non-fatal error data in kernel mode through integrated driver components and reports the first error data and the processed non-fatal error data to the user layer. The user layer is responsible for visualizing recoverable errors and further isolating the processed non-fatal error data in user mode. Thus, through the collaborative work of the hardware layer and various software layers, hierarchical detection, classification, processing, and automatic isolation of memory errors are achieved, which not only improves the stability and reliability of the system but also effectively prevents system crashes caused by memory faults. At the same time, through the linkage mechanism between kernel mode and user mode, combined with visualization, the monitorability and maintainability of memory errors are enhanced, making it easier for operation and maintenance personnel to quickly locate and repair problems, and reducing system operation and maintenance costs. This solves the problem that the method of locating memory faults by recording logs in related technologies cannot detect and avoid memory problems in advance, which can easily lead to server crashes.

[0061] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the memory fault management method.

[0062] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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.

[0063] The foregoing has provided a detailed description of a memory fault management system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A memory fault management system, characterized in that, include: A hardware memory processing circuit, wherein a hardware layer and a processor are provided on the processing circuit; The hardware layer detects first and second error data in the hardware memory. The first error data is recoverable data, and the second error data is unrecoverable data. If the first error data is detected during read / write operations, it is reported to the input / output layer via a CMCI interrupt. If the second error data is detected during read / write operations, it is reported to the input / output layer via an MCE interrupt. If the second error data is detected during inspection, it is reported to the input / output layer via a UE interrupt. The processor includes a kernel layer, a user layer, and an input / output layer. The input / output layer classifies the second error data to obtain a first type of data and a second type of data. The first type of data is non-fatal data, and the second type of data is fatal data. The second type of data is isolated, and the first type of data and the first error data are reported to the kernel layer. The kernel layer integrates multiple driver components, uses the kernel-mode protection processing mechanism to process the first type of data, and reports the first error data and the processed first type of data to the user layer. The driver component is further used to locate the corresponding physical memory slots of the first error data and the second error data through the target mapping file, wherein the target mapping file is a configuration file generated by the adapter component during the operating system startup phase, which stores the mapping relationship between the physical memory slots and the hardware identifiers corresponding to the error data; The user layer visualizes the first error data and isolates the processed first type of data in user mode.

2. The memory fault management system according to claim 1, characterized in that, The driver component copies the first type of data from the user address space to the kernel address space and returns an error code or the length already copied.

3. The memory fault management system according to claim 1 or 2, characterized in that, When the hardware layer performs a memory inspection operation and detects an error in the first type of data, the driver component identifies the memory page where the first type of data is located, marks the memory page as an abnormal page, and removes the mapping of the virtual address space corresponding to the abnormal page.

4. The memory fault management system according to claim 1, characterized in that, The user layer is configured with at least one of a daemon process, a monitoring process, and a main process. The daemon process is used to record the physical address information of the first error data and the second error data. After the monitoring process completes initialization during the startup phase of the operating system, it allocates a memory area for the main process and starts the main process.

5. The memory fault management system according to claim 4, characterized in that, The main process is equipped with multiple memory management modules, wherein the memory management modules are used to isolate the memory pages corresponding to the first type of data when the first type of data occurs in the memory region.

6. The memory fault management system according to claim 1, characterized in that, The adapter component is used to match the corresponding driver component according to the hardware platform.

7. The memory fault management system according to claim 1, characterized in that, The hardware identifier includes at least one of the following: memory controller number, chip select row number, channel number, and memory module number.

8. A server, characterized in that, include: The memory fault management system according to any one of claims 1-7.

9. A memory fault management method, characterized in that, The method is used in a processor of the memory fault management system according to any one of claims 1-7, wherein the processor is configured to perform the following steps: First and second error data of hardware memory are obtained from the hardware layer. The first error data is recoverable data and the second error data is unrecoverable data. If the first error data is detected during read / write operations, it is reported to the input / output layer via CMCI interrupt. If the second error data is detected during read / write operations, it is reported to the input / output layer via MCE interrupt. If the second error data is detected during inspection, it is reported to the input / output layer via UE interrupt. In the input / output layer, the second error data is classified and processed to obtain a first type of data and a second type of data. The first type of data is non-fatal data, and the second type of data is fatal data. The second type of data is isolated, and the first type of data and the first error data are reported to the kernel layer. At the kernel layer, the first type of data is processed using the kernel-mode protection mechanism, and the first error data and the processed first type of data are reported to the user layer; the driver component is further used to locate the corresponding physical memory slots of the first error data and the second error data through the target mapping file, wherein the target mapping file is a configuration file generated by the adaptation component during the operating system startup phase, which stores the mapping relationship between the physical memory slots and the hardware identifiers corresponding to the error data; At the user level, the first error data is visualized, and the processed first type of data is isolated in the user space.

10. An electronic device, characterized in that, include: memory for storing computer programs; A processor, configured to implement the steps of the memory fault management method as described in claim 9 when executing the computer program.

Images