A watchdog feeding method and system in a Linux system

Abstract

A watchdog feeding method and system in a Linux system, the system comprising a Linux application module, a Linux kernel module and an external watchdog module; the Linux kernel module comprising a watchdog thread management unit and an interrupt management unit; the external watchdog module comprising a fast feeding and a slow feeding, the CPU core connecting the fast feeding and the slow feeding; the Linux application module binding the CPU core through multiple real-time threads and feeding software, and interacting with the watchdog thread management unit; the watchdog thread management unit monitoring the state of each CPU core feeding thread; when the CPU occupancy rate exceeds the threshold, the feeding thread is blocked or exited, the feeding thread scheduling timeout, the Linux kernel is abnormal, the interrupt management unit respectively performs the inter-core migration of the feeding timer and the adjustment of the feeding period, the watchdog reset, and the watchdog circuit switching. The running reliability and fault event traceability of the Linux embedded board are improved.

Description

Technical Field

[0001] This invention belongs to the field of Linux system anomaly protection technology, and relates to a watchdog feeding method and system in Linux system. Background Technology

[0002] A watchdog timer is a mechanism to ensure the normal operation of a system or to exit abnormal states such as infinite loops and deadlocks. It is mainly used to monitor the operating status of a microcontroller and resolve program-related faults. Watchdogs are divided into hardware watchdogs and software watchdogs. A hardware watchdog uses a timer circuit whose timing output is connected to the circuit's reset terminal. The program resets the timer within a certain time range (commonly known as "feeding the dog"). Therefore, when the program is working normally, the timer should not overflow and thus should not generate a reset signal. If the program malfunctions and fails to reset the watchdog within the timing period, the watchdog timer overflows, generating a reset signal and restarting the system. A software watchdog works on the same principle, but replaces the hardware timer with the processor's internal timer. This simplifies hardware circuit design, but its reliability is not as good as a hardware timer; for example, it may not detect a fault in the system's internal timer itself.

[0003] Traditional Linux external watchdog GPIO feeding methods typically only implement hardware feeding in an application thread or interrupt, without monitoring each core of Linux SMP, logging watchdog timeout events, or handling system exceptions. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a watchdog feeding method and system in Linux systems, designed for anomaly protection of Linux applications and systems, primarily applied to embedded CPU boards. By monitoring the watchdog feeding thread of each CPU core, more comprehensive fault monitoring of the Linux system is achieved; hardware watchdog interrupts facilitate inter-core migration and dynamic adjustment of the watchdog feeding cycle, better ensuring load balancing of the Linux system; external hardware watchdog switching in the event of system anomalies effectively records abnormal events and supports abnormal kernel dumping; thus improving the operational reliability and fault event traceability of Linux embedded boards.

[0005] The present invention adopts the following technical solution:

[0006] A method for feeding a watchdog timer in a Linux system, the Linux system including a Linux application module, a Linux kernel module, and an external watchdog module; wherein, the Linux kernel module includes a watchdog feeding thread management unit and an interrupt management unit; the external watchdog module includes a fast watchdog timer and a slow watchdog timer, and the CPU core of the Linux system is simultaneously connected to both the fast and slow watchdog timers; the method includes the following steps:

[0007] Step 1: The Linux application module binds to the CPU core through multiple real-time threads and feeds the doggill via software, interacting with the doggill feeding thread management unit;

[0008] Step 2: The dog-feeding thread management unit monitors the status of the dog-feeding thread for each CPU core, including whether the CPU utilization exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out.

[0009] Step 3: When the CPU utilization rate exceeds the threshold, the interrupt management unit performs inter-core migration of the watchdog timer and adjusts the watchdog timer cycle;

[0010] Step 4: When the watchdog feeding thread is blocked or exits, or when the watchdog feeding thread scheduling times out, record the event and stop feeding the watchdog to trigger a watchdog reset;

[0011] Step 5: When a Linux kernel exception occurs, the interrupt management unit switches the watchdog circuit from a fast watchdog to a slow watchdog.

[0012] The present invention further includes the following preferred embodiments:

[0013] Preferably, the CPU core connects to both the fast watchdog and the slow watchdog simultaneously via two GPIO ports. When the Linux system is running normally, the fast watchdog is enabled and fed, while the slow watchdog is disabled.

[0014] The fast watchdog timer uses a 1.3s timeout reset duration, while the slow watchdog timer uses a configurable timeout reset duration of 30s-60s.

[0015] Preferably, the interrupt management unit manages the watchdog interrupt timer of each CPU core, and only one CPU core's watchdog interrupt timer is active at any given time.

[0016] Preferably, in step 1, the application module starts a real-time watchdog feeding thread for each CPU core, and the thread is bound to the CPU core; each watchdog feeding thread interacts with the watchdog feeding thread management unit, and the watchdog feeding thread management unit monitors the watchdog feeding status of each CPU core.

[0017] Preferably, the inter-core migration of the dog feeding timer and the adjustment of the dog feeding cycle in step 3 specifically refer to:

[0018] Select the CPU core with the lowest CPU utilization and switch to that CPU core's timer feeder. The feeder cycle for the new CPU core's timer is determined based on the CPU utilization of the newly switched CPU core, using the following formula:

[0019]

[0020] Among them, T wdiThis refers to the watchdog timer feeding cycle for the newly switched CPU core, i.e., the actual watchdog feeding cycle for GPIO.

[0021] P cpu The CPU utilization rate of the newly switched CPU core;

[0022] T0 is the watchdog timeout reset duration.

[0023] Preferably, in step 4, when the watchdog feeding thread management unit detects that the application watchdog feeding thread is blocked or exits, it indicates that the application watchdog feeding state is abnormal. Then, the interrupt management unit records the application abnormal event in the storage area of ​​the external memory and stops the watchdog feeding action to trigger the watchdog reset.

[0024] Preferably, in step 4, if the watchdog feeding thread management unit detects that the application watchdog feeding thread scheduling has timed out, indicating that the CPU core where the thread is located is deadlocked, then the interrupt management unit records the CPU core deadlock event in the storage area of ​​external memory, and then stops the watchdog feeding action to trigger the watchdog reset.

[0025] Preferably, step 4 further includes: when the system reboots, the interrupt management unit forces a watchdog reset after the watchdog delay time T1.

[0026] Preferably, in step 5, when the Linux kernel encounters an error, the kernel watchdog module switches the watchdog circuit to a slow watchdog, and then performs error log collection and memory dump.

[0027] A Linux system that runs the above-described watchdog feeding method, the Linux system comprising a Linux application module, a Linux kernel module, and an external watchdog module;

[0028] The Linux kernel module includes the dog-feeding thread management unit and the interrupt management unit;

[0029] The external watchdog module includes a fast watchdog and a slow watchdog. The CPU core in the Linux system is connected to both the fast watchdog and the slow watchdog.

[0030] The Linux application module interacts with the dog-feeding thread management unit to bind CPU cores through multiple real-time threads and feed the dog via software.

[0031] The dog-feeding thread management unit is used to monitor the status of the dog-feeding thread for each CPU core, including whether the CPU utilization rate exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out.

[0032] The interrupt management unit is used to perform inter-core migration of the watchdog timer and adjustment of the watchdog cycle when the CPU utilization exceeds the threshold; record events and stop watchingdog when the watchdog thread is blocked or exits or when the watchdog thread scheduling times out, so as to trigger watchdog reset; and switch the watchdog circuit from fast watchdog to slow watchdog when the Linux kernel is abnormal.

[0033] The beneficial effects of this invention are as follows: compared with existing technologies, it achieves monitoring of each CPU core by binding the CPU watchdog to multiple core threads in Linux; it achieves system load balancing through inter-core migration of watchdog interrupts and adjustment of the watchdog cycle; and it provides ample time for system exception log dumping and exception handling through slow watchdog switching. This invention is applicable to general-purpose embedded boards of Linux systems with external watchdog modules, balancing the watchdog's monitoring strength and exception handling capabilities, and can effectively improve the operational reliability and fault event traceability of Linux embedded boards. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the watchdog feeding principle in the Linux system of this invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this invention. The embodiments described in this application are merely some embodiments of this invention, and not all embodiments. Based on the spirit of this invention, other embodiments obtained by those skilled in the art without creative effort are all within the protection scope of this invention.

[0036] like Figure 1 As shown, Embodiment 1 of the present invention provides a watchdog feeding method in a Linux system. In a preferred but non-limiting embodiment of the present invention, the Linux system includes a Linux application module, a Linux kernel module, and an external watchdog module; wherein, the Linux kernel module includes a watchdog feeding thread management unit and an interrupt management unit; the external watchdog module includes a fast watchdog and a slow watchdog, and the CPU core in the Linux system is connected to both the fast watchdog and the slow watchdog simultaneously;

[0037] More preferably, the CPU core connects to both a fast watchdog timer and a slow watchdog timer simultaneously via two GPIO ports. During normal Linux system operation, the fast watchdog timer is enabled and fed, while the slow watchdog timer is disabled.

[0038] The fast watchdog timer uses a 1.3s timeout reset duration, while the slow watchdog timer uses a configurable timeout reset duration of 30s-60s.

[0039] The interrupt management unit manages the watchdog interrupt timer of each CPU core, and only one CPU core's watchdog interrupt timer is active at any given time.

[0040] That is, each CPU core is bound to a timer, and only one timer interrupt function is used to feed the external fast watchdog circuit or slow watchdog circuit via GPIO at any given time;

[0041] The watchdog feeding method in the Linux system includes the following steps:

[0042] Step 1: The Linux application module binds to the CPU core through multiple real-time threads and feeds the doggill via software, interacting with the doggill feeding thread management unit;

[0043] At this time, each CPU core in the Linux user-space process is bound to a real-time thread, and several real-time threads simultaneously feed the Linux kernel module via software.

[0044] The application module starts a real-time watchdog feeding thread for each CPU core, and the thread is bound to the CPU core.

[0045] Each dog-feeding thread interacts with the dog-feeding thread management unit, which monitors the dog-feeding status of each CPU core.

[0046] Step 2: The dog-feeding thread management unit monitors the status of the dog-feeding thread for each CPU core, including whether the CPU utilization exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out.

[0047] Step 3: When the CPU utilization rate exceeds the threshold, the interrupt management unit performs inter-core migration of the watchdog timer and adjusts the watchdog timer cycle;

[0048] More preferably, if the current CPU core load exceeds the threshold, the watchdog timer management unit will notify the interrupt management unit to migrate the watchdog timer to other CPU cores and adjust the hardware watchdog cycle according to the CPU core load.

[0049] The inter-core migration of the dog-feeding timer and the adjustment of the dog-feeding cycle are specifically as follows:

[0050] Select the CPU core with the lowest CPU utilization and switch to that CPU core's timer feeder. Determine the feeder cycle for the new CPU core's timer based on the CPU utilization of the newly switched CPU core.

[0051]

[0052] Among them, T wdi This refers to the watchdog timer feeding cycle for the newly switched CPU core, i.e., the actual watchdog feeding cycle for GPIO.

[0053] P cpu The CPU utilization rate of the newly switched CPU core;

[0054] T0 is the watchdog timeout reset duration.

[0055] Step 4: When the watchdog feeding thread is blocked or exits, or when the watchdog feeding thread scheduling times out, the interrupt management unit records the event and stops feeding the watchdog to trigger a watchdog reset;

[0056] More preferably, when the dog-feeding thread management unit detects that the application's dog-feeding thread is blocked or exits, it indicates that the application's dog-feeding state is abnormal and all dog-feeding threads exit. Then, the interrupt management unit records the application's abnormal exit event in the storage area of ​​the external memory and stops the dog-feeding action to trigger a system reset.

[0057] If the dog-feeding thread management unit detects a timeout in the application's dog-feeding thread scheduling, indicating that the CPU core where the thread resides is deadlocked, the interrupt management unit will record the CPU core deadlock event in the external memory storage area and then stop the dog-feeding action to trigger a system reset.

[0058] In addition, during system reboot, the interrupt management unit forces a watchdog reset after the watchdog delay time T1.

[0059] Therefore, the triggering conditions for watchdog reset can be summarized as follows:

[0060] 1. An abnormal application watchdog feeding status causes all watchdog feeding threads to exit, manifesting as the application watchdog feeding threads being blocked or exiting:

[0061] The interrupt management unit records the application's abnormal exit event in the storage area of ​​external memory, and then stops the dog-feeding action to trigger a system reset;

[0062] 2. A CPU core deadlocks, manifested as a timeout in the application's dog-feeding thread scheduling:

[0063] If the watchdog timer for a CPU application times out, the interrupt management unit records the CPU deadlock event in the external memory storage area and then stops the watchdog timer to trigger a system reset.

[0064] 3. System reboot

[0065] During system reboot, the interrupt management unit provides a forced watchdog reset function after a watchdog delay of T1 time to prevent reboot from being blocked;

[0066] The above 1-3 correspond to reset events: Event 1) All CPU core watchdog feeding threads time out (application exception), record the event in external memory and immediately stop hardware watchdog feeding; Event 2) A certain CPU core watchdog feeding thread times out (CPU core deadlock); Event 3) System reboot.

[0067] Step 5: If the Linux kernel malfunctions, the interrupt management unit switches the external watchdog circuit to a slow watchdog.

[0068] More preferably, when the Linux kernel encounters an error, the kernel watchdog module switches to the slow watchdog circuit of the external watchdog module, and then performs error log collection and memory dump.

[0069] When a Linux kernel crashes abnormally, the kernel watchdog module switches to the slow watchdog circuit 1 of the external watchdog module. Then, exception log collection and memory dumping are performed. In other words, when the Linux system crashes abnormally, the exception handling switches to the slow watchdog, allowing sufficient time for the system to complete exception logging and system memory dumping. Specifically, when a Linux kernel exception occurs, the interrupt management unit switches to watchdog circuit 1 of the external watchdog module. Within the watchdog circuit 1's feeding cycle T2, system exception logging and kernel memory dumping are completed, and the exception event is recorded in the external storage area.

[0070] like Figure 1 As shown, Embodiment 2 of the present invention provides a Linux system for running the watchdog feeding method, the Linux system including a Linux application module, a Linux kernel module and an external watchdog module;

[0071] The Linux kernel module includes the dog-feeding thread management unit and the interrupt management unit;

[0072] The external watchdog module includes a fast watchdog and a slow watchdog. The CPU core in the Linux system is connected to both the fast watchdog and the slow watchdog.

[0073] The Linux application module interacts with the dog-feeding thread management unit to bind CPU cores through multiple real-time threads and feed the dog via software.

[0074] The dog-feeding thread management unit is used to monitor the status of the dog-feeding thread for each CPU core, including whether the CPU utilization rate exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out.

[0075] The interrupt management unit is used to perform inter-core migration of the watchdog timer and adjustment of the watchdog cycle when the CPU utilization exceeds the threshold; record events and stop watchingdog when the watchdog thread is blocked or exits or when the watchdog thread scheduling times out, so as to trigger watchdog reset; and switch the watchdog circuit from fast watchdog to slow watchdog when the Linux kernel is abnormal.

[0076] The beneficial effects of this invention are as follows: compared with existing technologies, it achieves monitoring of each CPU core by binding the CPU watchdog to multiple core threads in Linux; it achieves system load balancing through inter-core migration of watchdog interrupts and adjustment of the watchdog cycle; and it provides ample time for system exception log dumping and exception handling through slow watchdog switching. This invention is applicable to general-purpose embedded boards of Linux systems with external watchdog modules, balancing the watchdog's monitoring strength and exception handling capabilities, and can effectively improve the operational reliability and fault event traceability of Linux embedded boards.

[0077] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0078] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0079] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0080] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0081] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0082] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0083] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for feeding a watchdog in a Linux system, wherein the Linux system includes a Linux application module, a Linux kernel module, and an external watchdog module; wherein, The Linux kernel module includes a watchdog thread management unit and an interrupt management unit; the external watchdog module includes a fast watchdog and a slow watchdog, and the CPU core in the Linux system is connected to both the fast and slow watchdogs simultaneously; its features are: The method includes the following steps: Step 1: The Linux application module binds to the CPU core through multiple real-time threads and feeds the doggill via software, interacting with the doggill feeding thread management unit; Step 2: The dog-feeding thread management unit monitors the status of the dog-feeding thread for each CPU core, including whether the CPU utilization exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out. Step 3: When the CPU utilization rate exceeds the threshold, the interrupt management unit performs inter-core migration of the watchdog timer and adjusts the watchdog timer feeding cycle; the inter-core migration of the watchdog timer and the adjustment of the watchdog timer feeding cycle are specifically as follows: Select the CPU core with the lowest CPU utilization and switch to that CPU core's timer feeder. The feeder cycle for the new CPU core's timer is determined based on the CPU utilization of the newly switched CPU core, using the following formula: Among them, T wdi This refers to the watchdog timer feeding cycle for the newly switched CPU core, i.e., the actual watchdog feeding cycle of the GPIO; P cpu T0 represents the CPU utilization of the newly switched CPU core; T0 represents the watchdog timeout reset duration. Step 4: When the watchdog feeding thread is blocked or exits, or when the watchdog feeding thread scheduling times out, record the event and stop feeding the watchdog to trigger a watchdog reset, including: When the watchdog feeding thread management unit detects that the application watchdog feeding thread is blocked or exits, it indicates that the application watchdog feeding state is abnormal. The interrupt management unit then records the application exception event in the storage area of ​​external memory and stops the watchdog feeding action to trigger a watchdog reset. If the watchdog feeding thread management unit detects that the application's watchdog feeding thread scheduling has timed out, indicating that the CPU core where the thread is located is deadlocked, the interrupt management unit will record the CPU core deadlock event in the storage area of ​​external memory and then stop the watchdog feeding action to trigger a watchdog reset. Step 5: When a Linux kernel exception occurs, the interrupt management unit switches the watchdog circuit from a fast watchdog to a slow watchdog, including: When a Linux kernel exception occurs, the kernel watchdog module switches the watchdog circuit to a slow watchdog, and then performs exception log collection and memory dump.

2. The method for feeding a watchdog in a Linux system according to claim 1, characterized in that: The CPU core connects to both the fast watchdog and the slow watchdog simultaneously via two GPIO ports. When the Linux system is running normally, the fast watchdog is enabled and fed, while the slow watchdog is disabled. The fast watchdog timer uses a 1.3s timeout reset duration, while the slow watchdog timer uses a configurable timeout reset duration of 30s-60s.

3. The method for feeding a watchdog in a Linux system according to claim 1, characterized in that: The interrupt management unit manages the watchdog interrupt timer of each CPU core, and only one CPU core's watchdog interrupt timer is active at any given time.

4. The method for feeding a watchdog in a Linux system according to claim 1, characterized in that: In step 1, the application module starts a real-time watchdog feeding thread for each CPU core, and the thread is bound to the CPU core; each watchdog feeding thread interacts with the watchdog feeding thread management unit, and the watchdog feeding thread management unit monitors the watchdog feeding status of each CPU core.

5. A method for feeding a watchdog in a Linux system according to claim 1, characterized in that: Step 4 also includes: when the system reboots, the interrupt management unit forces a watchdog reset after the watchdog delay time T1.

6. A Linux system that runs the watchdog feeding method according to any one of claims 1-5, characterized in that: The Linux system includes a Linux application module, a Linux kernel module, and an external watchdog module; The Linux kernel module includes the dog-feeding thread management unit and the interrupt management unit; The external watchdog module includes a fast watchdog and a slow watchdog. The CPU core in the Linux system is connected to both the fast watchdog and the slow watchdog. The Linux application module interacts with the dog-feeding thread management unit to bind CPU cores through multiple real-time threads and feed the dog via software. The dog-feeding thread management unit is used to monitor the status of the dog-feeding thread for each CPU core, including whether the CPU utilization rate exceeds the threshold, whether the dog-feeding thread is blocked or exits, and whether the dog-feeding thread scheduling times out. The interrupt management unit is used to perform inter-core migration of the watchdog timer and adjustment of the watchdog cycle when the CPU utilization exceeds the threshold; record events and stop watchingdog when the watchdog thread is blocked or exits or when the watchdog thread scheduling times out, so as to trigger watchdog reset; and switch the watchdog circuit from fast watchdog to slow watchdog when the Linux kernel is abnormal.

Images