Memory fault management system and method, server and electronic equipment

Abstract

The invention discloses a memory fault management system and method, a server and electronic equipment, and relates to the technical field of computers, the memory fault management system comprises a processing circuit of a hardware memory, a hardware layer and a processor are arranged on the processing circuit, and the processor is further divided into a kernel layer, a user layer and an input and output layer. Through cooperative work of the hardware layer and each software layer, hierarchical detection, classified processing and automatic isolation of memory error data are realized, and server downtime caused by memory fault error data is effectively prevented. And meanwhile, through a linkage mechanism of a kernel mode and a user mode and in combination with visual display, the monitorability and maintainability of memory errors are enhanced, operation and maintenance personnel can quickly position and repair problems conveniently, and the operation and maintenance cost of the system is reduced.

Description

Technical Field

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

[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 increases, the failure rate is also increasing. Memory failures can easily lead to system crashes and server downtime.

[0003] In related technologies, faults are mostly 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). However, the biggest problem with these methods is that memory problems cannot be detected in advance and are often discovered passively after the server crashes and restarts. Summary of the Invention

[0004] The present application provides a memory fault management system, method, server and electronic device to at least solve the problem in the related art that the method of locating memory faults by recording logs cannot detect and avoid memory problems in advance, which easily leads to server downtime.

[0005] The present application provides a memory fault management system, comprising: a processing circuit of a hardware memory, wherein a hardware layer and a processor are provided on the processing circuit; the hardware layer detects first error data and second error data of the hardware memory, wherein the first error data is recoverable data and the second error 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 and processes 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, isolates the second type data, and reports the first type data and the first error data to the kernel layer; the kernel layer integrates multiple driver components, processes the first type data using a kernel-state protection processing mechanism, and reports the first error data and the processed first type data to the user layer; the user layer visually displays the first error data and isolates the processed first type data in the user state.

[0006] The present application also provides a server, including: the memory fault management system of the above embodiment.

[0007] The present application also provides a memory fault management method, which is used for a processor of the memory fault management system of the above embodiment, and the processor is configured to perform the following steps: obtaining first error data and second error data of the 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 and output layer, using the input and output layer to classify and process the second error data to obtain first type data and second type data, 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 error data are reported to the kernel layer; at the kernel layer, using the kernel state protection processing mechanism to process the first type data, and report the first error data and the processed first type data to the user layer; at the user layer, visually display the first error data, and isolate the processed first type data in the user state.

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

[0009] The memory fault management system of the present application includes hardware memory processing circuitry, which is equipped 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 error data in the 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 data and recoverable data to the kernel layer. The kernel layer uses an integrated driver component to protect the non-fatal error data in kernel state and reports the first error data and processed non-fatal error data to the user layer. The user layer is responsible for visually displaying recoverable errors and further isolating the processed non-fatal error data in user state. Thus, through the collaborative work of the hardware layer and various software layers, hierarchical detection, classification, and automatic isolation of memory errors are achieved, which not only improves system stability and reliability but also effectively prevents system crashes caused by memory failures. Furthermore, the kernel-mode and user-mode linkage mechanism, combined with visual display, enhances the monitorability and maintainability of memory errors, making it easier for operation and maintenance personnel to quickly locate and fix problems, thereby reducing system operation and maintenance costs. This solves the problem in related technologies that the method of locating memory failures by recording logs cannot detect and avoid memory problems in advance, which easily leads to server downtime. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0011] Figure 1 A block diagram of a memory fault management system provided in an embodiment of the present application; Figure 2 An architectural diagram of memory error detection and processing provided for one embodiment of the present application; Figure 3 This is a flowchart of the memory fault management method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0012] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0014] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0015] The embodiment of the present application provides a memory fault management system, such as Figure 1 As shown, the system includes: a processing circuit 10 of a hardware memory, 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 and output layer 201.

[0016] Among them, the hardware layer 100 detects the first error data and the second error data of the hardware memory, the first error data is recoverable data, and the second error data is unrecoverable data; the input and output layer 201 classifies and processes the second error data to obtain first type data and second type data, the first type data is non-fatal data, and the second type data is fatal data, isolates the second type data, and reports the first type data and the first error data to the kernel layer 202; the kernel layer 202 integrates multiple driver components, uses the kernel state protection processing mechanism to process the first type data, and reports the first error data and the processed first type data to the user layer 203; the user layer 203 visualizes the first error data and isolates the processed first type data in the user state.

[0017] In an embodiment of the present application, the first error data CE (Correctable Error) refers to a memory error that can be automatically repaired by the system. The second error data UCE (Uncorrectable Error) refers to a serious memory error that cannot be repaired by existing methods. This type of error usually leads to data loss or system instability. In an embodiment of the present application, the hardware layer 100 detects the first error data and the 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 and processes the second error data to obtain first type data and second type data, wherein the first type data can be understood as non-fatal data. This type of error data will not immediately cause the system to crash or seriously affect the operation of the system. The first type data can be understood as fatal data. This type of error data may cause the system to crash or be unable to continue normal operation. For the fatal second type data, the input / output layer 201 will attempt to isolate it to prevent further impact on system stability. Specifically, in order to avoid the fatal UCE error being completely lost and not recorded, the BIOS of the embodiment of the present application can synchronize the error information to the BMC (Baseboard Management Controller). The BMC is a control unit independent of the main system, which is specifically used to monitor and manage the system hardware status. Even if the operating system crashes, the UCE error information can be accurately recorded by the BMC to ensure that no critical fault information is missed. During the actual execution process, if the above-mentioned fatal type of UCE error occurs, the operating system will be forced to restart in an attempt to restore normal operation. During the restart process, the BIOS will perform isolation measures on the specific memory bar that caused the UCE. This means that the memory bar will no longer be used by the system, thereby avoiding triggering the same error again. The non-fatal first type data and the recoverable first error data will be reported to the kernel layer 202 for further processing.

[0018] Furthermore, the kernel layer 202 integrates multiple driver components (such as the EDAC (Error Detection and Correction) driver) to process data from the input / output layer 201. For non-fatal UCE data, the kernel layer 202 implements a protection mechanism to prevent kernel-mode consumption of the first type of data from causing server downtime. After processing this data, the kernel layer 202 reports the first error data (CE) and the protected first type of data (non-fatal UCE) to the user layer 203. The user layer 203 is responsible for visually displaying the received first error data (CE) to facilitate review and analysis by operations and maintenance personnel. Simultaneously, the user layer 203 performs further isolation or repair operations on the processed first type of data (non-fatal UCE) in user mode to ensure that these issues do not affect normal system operation. Thus, this embodiment of the present application implements memory fault reporting while also isolating and repairing some critical memory faults, reducing the probability of downtime and achieving the goal of identifying and managing memory errors.

[0019] In one embodiment of the present application, 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 copied length.

[0020] Specifically, when the driver component (EDAC) detects non-fatal memory error data, if the error occurs in the data in the user address space, directly processing this data may cause the kernel to crash. Therefore, the embodiment of the present application can use uaccess interfaces such as copy_from_user and get_user, so that the kernel can detect data containing UCE errors when trying to copy data from the user address space to the kernel address space. According to the POSIX (Portable Operating System Interface) standard, the kernel will not continue to process the potentially damaged data in this case, but will return the error code EFAULT or the length of the successful copy, thereby avoiding kernel-mode consumption of UCE errors and downtime.

[0021] In another embodiment, when a user-mode process invokes a system call (such as write(2) or futex(2)), it triggers a synchronous exception through an SVC instruction, trapping it into kernel mode. The driver component (EDAC) then executes the corresponding system call logic based on the system call number. This mechanism ensures that even if a memory error occurs during processing, the process can safely exit and return to user mode 203, rather than crashing directly. This reduces the likelihood of system downtime and improves system availability and user experience.

[0022] In one embodiment of the present application, the user layer 203 is provided with at least one of a daemon process, a monitoring process and a main process, wherein the daemon process is used to record the physical address information of the first error data and the second error data, and 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.

[0023] Specifically, after detecting an error reported by EDAC, daemon process A classifies and processes it based on the specific error type. For CE errors, the number and specific address information are recorded. Based on the physical address information, the memory controller number (MC number), chip select row number (csrow number), channel number (channel number), and memory bank number (DIMM number) are determined and accumulated. Daemon process A periodically counts and records the number of newly added CEs for each MC number, csrow number, channel number, and DIMM number. When daemon process A detects a UCE error reported by EDAC, it records the error and resolves the physical address. Thus, this embodiment of the present application not only monitors the current memory status in real time but also stores and analyzes historical data. By statistically analyzing CE and UCE errors over a period of time, potential memory bank problems can be predicted and maintenance can be performed in advance. For example, when the number of CE or UCE errors on a memory bank exceeds a preset threshold, the system triggers an alarm, notifying operations and maintenance personnel to promptly inspect and replace the memory bank to avoid service interruptions caused by memory failures.

[0024] Monitoring process B monitors main process C. During the operating system startup phase, monitoring process B starts. After completing its own initialization, monitoring process B allocates a large memory area E for main process C and starts main process C. After process C initializes, it also initializes memory area E. All modules of main process C retrieve memory data from memory area E. Details of memory area E are subject to patents and are not detailed here. Monitoring process B also monitors all memory mappings of the main process. The mapping of virtual memory to physical addresses is obtained using the memory management mechanism provided by the Linux system. Monitoring process B also periodically notifies main process C of CE error data from the daemon process. After initialization, main process C periodically receives CE error data from the monitoring process. Main process C generates command-line output based on the CE error data and also provides a command line for reading historical data from daemon process A. Users can query real-time error information and historical data through the command line. When real-time data is updated, the GUI will output the data in real time for operation and maintenance personnel to view in real time.

[0025] In one embodiment of the present application, the main process is provided with multiple memory management modules, wherein the memory management module is used to isolate the memory pages corresponding to the first type of data when the first type of data occurs in the memory area.

[0026] Specifically, the main process is configured with multiple memory management modules that are responsible for managing and protecting memory resources. When a non-fatal UCE error is detected within the memory area allocated to the main process, the memory management module will isolate the memory page in question. This means marking the problematic memory page as unavailable, preventing it from further use.

[0027] For example, suppose kernel layer 202 uploads a non-fatal UCE error, and the error occurs in memory area E used by main process C. Daemon process B detects the UCE error and notifies main process C. Upon receiving the notification, main process C's memory management module locates the memory page where the UCE occurred and isolates it. After isolation, the isolated memory page is no longer requested or used by any other module, preventing further UCE errors and effectively protecting the system from memory failures.

[0028] In one embodiment of the present application, some fatal types of UCE memory errors will directly cause a kernel crash. To prevent this from happening, the BIOS in the embodiment of the present application will be synchronized with the BMC. The BMC will record the specific error information to ensure that the UCE is not missed. When this type of UCE occurs, the OS will be forced to restart. The BIOS will isolate the memory bar that caused the UCE, resulting in an inconsistency between the current memory size and the last boot memory size. The adapter module D can detect this inconsistency and notify the monitoring process B. The monitoring process B will communicate with the BMC, obtain the UCE error, and report it to the cluster.

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

[0030] It can be understood that in order to enable the memory fault management function on the supported platform, the embodiment of the present application requires the support of the corresponding hardware platform. In order to facilitate management, the embodiment of the present application will adapt the component to detect the hardware type and query the current number and size of memory sticks. Since the CPUs of different platforms are different, the adaptation component is required here to detect the current hardware platform when the operating system starts, and then load the EDAC driver corresponding to the platform to correctly obtain memory error data.

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

[0032] The EDAC driver component (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, edac_mc, edac_device, and PCI busscanning, are responsible for collecting errors reported by the memory controller, other controllers (such as the L3 cache controller), and PCI devices, respectively. Linux displays the hierarchical relationship of kernel devices through the sysfs file system, and EDAC uses it to control and report device failures. EDAC uses an abstract memory controller model to locate faults on the corresponding memory bank, which is primarily related to the memory arrangement structure in the system. Each memory controller (MC) device corresponding to the CPU controls a set of dual in-line memory modules (DIMMs). These modules are arranged in chip-select rows (csrowX) and channels (chX). There can be multiple csrows and multiple channels in the system.

[0033] Specifically, the embodiment of the present application can use 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 (channel number), and memory bank number (DIMM number), and then flush it to the configuration file lables.db. In this way, when 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 lables.db, the slot number corresponding to the error (such as CPU0_A, CPU0_B, CPU1_A, CPU1_B) can be determined. This slot number will also be printed on the motherboard, making it easier for operation and maintenance personnel to locate the problematic memory and improve work efficiency. In actual applications, only the specific faulty slot needs to be replaced, reducing operation and maintenance costs.

[0034] In one embodiment of the present application, when the driver component is used in the hardware layer 100 to perform a memory patrol operation and detects an error in the first type of data, it identifies the memory page where the first type of data is located, marks the memory page as an abnormal page, and unmaps the virtual address space corresponding to the abnormal page.

[0035] The above embodiment describes the memory errors detected during reading and writing. The embodiment of the present application also involves errors in memory patrol. When the patrol detects CE, no special processing is required. When the patrol detects UCE, a UE interrupt will be reported. Since this UE interrupt is not caused by the memory access behavior of the process, it is unrelated to the process context and will not cause the error to propagate. Therefore, there is no need to shut down immediately. The embodiment of the present application identifies the memory page where the first type of data is located. The driver component only needs to mark the memory page as an exception and unmap the page table to ensure that subsequent memory accesses will not touch the problematic memory page, thereby preventing the error from propagating to other parts. If the abnormal page is read during the life cycle of the subsequent process, a SIGBUS signal is sent to the process when the pagefault is triggered, so that the system can take timely measures when encountering a problematic memory page instead of crashing directly.

[0036] In actual execution, when a UCE error is detected, daemon process B reports an alarm to the master process C. Since the UCE address is available, the memory card number, csrow number, channel number, and DIMM number can be parsed. Similarly, the specific physical memory slot location can be obtained. The master process then notifies the multi-controller cluster. Daemon process B specifically records the alarm and reports it again after a restart. Upon receiving the alarm, the multi-controller cluster uses a corresponding alert mechanism (such as SMS or email) to notify operations and maintenance personnel. Based on the specific slot location reported in the alarm, operations and maintenance personnel can replace the memory to prevent further UCE errors. After replacing the memory, the operator uses the multi-controller cluster's repair process to notify the master process C of the corresponding node. Upon receiving the repair action initiated by the operator, master process C notifies daemon process B to resolve the alarm and will not report it again after the next restart.

[0037] In one embodiment of the present application, if the first error data and the second error data are detected when performing reading and writing, they are reported to the basic input and output layer 201 through MCE interruption or CMCI interruption; if the first error data and the second error data are detected during inspection, they are reported to the basic input and output layer 201 through UE interruption.

[0038] It will be appreciated that embodiments of the present application can select different interrupt mechanisms to report error data based on the method used to detect error data (i.e., during read / write operations or during memory inspections). Specifically, embodiments of the present application can report recoverable and unrecoverable data detected during read / write operations to the basic input / output layer 201 via MCE (Machine Check Exception) interrupts or CMCI (Corrected Machine Check Interrupt) interrupts. MCE interrupts are used to report serious hardware errors, typically unrecoverable errors (UCEs), while CMCI interrupts are used to report automatically recoverable errors (CEs). These errors typically do not cause a system crash, but require recording and monitoring. When an unrecoverable error (UCE) is detected during a memory inspection, it is reported to the basic input / output layer 201 via a UE (Uncorrectable Error) interrupt. This interrupt is typically independent of the process context and therefore does not immediately cause a system crash, but measures must still be taken to prevent the error from spreading. Therefore, embodiments of the present application can select the appropriate interrupt mechanism based on the method used to detect the error, ensuring timely and accurate error reporting and improving system stability.

[0039] In summary, the memory fault management system achieves memory fault reporting, early warning, fault isolation, and maintenance through the collaborative efforts of hardware, BIOS, kernel, applications, and a multi-controller cluster. Memory faults are detected by the hardware and reported via interrupts. The BIOS collaborates with the system to handle memory faults, especially critical ones. The kernel detects memory faults reported by the BIOS, categorizes and counts CE and UCE errors, and updates them to the sysfs log. Application-layer daemon A monitors the corresponding sysfs log in real time, reading and recording the type, number, and detailed information of reported errors. Monitoring process B monitors the type, number, and detailed information of errors reported by daemon A. Master process C provides multi-controller cluster services, including alarms and repair alarms. When a memory fault occurs on a node, the hardware detects the specific fault type and address and reports an interrupt to the BIOS. The BIOS then communicates the error type that can be transparently transmitted to the kernel, which then uploads it to the final application process, achieving memory error identification and management.

[0040] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0041] The following combination Figure 2The system architecture for memory error detection and handling is shown, which describes the interaction and data flow between different layers from the hardware layer to the user layer in detail as follows: 1) Hardware layer Memory hardware detection, located at the hardware layer, is responsible for real-time monitoring of memory status and triggering corresponding interrupts when memory errors are detected. Memory errors include CE errors (Correctable Errors), which are usually automatically corrected by hardware, and UCE errors (Uncorrectable Errors), which require processing by the operating system or higher layers. When a CE error is detected, a CMCI interrupt is triggered. This interrupt is used to report errors that can be corrected automatically, but still require recording and monitoring. When a UCE error is detected, an MCE interrupt is triggered. This interrupt usually indicates a serious hardware error and may require immediate action, such as restarting the system.

[0042] Secondly, the BIOS prioritizes hardware-reported errors. The CPU notifies the BIOS via an MCE interrupt or a CMCI interrupt. 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 UCE is not missed. When such a UCE occurs, the operating system is forced to restart. The BIOS will isolate the memory module that generated the UCE. Secondly, embodiments of the present application can report fatal error data to the kernel layer for processing.

[0043] 2) Kernel layer 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 it and handles it accordingly. The EDAC driver analyzes the error information, determines the error type and location, and decides on the next steps.

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

[0045] 3) User layer User-mode tools (such as memtool and edac-utils) can read error information from the sysfs file system and system logs for further analysis and processing. The MCS (Memory Control System) service collects and aggregates data from multiple user-mode tools. It consolidates scattered error information into a unified view for centralized management and analysis. Finally, memory error information is visualized through a graphical user interface (GUI), allowing operations personnel to intuitively assess the system's memory health and promptly identify and address potential issues.

[0046] In summary, the memory fault management system of the embodiment of the present application includes a hardware memory processing circuit, which is provided with a hardware layer and a processor, and the processor is further divided into a kernel layer, a user layer, and an input / output layer. The hardware layer detects first error data and second error data in the memory, and 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 data and recoverable data to the kernel layer. The kernel layer protects the non-fatal error data in the kernel state through an integrated driver component, and reports the first error data and the processed non-fatal error data to the user layer. The user layer is responsible for visually displaying recoverable errors and further isolating the processed non-fatal error data in the user state. Thus, through the collaborative work of the hardware layer and each software layer, 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 failures. Furthermore, through the linkage mechanism between kernel and user states, combined with visual display, memory errors are more easily monitored and maintainable, making it easier for operators to quickly locate and fix problems, reducing system operation and maintenance costs. This solves the problem that the related art method of locating memory faults through logging cannot detect and avoid memory problems in advance, which can easily lead to server downtime.

[0047] An embodiment of the present application further provides a server, including: the memory fault management system of the above embodiment.

[0048] Secondly, the embodiment of the present application also provides a memory fault management method, which is used for the processor of the memory fault management system of the above embodiment, such as Figure 3 As shown, the processor is configured to perform the following steps: In step S101, first error data and second error data of a hardware memory are obtained from a hardware layer, wherein the first error data is recoverable data and the second error data is unrecoverable data.

[0049] In step S102, at the input-output layer, the second error data is classified and processed using the input-output layer to obtain first type data and second type data, where 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 error data are reported to the kernel layer.

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

[0051] In step S104, the first error data is visually displayed at the user layer, and the processed first type of data is isolated at the user state.

[0052] It should be noted that the description of the features in the embodiments corresponding to the embodiments of the present application can refer to the relevant description of the embodiments corresponding to the above-mentioned memory fault management system. To avoid redundancy, they will not be repeated here one by one.

[0053] According to the memory fault management method provided by the embodiment of the present application, the hardware layer detects the first error data and the second error data in the memory, and the input and 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 data and recoverable data to the kernel layer. The kernel layer uses an integrated driver component to protect the non-fatal error data in the kernel state and reports the first error data and the processed non-fatal error data to the user layer. The user layer is responsible for visually displaying the recoverable errors and further isolating the processed non-fatal error data in the user state. Thus, through the collaborative work of the hardware layer and the 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 failures. At the same time, through the linkage mechanism between the kernel state and the user state, combined with the visual display, the monitorability and maintainability of memory errors are enhanced, making it easier for operation and maintenance personnel to quickly locate and repair problems, reducing system operation and maintenance costs. This solves the problem in related technologies that the method of locating memory failures by recording logs cannot detect and avoid memory problems in advance, which easily leads to server downtime.

[0054] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned memory fault management method embodiments.

[0055] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0056] The above is a detailed introduction to a memory fault management system provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A memory fault management system, characterized in that: include: A processing circuit of the hardware memory, wherein the processing circuit is provided with a hardware layer and a processor; The hardware layer detects first error data and second error data of the hardware memory, wherein the first error data is recoverable data and the second error 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 error data to obtain first-type data and second-type data, where the first-type data is non-fatal data and the second-type data is fatal data, isolates the second-type data, and reports the first-type data and the first error data to the kernel layer; The kernel layer integrates a plurality of driver components, processes the first type of data using a kernel state protection processing mechanism, and reports the first error data and the processed first type of data to the user layer; The user layer visually displays the first erroneous data and isolates the processed first type of data in the user state.

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 copied length.

3. The memory fault management system according to claim 1 or 2, characterized in that: The driver component is used to identify the memory page where the first type of data is located when the hardware layer performs a memory patrol operation and detects an error in the first type of data, mark the memory page as an abnormal page, and unmap the virtual address space corresponding to the abnormal page.

4. The memory fault management system according to claim 1, wherein: The user layer is provided with at least one of a daemon process, a monitoring process and a main process, wherein 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 provided with a plurality of memory management modules, wherein the memory management module is used to isolate the memory pages corresponding to the first type of data when the first type of data occurs in the memory area.

6. The memory fault management system according to claim 1, wherein: Also includes: 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 6, characterized in that: The driver component is used to locate the corresponding memory physical slots of the first error data and the second error data through a target mapping file, wherein the target mapping file is a configuration file generated by the adapter component during the startup phase of the operating system, and stores the mapping relationship between the memory physical slots and the hardware identifiers corresponding to the error data, and the hardware identifier includes at least one of a memory controller number, a chip select row number, a channel number, and a memory bar number.

8. A server, characterized in that: include: The memory fault management system according to any one of claims 1 to 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 to 7, wherein the processor is configured to perform the following steps: Acquire first error data and second error data of a hardware memory from a hardware layer, wherein the first error data is recoverable data and the second error data is unrecoverable data; At the input / output layer, the second error data is classified and processed by the input / output layer to obtain first type data and second type data, where 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 error data are reported to the kernel layer; At the kernel layer, the first type of data is processed by using a kernel-mode protection processing mechanism, and the first error data and the processed first type of data are reported to the user layer; At the user layer, the first erroneous data is visually displayed, and the processed first type of data is isolated at the user state.

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 according to claim 9 when executing the computer program.

Images