Abnormal restart processing method and device, and related equipment

Abstract

Embodiments of the present disclosure provide an abnormal restart processing method and device, electronic equipment, storage medium and program product. The method comprises: in response to an abnormal restart event of a kernel of an operating system, triggering a panic processing flow; in the panic processing flow, obtaining an abnormal restart reason and encoding the abnormal restart reason to obtain a restart reason code; and / or, collecting register context information of each central processing unit (CPU) core; and writing the restart reason code and / or the register context information of each CPU core into a non-volatile storage area, so as to solve the technical problem that in related technologies, the restart reason and all CPU core state information cannot be recorded completely when the Linux system abnormally restarts, and improve the efficiency and accuracy of system fault diagnosis.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to an abnormal restart handling method, apparatus, and related equipment. Background Technology

[0002] In modern data center network environments, network devices use the Linux operating system as a critical infrastructure. The stability and reliability of the Linux operating system are of paramount importance, but in actual operation, the system may crash and restart unexpectedly due to hardware failures, software defects, resource exhaustion, and other reasons.

[0003] When an operating system crashes or restarts unexpectedly, the panic handling technology can only output error messages in text format and cannot perform fault analysis.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] This disclosure provides an abnormal restart handling method, apparatus, electronic device, storage medium, and program product to improve the efficiency and accuracy of system fault diagnosis.

[0006] According to a first aspect of the present disclosure, an abnormal restart handling method is provided, comprising: triggering a panic handling process in response to an abnormal restart event occurring in the kernel of the operating system; in the panic handling process, obtaining the cause of the abnormal restart and encoding it to obtain a restart cause code; and / or, collecting the register context information of each CPU (Central Processing Unit) core; and writing the restart cause code and / or the register context information of each CPU core into a non-volatile storage area.

[0007] In some embodiments, in the panic processing flow, obtaining the abnormal restart reason and encoding it to obtain the restart reason code includes: in the panic processing flow, obtaining the abnormal restart reason and encoding it according to a preset encoding structure to obtain the restart reason code; wherein, the preset encoding structure includes at least one of the following: a first field representing the type of normal restart reason, a second field representing the subtype under the abnormal restart reason type, a fourth field representing the abnormal restart trigger source, and a fourth field representing the abnormal level.

[0008] In some embodiments, encoding the restart reason code according to a preset encoding structure includes: filling the encoding value corresponding to the type to which the abnormal restart reason belongs into the first field; filling the encoding value corresponding to the subtype to which the abnormal restart reason belongs into the second field; filling the encoding value corresponding to the triggering source of the abnormal restart reason into the third field; and filling the exception level corresponding to the abnormal restart event into the fourth field to obtain the restart reason code.

[0009] In some embodiments, the CPU core includes an online CPU core; in the panic processing flow, collecting the register context information of each CPU core includes: sending a disable interrupt signal to each online CPU core, wherein the disable interrupt signal is used to instruct each online CPU core to stop using local interrupts and save the register context information; in response to each online CPU core stopping interrupt completion, collecting the register context information of each online CPU core.

[0010] In some embodiments, if the operating system adopts a first instruction set architecture, the registers include at least one of the following: a first quantity general-purpose register, an exception level-related register, an exception diagnosis register, a program counter, and a status register.

[0011] In some embodiments, if the operating system adopts a second instruction set architecture, the registers include at least one of the following: a second quantity general-purpose register, an instruction pointer and identity register, a debug register, a model-specific register, and a control register.

[0012] In some embodiments, writing the abnormal restart cause code and / or the register context information of each CPU core into the non-volatile storage area includes: writing the restart cause code and / or the register context information of each CPU core into the non-volatile storage area according to a preset storage format; wherein, the preset storage format includes: a data header, a data record area, and a data tail, the data header is used to store metadata related to the abnormal restart event, the data record area is used to record the restart cause code and / or the register context information of each CPU core, and the data tail is used to store verification data.

[0013] In some embodiments, the non-volatile storage area includes at least one of the following: non-volatile random access memory (NVRAM), the storage area of ​​the baseboard management controller (BMC), serial peripheral interface flash memory, the storage area corresponding to the scalable firmware interface variables, and reserved memory for the capture kernel.

[0014] In some embodiments, the method further includes: triggering the operating system to execute a restart process in response to the end of the panic processing flow; reading the restart reason code and / or the register context information of each CPU core in the storage area in response to the successful restart of the operating system; and generating an abnormal restart event report based on the restart reason code and / or the register context information of each CPU core.

[0015] In some embodiments, generating an abnormal restart event report based on the restart reason code and / or the register context information of each CPU core includes: decoding the restart reason code to obtain the type and subtype of the abnormal restart reason, the abnormal restart trigger source, and the exception level; determining the processing level of the abnormal restart event and the CPU core that triggered the abnormal restart event based on the abnormal restart trigger source and the exception level; restoring the register context information of each CPU core according to the instruction set architecture of the operating system; performing call stack backtracking based on the CPU core that triggered the abnormal restart event and the register context information of each CPU core to obtain the target call stack; determining fault location information based on the type and subtype of the abnormal restart reason, the processing level of the abnormal restart event, and the target call stack; and generating an abnormal restart event report based on at least two of the following: the type and subtype of the abnormal restart reason, the register context information of each CPU core, the target call stack, and the fault location information.

[0016] According to a second aspect of the present disclosure, an abnormal restart processing apparatus is provided, comprising: an abnormal detection module, configured to trigger a panic processing flow in response to an abnormal restart event occurring in the kernel of the operating system; a data acquisition module, configured to acquire the cause of the abnormal restart and encode it to obtain a restart cause code during the panic processing flow; and / or to acquire register context information of each CPU core; and a data storage module, configured to write the restart cause code and / or the register context information of each CPU core into a non-volatile storage area.

[0017] According to a third aspect of the present disclosure, an electronic device is provided, characterized in that it includes: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement the abnormal restart processing method of any of the above.

[0018] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform any of the above-described abnormal restart processing methods or any of the above-described video quality assessment methods.

[0019] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that is executed by a processor as any of the above-described abnormal restart processing methods.

[0020] The abnormal restart handling method provided in this disclosure first triggers a panic handling process in response to an abnormal restart event in the operating system kernel. Then, within the panic handling process, the cause of the abnormal restart is obtained and encoded to obtain a restart cause code; and / or, the register context information of each CPU core is collected; finally, the restart cause code and / or the register context information of each CPU core is written to a non-volatile storage area. This solves the technical problem in the prior art where the Linux system cannot completely record the restart cause and the status information of all CPU cores during an abnormal restart, significantly improving the efficiency and accuracy of system fault diagnosis.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 A schematic diagram of an exemplary system architecture to which the abnormal restart handling method of the present disclosure embodiments can be applied is shown.

[0024] Figure 2 This is a flowchart illustrating an abnormal restart handling method according to an exemplary embodiment.

[0025] Figure 3 This is a flowchart illustrating another abnormal restart handling method according to an exemplary embodiment.

[0026] Figure 4 This is a schematic diagram illustrating a restart reason encoding structure according to an exemplary embodiment.

[0027] Figure 5 This is a flowchart illustrating a register context information acquisition method according to an exemplary embodiment.

[0028] Figure 6 This is a schematic diagram of a register under the ARM64 architecture according to an exemplary embodiment.

[0029] Figure 7 This is a schematic diagram of a register under an x86_64 architecture according to an exemplary embodiment.

[0030] Figure 8This is a flowchart illustrating the recording of abnormal restart reasons and CPU core context information according to an exemplary embodiment.

[0031] Figure 9 This is a flowchart illustrating yet another abnormal restart handling method according to an exemplary embodiment.

[0032] Figure 10 This is a schematic diagram illustrating a data storage format according to an exemplary embodiment.

[0033] Figure 11 This is a flowchart illustrating an abnormal restart analysis according to an exemplary embodiment.

[0034] Figure 12 This is a system that records the reason for device restart and CPU multi-core status register information when Linux restarts abnormally, according to an exemplary embodiment.

[0035] Figure 13 This is a block diagram illustrating an abnormal restart processing apparatus according to an exemplary embodiment.

[0036] Figure 14 This is a schematic diagram illustrating the structure of an electronic device suitable for implementing exemplary embodiments of the present disclosure, according to an exemplary embodiment. Detailed Implementation

[0037] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0038] The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more specific details omitted, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0039] The accompanying drawings are merely illustrative of this disclosure, and the same reference numerals in the drawings denote the same or similar parts, thus omitting repeated descriptions of them. Some block diagrams shown in the drawings do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in at least one hardware module or integrated circuit, or in different network and / or processor devices and / or microcontroller devices.

[0040] The flowchart shown in the accompanying drawings is merely illustrative and does not necessarily include all content and steps, nor does it require execution in the described order. For example, some steps may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0041] In this specification, the terms “a,” “an,” “the,” “the,” and “at least one” are used to indicate the presence of at least one element / component / etc.; the terms “comprising,” “including,” and “having” are used to indicate an open-ended inclusion and to mean that there may be other elements / components / etc. in addition to the listed elements / components / etc.; the terms “first,” “second,” and “third,” etc., are used only as markings and are not a limitation on the number of objects.

[0042] Figure 1 A schematic diagram of an exemplary system architecture to which the abnormal restart handling method of the present disclosure embodiments can be applied is shown.

[0043] like Figure 1 As shown, the system architecture may include server 101, network 102, terminal device 103, terminal device 104, and terminal device 105. Network 102 serves as the medium for providing a communication link between terminal device 103, terminal device 104, or terminal device 105 and server 101. Network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0044] Server 101 can be a server that provides various services, such as a back-end management server that supports the devices operated by users using terminal devices 103, 104, or 105. The back-end management server can analyze and process received requests and other data, and feed back the processing results to terminal devices 103, 104, or 105.

[0045] Terminal devices 103, 104, and 105 can be smartphones, tablets, laptops, desktop computers, smart speakers, wearable smart devices, virtual reality devices, augmented reality devices, etc., but are not limited to these.

[0046] In this embodiment of the disclosure, server 101 may: trigger a panic handling process in response to an abnormal restart event of the operating system kernel; in the panic handling process, obtain the cause of the abnormal restart and encode it to obtain a restart cause code; and / or collect the register context information of each central processing unit (CPU) core; and write the restart cause code and / or the register context information of each CPU core into a non-volatile storage area.

[0047] It should be understood that Figure 1 The number of terminal devices 103, 104, 105, network 102, and server 101 in the diagram is merely illustrative. Server 101 can be a single physical server, a server cluster consisting of multiple servers, or a cloud server. Depending on actual needs, it can have any number of terminal devices, networks, and servers.

[0048] The following will describe in more detail the steps of the abnormal restart handling method in the exemplary embodiments of this disclosure, with reference to the accompanying drawings and examples. The method provided in the embodiments of this disclosure can be executed by any electronic device, such as the one described above. Figure 1 The server and / or terminal equipment in the process, but this disclosure does not limit this.

[0049] Figure 2 This is a flowchart illustrating an abnormal restart handling method according to an exemplary embodiment. Figure 2 The method provided in the embodiments can be executed by any electronic device, such as those described above. Figure 1 Terminal devices in or Figure 1 The server in, or Figure 1 The terminal devices and servers in the process execute together, but this disclosure does not limit this. For example... Figure 2 As shown, the abnormal restart handling method provided in this embodiment mainly includes steps S202-S206.

[0050] In S202, a panic handling process is triggered in response to an abnormal kernel reboot event in the operating system.

[0051] An operating system can refer to a system software program that manages computer hardware and software resources. In this embodiment, the Linux system is used as an example for illustration, and the kernel of the operating system can refer to any version of the Linux kernel.

[0052] An abnormal restart event can refer to a system restart process that is not actively triggered by the user due to an unrecoverable error in the Linux system kernel. The opposite of an abnormal restart is a normal shutdown or normal restart.

[0053] Panic handling refers to a set of exception handling procedures executed by the Linux system kernel after an unrecoverable error occurs. Panic handling is mainly used to suspend normal system operation, record error information, drive system reset or stop, etc., to prevent the spread of errors or data corruption.

[0054] In one possible implementation, when the Linux system kernel detects an unrecoverable error during runtime, it calls the `panic()` function to proactively trigger a panic handling process. Internally, the `panic()` function sequentially calls callbacks registered on the `panic_notifier_list`. In this embodiment, these callbacks are used to perform structured encoding of the restart reason and collection of register context information during the panic handling process, before the system reboots, and write this information to a non-volatile storage area.

[0055] In S204, during the panic handling process, the cause of the abnormal restart is obtained and encoded to obtain the restart cause code; and / or, the register context information of each CPU core is collected.

[0056] The cause of an abnormal restart can refer to the triggering source, exception type, exception level, etc., which trigger this abnormal restart event. For example, the cause of an abnormal restart can be hardware failure, software logic error, system resource exhaustion, and external forced events.

[0057] The register context information of a CPU core can refer to the set of current values ​​of registers defined by the internal architecture of each CPU core when an abnormal restart event occurs.

[0058] In this embodiment, during the panic processing flow, the cause of the abnormal restart is obtained and encoded to obtain the restart cause code; or, during the panic processing flow, the register context information of each CPU core is collected; or, during the panic processing flow, the cause of the abnormal restart is obtained and encoded to obtain the restart cause code, and the register context information of each CPU core is collected.

[0059] Encoding the cause of abnormal restarts refers to converting unstructured text information, raw status codes, or semantically ambiguous kernel error codes into standardized numerical codes. This avoids the risk of writing variable-length fields to other fields and also facilitates subsequent fault analysis.

[0060] Since the restart reason code is a standardized representation of the cause of an abnormal restart, it can accurately characterize the type, source, and level of the exception that triggered the abnormal restart. The register context information of the CPU core represents a snapshot of the registers inside each CPU core at the time of the abnormal restart event. Therefore, fault diagnosis information can be generated by analyzing the restart reason code and the register context information of the CPU core.

[0061] In S206, the reboot reason code and / or the register context information of each CPU core are written to the non-volatile memory area.

[0062] Non-volatile storage areas refer to storage spaces whose contents can still be retained after the power to the Linux system is turned off.

[0063] In one possible implementation, after obtaining the reboot reason code and the register context information of each CPU core, the above data is encapsulated and serialized according to a preset storage format, and the encapsulated data block is written to a non-volatile storage area.

[0064] When an abnormal reboot occurs in the Linux system kernel, a reboot cause encoding and recording mechanism is triggered through a panic handling process. The reboot cause is encoded to obtain a reboot cause code, and complete register context information of each CPU core is collected. The collected reboot cause code and complete register context information of the multi-core CPU cores are written to a non-volatile storage area in a preset format. This enables the root cause of the fault after the abnormal reboot to be traced and analyzed, solving the technical problem that the reboot cause and all CPU core status information cannot be completely recorded when the Linux system is abnormally rebooted, and improving the efficiency and accuracy of system fault diagnosis.

[0065] In some embodiments, the optimized abnormal restart handling method mainly includes the following steps S302-S306.

[0066] In S302, a panic handling process is triggered in response to an abnormal kernel reboot event in the operating system.

[0067] In S304, during the panic handling process, the cause of the abnormal restart is obtained and encoded according to a preset encoding structure to obtain the restart cause encoding; wherein, the preset encoding structure includes at least one of the following: a first field representing the type of abnormal restart cause, a second field representing the subtype under the abnormal restart cause type, a fourth field representing the source of the abnormal restart trigger, and a fourth field representing the level of the abnormality.

[0068] In this embodiment, as Figure 4As shown, the preset encoding structure includes a 64-bit encoding, which is divided into four fields by bits for the restart reason encoding. Each field is used to carry different fault information. Specifically, bits [7:0] represent the main type of abnormal restart reason, bits [15:5] represent the subtype under the main type of abnormal restart reason, bits [19:16] represent the fault level, bits [27:20] represent the CPU core ID, bits [31:28] represent 4 reserved bits, and bits [63:32] represent the PID.

[0069] Specifically, such as Figure 4 As shown in Table 1, the first field represents the type of abnormal restart reason, including 8 bits (bits [7:0]). The 8-bit encoding is used to distinguish the main type of abnormal restart reason; for example: 0x01 represents a kernel crash, 0x02 represents an OOPS exception (recoverable), 0x03 represents a hardware exception, 0x04 represents a software watchdog timeout, 0x05 represents a hard lock-up, 0x06 represents a soft lock-up, 0x07 represents a BUG_ON assertion failure, 0x08 represents a manual trigger, and 0xFF represents an unknown reason.

[0070] Table 1

[0071] Furthermore, the first field mainly includes 9 types of abnormal restart reasons, and reserves extension bits to support up to 256 main types of abnormal restart reasons.

[0072] The second field represents the subtype under the main type of abnormal restart reason, including 8 bits (bit[15:8]). Taking the abnormal restart reason type as kernel panic as an example, the corresponding configured subtypes include: 0x0101 represents memory allocation failure, 0x0102 represents page fault that cannot be handled, 0x0103 represents kernel stack overflow, 0x0104 represents scheduler deadlock, 0x0104 represents clock interrupt loss, etc. Furthermore, it can be expanded to support 256 fault subtypes.

[0073] The third field, the trigger source identifier, is represented in structure form, including: a 32-bit process ID (PID), a 16-bit task name, an interrupt context identifier, and an 8-bit CPU core ID. The CPU core ID is used to record the number of the CPU corresponding to the fault trigger, the PID is used to store the process identifier of the fault-related process, and information such as the task name and interrupt context identifier helps to locate the source of the fault.

[0074] The fourth field represents the exception level information field, which is used to identify the operating level at which the fault occurred. It consists of 4 bits (bit[19:16]): EL0 represents user mode, EL1 represents kernel mode, EL2 represents virtual machine monitor, and EL3 represents security monitor.

[0075] In this embodiment, when an abnormal restart event occurs in the Linux system, multi-dimensional information such as the main type, subtype, exception level, and trigger source of the current abnormal restart cause is collected. The information of each dimension is mapped and filled into the corresponding fields according to the above-mentioned 64-bit layered preset encoding structure, and a complete 64-bit restart cause code is generated by splicing. This facilitates the automatic parsing of fault logs and fault tracing.

[0076] In some embodiments, encoding the restart reason code according to a preset encoding structure includes: filling the encoding value corresponding to the type to which the abnormal restart reason belongs into the first field; filling the encoding value corresponding to the subtype to which the abnormal restart reason belongs into the second field; filling the encoding value corresponding to the triggering source of the abnormal restart reason into the third field; and filling the exception level corresponding to the abnormal restart event into the fourth field to obtain the restart reason code.

[0077] During the restart reason encoding process, after obtaining the abnormal restart reason, the 8-bit encoded value corresponding to the main type of the abnormal restart reason is written into the first field of the encoding structure; the 8-bit encoded value corresponding to the subtype under the main type is written into the second field of the encoding structure; the relevant identification information of the trigger source of this abnormal restart is written into the third field of the encoding structure; the 4-bit encoded value corresponding to the exception level is written into the fourth field of the encoding structure; after completing the filling of the encoded values ​​of all fields, the bit segments of each field are concatenated and integrated according to the preset bit order to finally obtain the 64-bit restart reason code.

[0078] In S306, the reboot reason code and / or the register context information of each CPU core are written to the non-volatile memory area.

[0079] In some embodiments, such as Figure 5 As shown, collecting the register context information of each CPU core mainly includes steps S502-S504.

[0080] In S502, an interrupt disable signal is sent to each online CPU core. The interrupt disable signal is used to instruct each online CPU core to stop using local interrupts and save the context information of the registers.

[0081] An online CPU core refers to a CPU core that has been added to the system scheduling domain and is currently in an active working state during Linux system operation. In the Panic processing flow, only online CPU cores are sent with a disable interrupt signal to avoid performing invalid operations on uninitialized CPU cores.

[0082] Disabling interrupt signals can refer to control messages sent by the master core executing the Panic process to other online CPU cores via inter-processor interrupts (IPI) or maskable interrupts (NMI).

[0083] The main core executing the Panic process sends an interrupt disable signal to all other online CPU cores. Upon receiving the interrupt disable signal, each online CPU core sets its local interrupt mask register, preventing it from responding to subsequent interrupt requests or inter-core interrupt requests. After disabling interrupts, the online CPU core copies the current values ​​of all its registers from the processor's internal registers to its dedicated memory buffer in a specific format.

[0084] In some embodiments, if the operating system adopts a first instruction set architecture, the registers include at least one of the following: a first quantity general-purpose register, an exception level-related register, an exception diagnosis register, a program counter, and a status register.

[0085] The first instruction set architecture can refer to the ARM64 architecture under the Linux system, such as... Figure 6 As shown in Table 2, the register set contains at least four types of registers.

[0086] Specifically, the first category consists of a large number of general-purpose registers, including 31 64-bit general-purpose registers (X0~X30), used for data operations, address calculations, platform reservation, and linked storage. The second category comprises registers related to exception levels, including the stack pointer register SP_ELx, the exception link return address register ELR_ELx, and the exception saved status register SPSR_ELx corresponding to the four exception levels EL0, EL1, EL2, and EL3. The third category consists of exception diagnostic registers, including the exception synthesis feature register ESR_ELx, used to encode and store the root cause of the exception; the fault virtual address register FAR_ELx, used to record the virtual memory address that triggered the exception; and the thread local storage pointer register TPIDR_ELx, used to store the corresponding thread ID and TLS pointer to locate the exception triggering scenario and associated thread. The fourth category is the program counter and status-related registers, including: the program counter PC, which records the address of the instruction being executed when the exception occurs; the stack pointer SP, which records the address of the instruction being executed when the exception occurs; and the processor status register PSTATE, which records and stores the processor state, as well as the NZCV condition flag and exception mask, to restore the program execution and basic processor state before the exception occurred.

[0087] Table 2

[0088] In some embodiments, if the operating system adopts a second instruction set architecture, the registers include at least one of the following: a second quantity general-purpose register, an instruction pointer and identity register, a debug register, a model-specific register, and a control register.

[0089] The second instruction set architecture can refer to the x86_64 architecture under the Linux system, such as... Figure 7 As shown in Table 3, the x86_64 architecture register set includes at least the following five types of registers.

[0090] Specifically, the first category consists of the second number of general-purpose registers, including 16 64-bit general-purpose registers: RAX, RBX, RCX, RDX, RSI, RDI, RBP, and RSP basic general-purpose registers, as well as eight groups of extended registers (R8-R15). These are used for arithmetic operations, data storage, source indexing, target indexing, stack base address and stack top pointer, and other data processing and address management functions, and are used to retain the computation and memory access context at the time of exceptions. The second category consists of instruction pointer and flag registers, including the instruction pointer register RIP, which stores the address of the next instruction to be executed when an exception occurs; and the flag register RFLAGS, which carries various condition control flags such as carry, zero value, and interrupt to restore the program execution flow and processor state. The third category consists of debug registers, including the DR0, DR1, DR2, and DR3 hardware breakpoint address registers and the DR6 and DR7 debug control status registers, used to capture fault debugging information in hardware breakpoint trigger scenarios. The fourth category is Model-Specific Registers (MSRs), including: Extended Function Enable Register MSR_EFER, System Call Target Register MSR_STAR, and Long Mode System Call Register MSR_LSTAR, used to record processor long mode and system call related configuration parameters. The fifth category is Control Registers, including: Processor Mode Control Register CR0, Page Fault Linear Address Register CR2, and Page Directory Base Address Register CR3, used to store key memory management parameters such as paging protection mechanisms, page fault addresses, and memory paging base addresses; additionally, six segment registers (CS, DS, ES, FS, GS, and SS) are used to record code, data, and stack segment selection information.

[0091] Table 3

[0092] In S504, in response to the completion of interrupts for each online CPU core, the register context information of each online CPU core is collected.

[0093] In one possible implementation, after sending a disable interrupt signal, the main core enters a timeout polling loop. In this loop, the main core checks the status flags in the per_cpu data structure corresponding to each online CPU core. If all flags are set within a set threshold, it is determined that all online CPU cores have stopped interrupt completion; the register context information of each online CPU core is then collected. If a timeout occurs, a timeout error is recorded for the CPU core that has not yet responded, and that core is skipped in subsequent data collections, or only data from cores that have been successfully saved is collected.

[0094] Figure 8 A flowchart illustrating the implementation of acquiring CPU core context information is shown, such as... Figure 8 As shown, the main steps include: In S801, the panic() function is called.

[0095] In response to an abnormal kernel reboot, the panic() function is called.

[0096] In S802, local interrupts are disabled.

[0097] Call the local_irq_disable() function to disable local interrupts.

[0098] In S803, set the global panic flag.

[0099] Set the global panic flag to indicate that the system is entering the kernel crash handling process.

[0100] In S804, the restart reason code is used.

[0101] Call the classify_reboot_reason() function to encode the reboot reason.

[0102] In S805, a stop IPI is sent to all online CPU cores.

[0103] The arm64_send_nmi_stop() function is called to send a stop IPI interrupt signal to all online CPU cores.

[0104] In S806, each online CPU core receives an IPI interrupt.

[0105] Each online CPU core receives a stop IPI interrupt via the panic_cpu_stop_handler function.

[0106] In S807, each CPU core collects context information from all registers.

[0107] The `collect_cpu_registers()` function is called to collect context information for all registers of this CPU.

[0108] In S808, the CPU is marked as saved successfully.

[0109] The atomic operation `atomic_inc (&cpus_stopped)` marks the completion of saving the current CPU core registers.

[0110] In S809, the main CPU waits for all cores to stop.

[0111] After the main CPU core sends the IPI signal, it runs the wait_for_cpus_stop() function to wait for all slave CPU cores to complete register saving.

[0112] The waiting logic is configured with a 5-second timeout mechanism. If there are still CPU cores that have not been saved after 5 seconds, the waiting process will be exited directly to prevent the process from getting stuck.

[0113] In the S810, the register status of each CPU is collected and triggered.

[0114] After the waiting phase ends, the main CPU calls collect_cpu_registers(current_cpu) to collect the context information of all registers of each online CPU that triggered this panic process.

[0115] In S811, data is saved to a non-volatile storage area.

[0116] Calling save_to_persistent_storage() writes the reboot reason code, context information of each CPU core register, etc., to a non-volatile storage area to achieve persistent storage.

[0117] In S812, a system restart operation is performed.

[0118] The machine_restart() function is called to restart the entire system, and the process ends.

[0119] In some embodiments, the optimized abnormal restart handling method includes steps S902-S912.

[0120] In S902, a panic handling process is triggered in response to an abnormal kernel reboot event in the operating system.

[0121] In S904, during the panic handling process, the cause of the abnormal restart is obtained and encoded to obtain the restart cause code; and / or, the register context information of each CPU core is collected.

[0122] In S906, the reboot reason code and / or the register context information of each CPU core are written to the non-volatile memory area according to the preset storage format.

[0123] The preset storage format includes a data header, a data record area, and a data tail. The data header is used to store metadata related to the abnormal restart event, the data record area is used to record the restart reason code and / or the register context information of each CPU core, and the data tail is used to store verification data.

[0124] like Figure 10 As shown, the storage format used in this embodiment includes: a data header, a restart reason record area, a CPU core status record area, and a data tail.

[0125] The data header is implemented using the structure struct reboot_reason_header, which internally stores the magic number identifier (0x52425248), version number, header size, total data size, checksum, architecture type, timestamp, etc., to identify the start of data, distinguish data version and hardware architecture, statistical data size, and provide a basis for global data verification.

[0126] The reboot reason record area is implemented using the structure struct reboot_reason_record, which stores the reboot reason code, including: main type code, subtype code, exception level, triggering CPU core ID, triggering PID, task name, and panic message digest, to fully retain the reboot root cause and fault context information after standardization coding.

[0127] The CPU core status record area stores the independent status records of CPU0, CPU1, and so on up to CPU(N-1) in sequence according to the CPU core number. The context information structure of each CPU core register is consistent, including: CPU status header, 31 64-bit general-purpose registers X0-X30, PC / SP / PSTATE register, four-level EL stack pointer SP_ELx, exception link register ELR_ELx, exception save status register SPSR_ELx, exception diagnosis registers ESR_ELx and FAR_ELx, which completely record the register snapshot of each CPU core at the moment of exception.

[0128] The data footer is implemented using the structure struct reboot_reason_footer, which includes: the end magic number (0x454E4421) and the footer checksum, used to identify the end point of data storage. Together with the header checksum, it achieves two-layer data integrity verification.

[0129] In some embodiments, the non-volatile storage area includes at least one of the following: non-volatile random access memory (NVRAM), the storage area of ​​the baseboard management controller (BMC), serial peripheral interface flash memory, the storage area corresponding to the scalable firmware interface variables, and reserved memory for the capture kernel.

[0130] In this embodiment, different priorities are set for various storage schemes, as shown in Table 4. The highest priority from highest to lowest is: NVRAM storage, BMC storage, SPI Flash storage, EFI variable storage, and reserved memory crashkernel.

[0131] NVRAM storage is suitable for server platforms. The motherboard has built-in non-volatile memory, ensuring data retention even during power outages, providing optimal data reliability. BMC storage is suitable for servers and switches, accessible via the IPMI interface, and supports remote reading of fault logs. SPI Flash storage is suitable for embedded and network devices, offering the advantage of low hardware deployment costs. EFI variable storage is suitable for systems with UEFI firmware, utilizing UEFI runtime services for data writing and reading. Crashkernel reserved memory is a universal storage solution across all platforms. It uses the kdump kernel dump mechanism to lock fault data in reserved memory during system crashes, allowing for the retrieval of fault information after device restart.

[0132] In this embodiment, based on the storage media available on the current hardware platform, the system can automatically select available storage media to write fault data such as restart reasons and register status according to the priority from high to low, prioritizing high-priority storage solutions that ensure fault data is not lost and support remote operation and maintenance.

[0133] Table 4

[0134] In S908, in response to the end of the panic handling process, the operating system is triggered to execute the restart process.

[0135] In this embodiment, after the kernel panic process ends, the Linux system reset interface is called to trigger the restart process.

[0136] In the S910, in response to a successful operating system reboot, the reboot reason code and / or register context information of each CPU core are read from the storage area.

[0137] During the Linux system reboot and kernel initialization phase, the `truct reboot_reason_record` structure in the storage area is read through the platform driver interface to obtain the reboot reason code, and the context information of each core register is read by traversing the CPU status record area.

[0138] In S912, an abnormal reboot event report is generated based on the reboot reason code and / or the register context information of each CPU core.

[0139] Data is read from non-volatile memory to generate an analysis report that includes register values, call stack backtracking, and fault location suggestions.

[0140] In some embodiments, generating an abnormal restart event report based on the restart reason code and / or the register context information of each CPU core includes steps S1102-S1112.

[0141] In S1102, the restart reason code is decoded to obtain the type and subtype of the abnormal restart reason, the abnormal restart trigger source, and the exception level.

[0142] The original data is read from the non-volatile storage area, and the header magic number (0x52425248) and tail magic number (0x454E4421) are checked sequentially. The overall checksum is calculated and compared with the stored value. If the check fails, the data is marked as corrupted, and only the usable part is output; if the check passes, the corresponding register parsing template is selected according to the architecture type field in the header.

[0143] The `reboot_reason_record` structure is parsed, mapping the main type encoding and subtype encoding to a readable fault classification description. The PID, task name, CPU core ID, and interrupt context identifier are extracted from the trigger source identifier structure to locate the process / thread and CPU core where the exception occurred. The exception level field is then used to determine whether the exception occurred in EL1 (kernel mode), EL2 (virtualization layer), EL3 (security monitoring layer), or x86 Ring0 / Ring3.

[0144] In S1104, the processing level of the abnormal restart event and the CPU core that triggered the abnormal restart event are determined based on the abnormal restart trigger source and the abnormal level.

[0145] In S1106, the register context information of each CPU core is restored according to the instruction set architecture of the operating system.

[0146] Traverse the CPU core status record area in CPU core ID order. For the ARM64 architecture, restore the X0-X30 general-purpose registers, PC, SP, PSTATE, and exception level registers such as ELRELx (exception return address), ESRELx (exception syndrome), and FARELx (fault address). For the x8664 architecture, restore the general-purpose registers, RIP, RFLAGS, CR2 (page fault address), and CR3 (page table base address). Label the functional meaning of each register value and provide a semantic interpretation of the current value.

[0147] In S1108, based on the CPU core that triggered the abnormal restart event and the register context information of each CPU core, call stack backtracking is performed to obtain the target call stack.

[0148] Focusing on the CPU core that triggered the panic, the call stack is traced back using the following method.

[0149] For ARM64: Using SPEL1 as the base address, and combining the FP (X29) register chain and PC value, backtrack the stack frame by frame. Use the exception type encoding in ESRELx to determine the root cause of the exception (such as data exception, alignment exception, synchronization external abort, etc.).

[0150] For x86_64: Using RSP as the base address, and combining the RBP frame pointer chain and RIP value, the stack frames are traced back frame by frame. CR2 is used to determine if it is a page fault, and error codes are used to distinguish between page faults, protection exceptions, write conflicts, etc.

[0151] For other online CPU cores, the same backtrace is performed based on their respective SP and FP / RBP for cross-core correlation analysis (such as detecting mutual waiting caused by deadlock and CPU stall caused by RCU stall).

[0152] The backtracked instruction addresses are resolved into function names and offsets using a symbol table (vmlinux or .ko files under / modules / ), generating a readable call stack.

[0153] In S1111, fault location information is determined based on the type and subtype of the cause of the abnormal restart, the processing level of the abnormal restart event, and the target call stack.

[0154] Based on the main type of the restart reason and the call stack information, the system automatically matches the preset fault mode rule base and generates location suggestions.

[0155] Kernel panic type: Extract the BUG / KASAN / UBSAN keywords from the panic message and combine them with the call stack to locate the specific source file and line number.

[0156] Hardware exception type: Analyze the EC field (exception type) and ISS field (instruction-specific syndrome) of ESR_ELx, or the MCE error code of x86, to determine whether it is a memory ECC error, a bus error, or an internal CPU error.

[0157] Watchdog / Deadlock Type: Analyze the call stack of each CPU core to see if there is a lock-holding and waiting loop, and mark the lock objects suspected of deadlock and the relationship between the holders / waiters.

[0158] Cross-validation: When multiple CPU core call stacks point to the same lock object or the same critical section, output cross-core deadlock correlation analysis conclusions.

[0159] In S1112, an abnormal restart event report is generated based on at least two of the following: the type and subtype of the cause of the abnormal restart, the register context information of each CPU core, the target call stack, and the fault location information.

[0160] All the above analysis results are summarized into a structured report, including: a summary of the restart cause (main type / subtype / exception level / trigger source), a table of register values ​​for each CPU core, a call stack backtrace diagram for each core, and a list of fault location suggestions. The report is output in JSON format for automated tools and in readable text format for manual analysis.

[0161] Figure 12 This disclosure provides a system for recording the reason for a device restart and CPU multi-core status register information when Linux experiences an abnormal restart, such as... Figure 12 As shown, the system includes the following core modules: Anomaly detection module: Monitors the running status of the Linux kernel and triggers a panic handling process when an abnormal kernel event is detected.

[0162] Restart Reason Encoding Module: In the panic handling process, the reasons for abnormal restarts are classified and encoded in multiple dimensions to generate restart reason codes.

[0163] SMP Stop Control Module: Sends a stop signal to all online CPU cores through the SMP stop mechanism, causing each CPU core to enter a frozen state.

[0164] Register acquisition module: Acquires complete register context information for each CPU core.

[0165] Data storage module: Writes the restart reason code and all CPU core register contexts into the non-volatile memory area in a preset format.

[0166] System restart module: Performs system restart operation after completing data recording.

[0167] Data parsing module: After system restart, it reads and parses the data recorded in the non-volatile storage area.

[0168] Fault Analysis Module: Generates fault analysis reports based on parsed register context information.

[0169] This disclosure provides a method and system for recording the cause of a device restart and CPU multi-core status register information during a Linux abnormal restart. The method includes: triggering a restart cause classification and recording mechanism through a panic handling path when an abnormal restart event occurs in the Linux kernel; classifying and encoding the restart cause in multiple dimensions, including kernel panic type, trigger source, and exception level; coordinating all CPU cores to enter a frozen state through an SMP stop mechanism, and collecting complete register context information for each CPU core, including general-purpose registers (X0-X30), program counter (PC), stack pointer (SP), processor state (PSTATE), exception level-related registers (ELR_EL1 / EL2 / EL3, SPSR_EL1 / EL2 / EL3, SP_EL0 / EL1), and system control registers; and writing the collected restart cause encoding and multi-core CPU status information into a persistent storage area according to a preset format to ensure that the root cause of the fault after the abnormal restart can be traced and analyzed. This invention solves the technical problem in the prior art that Linux systems cannot completely record the restart cause and all CPU core status information during abnormal restarts, improving the efficiency and accuracy of system fault diagnosis.

[0170] In one specific implementation, `panic_notifier_list` is the notification chain in the Linux kernel panic process. When `panic()` is executed, it iterates through the callback functions on this chain. In this implementation, a hook function is registered using `INT_MAX` (highest priority). This function internally connects the core logic: `panic()` is called, the kernel iterates through `panic_notifier_list`, and the subsequent panic process (timeout restart). The hook function executes the following sequentially: ① Restart reason classification encoding; ② SMP stop (sending IPI / NMI); ③ Full kernel register sampling; ④ Writing to non-volatile memory; and other low-priority notification chain callbacks (such as `kdump`).

[0171] The purpose of the INT_MAX priority is to ensure that the acquisition logic of this scheme is executed before other panic handlers such as kdump, so as to avoid kdump modifying the register state or preempting memory when capturing the kernel, and to ensure that the raw register context acquired is not contaminated.

[0172] The beneficial effects of the technical solutions in the embodiments of this disclosure: (1) Improved fault diagnosis efficiency: Through structured restart cause coding, the fault location time is shortened by more than 80%, supporting the development of automated fault diagnosis tools.

[0173] (2) Enhanced multi-core fault analysis capability: Completely collect the register status of all online CPU cores, support cross-core correlation analysis (such as deadlock, race conditions), and cover scenarios that cannot be detected by soft deadlock mechanisms such as hard deadlock.

[0174] (3) Strong architecture compatibility: It supports mainstream server architectures such as ARM64 and x86_64. The unified storage format facilitates cross-platform tool development and is easy to extend to other architectures such as RISC-V and PowerPC.

[0175] (4) Improved reliability: Through multiple non-volatile storage back-ends, data retention is ensured in power failure scenarios, and BMC remote access is supported for offline fault analysis.

[0176] (5) The technical solution in this embodiment does not replace kdump, but completes lightweight structured collection in real time in the panic processing path. Compared with kdump, which requires starting the capture kernel, it has lower latency and lighter data format.

[0177] The following are embodiments of the apparatus disclosed herein, which can be used to execute embodiments of the method disclosed herein. For details not disclosed in the apparatus embodiments of this disclosure, please refer to the embodiments of the method disclosed herein.

[0178] Figure 13 This is a block diagram illustrating an abnormal restart handling apparatus according to an exemplary embodiment. (Refer to...) Figure 9 The device may include: an anomaly detection module 1310, used to trigger a panic processing flow in response to an abnormal restart event in the kernel of the operating system; a data acquisition module 1320, used to obtain the cause of the abnormal restart and encode it to obtain a restart cause code in the panic processing flow; and / or to acquire the register context information of each CPU core; and a data storage module 1330, used to write the restart cause code and / or the register context information of each CPU core into a non-volatile storage area.

[0179] In some embodiments, the data acquisition module 1320 includes a restart reason acquisition and encoding unit, used to acquire the abnormal restart reason in the panic processing flow and encode it according to a preset encoding structure to obtain the restart reason code; wherein, the preset encoding structure includes at least one of the following: a first field representing the type of normal restart reason, a second field representing the subtype under the abnormal restart reason type, a fourth field representing the abnormal restart trigger source, and a fourth field representing the abnormal level.

[0180] In some embodiments, the restart reason acquisition and encoding unit is specifically used to fill the encoding value corresponding to the type to which the abnormal restart reason belongs into the first field; fill the encoding value corresponding to the subtype to which the abnormal restart reason belongs into the second field; fill the encoding value corresponding to the trigger source of the abnormal restart reason into the third field; and fill the exception level corresponding to the abnormal restart event into the fourth field to obtain the restart reason encoding.

[0181] In some embodiments, the CPU core includes an online CPU core; the data acquisition module 1320 includes a CPU core status acquisition unit, which is used to send a disable interrupt signal to each online CPU core, wherein the disable interrupt signal is used to instruct each online CPU core to stop using local interrupts and save the context information of the registers; in response to each online CPU core stopping interrupt completion, the register context information of each online CPU core is acquired.

[0182] In some embodiments, if the operating system adopts a first instruction set architecture, the registers include at least one of the following: a first quantity general-purpose register, an exception level-related register, an exception diagnosis register, a program counter, and a status register.

[0183] In some embodiments, if the operating system adopts a second instruction set architecture, the registers include at least one of the following: a second quantity general-purpose register, an instruction pointer and identity register, a debug register, a model-specific register, and a control register.

[0184] In some embodiments, the data storage module 1330 is specifically used to write the restart reason code and / or the register context information of each CPU core into a non-volatile storage area according to a preset storage format; wherein, the preset storage format includes: a data header, a data record area and a data tail, the data header is used to store metadata related to the abnormal restart event, the data record area is used to record the restart reason code and / or the register context information of each CPU core, and the data tail is used to store verification data.

[0185] In some embodiments, the non-volatile storage area includes at least one of the following: non-volatile random access memory (NVRAM), the storage area of ​​the baseboard management controller (BMC), serial peripheral interface flash memory, the storage area corresponding to the scalable firmware interface variables, and reserved memory for the capture kernel.

[0186] In some embodiments, the system further includes a restart module for triggering the operating system to execute a restart process in response to the end of the panic processing flow; and a restart event analysis module for reading the restart reason code and / or the register context information of each CPU core in the storage area in response to the successful restart of the operating system; and generating an abnormal restart event report based on the restart reason code and / or the register context information of each CPU core.

[0187] In some embodiments, the restart event analysis module is specifically used to decode the restart cause encoding to obtain the type and subtype of the abnormal restart cause, the abnormal restart trigger source, and the exception level; determine the processing level of the abnormal restart event and the CPU core that triggered the abnormal restart event based on the abnormal restart trigger source and the exception level; restore the register context information of each CPU core according to the operating system's instruction set architecture; perform call stack backtracking based on the CPU core that triggered the abnormal restart event and the register context information of each CPU core to obtain the target call stack; determine fault location information based on the type and subtype of the abnormal restart cause, the processing level of the abnormal restart event, and the target call stack; and generate an abnormal restart event report based on at least two of the following: the type and subtype of the abnormal restart cause, the register context information of each CPU core, the target call stack, and the fault location information.

[0188] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0189] The following reference Figure 14 To describe an electronic device 1400 according to such an embodiment of the present disclosure. Figure 14 The electronic device 1400 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0190] like Figure 14 As shown, the electronic device 1400 is manifested in the form of a general-purpose computing device. The components of the electronic device 1400 may include, but are not limited to: at least one processing unit 1410, at least one storage unit 1420, a bus 1430 connecting different system components (including storage unit 1420 and processing unit 1410), and a display unit 1440.

[0191] The storage unit stores program code, which can be executed by the processing unit 1410 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 1410 can perform actions such as... Figure 3 The steps shown. For example, electronic devices can achieve, for instance, the following steps. Figure 3 The steps shown.

[0192] Storage unit 1420 may include readable media in the form of volatile storage units, such as random access memory (RAM) 1421 and / or cache memory 1422, and may further include read-only memory (ROM) 1423.

[0193] Storage unit 1420 may also include a program / utility 1424 having a set (at least one) of program modules 1425, such program modules 1425 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0194] Bus 1430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0195] Electronic device 1400 can also communicate with one or more external devices 1470 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1400, and / or any device that enables electronic device 1400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1450. Furthermore, electronic device 1400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1460. As shown, network adapter 1460 communicates with other modules of electronic device 1400 via bus 1430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0196] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0197] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of the device to perform the described method. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0198] In an exemplary embodiment, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods described above.

[0199] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0200] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for handling abnormal restarts, characterized in that, include: In response to an abnormal kernel reboot event in the operating system, a panic handling process is triggered. In the panic handling process, the reason for the abnormal restart is obtained and encoded to obtain the restart reason code; And / or, collect register context information for each CPU core; Write the reboot reason code and / or the register context information of each CPU core into the non-volatile memory area.

2. The abnormal restart handling method according to claim 1, characterized in that, In the panic handling process, obtaining the cause of the abnormal restart and encoding it to obtain the restart cause code includes: In the panic handling process, the reason for the abnormal restart is obtained and encoded according to a preset encoding structure to obtain the restart reason code; The preset encoding structure includes at least one of the following: a first field representing the type of abnormal restart cause, a second field representing the subtype under the abnormal restart cause type, a third field representing the abnormal restart trigger source, and a fourth field representing the abnormal level.

3. The abnormal restart handling method according to claim 2, characterized in that, The method of encoding the restart reason according to the preset encoding structure includes: Fill the first field with the encoded value corresponding to the type of the abnormal restart reason; Fill the second field with the encoded value corresponding to the subtype to which the abnormal restart reason belongs; Fill the third field with the encoded value corresponding to the trigger source of the abnormal restart reason; The exception level corresponding to the abnormal restart event is filled into the fourth field to obtain the restart reason code.

4. The abnormal restart handling method according to claim 1, characterized in that, The CPU cores include online CPU cores; in the panic processing flow, the collection of register context information for each CPU core includes: Send an interrupt disable signal to each online CPU core, wherein the interrupt disable signal is used to instruct each online CPU core to stop using local interrupts and save the context information of the registers; In response to the completion of the interrupt for each of the online CPU cores, the register context information of each of the online CPU cores is collected.

5. The abnormal restart handling method according to claim 4, characterized in that, If the operating system adopts a first instruction set architecture, the register includes at least one of the following: a first quantity general-purpose register, an exception level-related register, an exception diagnosis register, a program counter, and a status register.

6. The abnormal restart handling method according to claim 4, characterized in that, If the operating system adopts a second instruction set architecture, the registers include at least one of the following: a second quantity general-purpose register, an instruction pointer and identifier register, a debug register, a model-specific register, and a control register.

7. The abnormal restart handling method according to claim 1, characterized in that, The step of writing the abnormal restart cause code and / or the register context information of each CPU core into the non-volatile storage area includes: The reboot reason code and / or the register context information of each CPU core are written into the non-volatile storage area according to the preset storage format. The preset storage format includes a data header, a data record area, and a data tail. The data header is used to store metadata related to the abnormal restart event. The data record area is used to record the restart reason code and / or the register context information of each CPU core. The data tail is used to store verification data.

8. The abnormal restart handling method according to claim 1, characterized in that, The non-volatile storage area includes at least one of the following: non-volatile random access memory (NVRAM), the storage area of ​​the baseboard management controller (BMC), the serial peripheral interface flash memory, the storage area corresponding to the scalable firmware interface variables, and the reserved memory of the capture kernel.

9. The abnormal restart handling method according to claim 1, characterized in that, Also includes: In response to the completion of the panic handling process, the operating system is triggered to execute a restart process; In response to the successful restart of the operating system, the restart reason code and / or the register context information of each CPU core are read from the storage area; An abnormal restart event report is generated based on the restart reason code and / or the register context information of each CPU core.

10. The abnormal restart handling method according to claim 9, characterized in that, The step of generating an abnormal restart event report based on the restart reason code and / or the register context information of each CPU core includes: Decode the restart reason code to obtain the type and subtype of the abnormal restart reason, the abnormal restart trigger source, and the exception level; Based on the abnormal restart trigger source and the abnormal level, determine the processing level of the abnormal restart event and the CPU core that triggered the abnormal restart event; Based on the instruction set architecture of the operating system, reconstruct the register context information of each CPU core; Based on the CPU core that triggered the abnormal restart event and the register context information of each CPU core, a call stack backtracking is performed to obtain the target call stack; Based on the type and subtype of the cause of the abnormal restart, the processing level of the abnormal restart event, and the target call stack, the fault location information is determined. An abnormal restart event report is generated based on at least two of the following: the type and subtype of the cause of the abnormal restart, the register context information of each CPU core, the target call stack, and the fault location information.

11. An abnormal restart handling device, characterized in that, include: The anomaly detection module is used to respond to an abnormal kernel reboot event in the operating system and trigger a panic handling process. The data acquisition module is used to obtain the cause of the abnormal restart and encode it to obtain the restart cause code in the panic processing flow; And / or, collect register context information for each CPU core; The data storage module is used to write the reboot reason code and / or the register context information of each CPU core into a non-volatile storage area.

12. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the executable instructions to implement the abnormal restart handling method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the abnormal restart processing method as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the abnormal restart handling method as described in any one of claims 1 to 10.

Images