Computer systems and their dedicated crash recovery devices and methods for recording error data
By introducing dedicated crash logger hardware circuitry and non-volatile memory into the computer system, the problem of error recording by the central processing unit in the absence of a baseboard management controller is solved, realizing automated error data storage and analysis, and reducing fault analysis time and system costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-07-16
- Publication Date
- 2026-03-13
AI Technical Summary
Existing computer systems without a baseboard management controller cannot effectively record errors in the central processing unit, leading to prolonged fault analysis time and increased system costs and security risks.
It employs dedicated crash logger hardware circuitry and non-volatile memory, connected to the central processing unit via a bus, to automatically record and store error data, thus avoiding dependence on the board management controller.
It enables automatic recording and analysis of central processing unit error data without the need for a baseboard management controller, reducing fault analysis time, lowering system costs, and improving system operational reliability.
Smart Images

Figure CN114968629B_ABST
Abstract
Description
Technical Field
[0001] In general, this disclosure relates to the operational reliability of computing devices. Specifically, aspects of this disclosure relate to a dedicated crash dump hardware circuit for storing erroneous data from a damaged processor in a computer system. Background Technology
[0002] Computer systems can perform general computational operations. A typical computer system, such as a server, generally includes hardware components such as a processor, memory, network interface cards, a power supply, and other dedicated hardware. A computer system has a Basic Input / Output System (BIOS), usually a chip. The BIOS is used to test basic inputs and outputs from these hardware components before the computer system boots up.
[0003] When a computer system's central processing unit (CPU) malfunctions, the system may crash. Generally, the CPU comprises multiple different chips performing various functions. For example, in an Intel processor, a catastrophic error (CATERR) event signal may be sent when the processor fails. If a damaged processor is present in the computer system, the system will fail to boot in subsequent power-on attempts. Therefore, the computer system will not start normally. Intel processors have a management engine (ME) that collects error data related to the crash to assist in the analysis of the damaged processor.
[0004] Complex computer systems, such as servers, use a baseboard management controller (BMC) to store data on damaged components in a system error log (SEL). Figure 1A known computer system 10 is shown, comprising a Central Processing Unit (CPU) 12 and a BMC 14 according to the Intelligent Platform Management Interface (IPMI) specification. In this example, the CPU 12 may include a specific chip (e.g., a Platform Path Controller (PCH)) for specific operations and multiple processing cores. In this example, the BMC 14 may be a complex processor, such as, but not limited to, ASPEED's AST2500. The BMC 14 includes a connection to a bus, such as an I2C bus 16, enabling communication between the BMC 14 and the CPU 12. The BMC 14 also includes a General Purpose Input / Output (GPIO) pin 20 for error signals to be communicated from the CPU 12. The BMC 14 is a service processor that monitors the physical state of the computer system 10 and generally includes support for advanced functions. For example, the BMC 14 includes support for a keyboard, graphics, mouse (KVM), a network interface for a management network, and internal memory for storing operational data, such as system error logs.
[0005] However, some computer systems, such as network switches, may not have a Baseboard Management Controller (BMC). Furthermore, many users prefer computer systems without a BMC. For example, integrating a BMC into a computer system requires specific knowledge and communication protocols to comply with IPMI standards for writing firmware for use by the rest of the system. Moreover, the BMC is essentially a separate processor unit, increasing the overall cost of the computer system. In some cases, the BMC can pose a security risk because operational data can be accessed through it. However, without a BMC, CPU fault logging is impossible, so computer systems without a BMC cannot analyze errors occurring in the CPU. This increases downtime, as technicians must spend time and resources determining the cause of CPU failures.
[0006] Therefore, there is an urgent need for a dedicated hardware circuit for computer systems to enable error logging via an automatic shutdown component that prevents the computer system from powering on. There is also an urgent need for a simpler component for error logging to eliminate the need for a complex board management controller. And there is an urgent need for a component that allows system management functions to be integrated into a single processor. Summary of the Invention
[0007] The term “embodiment” and similar terms are intended to broadly refer to all subject matter of this disclosure and the following claims. Statements containing such terms should be understood not to limit the subject matter of this disclosure, or to limit the meaning or scope of the following claims. The embodiments covered by this disclosure are defined by the following claims, not by the contents of this section. This section provides a general overview of several different variations of this disclosure and introduces some concepts that will be further detailed in the “Implementation” section. This section is not intended to identify key or essential features of the claimed subject matter; nor is it intended to be used alone to determine the scope of the claimed subject matter. Understanding of the subject matter should be made by referring to the entire specification of this disclosure, any or all of the drawings, and the appropriate portions of each claim.
[0008] One disclosed example is a computer system including a central processing unit (CPU) operable to transmit an error signal. The CPU has a management engine configured to collect error data. A dedicated crash dump device is coupled to the CPU to receive the error signal. A storage device is coupled to the crash dump device. The crash dump device is configured to transmit an error data request to the CPU, receive error data from the CPU in response to the request, and store the error data in the storage device.
[0009] A further embodiment of this exemplary system is an example in which the computer system is a server. Another embodiment is in which the crash logger is a programmable device. Another embodiment is in which the crash logger is one of: a complex programmable logic device, a field-programmable gate array (FPGA), or a programmable microcontroller integrated circuit. Another embodiment is in which the system includes a bus coupled to the storage device, the central processing unit (CPU), and the crash logger circuit (device). Another embodiment is in which the storage device is configured to store instructions that instruct the crash logger to transmit the request using a preset communication protocol and to receive the error data on the bus using the preset communication protocol. Another embodiment is in which the bus is an I2C bus, and the preset communication protocol is the Intelligent Platform Management Bus (IPMB) communication protocol. Another embodiment is in which the storage device is an electronically erasable programmable read-only memory (EEPROM). Another embodiment is in which the crash logger includes a general-purpose input / output pin configured to receive the error signal from the CPU.
[0010] Another disclosed example is a method for recording error data from a processor in a computer system. An error signal is transmitted from the central processing unit (CPU). The error signal is received by a dedicated crash logger coupled to the CPU. An error data request is transmitted from the crash logger to the CPU. The error data is received from the CPU. The received error data is stored in a storage device coupled to the crash logger.
[0011] Another embodiment of this exemplary method is in which the computer system is a server. Another embodiment is in which the crash logger is a programmable device. Another embodiment is in which the crash logger is one of the following: a complex programmable logic device, a field-programmable gate array (FPGA), or a programmable microcontroller integrated circuit. Another embodiment is in which the request is transmitted via a bus coupled to the storage device, the central processing unit (CPU), and the crash logger circuit. Another embodiment is in which the storage device stores instructions instructing the crash logger to transmit the request using a preset communication protocol and to receive the error data on the bus using the preset communication protocol. Another embodiment is in which the bus is an I2C bus, and the preset communication protocol is the IPMB communication protocol. Another embodiment is in which the storage device is an electronically erasable programmable read-only memory (EEPROM). Another embodiment is in which the crash logger includes a general-purpose input / output pin to receive the error signal from the CPU.
[0012] Another disclosed example is a dedicated crash logger hardware device, including a general-purpose input / output pin configured to receive an error signal from a central processing unit (CPU). The hardware device includes a bus interface communicating with a bus coupled to the CPU and a storage device. The device includes a crash logger circuit operable to transmit a request to the CPU in response to receiving the error signal at the bus interface. The crash logger circuit is operable to receive error data from the CPU via the bus interface. The crash logger circuit is operable to store the error data in the storage device via the bus. Attached Figure Description
[0013] Read the following description of exemplary embodiments and refer to the appendix. Figure 1 Upon reading this, one can achieve the best understanding of this disclosure, in which:
[0014] Figure 1 The diagram shows a prior art system that uses a baseboard management controller for error logging.
[0015] Figure 2 The diagram shows a computer system using a sample-specific crash dump hardware device to record CPU errors.
[0016] Figure 3 A detailed chart showing Figure 2 The dedicated crash log hardware and the CPU communicate and respond to each other in order to record errors.
[0017] Figure 4A A graph showing the request message from the dedicated crash save hardware; and
[0018] Figure 4B A graph displaying the response messages from the CPU; and
[0019] Figure 5 This is a flowchart showing the process from... Figure 2 The example in the text is a dedicated crash logger that performs error logging.
[0020] This disclosure may have various modifications and alternatives. Certain representative embodiments have been shown by way of example in the drawings and will be described in detail in this specification. However, it should be noted that the invention is not intended to be limited to the specific forms disclosed. Rather, this disclosure is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined in the claims in the appendix.
[0021] [Symbol Explanation]
[0022] 10: Computer System
[0023] 12: Central Processing Unit (CPU)
[0024] 14: Baseboard Management Controller (BMC)
[0025] 16: I2C bus
[0026] 20: General Purpose Input / Output (GPIO) Pins
[0027] 100: Computer System
[0028] 110: Central Processing Unit (CPU)
[0029] 112: Crash save hardware device
[0030] 114: Storage device
[0031] 120: Bus
[0032] 122: General Purpose Input / Output (GPIO) Pin
[0033] 310: Request Message
[0034] 312: Response Message
[0035] 320: Instruction Block
[0036] 322: Data Result Block
[0037] 400: Request Instruction
[0038] 401-405: Registers
[0039] 450: Response
[0040] 510, 512, 514, 516, 518: Steps Detailed Implementation
[0041] This invention can be embodied in many different forms. Representative embodiments are shown in the accompanying drawings and will be described in detail in this specification. This disclosure is an example or illustration of its principles and is not intended to limit the broad scope of this disclosure to the embodiments shown. In this regard, elements and limitations disclosed in sections such as “Abstract,” “Summary,” and “Description,” but not expressly stated in the claims, should not be incorporated into the claims individually or collectively, implicitly, inferred, or otherwise. For the convenience of this description, unless otherwise stated, singular words include plural words and vice versa; the word “comprising” means “including but not limited to.” Furthermore, words indicating approximation, such as “about,” “nearly,” “substantially,” “close to,” etc., may in this specification mean, for example, “in,” “close to,” or “approximately,” or “within a 3-5% error range,” or “within permissible manufacturing tolerances,” or any logical combination of the foregoing ranges.
[0042] This disclosure relates to a computer system that can perform a crash dump function, recording error data about the central processing unit, without the need for a management controller. The system has a specific dedicated crash dump hardware device and non-volatile memory for the error recording function. Therefore, the remaining system monitoring operations of the board management controller can be performed by the central processing unit, thus eliminating the need for a board management controller.
[0043] Figure 2This is a block diagram showing the components in computer system 100, enabling error logging via a dedicated crash log hardware circuit. Computer system 100 has a central processing unit (CPU) 110, which may include a specific chip, such as a platform controller hub, for specific operations, and may also include multiple processing cores. CPU 110 also includes a management engine (ME) that provides model-specific register (MSR) error data associated with the error that caused the CPU 110 to malfunction. A dedicated crash log hardware device 112 is used to process error reports. Storage device 114 stores error data from CPU 110. In this example, bus 120, such as, but not limited to, an inter-integrated circuit (I2C) bus, enables communication between CPU 110, crash log hardware device 112, and storage device 114 according to a preset communication protocol. The crash logger hardware device 112 includes circuitry for performing crash logger functionality, a bus interface coupled to bus 120, and a general purpose input / output (GPIO) pin 122 coupled to a wire for receiving signals from CPU 110. An example of this signal is a catastrophic error (CATERR) event signal, generated by CPU 110 according to the Intel x86 standard when CPU 110 fails.
[0044] Computer system 100 may also include dual in-line memory modules (DIMMs) to provide additional memory support for CPU 110. Specific functions may be performed by specific processors, such as graphics processing units (GPUs) or field-programmable gate arrays (FPGAs) mounted on a motherboard or expansion card. Computer system 100 may also include additional hardware components, such as, but not limited to, network interface cards (NICs), RAID cards, FPGA cards, power supply units (PSUs), hard disk drives (HDDs), solid-state drives (SSDs), dual in-line memory modules (DIMMs), central processing units (CPUs), and graphics processing units (GPUs).
[0045] In this example, the crash dump hardware device 112 may be a special-purpose circuit device, such as a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any programmable microcontroller integrated circuit that implements crash dump functionality. In this example, the crash dump hardware device is a MAX10. In this example, the crash dump hardware device 112 can be programmed via instructions stored in the storage device 114. If the crash dump hardware device 112 is a special-purpose circuit (e.g., an ASIC), then such functionality is designed into the hardware itself. If the crash dump hardware device 112 includes programmable hardware (e.g., a CPLD or FPGA), then the hardware device can be programmed before being installed in the computer system 100. In this example, the storage device 114 is a discrete component, such as an electronically erasable programmable read-only memory (EEPROM); however, other suitable non-volatile memory devices may also be used. Alternatively, the storage device 114 may be built into the hardware device 112.
[0046] In this example, the crash log hardware device 112 receives an error signal from the CPU 110 via GPIO pin 122. The crash log hardware device 112 requests and receives error data from the CPU 110 via bus 120 to perform the crash log function. The crash log hardware device 112 moves the error data to storage device 114 via bus 120 for storage. This specific crash log hardware device 112 and storage device 114 enable error data storage without the need for a complex management controller, such as a BMC. Technicians can access the CPU's Model-Specific Register (MSR) via access hardware device 112, and then read the data stored in storage device 114. Furthermore, data stored in EEPROM storage device 114 can also be read via I2C bus 120. This data may include analysis error messages and other data in the Model-Specific Register defined by the CPU model through the management engine.
[0047] Under normal operating conditions, the crash dump hardware device 112 always checks for an error signal on GPIO pin 122. When the crash dump hardware device 112 detects an error signal on GPIO pin 122, it activates the crash dump function. The crash dump hardware device 112 queries the management engine of CPU 110 to retrieve all data from the model-specific registers. This query or request instruction from the crash dump hardware circuit is stored in memory device 114 to receive error data via bus 120 using a data communication protocol (e.g., Intelligent Platform Management Bus (IPMB) communication protocol).
[0048] Figure 3This is a block diagram illustrating the request and response messages when the crash save function is activated by the hardware device 112 receiving a CATERR message from the CPU 110. When the crash save function is activated by the crash save hardware device 112, the request message 310 is transmitted to the CPU 110 via the bus 120. Then, the error data is returned to the crash save hardware device 112 via the bus 120 as a response message 312.
[0049] As described above, memory blocks in storage device 114 are allocated for storing instructions or for storing data. In this example, storage device 114 includes a set of instruction blocks 320, which includes instructions for a preset communication protocol (e.g., IPMB) enabling crash dump hardware device 112 to request the CPU via bus 120 and receive a response from the CPU. Storage device 114 also includes a series of data result blocks 322 for storing received error data. A technician can examine the stored error data in the data result blocks 322 to analyze the cause of the CPU crash. For example, instruction blocks 320 may store 4KB of crash dump instructions, while data result blocks 322 may store 4KB of CPUMSR (Model-Specific Register) register data.
[0050] In this example, the instructions for the IPMB communication protocol are pre-programmed into storage device 114. Storage device 114 and crash log hardware device 112 are then installed in computer system 100. When hardware device 112 receives an error signal from CPU 110 via GPIO pin 122, dedicated circuitry in crash log hardware device 112 executes the crash log function.
[0051] In this example, the crash dump hardware device 112 uses a display... Figure 4A Request instruction 400 in IPMB format via Figure 3 The request instruction 400 is transmitted via bus 120 to the management engine of CPU 110. In this example, the request instruction has a machine bank with five 20-byte segments for registers 401, 402, 403, 404, and 405, labeled Machine Control (MCi_CTL), Machine Status (MCi_STATUS), Machine Address (MCi_ADDR), Machine Miscellaneous (MCi_MISC), and another machine control (MCi_CTL2), respectively. The total size of the request instruction 400 is the product of the number of instructions and the instruction size. For example, when the number of instructions is 200 and the instruction size is 20 bytes, the request instruction size is 4KB.
[0052] like Figure 4AAs shown, request instruction 400 includes byte 4, the slave (Rs) address; byte 5, the function and logical unit number (netfn / Lun) to be accessed; byte 6, the first checksum; byte 7, the requester (Rq) address; byte 8, the response sequence and logical unit number (Rq Seq / Lun); byte 9, the instruction (cmd) byte; and byte 18, the second checksum. Bytes 10-17 store the data payload, which in this example is the request instruction.
[0053] Figure 4B The display shows a response of 450, transmitted from CPU 110 to... Figure 3 The crash dump hardware device 112 is used. Response 450 is presented in IPMB format and can therefore be read according to the instructions of the crash dump hardware device 112. In this example, response 450 has five 20-byte segments. Response 450 includes byte 1, the requester (Rq) address; byte 2, the function and logical unit number (netfn / Lun) to be accessed; byte 3, the first checksum; byte 4, the slave (Rs) address; byte 5, the response sequence and logical unit number (Rq Seq / Lun); byte 6, the instruction (cmd) byte; byte 7, the error check (CCODE); and byte 19, the second checksum. Bytes 8-18 store the data payload, which in this example is the error data from the CPU 110 management engine.
[0054] Upon receiving response 450, the crash dump hardware device 112 reads data from the CPU 110 (e.g., data from model-specific registers) and stores the error data in storage device 114. A technician can read all error data presented in IPMB format from storage device 114. The technician can use comparison tools on this error data to quickly determine the cause of the CPU 110 failure.
[0055] Figure 5 This is a flowchart showing the process... Figure 2 The general flow of error signal handling by the specific crash log hardware device 112 in the CPU 110 is as follows: When an error occurs in the CPU 110, an error signal (e.g., a CATERR event signal) is transmitted to the GPIO pin 122 (step 510). This routine determines whether a signal is received from the GPIO pin 122 (step 512). If no error signal is received, the automatic crash log function remains disabled (step 514). If an error signal is received, the crash log function of the crash log hardware device 112 is activated (step 516). Then, the crash log hardware device 112 transmits an IPMB request instruction via the bus 120.
[0056] When CPU 110 receives the IPMB request instruction via bus 120, CPU 110 sends back relevant program code error data to crash save hardware device 112 (step 518). Crash save hardware device 112 uses bus 120 to store the error data in storage device 114. Therefore, technicians can read the data from storage device 114 to determine the CPU error message and error type. This data helps resolve problems causing CPU crashes. Once these error messages are stored in storage device 114, the automatic crash save function is disabled (step 514).
[0057] Figure 5 The flowchart in the diagram represents example machine-readable instructions used for Figure 2 The crash dump hardware device 112 in the example is used for error detection and logging. In this example, the machine-readable instructions include an algorithm executed by: (a) a processor; (b) a controller; and / or (c) one or more other suitable processing devices. The algorithm can be implemented in software and stored in a tangible medium, such as flash memory, CD-ROM, floppy disk, hard disk, DVD, or other storage device. However, those skilled in the art will readily recognize that the algorithm, in whole or in part, can also be implemented in a known manner (e.g., by means of application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable logic devices (FPLDs), field-programmable gate arrays (FPGAs), discrete logic gates, etc.) by a device other than a processor, and / or in the form of firmware or dedicated hardware. For example, any or all of the components of such interfaces can be implemented in software, hardware, and / or firmware. Furthermore, some or all of the machine-readable instructions represented by the foregoing flowchart can be implemented manually. Moreover, although the example algorithm is based on... Figure 5 The flowchart shown is used to illustrate the invention; however, those skilled in the art will readily recognize that various other methods can be used to implement these exemplary machine-readable instructions. For example, the flowchart may be modified. Figure 5 The execution order of each block, and / or the blocks may be changed, removed, or merged.
[0058] As used in this patent application, the terms "component," "module," "system," or similar terms generally refer to a computer-related entity that may be hardware (e.g., circuitry), a combination of hardware and software, software, or an entity associated with an operating machine having one or more specific functions. For example, a component may be, but is not limited to, a program, a processor, an object, an executable file, a thread, a program, and / or a computer operating on a processor (e.g., a digital signal processor). For instance, an application running on a controller and the controller itself can both be a component. One or more components may reside within a program and / or a thread, and a component may reside within a computer and / or be distributed among two or more computers. Furthermore, a "device" may be implemented in the form of specifically designed hardware, specific general-purpose hardware (which performs specific functions by executing software on it), software stored on a computer-readable medium, or a combination of the various entities described above.
[0059] Although several embodiments of the invention have been described above, it should be noted that these embodiments are presented as examples only and not as limitations. While one or more embodiments of the invention have been illustrated and described, those skilled in the art will recognize equivalent modifications or alterations upon reading and understanding this specification and the accompanying drawings. Furthermore, although a particular feature of the invention may be disclosed only in one of several embodiments, that feature may be combined with other features in one or more other embodiments if desired or advantageous for any given or particular application. Therefore, the breadth and scope of the invention should not be limited to any of the foregoing embodiments. Rather, the scope of the invention should be defined by the following claims and their equivalents.
[0060] The vocabulary used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. Unless otherwise specified herein, the singular words “a,” “an,” and “the” used in this specification are intended to include the plural words as well. Furthermore, the words “comprising,” “including,” “having,” and “having” used in “implementation” and / or claims are intended to refer to an inclusive meaning, similar to the word “comprising.”
[0061] Unless otherwise defined, all terms used in this specification (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. Furthermore, terms that are defined, for example, in common dictionaries, should be interpreted as having the same meaning as in their relevant technical context, unless explicitly defined in this specification, and should not be interpreted in an idealized or overly formal manner.
Claims
1. A computer system comprising: a central processing unit operable to transmit an error signal, the central processing unit comprising a management engine configured to collect error data; a crash dump device coupled to the central processing unit and configured to receive the error signal; a storage device coupled to the crash dump device; and a bus coupled to the storage device, the central processing unit and the crash dump device; wherein the crash dump device is configured to: in response to receiving the error signal, transmit an error data request to the central processing unit; in response to the error data request, receive the error data from the central processing unit; and store the error data in the storage device, wherein the storage device is configured to store instructions for the crash dump device to transmit the error data request in a predetermined communication protocol and to receive the error data in the predetermined communication protocol over the bus, wherein the crash dump device comprises a general purpose input / output (GPIO) pin configured to receive the error signal from the central processing unit, in a normal operating state, the crash dump device is always detecting whether the error signal is present on the general purpose input / output (GPIO) pin, when the crash dump device detects the error signal on the general purpose input / output (GPIO) pin, a crash dump function is initiated; and the management engine is interrogated for all data from model specific registers of the central processing unit.
2. A method of recording error data from a central processing unit of a computer system, the method comprising: transmitting an error signal from the central processing unit; receiving the error signal with a crash dump device coupled to the central processing unit; in response to receiving the error signal, transmitting an error data request by the crash dump device to the central processing unit via a bus, wherein the bus is coupled to a storage device, the central processing unit and the crash dump device; in response to the error data request, receiving the error data from the central processing unit; storing the received error data in the storage device coupled to the crash dump device, wherein the storage device is configured to store instructions for the crash dump device to transmit the error data request in a predetermined communication protocol and to receive the error data in the predetermined communication protocol over the bus, wherein the crash dump device comprises a general purpose input / output (GPIO) pin configured to receive the error signal from the central processing unit, in a normal operating state, the crash dump device is always detecting whether the error signal is present on the general purpose input / output (GPIO) pin, when the crash dump device detects the error signal on the general purpose input / output (GPIO) pin, a crash dump function is initiated; and the management engine is interrogated for all data from model specific registers of the central processing unit.
3. A dedicated crash dump hardware device comprising: a general purpose input / output (GPIO) pin configured to receive an error signal from a central processing unit; a bus interface in communication with a bus, the bus coupled to the central processing unit and a storage device; and a bus interface in communication with a bus, the bus coupled to the central processing unit and a storage device; and A crash dump circuit operable to: in response to receiving the error signal at the bus interface, transmit an error data request to the central processing unit; in response to receiving the error data request, receive the error data from the central processing unit via the bus interface; and store the error data in the storage device via the bus, wherein the storage device is configured to store instructions for the crash dump circuit to transmit the error data request in a predetermined communication protocol and to receive the error data in the predetermined communication protocol at the bus, wherein in a normal operating state, the crash dump circuit is always detecting whether the error signal is present on the input / output GPIO pin, and when the crash dump circuit detects the error signal on the input / output GPIO pin, initiates a crash dump function and issues a query to a management engine of the central processing unit for all data from model specific registers of the central processing unit.
Citation Information
Patent Citations
Method for acquiring crash information through black box, black box and server
CN102622322A
LZO compression method and system for abnormal log dump
CN108563719A