A test method and computing device for operating system deadlock reset

Abstract

The embodiment of the present application provides a test method and computing device for operating system deadlock reset. In the method, the operating system deadlock is triggered; in the systemd initialization phase of the operating system startup, the operating system reset information recorded in the operating system log is obtained, and it is determined whether the operating system reset information meets the preset conditions. When the operating system reset information meets the preset conditions, the reset number is updated, and it is determined whether the updated reset number reaches the preset reset number. When the updated reset number reaches the preset reset number, it is determined that the operating system passes the deadlock reset test. The accuracy of the test results is improved, the occupation of additional resources is avoided, and the test efficiency is improved.

Description

Technical Field

[0001] The present application relates to the technical field of computing devices, and in particular to a testing method for resetting deadlock of an operating system and a computing device. Background Art

[0002] Operating system deadlock refers to a situation where multiple processes or threads are waiting for each other's resources, causing them to be unable to continue to execute. After the operating system deadlocks, whether it can automatically execute the normal reset process is an important criterion for testing the fault tolerance of the operating system. The industry standard is generally to successfully reset at least 10,000 times in a row.

[0003] Related technology During each test of operating system deadlock reset, the control device (also known as the control machine) sends a deadlock instruction to the computing device (also known as the execution machine) to cause the computing device to trigger deadlock and reset. After sending the deadlock instruction to the computing device, the control device polls to confirm whether the computing device is reset successfully, and when it is determined that the reset is successful, it sends a test command to the computing device to find out whether the operating system reset information of the computing device meets the preset conditions, thereby determining whether the operating system deadlock reset is successful in this test.

[0004] However, the methods in the related art, on the one hand, the fluctuation of the network environment between the control device and the computing device will affect the test results, resulting in low test result accuracy; on the other hand, the control device needs to control the computing device, resulting in high resource usage; on the other hand, the control device needs to continuously poll to confirm whether the computing device is reset successfully, send test commands, and send deadlock instructions, and can only execute the test process through synchronous blocking, resulting in low test efficiency. In other words, the methods in the related art have technical problems such as low test result accuracy, high resource usage, and low test efficiency. Summary of the invention

[0005] The embodiment of the present application provides a test method and computing device for operating system deadlock reset, which improves the accuracy of operating system deadlock reset test results, avoids occupying additional resources, and can improve test efficiency.

[0006] In a first aspect, an embodiment of the present application provides a method for testing an operating system deadlock reset, the method comprising:

[0007] Trigger operating system deadlock;

[0008] During the systemd initialization phase when the operating system is started, obtain the operating system reset information recorded in the operating system log;

[0009] Determine whether the operating system reset information meets the preset conditions;

[0010] When the operating system reset information meets the preset conditions, the reset times are updated;

[0011] Determine whether the number of resets after the update reaches the preset number of resets;

[0012] When the number of resets after the update reaches the preset number of resets, it is determined that the operating system passes the deadlock reset test.

[0013] The beneficial effects of this embodiment: after triggering the operating system deadlock, a new test process can be started during the systemd initialization phase of the operating system startup - obtaining the operating system reset information recorded in the operating system log, determining whether the operating system reset information meets the preset conditions, and updating the reset times when the operating system reset information meets the preset conditions, determining whether the updated reset times reach the preset reset times, and determining that the operating system has passed the deadlock reset test when the updated reset times reach the preset reset times. The method of the embodiment of the present application does not require additional control equipment, and can automatically continue the test process after the operating system deadlock is reset, thereby ensuring that the test is not interrupted and realizing continuous automated testing of operating system deadlock reset in a single-machine test scenario. The accuracy of the test results is improved, the use of additional resources is avoided, and the test efficiency is improved.

[0014] In one implementation, the operating system reset information includes a deadlock type; when the operating system reset information meets a preset condition, updating the reset count includes:

[0015] When the deadlock type is a target deadlock type, the reset times are updated; wherein the deadlock type is a hard lock type or a soft lock type, and the target deadlock type is a hard lock type or a soft lock type.

[0016] Beneficial effects of this implementation: During each test, the deadlock self-healing ability of the operating system is measured from two aspects, namely, whether the operating system can automatically reset after deadlock, and whether the operating system can accurately identify the deadlock type. After the operating system automatically resets, it can be determined whether the deadlock type recorded in the system log is the target deadlock type to determine whether the operating system can accurately identify the deadlock type. When the deadlock type is determined to be the target deadlock type, it is determined that the operating system deadlock reset is successful during this test, so the reset count can be updated.

[0017] In one implementation, the method further includes:

[0018] When the deadlock type is not the target deadlock type, it is determined that the operating system fails the current deadlock reset test.

[0019] The beneficial effect of this implementation is that after the operating system is automatically reset, when it is determined that the deadlock type is not the target deadlock type, it can be determined that the operating system has failed the current deadlock reset test.

[0020] In one implementation, the method further includes:

[0021] When the reset times after the update do not reach the preset reset times, the operating system deadlock is triggered.

[0022] The beneficial effect of this implementation is that when the number of resets after the update does not reach the preset number of resets, it is determined that the operating system needs to be tested further, and the operating system deadlock can be triggered to start the next test operating system deadlock reset process.

[0023] In one implementation, the reset times are stored in a persistent device.

[0024] The beneficial effect of this implementation is that the number of resets can be stored in a persistent device (data is not lost when power is off) to achieve persistence of the number of resets, so that the number of resets can continue to be correctly counted when the test is performed next time.

[0025] In one implementation, triggering an operating system deadlock includes:

[0026] When the target deadlock type is a hard lock type, a hard lock type deadlock condition is generated and the operating system hard lock is triggered; or,

[0027] In the case where the target deadlock type is a soft lock type, a deadlock condition of the soft lock type is generated, and an operating system soft lock is triggered.

[0028] The beneficial effects of this implementation are as follows: when the target deadlock type is a hard lock type, the operating system hard lock can be triggered by generating a hard lock type deadlock condition. When the target deadlock type is a soft lock type, the operating system soft lock can be triggered by generating a soft lock type deadlock condition. The above method can help developers or testers actively trigger operating system deadlocks without having to passively wait for the operating system to occasionally experience deadlock problems, thereby improving test efficiency.

[0029] In one implementation, the method further includes:

[0030] When the operating system reset information does not meet the preset condition, it is determined that the operating system fails the current deadlock reset test.

[0031] The beneficial effect of this implementation is that when the operating system reset information does not meet the preset conditions, it can be directly determined that the operating system has failed the current deadlock reset test, thereby achieving rapid acquisition of test results and improving test efficiency.

[0032] In one implementation, before triggering the operating system deadlock, the method further includes:

[0033] A test software package sent by a receiving control device is used to trigger the operating system to perform a deadlock reset test.

[0034] The beneficial effects of this implementation method: In a cluster test scenario where a computing device and a control device are connected in communication, a test software package sent by the control device can be received. The test software package is used to trigger the operating system to perform a deadlock reset test. Compared with the related art, the control device needs to send deadlock instructions, confirmation instructions and test commands to the computing device by synchronous blocking, which leads to the problems of low test result accuracy, high resource usage and low test efficiency in the test method of the related art. In this application, the control device only needs to send a test software package to the computing device, does not participate in the process of the computing device testing the operating system deadlock reset, and can handle other matters, thereby improving resource utilization, reducing test time, simplifying the test process, saving network bandwidth and improving test efficiency.

[0035] In one implementation, after determining that the operating system passes the deadlock reset test, the method further includes:

[0036] Send a feedback instruction to the control device; the feedback instruction is used to instruct the operating system to pass the deadlock reset test.

[0037] The beneficial effect of this implementation method: in a cluster test scenario where the computing device and the control device are connected in communication, after sending a test software package to the computing device, the control device does not need to participate in the process of the computing device testing the operating system deadlock reset, and can directly wait for the feedback instruction sent by the computing device, and the feedback instruction is used to indicate that the operating system passes the deadlock reset test. Compared with the related art, the control device needs to send deadlock instructions, confirmation instructions and test commands to the computing device in a synchronous blocking manner, resulting in the problems of low test result accuracy, high resource occupation and low test efficiency in the test method in the related art. In this application, the interaction between the computing device and the control device is asynchronous and non-blocking, and the control device does not participate in the process of the computing device testing the operating system deadlock reset, and can handle other matters. Subsequently, based on the feedback instruction sent by the computing device indicating that the operating system passes the deadlock reset test, it can be determined that the operating system passes the deadlock reset test. It improves resource utilization, reduces test time, simplifies the test process, saves network bandwidth, and improves test efficiency.

[0038] In a second aspect, an embodiment of the present application provides a test device for resetting a deadlock of an operating system, comprising:

[0039] A deadlock triggering module, used to trigger an operating system deadlock;

[0040] The deadlock reset service module is used to call the test script module during the systemd initialization phase when the operating system is started;

[0041] A test script module is used to obtain the operating system reset information recorded in the operating system log;

[0042] The test script module is also used to determine whether the operating system reset information meets the preset conditions;

[0043] The test script module is also used to update the reset times when the operating system reset information meets the preset conditions;

[0044] The test script module is also used to determine whether the reset number after the update reaches the preset reset number;

[0045] The test script module is also used to determine that the operating system passes the deadlock reset test when the number of resets after the update reaches a preset number of resets.

[0046] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0047] In one implementation, the operating system reset information includes a deadlock type; and a test script module is specifically used to:

[0048] When the deadlock type is a target deadlock type, the reset times are updated; wherein the deadlock type is a hard lock type or a soft lock type, and the target deadlock type is a hard lock type or a soft lock type.

[0049] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0050] In one implementation, the test script module is further used to:

[0051] When the deadlock type is not the target deadlock type, it is determined that the operating system fails the current deadlock reset test.

[0052] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0053] In one implementation,

[0054] The test script module is also used to call the deadlock trigger module when the reset number after the update does not reach the preset reset number;

[0055] The deadlock triggering module is used to trigger the operating system deadlock.

[0056] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0057] In one implementation, the reset times are stored in a persistent device.

[0058] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0059] In one implementation, the deadlock triggering module is specifically used to:

[0060] When the target deadlock type is a hard lock type, a hard lock type deadlock condition is generated and the operating system hard lock is triggered; or,

[0061] In the case where the target deadlock type is a soft lock type, a deadlock condition of the soft lock type is generated, and an operating system soft lock is triggered.

[0062] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0063] In one implementation,

[0064] The test script module is also used to determine that the operating system fails the current deadlock reset test when the operating system reset information does not meet the preset conditions.

[0065] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0066] In one implementation, the method further includes:

[0067] The transceiver module is used to receive a test software package sent by the control device; the test software package is used to trigger the operating system to perform a deadlock reset test.

[0068] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0069] In one implementation,

[0070] The transceiver module is also used to send feedback instructions to the control device; the feedback instructions are used to instruct the operating system to pass the deadlock reset test.

[0071] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0072] In a third aspect, an embodiment of the present application provides a computing device, the computing device is installed with an operating system for performing a deadlock reset test; the computing device includes a memory and a processor;

[0073] The memory is coupled to the processor;

[0074] Memory is used to store computer instructions;

[0075] The processor is used to execute computer instructions to enable the computing device to implement the operating system deadlock reset test method of the first aspect.

[0076] The computing device provided in the embodiment of the present application can execute the technical solution in the above method embodiment, and its beneficial effects are similar, which will not be repeated here.

[0077] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the test method for resetting the operating system deadlock of the first aspect.

[0078] The computer-readable storage medium provided in the embodiment of the present application can execute the technical solution in the above method embodiment, and its beneficial effects are similar, which will not be repeated here.

[0079] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the test method for resetting an operating system deadlock according to the first aspect.

[0080] The computer program product provided in the embodiment of the present application can execute the technical solution in the above method embodiment, and its beneficial effects are similar and will not be described in detail here. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0082] Figure 1aA logic diagram of an operating system deadlock reset test provided in an embodiment of the present application;

[0083] Figure 1b It is a schematic diagram of application scenarios in related technologies;

[0084] Figure 1c A schematic diagram of an operating system reset process provided in an embodiment of the present application;

[0085] Figure 1d A flowchart of an embodiment of a test method for resetting a deadlock of an operating system in the related art;

[0086] Figure 2a A schematic diagram of an application scenario provided in an embodiment of the present application;

[0087] Figure 2b A schematic diagram of another application scenario provided by an embodiment of the present application;

[0088] Figure 3 A flowchart of a first embodiment of a method for testing a deadlock reset of an operating system provided in an embodiment of the present application;

[0089] Figure 4a A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0090] Figure 4b A flowchart of a second embodiment of a method for testing a deadlock reset of an operating system provided in an embodiment of the present application;

[0091] Figure 5 A flowchart of a third embodiment of a method for testing a deadlock reset of an operating system provided in an embodiment of the present application;

[0092] Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0093] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments made by ordinary technicians in this field under the enlightenment of the embodiments belong to the scope of protection of the present application.

[0094] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0095] Glossary:

[0096] Deadlock: A term in the operating system field that refers to an abnormal state that occurs between multiple processes or threads, in which each process or thread is waiting for a resource, but this resource is occupied by other processes or threads, causing all processes or threads to be unable to continue execution.

[0097] systemd (system deamon): system daemon, an initialization system and service manager under Linux system. Responsible for managing services, systemd can start services managed by systemd at boot time, that is, to achieve automatic startup of services managed by systemd. systemd provides an on-demand startup strategy based on daemon, supports snapshots and system status recovery, and maintains mount and self-mount points. Compared with other service managers, it has more sophisticated control over services and higher efficiency. systemd also provides developers with an interface for custom services, which can manage the functions implemented by developers as services.

[0098] Watchdog: An important mechanism under the Linux system, used to monitor the running status of the operating system and take automatic actions (such as system reset) to restore the normal operation of the operating system when the operating system fails or deadlocks.

[0099] Automated testing: A testing method that automatically performs testing tasks by using software tools and scripts. Its goal is to reduce manual labor, improve testing efficiency, and ensure the quality and stability of the software system.

[0100] Service: specifically refers to a background process or daemon managed by systemd in a Linux system. It usually exists in the form of a service unit. The service configuration file defines the properties of a service, including the service name, description, startup command, dependencies, and other information.

[0101] During the verification phase of the operating system development process, each operating system to be released is considered unknown and needs to undergo certain stress and disaster recovery tests to meet the release standards of high reliability, high stability, and high fault tolerance of the operating system. Deadlock is a classic problem in the operating system field. Once a deadlock occurs, the process or thread will not be able to continue executing, and the entire operating system may also become stagnant, seriously blocking the execution flow of upper-level user services. Therefore, whether the operating system can handle deadlocks in a timely and effective manner is an important manifestation of the reliability of the operating system.

[0102] In order to verify whether the operating system is reliable, we can trigger deadlock continuously to observe whether the operating system can automatically reset after each deadlock. The industry's operating system distribution generally requires that the operating system can complete automatic reset in a deadlock state 10,000 times in a row, that is, there is a standard requirement of "10,000 resets". Figure 1a This is a logic diagram of the operating system deadlock reset test provided by the embodiment of the present application. Figure 1a As shown, when the operating system is in a deadlock state continuously, it is determined whether the operating system can automatically reset continuously. If it can, it is determined that the operating system has the deadlock self-healing ability; if not, it is determined that the operating system does not have the deadlock self-healing ability.

[0103] In a single-machine (single computing device) test scenario, after the operating system is reset, the entire computer system (operating system, programs, and various hardware) will restart and reload the operating system, and the memory will be initialized. When the memory is initialized, the running information of the test script stored in the memory is cleared, and the test script cannot continue to work. In other words, in a single-machine test scenario, it is impossible to continuously test the operating system deadlock reset.

[0104] In the related art, the interaction between a control device (responsible for controlling the test) and a computing device (responsible for executing the test) can be used to implement a continuous test of the operating system deadlock reset.

[0105] Figure 1b Schematic diagram of application scenarios in related technologies. Figure 1b As shown, in this scenario, a control device 10 and a computing device 20 are included.

[0106] Remote login software (using a remote connection tool such as secure shell protocol (SSH)) is installed on both the control device 10 and the computing device 20. The control device 10 can manage the computing device 20 to execute the test process through the remote login software.

[0107] Figure 1c A schematic diagram of an operating system reset process provided in an embodiment of the present application. Figure 1c As shown, the operating system reset process is divided into a basic input output system (BIOS) boot phase, a grand unified bootloader (GURB) boot phase, a systemd initialization phase, and a terminal login phase. In the related art, the control device 10 manages the computing device 20 to perform a test process through remote login software, which occurs during the terminal login phase of the operating system reset process.

[0108] The following is a detailed introduction to the testing method for operating system deadlock reset in the related art.

[0109] Figure 1d The present invention is a flowchart of an embodiment of a test method for resetting deadlock of an operating system in the related art.

[0110] like Figure 1d As shown, in a test process, the control device sends a deadlock instruction to the computing device.

[0111] The computing device triggers the deadlock of the operating system in response to the deadlock instruction. When the operating system is in the deadlock state, based on the watchdog mechanism of the operating system, the operating system is reset to restart when it detects that the operating system is in the deadlock state.

[0112] After the control device sends the deadlock instruction to the computing device, the control device continuously polls the computing device for confirmation instructions to confirm whether the computing device is started (reset).

[0113] If the control device determines that the response instruction sent by the computing device is not received within the preset time range, it can be determined that the operating system has failed the deadlock reset test. The response instruction is an instruction sent by the computing device in response to receiving the confirmation instruction after the operating system deadlock resets.

[0114] If the control device determines that a response instruction sent by the computing device is received within a preset time range, a test instruction may be sent to the computing device.

[0115] The computing device obtains the operating system log in response to the test instruction, and determines whether the operating system reset information in the operating system log meets a preset condition.

[0116] When the operating system reset information in the operating system log does not meet the preset condition, the computing device sends a feedback instruction indicating that the preset condition is not met to the control device. In response to receiving the feedback instruction indicating that the preset condition is not met, the computing device determines that the operating system has not passed the deadlock reset test.

[0117] When the operating system reset information in the operating system log meets the preset condition, the computing device sends a feedback instruction indicating that the preset condition is met to the control device. In response to receiving the feedback instruction indicating that the preset condition is met, the control device updates the reset count.

[0118] The control device determines whether the updated reset number reaches a preset reset number.

[0119] The control device determines that the operating system passes the deadlock reset test when determining that the number of resets after the update reaches the preset number of resets.

[0120] When the control device determines that the number of resets after the update does not reach the preset number of resets, it enters the next round of testing process.

[0121] The test process is repeated continuously until a pass or fail test result is reached.

[0122] That is to say, in the related technology, a control device is used to control the computing device that needs to test the operating system deadlock reset to continuously trigger deadlock and reset, which can solve the problem that the test cannot continue to execute due to memory initialization after the computing device is reset, thereby achieving the purpose of continuously testing the system deadlock reset.

[0123] However, the methods in the related art, on the one hand, the fluctuation of the network environment between the control device and the computing device will affect the test results, resulting in low test result accuracy; on the other hand, the control device is required, resulting in high resource usage; on the other hand, the control device needs to continuously poll to confirm whether the computing device is reset successfully, send test commands, and send deadlock instructions, and can only execute the test process through synchronous blocking, resulting in low test efficiency. In other words, the methods in the related art have technical problems such as low test result accuracy, high resource usage, and low test efficiency.

[0124] Based on the above technical problems, an embodiment of the present application provides a test method for operating system deadlock reset: triggering operating system deadlock, starting the current deadlock reset test process during the systemd initialization phase of the operating system startup - obtaining the operating system reset information recorded in the operating system log, and determining whether the operating system reset information meets the preset conditions. If the operating system reset information in the operating system log meets the preset conditions, update the reset number. Determine whether the updated reset number reaches the preset reset number, and if the updated reset number reaches the preset reset number, determine that the operating system has passed the deadlock reset test. Through the method of the embodiment of the present application, the deadlock reset of the operating system installed on the computing device can be continuously tested by the computing device itself without the need for continuous control by an additional control device.

[0125] The following is a detailed description of the test method for operating system deadlock reset in an embodiment of the present application.

[0126] First, the application scenarios of the embodiments of the present application are described.

[0127] Figure 2a A schematic diagram of an application scenario provided by an embodiment of the present application. Figure 2a As shown, the application scenario is a stand-alone test scenario, which includes a computing device 20. In this scenario, a deadlock reset of the operating system to be tested can be implemented by continuously testing the operating system to be tested through a computing device installed with the operating system to be tested.

[0128] Exemplarily, the computing device may be a server. Exemplarily, from the perspective of architecture, the server may be a rack server, a high-density server, a tower server, or a whole cabinet server; functionally, the server may be a general-purpose server or an artificial intelligence server (AI (artificial intelligence) server), etc. Exemplarily, the artificial intelligence server may be a graphics processing server (GPU (graphics processing unit) server).

[0129] It should be noted that the computing device may also be a terminal device equipped with a Linux kernel, and illustratively, may be a terminal device equipped with an Android operating system.

[0130] Figure 2b A schematic diagram of another application scenario provided for an embodiment of the present application.

[0131] like Figure 2b As shown, the application scenario is a cluster test scenario, which includes at least one computing device and a control device 10. The control device 10 is communicatively connected with the at least one computing device.

[0132] For example, Figure 2b A computing device 20 is shown.

[0133] In this scenario, the control device 10 can be a terminal device, such as a computer or a mobile phone. It can also be a server; for example, from the perspective of architecture, the server can be a rack server, a high-density server, a tower server, or a whole cabinet server; from the perspective of function, the server can be a general-purpose server or an AI server, etc.

[0134] It should be noted that Figure 2a and Figure 2b This is a schematic diagram of the scenario provided by the embodiment of the present application. The embodiment of the present application is not Figure 2a and Figure 2b The actual form of the various devices included in the Figure 2a and Figure 2b The interaction mode between devices is limited, and in the application of the solution, it can be set according to actual needs.

[0135] The technical solution of the present application is described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0136] First, the process of resetting a deadlock of a test operating system in a single-machine test scenario is described through method embodiment 1.

[0137] Figure 3 This is a flow chart of a first embodiment of a test method for resetting a deadlock in an operating system provided by an embodiment of the present application. Figure 3 , the method specifically comprises the following steps:

[0138] S301: triggering operating system deadlock.

[0139] In this embodiment, the computing device may trigger an operating system deadlock.

[0140] Specifically, when the target deadlock type is a hard lockup type, the computing device may generate a deadlock condition of the hard lockup type and trigger the operating system hard lockup. In one implementation, the computing device may execute an infinite loop and trigger the operating system hard lockup when creating a kernel thread and disabling interrupts. It should be noted that the computing device may also trigger the operating system hard lockup in other ways, which is not limited in the embodiments of the present application.

[0141] When the target deadlock type is a soft lockup type, the computing device may generate a deadlock condition of the soft lockup type and trigger an operating system soft lockup. In one implementation, the computing device may execute an infinite loop while creating a kernel thread and turning off scheduling, and trigger an operating system soft lockup. In one implementation, the computing device may create a communication error between kernel threads and trigger an operating system soft lockup. In one implementation, the computing device may create a kernel thread error in using a mutex and trigger an operating system soft lockup. It should be noted that the computing device may also trigger an operating system soft lockup in other ways, and the embodiments of the present application do not limit this.

[0142] S302: During the systemd initialization phase of the operating system startup, the operating system reset information recorded in the operating system log is obtained.

[0143] In this embodiment, when the operating system is in a deadlock state, the watchdog (program) in the computing device will perform a reset operation to reset the operating system when it recognizes that the operating system is in a deadlock state.

[0144] The operating system reset process includes the BIOS boot phase, the GURB boot phase, the systemd initialization phase, and the terminal login phase.

[0145] During the systemd initialization phase of the operating system reset process, the computing device can start up after receiving a startup command sent by systemd (the first program started by the kernel). After starting up according to the startup command, the computing device can obtain the operating system reset information recorded in the operating system log.

[0146] S303: Determine whether the operating system reset information meets a preset condition.

[0147] In this embodiment, after obtaining the operating system reset information, the computing device may determine whether the operating system reset information meets a preset condition.

[0148] When the computing device determines that the operating system reset information does not meet the preset condition, executing S304;

[0149] When the computing device determines that the operating system reset information meets the preset condition, it executes S305.

[0150] S304: Determine whether the operating system fails the current deadlock reset test.

[0151] In this embodiment, the computing device may determine that the operating system fails the current deadlock reset test when determining that the operating system reset information does not meet a preset condition.

[0152] In one implementation, when the operating system reset information includes a deadlock type, the computing device determines that the operating system fails the current deadlock reset test when determining that the deadlock type is not a target deadlock type. The deadlock type is a hard lock type or a soft lock type. The target deadlock type is a hard lock type or a soft lock type.

[0153] S305: Update the reset times.

[0154] In this embodiment, the computing device may update the reset times when determining that the operating system reset information meets a preset condition. Exemplarily, the computing device may add 1 to the reset times.

[0155] In one implementation, when the operating system reset information includes a deadlock type, the computing device updates the reset count when determining that the deadlock type is a target deadlock type, wherein the deadlock type is a hard lock type or a soft lock type, and the target deadlock type is a hard lock type or a soft lock type.

[0156] It should be noted that the reset times are stored in a persistent device, for example, the persistent device may be a hard disk.

[0157] S306: Determine whether the updated reset number reaches the preset reset number.

[0158] In this embodiment, the computing device may determine whether the updated reset times reach a preset reset times. For example, the preset reset times may be 10,000 times.

[0159] When determining that the number of reset times after the update does not reach the preset number of reset times, the computing device may return to execute S301 to start the next operating system deadlock reset test process.

[0160] The computing device may execute S307 when determining that the updated reset number reaches a preset reset number.

[0161] S307: Determine whether the operating system passes the deadlock reset test.

[0162] In this embodiment, the computing device determines that the operating system passes the deadlock reset test when determining that the number of resets after the update reaches a preset number of resets.

[0163] The beneficial effects of this embodiment: after the operating system deadlock is triggered, a new deadlock reset test process can be started during the systemd initialization phase of the operating system startup - when it is determined that the operating system reset information in the operating system log meets the preset conditions, the reset times are updated. Determine whether the updated reset times reach the preset reset times. When the updated reset times reach the preset reset times, it is determined that the operating system has passed the deadlock reset test; when the updated reset times do not reach the preset reset times, the operating system deadlock is triggered. The method of the embodiment of the present application does not require additional control equipment, and can automatically start the test process after the operating system deadlock is reset, thereby ensuring that the test is not interrupted and realizing continuous automated testing of operating system deadlock reset in a single-machine test scenario. The accuracy of the test results is improved, the occupation of additional resources is avoided, and the test efficiency is improved.

[0164] Figure 4a This is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. Figure 4a As shown, the computing device 20 stores a deadlock reset service module 201 , a test script module 202 , and a deadlock trigger module 203 .

[0165] It should be noted that the deadlock reset service module, the test script module and the deadlock trigger module are programs used by the computing device when testing the deadlock reset of the operating system.

[0166] The following describes the process of testing operating system deadlock reset from the perspectives of a deadlock reset service module, a test script module, and a deadlock trigger module through a second method embodiment.

[0167] Figure 4b This is a flow chart of a second embodiment of a test method for resetting a deadlock in an operating system provided in an embodiment of the present application. Figure 4b , the method specifically comprises the following steps:

[0168] S401: The deadlock triggering module triggers the operating system deadlock.

[0169] In this embodiment, the deadlock triggering module can trigger the operating system deadlock.

[0170] Specifically, when the target deadlock type is a hard lockup type, the deadlock trigger module can generate a deadlock condition of the hard lockup type and trigger the operating system to hard lockup. In one implementation, the deadlock trigger module can execute an infinite loop and trigger the operating system to hard lockup when a kernel thread is created and interrupts are disabled.

[0171] In the case where the target deadlock type is a soft lockup type, the deadlock trigger module can generate a deadlock condition of the soft lockup type and trigger the operating system soft lockup. In one implementation, the deadlock trigger module can execute an infinite loop and trigger the operating system soft lockup when a kernel thread is created and scheduling is turned off. In one implementation, the deadlock trigger module can create a communication error between kernel threads and trigger the operating system soft lockup. In one implementation, the deadlock trigger module can create a kernel thread error in using a mutex and trigger the operating system soft lockup.

[0172] It should be noted that, when the deadlock triggering module includes a code for constructing a hard-lock type deadlock condition, the deadlock triggering module can generate a hard-lock type deadlock condition when running, and trigger the operating system to hard lock. When the deadlock triggering module includes a code for constructing a soft-lock type deadlock condition, the deadlock triggering module can generate a soft-lock type deadlock condition when running, and trigger the operating system to soft lock.

[0173] S402: During the systemd initialization phase when the operating system is started, the deadlock reset service module calls the test script module.

[0174] In this embodiment, when the operating system is in a deadlock state, the watchdog (program) will perform a reset operation upon identifying that the operating system is in a deadlock state, so as to reset the operating system.

[0175] The operating system reset process includes the BIOS boot phase, the GURB boot phase, the systemd initialization phase, and the terminal login phase.

[0176] During the systemd initialization phase of the operating system reset process, systemd (the first program started by the kernel) sends a startup command to the deadlock reset service module.

[0177] The deadlock reset service module responds to the systemd startup command and starts. After the deadlock reset service module is started, it calls the test script module.

[0178] It should be noted that the deadlock reset service module is a service managed by systemd, and can be started in response to a systemd startup command when the operating system is reset.

[0179] The following describes the process of incorporating the deadlock reset service module into systemd management.

[0180] After obtaining the configuration file of the deadlock reset service module, the computing device may place the configuration file of the deadlock reset service module in the directory of systemd.

[0181] The configuration file of the deadlock reset service module includes three main blocks:

[0182] Unit: defines the basic information of the deadlock reset service module, such as description, startup sequence, etc.

[0183] Service: defines the startup, restart and permission parameters of the deadlock reset service; it should be noted that ExecStart included in Service is the startup command.

[0184] Install: defines how to install the deadlock reset service module.

[0185] After placing the configuration file of the deadlock reset service module in the directory of systemd, the deadlock reset service module can be registered, wherein the registration steps include: reloading systemd; enabling the deadlock reset service module; and starting the deadlock reset service module.

[0186] The process based on installing the deadlock reset service module includes starting the deadlock reset service module. After the deadlock reset service module is started, the deadlock reset service module calls the test script module. The test script module checks the system log to determine that the system log does not record the operating system reset information, and reads the reset number stored in the hard disk to determine that the reset number is 0. The test script module calls the deadlock trigger module. In response to the call of the test script module, the deadlock trigger module triggers the operating system deadlock, and then enters the first test process.

[0187] During the first test, during the systemd initialization phase when the operating system is started, the deadlock reset service module receives the startup command sent by systemd, starts up, and after starting up, calls the test script module.

[0188] S403: The test script module obtains the operating system reset information recorded in the operating system log.

[0189] In this embodiment, the test script module may obtain the operating system reset information recorded in the operating system log in response to the call of the deadlock reset service module.

[0190] S404: The test script module determines whether the operating system reset information meets a preset condition.

[0191] In this embodiment, after obtaining the operating system reset information, the test script module may determine whether the operating system reset information satisfies a preset condition.

[0192] When the operating system reset information does not meet the preset condition, the test script module executes S405;

[0193] When the operating system reset information meets the preset conditions, the test script module executes S406.

[0194] S405: The test script module determines that the operating system fails the current deadlock reset test.

[0195] In this embodiment, when the operating system reset information does not meet the preset condition, the test script module can determine that the operating system has failed the current deadlock reset test.

[0196] In one implementation, the operating system reset information includes a deadlock type. When the test script module determines that the deadlock type is not the target deadlock type, the test script module determines that the operating system fails the current deadlock reset test.

[0197] S406: The test script module updates the reset times.

[0198] In this embodiment, when the operating system reset information meets a preset condition, the test script module may update the reset times.

[0199] In one implementation, the operating system reset information includes the deadlock type. When the test script module determines that the deadlock type is the target deadlock type, the test script module updates the reset times.

[0200] It should be noted that, in the process of updating the reset number, the test script module may read the reset number stored in the persistence device, update the reset number, and store the updated reset number in the persistence device.

[0201] S407: The test script module determines whether the updated reset times reach the preset reset times.

[0202] In this embodiment, the test script module may determine whether the updated reset times reaches a preset reset times.

[0203] When the updated reset number reaches the preset reset number, the test script module executes S408;

[0204] When the updated reset times do not reach the preset reset times, the test script module executes S409.

[0205] S408: The test script module determines that the operating system passes the deadlock reset test.

[0206] In this embodiment, the test script module may determine that the operating system passes the deadlock reset test when the number of reset times after the update reaches a preset number of reset times.

[0207] S409: The test script module calls the deadlock trigger module.

[0208] In this embodiment, the test script module may call the deadlock trigger module when the updated reset times do not reach the preset reset times.

[0209] The deadlock triggering module returns to execute S401 to start the next operating system deadlock reset test.

[0210] Beneficial effects of this embodiment: The deadlock trigger module can trigger the deadlock of the operating system. The deadlock reset service module is managed by systemd. In the systemd initialization phase when the operating system is started, the deadlock reset service module can call the test script module. The test script module can obtain the operating system reset information recorded in the operating system log. The test script module can determine whether the operating system reset information meets the preset conditions. The test script module updates the reset number when it determines that the operating system reset information meets the preset conditions. The test script module determines whether the updated reset number reaches the preset reset number. The test script module can determine that the operating system passes the deadlock reset test when the updated reset number reaches the preset reset number. The method of the embodiment of the present application does not need to occupy additional resources. The deadlock reset service module that can be self-started in the systemd initialization phase when the operating system is started enables the entire test process, thereby realizing continuous testing of the operating system deadlock reset. The accuracy of the test results is improved, the occupation of additional resources is avoided, and the test efficiency is improved.

[0211] The following describes the process of resetting the deadlock of the test operating system in a cluster test scenario (a computing device and a control device are in communication connection) through a third method embodiment.

[0212] Figure 5 This is a flow chart of a third embodiment of a test method for resetting a deadlock of an operating system provided in an embodiment of the present application. Figure 5 , the method specifically comprises the following steps:

[0213] S501: Receive a test software package sent by a control device.

[0214] In this embodiment, the computing device may receive a test software package sent by the control device. The test software package includes a deadlock reset service module, a test script module, and a deadlock trigger module. Exemplarily, the deadlock reset service module may be a configuration file, the test script module may be a shell file, and the deadlock trigger module may be a C file.

[0215] It is understandable that the computing device may install the deadlock reset service module, the test script module, and the deadlock trigger module after obtaining the test software package.

[0216] It should be noted that the deadlock triggering module includes codes for constructing a deadlock condition of a target deadlock type.

[0217] For example, the deadlock trigger module includes code that generates a hard lock type deadlock condition - code that creates a kernel thread and executes an infinite loop with interrupts disabled.

[0218] For another example, the deadlock trigger module includes code that generates a soft lock type deadlock condition - code that creates a kernel thread and executes an infinite loop with scheduling turned off.

[0219] In addition, the process of installing the deadlock reset service module based on the computing device includes starting the deadlock reset service module, that is, the computing device starts the process of testing the deadlock reset of the operating system. Therefore, the control device can start timing after sending the test software package to the computing device. When the control device determines that no feedback instruction is received from the computing device within the preset time range, it determines that the computing device fails to reset the operating system during the test. The computing device can determine that the operating system has not passed the deadlock reset test.

[0220] S502: Triggering operating system deadlock.

[0221] In this embodiment, the computing device may trigger an operating system deadlock.

[0222] It should be noted that the process based on installing the deadlock reset service module includes starting the deadlock reset service module. After the deadlock reset service module is started, the deadlock reset service module will call the test script module. The test script module checks the operating system log to determine that the operating system reset information is not recorded in the operating system log, and reads the number of resets stored in the persistent device to determine that the number of resets is 0. The test script module calls the deadlock trigger module. The deadlock trigger module triggers the operating system deadlock in response to the call of the test script module. It should be noted that at this time, the computing device enters the first deadlock reset test process.

[0223] S503: During the systemd initialization phase of the operating system startup, the operating system reset information recorded in the operating system log is obtained.

[0224] In this embodiment, when the operating system is in a deadlock state, the watchdog (program) in the computing device will restart the operating system to reset it when it recognizes that the operating system is in a deadlock state.

[0225] The operating system reset process includes the BIOS boot phase, the GURB boot phase, the systemd initialization phase, and the terminal login phase.

[0226] During the systemd initialization phase of the operating system reset process, the computing device can receive a startup command sent by systemd (the first program started by the kernel).

[0227] After being started according to the startup command, the computing device can obtain the operating system reset information recorded in the operating system log.

[0228] S504: Determine whether the operating system reset information meets a preset condition.

[0229] In this embodiment, after obtaining the operating system reset information recorded in the operating system log, the computing device can determine whether the operating system reset information meets the preset condition. In one implementation, when the operating system reset information is a deadlock type, the computing device can determine whether the operating system reset information meets the preset condition by determining whether the deadlock type is a target deadlock type.

[0230] When the operating system reset information satisfies the non-preset condition, the computing device executes S505;

[0231] When the operating system reset information meets the preset condition, the computing device executes S507.

[0232] S505: Determine whether the operating system fails the current deadlock reset test.

[0233] In this embodiment, when the computing device determines that the operating system reset information does not meet the preset condition, it determines that the operating system fails the current deadlock reset test.

[0234] S506: Send a feedback instruction to the control device.

[0235] In this embodiment, when the computing device determines that the operating system fails the current deadlock reset test, the computing device sends a feedback instruction to the control device, wherein the feedback instruction is used to indicate that the operating system fails the current deadlock reset test.

[0236] In one implementation, the computing device can also read the reset times stored in the persistent device to determine the test number ranking of the current deadlock reset test in the total test process (which test number the current deadlock reset test is), and rank the test number of the current deadlock reset test in the total test process and add it to the feedback instruction.

[0237] S507: Update the reset times.

[0238] In this embodiment, when the computing device determines that the operating system reset information meets a preset condition, the computing device updates the reset times.

[0239] S508: Determine whether the updated reset number reaches the preset reset number.

[0240] In this embodiment, the computing device may determine whether the updated reset number reaches a preset reset number.

[0241] When the number of reset times after the update reaches the preset number of reset times, the computing device executes S509;

[0242] When the updated reset number does not reach the preset reset number, the computing device returns to execute S502 to enter the next deadlock reset test process.

[0243] S509: Determine whether the operating system passes the deadlock reset test.

[0244] In this embodiment, the computing device determines that the operating system passes the deadlock reset test when the number of resets after the update reaches a preset number of resets.

[0245] S510: Send a feedback instruction to the control device.

[0246] In this embodiment, when the computing device determines that the operating system passes the deadlock reset test, it may send a feedback instruction to the control device; wherein the feedback instruction is used to indicate that the operating system passes the deadlock reset test.

[0247] The beneficial effects of this embodiment: in a cluster test scenario where a computing device and a control device are communicatively connected, after sending a test software package to the computing device, the control device does not need to participate in the process of the computing device testing the operating system deadlock reset, and can directly wait for the feedback instruction sent by the computing device (indicating that the operating system has passed the deadlock reset test, or indicating that the operating system has not passed the current deadlock reset test). Compared with the related art, the control device needs to send deadlock instructions, confirmation instructions and test commands to the computing device in a synchronous blocking manner, resulting in the problems of low test result accuracy, high resource usage and low test efficiency in the test method of the related art. In this application, the interaction between the computing device and the control device is asynchronous and non-blocking, and the control device does not participate in the process of the computing device testing the operating system deadlock reset, and can handle other matters, thereby improving resource utilization, reducing test time, simplifying the test process, saving network bandwidth and improving test efficiency.

[0248] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0249] In a second aspect, an embodiment of the present application provides a test device for resetting a deadlock of an operating system, comprising:

[0250] A deadlock triggering module, used to trigger an operating system deadlock;

[0251] The deadlock reset service module is used to call the test script module during the systemd initialization phase when the operating system is started;

[0252] A test script module is used to obtain the operating system reset information recorded in the operating system log;

[0253] The test script module is also used to determine whether the operating system reset information meets the preset conditions;

[0254] The test script module is also used to update the reset times when the operating system reset information meets the preset conditions;

[0255] The test script module is also used to determine whether the reset number after the update reaches the preset reset number;

[0256] The test script module is also used to determine that the operating system passes the deadlock reset test when the number of resets after the update reaches a preset number of resets.

[0257] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0258] In one implementation, the operating system reset information includes a deadlock type; and a test script module is specifically used to:

[0259] When the deadlock type is a target deadlock type, the reset times are updated; wherein the deadlock type is a hard lock type or a soft lock type, and the target deadlock type is a hard lock type or a soft lock type.

[0260] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0261] In one implementation, the test script module is further used to:

[0262] When the deadlock type is not the target deadlock type, it is determined that the operating system fails the current deadlock reset test.

[0263] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0264] In one implementation,

[0265] The test script module is also used to call the deadlock trigger module when the reset number after the update does not reach the preset reset number;

[0266] The deadlock triggering module is used to trigger the operating system deadlock.

[0267] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0268] In one implementation, the reset times are stored in a persistent device.

[0269] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0270] In one implementation, the deadlock triggering module is specifically used to:

[0271] When the target deadlock type is a hard lock type, a hard lock type deadlock condition is generated and the operating system hard lock is triggered; or,

[0272] In the case where the target deadlock type is a soft lock type, a deadlock condition of the soft lock type is generated, and an operating system soft lock is triggered.

[0273] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0274] In one implementation,

[0275] The test script module is also used to determine that the operating system fails the current deadlock reset test when the operating system reset information does not meet the preset conditions.

[0276] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0277] In one implementation, the method further includes:

[0278] The transceiver module is used to receive a test software package sent by the control device; the test software package is used to trigger the operating system to perform a deadlock reset test.

[0279] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0280] In one implementation,

[0281] The transceiver module is also used to send feedback instructions to the control device; the feedback instructions are used to instruct the operating system to pass the deadlock reset test.

[0282] The operating system deadlock reset test device provided in this embodiment can execute the technical solution shown in the above method embodiment, and its beneficial effects are similar and will not be repeated here.

[0283] Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. Figure 6 As shown, the computing device 60 includes: a processor 61 and a memory 62; wherein the processor 61 is coupled to the memory 62, and the memory 62 is used to store computer instructions; the processor 61 is configured to execute the technical solution in the aforementioned method embodiment by executing the computer instructions stored in the memory 62.

[0284] Optionally, the memory 62 may be independent or integrated with the processor 61. Optionally, when the memory 62 is a device independent of the processor 61, the computing device 60 may further include: a bus for connecting the above devices.

[0285] The processor is used to execute the technical solution in the aforementioned method embodiment, and its implementation principle and technical effect are similar and will not be repeated here.

[0286] An embodiment of the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the technical solution provided by the aforementioned method embodiment.

[0287] An embodiment of the present application also provides a computer program product, including a computer program, which is used to implement the technical solution provided by the aforementioned method embodiment when executed by a processor.

[0288] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0289] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A test method for operating system deadlock reset, characterized in that: The method comprises: Triggering a deadlock of the operating system; During the systemd initialization phase of the operating system startup, obtaining the operating system reset information recorded in the operating system log; Determining whether the operating system reset information meets a preset condition; When the operating system reset information meets the preset condition, updating the reset times; Determine whether the number of resets after the update reaches the preset number of resets; When the number of resets after the update reaches the preset number of resets, determining that the operating system passes the deadlock reset test; The operating system reset information includes a deadlock type; and when the operating system reset information satisfies the preset condition, updating the reset times includes: In the case where the deadlock type is a target deadlock type, the reset times are updated; wherein the deadlock type is a hard lock type or a soft lock type, and the target deadlock type is a hard lock type or a soft lock type.

2. The testing method according to claim 1, characterized in that: The method further comprises: When the deadlock type is not the target deadlock type, it is determined that the operating system fails the current deadlock reset test.

3. The testing method according to claim 1, characterized in that: The method further comprises: When the updated reset number does not reach the preset reset number, the operating system is triggered to deadlock.

4. The testing method according to any one of claims 1 to 3, characterized in that: The reset times are stored in a persistent device.

5. The testing method according to any one of claims 1 to 3, characterized in that: The triggering of the operating system deadlock includes: In the case where the target deadlock type is a hard lock type, generating a deadlock condition of the hard lock type and triggering the operating system to hard lock; or, In the case where the target deadlock type is a soft lock type, a deadlock condition of the soft lock type is generated, and the operating system soft lock is triggered.

6. The testing method according to any one of claims 1 to 3, characterized in that: The method further comprises: When the operating system reset information does not satisfy the preset condition, it is determined that the operating system fails the current deadlock reset test.

7. The testing method according to any one of claims 1 to 3, characterized in that: Before triggering the operating system deadlock, the method further includes: A test software package sent by a control device is received; the test software package is used to trigger the operating system to execute the deadlock reset test.

8. The testing method according to claim 7, characterized in that: After determining that the operating system passes the deadlock reset test, the method further includes: Sending a feedback instruction to the control device; the feedback instruction is used to indicate that the operating system passes the deadlock reset test.

9. A computing device, characterized in that The computing device is installed with an operating system for performing a deadlock reset test; the computing device includes a memory and a processor; The memory is coupled to the processor; The memory is used to store computer instructions; The processor is used to execute the computer instructions so that the computing device implements the operating system deadlock reset testing method described in any one of claims 1-8.

Images