A module hibernation exception diagnosis method, system, device and medium

Abstract

The application discloses a kind of module dormancy exception diagnosis method, system, device and medium, when module enters dormancy flow, stage identifier and stage time information are recorded in multiple preset key stages to form dormancy life cycle, and when abnormal event occurs, corresponding diagnosis information is obtained based on the life cycle, and the diagnosis information is associated with the stage information in the life cycle, to realize the positioning of abnormal stage and process restoration analysis, Therefore, it solves the technical problems that there is lack of effective process information support after the occurrence of dormancy-related abnormalities in the prior art, which leads to a long problem positioning period, and achieves the technical effect of completing abnormal positioning without relying on repeated reproduction, shortening the problem analysis period.

Description

Technical Field

[0001] This invention relates to the field of module monitoring, and in particular to a method, system, device, and medium for diagnosing abnormal module sleep conditions. Background Technology

[0002] Existing communication modules typically include sleep and wake-up state switching mechanisms during operation to reduce device power consumption and adapt to long standby scenarios. In actual operation, system anomalies often occur during sleep or wake-up processes, such as operational abnormalities during the entry into low-power mode or abnormal restarts during the recovery process from a low-power state.

[0003] However, because some operational logging mechanisms cease or become limited as the system enters a low-power state, critical operational information generated during hibernation and the initial wake-up phase is difficult to record and save in a timely and complete manner. When anomalies occur in these processes, there is often a lack of sufficient operational log support on-site, making it impossible to effectively analyze the anomaly process.

[0004] Therefore, in the actual process of locating problems, it is usually necessary to repeatedly reproduce the abnormal scenario and capture logs. However, dormant anomalies are random and environmentally dependent, making them difficult to reproduce stably. This results in a long problem location cycle and high R&D and on-site analysis costs.

[0005] Therefore, how to reliably acquire key operational information and conduct subsequent anomaly localization analysis during the hibernation and wake-up process is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to provide a method, system, device, and medium for diagnosing module hibernation anomalies. This invention solves the technical problem in the prior art where there is a lack of effective process information to support the diagnosis of hibernation-related anomalies, resulting in a long problem localization cycle. It achieves the technical effect of being able to complete anomaly localization without relying on repeated reproduction, thus shortening the problem analysis cycle.

[0007] Firstly, this application provides a method for diagnosing module hibernation anomalies, including: When the response module enters the hibernation process, the corresponding stage identifier and stage time information are recorded at multiple preset key stages of the hibernation process to establish the hibernation life cycle corresponding to the module. During the dormancy lifecycle, the operating status of the module is monitored based on the stage time information, and when an abnormal event is detected, diagnostic information corresponding to the abnormal event is obtained according to the type of the abnormal event. The diagnostic information is associated with the stage information corresponding to the hibernation life cycle to determine the occurrence stage of the abnormal event. Anomaly diagnosis results for the module are generated based on the associated diagnostic information.

[0008] Optionally, the abnormal event includes at least one of the following: The sleep timeout exception corresponding to the module failing to enter sleep state within a preset time threshold; the abnormal wake-up event corresponding to the module being unexpectedly woken up in sleep state; and the abnormal restart event corresponding to the module crashing during sleep and restarting after the crash.

[0009] Optionally, the detection method for the hibernation timeout anomaly includes: A sleep timer is started when the module enters the sleep process; If the module fails to enter sleep mode when the sleep timer exceeds a preset time threshold, it is determined that there is a sleep timeout abnormality. The step of obtaining diagnostic information corresponding to the abnormal event based on the type of the abnormal event includes: The module's running status information is obtained, which includes at least one of the following: a wake-up lock list, wake-up source status, CPU idle statistics, and active process and thread stack information. The running status information is used to diagnose the blocking sources that prevent the module from successfully entering sleep mode. A hibernation failure diagnostic log is generated based on the aforementioned operating status information.

[0010] Optionally, the detection method for the abnormal wake-up event includes: When the module is woken up from sleep mode, the type of the current wake-up source that triggered the wake-up is identified; Get the current wake-up time window and the current wake-up frequency; If the current wake-up source type is not in the preset allowed wake-up source whitelist, and / or the current wake-up time window is less than the preset time window threshold, and / or the current wake-up frequency exceeds the preset frequency threshold, then it is determined that the abnormal wake-up event exists. The step of obtaining diagnostic information corresponding to the abnormal event based on the type of the abnormal event includes: Match the target log type corresponding to the current wake-up source type according to the preset mapping strategy; Perform targeted log fetching on the module based on the target log type.

[0011] Optionally, the preset mapping strategy includes: When the current wake-up source type is modem wake-up, the matched target log types include at least modem crash logs and network status logs; When the current wake-up source type is a general input / output interface wake-up, the matching target log type includes at least interrupt driver log and general input / output interface configuration log; When the current wake-up source type is Wake-up from the network, the matched target log types include at least TCP / IP protocol stack logs and wireless interface layer logs; When the current wake-up source type is real-time clock wake-up, the matched target log type includes at least timer logs and system task logs.

[0012] Optionally, the methods for obtaining detection and diagnostic information for the abnormal restart event include: After the module restarts, obtain the power-on reason code; If the boot reason code indicates that this boot is an abnormal restart, then read the kernel crash call stack log saved in the persistent storage space; The kernel crash call stack log is correlated with the phase information corresponding to the previous sleep lifecycle to determine whether a crash event occurred during sleep.

[0013] Optionally, the plurality of preset key stages include at least two of the following stages: The hibernation request initiation phase is used to respond to a hibernation command and perform actions related to the hibernation command; The device freeze phase is used to stop the execution of upper-layer applications or threads; The interrupt shutdown phase is used to stop the operation of the driver and put each driver into sleep mode; The central processing unit enters a low-power phase, which is used to control the central processing unit to enter a low-power state after the upper-layer application and the driver have both stopped. The system wake-up phase is used to respond to a wake-up command or external interrupt to wake up the central processing unit; The device recovery phase is used to restore the operation of the driver and the upper-layer application or thread.

[0014] Secondly, this application provides a module sleep anomaly diagnostic system, comprising: The lifecycle recording module is used to respond to the module entering the hibernation process, and to record the corresponding stage identifier and stage time information in multiple preset key stages of the hibernation process, so as to establish the hibernation lifecycle corresponding to the module. An anomaly detection module is used to monitor the operating status of the module based on the stage time information during the hibernation life cycle, and to obtain diagnostic information corresponding to the anomaly event according to the type of the anomaly event when an anomaly event is detected. The stage association module is used to associate the diagnostic information with the stage information corresponding to the hibernation life cycle in order to determine the occurrence stage of the abnormal event. The diagnosis result generation module is used to generate the abnormal diagnosis result of the module based on the associated diagnosis information.

[0015] Thirdly, this application provides a module sleep abnormality diagnostic device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of the module hibernation anomaly diagnosis method as described above when executing a computer program.

[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the module hibernation anomaly diagnosis method described above.

[0017] This invention provides a method, system, device, and medium for diagnosing module hibernation anomalies. When a module enters the hibernation process, stage identifiers and stage time information are recorded at multiple preset key stages to form a hibernation lifecycle. When an abnormal event occurs, corresponding diagnostic information is obtained based on this lifecycle, and the diagnostic information is correlated with the stage information in the lifecycle. This enables the localization of the abnormality stage and process reconstruction analysis. Therefore, it solves the technical problem in the prior art that there is a lack of effective process information support after the occurrence of hibernation-related anomalies, resulting in a long problem localization cycle. It achieves the technical effect of completing anomaly localization without relying on repeated reproduction and shortening the problem analysis cycle. Attached Figure Description

[0018] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart of a module sleep abnormality diagnosis method provided by the present invention; Figure 2 This is a flowchart illustrating the complete process of a module sleep anomaly diagnosis method provided by the present invention. Figure 3 This is a schematic diagram of a module sleep abnormality diagnosis system provided by the present invention; Figure 4 This is a schematic diagram of a module sleep abnormality diagnosis device provided by the present invention. Detailed Implementation

[0020] The core of this invention is to provide a method, system, device, and medium for diagnosing module hibernation anomalies. This invention solves the technical problem in the prior art where there is a lack of effective process information to support the occurrence of hibernation-related anomalies, resulting in a long problem localization cycle. It achieves the technical effect of being able to complete anomaly localization without relying on repeated reproduction, thus shortening the problem analysis cycle.

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

[0022] Firstly, this application provides a method for diagnosing module hibernation anomalies, including: S11: Respond to the module entering the hibernation process, record the corresponding stage identifier and stage time information in multiple preset key stages of the hibernation process to establish the hibernation life cycle corresponding to the module; This is executed after the system receives the instruction for the module to enter the hibernation process. During hibernation, the system operates under the control of the power management control module, recording operations at multiple preset key stages to form the basis for the hibernation process's stage records. In this embodiment, the preset key stages may include one or more combinations of the following: hibernation request initiation stage, device freeze stage, interrupt disabling stage, central processing unit entering low-power stage, system wake-up stage, and device recovery stage.

[0023] Upon reaching each preset key stage, the stage identifier and corresponding stage time information are obtained. The stage identifier can be represented by a stage name, stage number, or a preset encoding method, and the stage time information is the timestamp corresponding to the system's current running time. In this embodiment, the timestamp can originate from the system clock module or the kernel time recording interface, thereby ensuring that the time sequence between different stages is consistently recorded.

[0024] In the specific implementation, when the module executes the hibernation process, recording actions are inserted at the nodes where the above-mentioned key stages are entered, and the stage identifier and corresponding timestamp are written to the log storage area, thus forming stage record data arranged in chronological order. The record data of each stage together constitute the hibernation lifecycle, which is used to reflect the overall operation trajectory of the module from entering the hibernation process to completing the relevant state transition.

[0025] Through the above method, this embodiment can continuously record key stages during the module's hibernation process, giving the hibernation process a traceable temporal sequence basis, thereby providing data support for process analysis when an anomaly occurs and avoiding the problem of being unable to determine the location of the anomaly due to missing stage information.

[0026] S12: During the hibernation lifecycle, monitor the module's operating status based on stage time information, and when an abnormal event is detected, obtain the diagnostic information corresponding to the abnormal event based on the type of the abnormal event; Executed after the hibernation lifecycle is established, this monitoring is used to monitor the module's operating status during the hibernation process. This monitoring is triggered and corresponds to the stage time information recorded in S11, ensuring that the collected operating status data corresponds to specific stage time points. Specifically, during the module's hibernation process, the current operating status is continuously or intermittently collected based on the time information recorded at each stage. In this embodiment, the operating status may include one or more of the following: wake-up lock list status, wake-up source status, CPU idle status statistics, and stack information of currently active processes or threads. This status information can be obtained through the kernel interface, driver interface, or user-mode query interface.

[0027] When an abnormal event is detected, the system triggers a corresponding diagnostic information retrieval action based on the type of the abnormal event. In this embodiment, the abnormal event may include one or more of the following: a sleep timeout exception, an abnormal wake-up event, or an abnormal restart event. When a sleep timeout exception occurs, the system retrieves the current wake-up lock list, wake-up source status, CPU idle state statistics, and process or thread stack information to reflect the current inability to enter a sleep state. When an abnormal wake-up event occurs, the system performs a corresponding diagnostic information retrieval operation based on the wake-up source type to record the running state at the time of the wake-up. When an abnormal restart event occurs, the system reads the corresponding crash log from persistent storage as the source of diagnostic information.

[0028] Through the above method, this embodiment can trigger different running status collection actions according to different types of abnormal events during the dormant life cycle, thereby obtaining diagnostic information corresponding to the current running status when an abnormality occurs, providing a data foundation for subsequent abnormal location, and reducing the problem of relying on repeated reproduction to obtain logs.

[0029] S13: Associate diagnostic information with the stage information corresponding to the hibernation lifecycle to determine the stage at which the abnormal event occurred; In this embodiment, after obtaining the diagnostic information corresponding to the abnormal event, the procedure is executed to establish a correspondence between the diagnostic information and the stage records in the hibernation lifecycle. The hibernation lifecycle consists of the stage identifiers and stage time information of each preset key stage in S11. The different stages are arranged sequentially according to time, thereby forming a time sequence record of the module hibernation process.

[0030] Specifically, in this embodiment, when mapping diagnostic information to the hibernation lifecycle, the diagnostic information is assigned to the stage identifier that is closest in time or corresponds to the range of occurrence based on the time information of the diagnostic information generation and the time information of each stage. For example, if the diagnostic information generation time is between the hibernation request initiation stage and the device freeze stage, the diagnostic information is mapped to the stage record range corresponding to the hibernation request initiation stage or the device freeze stage, thereby determining the correspondence between diagnostic information and specific stages.

[0031] In one optional implementation, if the diagnostic information itself carries a trigger time point, then the corresponding match is directly performed based on the trigger time point and the time information of each stage. If the diagnostic information does not contain a specific time point, then the corresponding stage is determined by reverse calculation based on the current system operation record time. In this embodiment, this matching process can be implemented through timestamp comparison or through stage sequence indexing, but is not limited to the above methods.

[0032] In this embodiment, diagnostic information from different sources is uniformly mapped to specific stages in the dormant life cycle, so that the originally scattered operational information can be merged according to the time sequence and stage affiliation, thereby providing a consistent data foundation for the subsequent generation of abnormal diagnostic results, which is conducive to locating the location of the abnormality and reconstructing the process.

[0033] S14: Generate abnormal diagnosis results for the module based on the associated diagnostic information.

[0034] This embodiment executes after establishing the correspondence between diagnostic information and the dormant lifecycle, and is used to generate abnormal diagnostic results for the module based on the associated information. Specifically, the abnormal diagnostic results in this embodiment consist of stage record information in the dormant lifecycle and diagnostic information for the corresponding stage. The stage record information includes the stage identifier and stage time information of each preset key stage, and the diagnostic information includes the operating status information and other relevant record information obtained under different abnormal events. The above information is summarized and organized in chronological order of stages, so that the diagnostic information corresponding to each stage can be centrally displayed within the same dormant lifecycle.

[0035] In one optional implementation, diagnostic information is merged according to the stage sequence, and diagnostic information occurring in the same stage or within the same time range is associated and labeled to form abnormal description information corresponding to the stage. For example, the running status information corresponding to the hibernation timeout abnormality is classified into the early stage of the hibernation process, the diagnostic information corresponding to the abnormal wake-up is classified into the system wake-up stage, and the crash log corresponding to the abnormal restart is classified into the system recovery stage, thereby forming an abnormal process record divided by stage.

[0036] Through the above method, this embodiment can unify and organize the stage information and anomaly diagnosis information in the dormant life cycle, so that the anomaly occurrence process can be restored and displayed in chronological order and stage affiliation, thereby realizing the overall analysis of the anomaly occurrence process, providing complete data basis for subsequent problem localization, and reducing the reliance on repeated reproduction of logs.

[0037] In one exemplary embodiment, the abnormal event includes at least one of the following: The following events are considered as follows: a sleep timeout exception when the module fails to enter sleep mode within a preset time threshold; an abnormal wake-up event when the module is unexpectedly woken up from sleep mode; and an abnormal restart event when the module crashes during sleep and restarts after the crash.

[0038] In this embodiment, a sleep timeout anomaly refers to a situation where the module, after entering the sleep process, fails to complete the process of entering sleep mode within a preset time threshold. In other words, the module has issued the relevant actions to enter sleep mode, but during subsequent execution, it remains in an active operating state and fails to switch to a low-power state as expected. In this embodiment, the sleep process can be considered abnormal if, but is not limited to, the time after entering sleep mode is measured, and the state switch is not completed within the preset time threshold.

[0039] In one exemplary implementation, this type of exception is usually related to a blocking state during the hibernation execution process, such as some running tasks not completing and exiting, some resources not being released, or the continuous occupation of running permissions, making it impossible for the hibernation process to converge normally to a low-power state. Therefore, in this embodiment, the situation where the state switch cannot be completed within a specified time is classified as a hibernation timeout exception, which is used to characterize the failure state of the hibernation entry process.

[0040] In this embodiment, an abnormal wake-up event refers to a situation where the module, after entering a sleep state, is reawakened without meeting the expected wake-up conditions. In other words, the module should be operating at low power, but an unplanned wake-up action occurs during operation, causing it to switch from sleep to normal operation. This embodiment may, but is not limited to, compare the wake-up trigger source with the expected wake-up conditions; when the wake-up source does not meet the preset rules, it can be considered an abnormal wake-up event.

[0041] In this embodiment, such abnormal wake-up events may manifest as repeatedly entering the wake-up state within a short period of time, or being woken up again very shortly after entering the sleep state, making it impossible to maintain stable and continuous operation of the sleep state. In this embodiment, such wake-up behaviors that do not meet the expected sleep maintenance conditions are uniformly classified as abnormal wake-up events to characterize abnormal interruptions in the sleep state maintenance process.

[0042] In this embodiment, an abnormal restart event refers to a situation where the module crashes during hibernation, causing an interruption in its operation and a restart. In other words, the module crashes due to an abnormal error during low-power operation, forcibly terminating the current operation and initiating a restart process. This embodiment can identify, but is not limited to, the presence of a restart caused by an abnormal crash by detecting the module restart flag or startup reason information.

[0043] In this embodiment, such abnormal restarts typically indicate a serious operational error during hibernation, such as kernel malfunction, critical task execution error, or resource access error, preventing the module from maintaining its original operational state. Therefore, this embodiment categorizes such crashes and restarts during hibernation as abnormal restart events to characterize serious operational interruption problems occurring during the hibernation phase.

[0044] In one exemplary embodiment, the detection method for hibernation timeout anomalies includes: Start the sleep timer when the module enters the sleep process; If the module fails to enter sleep mode when the sleep timer exceeds the preset time threshold, a sleep timeout abnormality is determined. Based on the type of the abnormal event, obtain the corresponding diagnostic information, including: Obtain the module's running status information, which includes at least one of the following: wake-up lock list, wake-up source status, CPU idle statistics, active process and thread stack information. The running status information is used to diagnose the blocking sources that prevent the module from successfully entering sleep mode. Generate a hibernation failure diagnostic log based on the running status information.

[0045] In this embodiment, the detection method for hibernation timeout anomalies is based on a hibernation timer. The hibernation timer is started when the module enters the hibernation process. This timer continuously counts from the moment the hibernation process begins, and is used to constrain and determine the execution time of the hibernation process. In this embodiment, the timing function can be implemented using, but is not limited to, a kernel timer or a user-mode timer statistics method. The core is to set a determinable time boundary for the hibernation entry process.

[0046] If the module fails to enter sleep mode after the sleep timer has exceeded a preset time threshold, a sleep timeout exception is determined. In this embodiment, this judgment logic is equivalent to imposing a time window constraint on the sleep entry process. If the actual entry into low-power state is not completed within the specified time range, it indicates that there is a blockage or abnormal interruption in the sleep process, which results in the inability to enter sleep mode as expected.

[0047] After a hibernation timeout exception occurs, this embodiment further acquires the module's operating status information to analyze the reasons for not entering hibernation. The operating status information may include one or more of the following: a wake-up lock list, wake-up source status, CPU idle statistics, and active process and thread stack information. In this embodiment, this information corresponds to different dimensions of runtime usage, such as resource holding status, driver activation status, and CPU execution distribution, thereby helping to pinpoint the source of the hibernation process's failure to converge.

[0048] The wake-up lock list reflects which processes or threads currently hold wake-up locks, allowing for the determination of whether any tasks are continuously holding them and preventing the CPU from entering a sleep state. The wake-up source status reflects the currently active wake-up sources and their corresponding driver states, helping to determine if any driver layers are continuously maintaining an active state. CPU idle statistics reflect the proportion of CPU resources used by different tasks, aiding in the determination of whether continuously running tasks are preventing the CPU from entering an idle state. Active process and thread stack information reflects the current thread execution position and call relationships, helping to pinpoint the stall location of the sleep process within its execution path.

[0049] In this embodiment, a hibernation failure diagnostic log is generated based on the aforementioned operational status information. This diagnostic log records a set of key operational status data when a hibernation timeout anomaly occurs, enabling subsequent backtracking analysis of the source of the blockage based on this log. This embodiment simultaneously collects multi-dimensional operational status information when a hibernation timeout anomaly occurs, ensuring that the reason for the unsuccessful hibernation entry is recorded instantly upon the anomaly's occurrence, thereby avoiding information loss due to subsequent status changes.

[0050] In one exemplary embodiment, the detection method for abnormal wake-up events includes: When the module is woken up from sleep mode, the type of the current wake-up source that triggered this wake-up is identified; Get the current wake-up time window and the current wake-up frequency; If the current wake-up source type is not in the preset allowed wake-up source whitelist, and / or the current wake-up time window is less than the preset time window threshold, and / or the current wake-up frequency exceeds the preset frequency threshold, then an abnormal wake-up event is determined to exist. Based on the type of the abnormal event, obtain the corresponding diagnostic information, including: Match the target log type corresponding to the current wake-up source type according to the preset mapping strategy; Perform targeted log fetching on the module based on the target log type.

[0051] In this embodiment, when the module is woken up from sleep mode, the current wake-up source type is first identified to determine the trigger source of this wake-up action. In this embodiment, the wake-up source type can be, but is not limited to, wake-up source information generated by hardware interrupt sources, communication modules, timer events, or external input events, and is used to characterize the specific trigger point that causes the module to exit sleep mode.

[0052] Based on identifying the wake-up source type, the current wake-up time window and current wake-up frequency are further obtained. The current wake-up time window represents the time interval between the module entering sleep mode and the current wake-up occurrence, while the current wake-up frequency represents the number of wake-ups occurring within a unit of time. In this embodiment, these two parameters reflect the wake-up behavior characteristics of the module during sleep, describing the wake-up behavior from two dimensions: time distribution and occurrence density.

[0053] Based on this, this embodiment performs anomaly detection for wake-up behavior. If the current wake-up source type is not within the preset allowed wake-up source whitelist, it indicates that the wake-up source does not meet the expected control range. If the current wake-up time window is less than a preset time window threshold, it indicates that the module was woken up shortly after entering sleep mode, and the sleep state failed to remain stable. If the current wake-up frequency exceeds a preset frequency threshold, it indicates that the module exhibits excessively frequent wake-up behavior within a unit of time. When any of the above conditions are met, an abnormal wake-up event is determined to exist.

[0054] After determining that an abnormal wake-up event has occurred, this embodiment performs a corresponding log type matching based on the current wake-up source type. The matching process is implemented based on a preset mapping strategy. In this mapping strategy, different wake-up source types are associated with the runtime log categories they may involve, in order to determine the scope of logs that need to be acquired in this abnormal wake-up scenario.

[0055] After completing log type matching, a targeted log fetching operation is performed on the module, acquiring only data related to the target log type corresponding to the current wake-up source type. In this embodiment, this method avoids indiscriminate collection of all logs, instead selectively acquiring corresponding log information based on the source of the abnormal wake-up. This allows key operational information at the time of the abnormal wake-up to be centrally recorded, providing a targeted data foundation for subsequent anomaly cause analysis.

[0056] In one exemplary embodiment, the preset mapping strategy includes: When the current wake-up source type is modem wake-up, the matching target log type includes at least modem crash logs and network status logs; When the current wake-up source type is a general input / output interface wake-up, the matching target log type must include at least interrupt driver log and general input / output interface configuration log; When the current wake-up source type is Wake-up from the network, the matching target log types include at least TCP / IP protocol stack logs and wireless interface layer logs; When the current wake-up source type is real-time clock wake-up, the matching target log types must include at least timer logs and system task logs.

[0057] In this embodiment, a preset mapping strategy is used to determine the corresponding target log type set based on the current wake-up source type, thereby enabling targeted log acquisition when an abnormal wake-up occurs. In this embodiment, the mapping relationship can be pre-configured in the module's storage unit and directly read and called by the control logic during operation to establish the correspondence between the wake-up source type and the log type.

[0058] When the current wake-up source type is modem wake-up, the log acquisition in this embodiment is not limited to a single type of log, but is classified and matched according to different operating states that may be involved in the modem operation. For example, when the modem malfunctions, it may manifest as different situations such as protocol stack malfunction, driver crash, or network connection malfunction. Therefore, the corresponding log types include at least modem crash logs and network status logs. In this embodiment, the log collection items can be adapted and configured according to the implementation differences of different modem manufacturers. For example, for different baseband chips or driver implementations, the crash log output interface or network status recording node can be adjusted so that the log acquisition can cover the sources of key abnormal information during its operation.

[0059] When the current wake-up source type is a general input / output interface wake-up, the corresponding exception is often related to peripheral interrupt triggering or interface configuration status. In this embodiment, the matched target log types include at least interrupt driver logs and general input / output interface configuration logs. The interrupt driver log is used to reflect the interrupt triggering process and execution path, while the interface configuration log is used to reflect the current interface level status and configuration parameter changes, thereby determining whether there is a wake-up behavior caused by an abnormal interrupt trigger or configuration error.

[0060] When the current wake-up source type is Wake-up from the network, this embodiment focuses on the triggering source of the network communication link during the wake-up process. Therefore, the target log types to be matched include at least TCP / IP protocol stack logs and wireless interface layer logs. The TCP / IP protocol stack logs are used to reflect the upper-layer protocol processing and connection state changes, while the wireless interface layer logs are used to reflect wireless link state changes and receiving and sending behaviors, thereby locating the specific source link that triggers the wake-up from the network communication.

[0061] When the current wake-up source type is real-time clock wake-up, this embodiment mainly analyzes timed task triggering or periodic scheduling behavior. Therefore, the target log types to be matched include at least timer logs and system task logs. Timer logs are used to record the triggering of timed events, and system task logs are used to record task scheduling execution, thereby determining whether there is a situation where a timed task abnormally triggers a wake-up or a task scheduling abnormality causes a wake-up behavior. By matching different wake-up sources with different log types as described above, this embodiment can ensure that the log collection scope when an abnormal wake-up occurs is consistent with the triggering source, thus providing a more targeted operational information foundation for subsequent problem analysis.

[0062] In one exemplary embodiment, the method for obtaining detection and diagnostic information of abnormal restart events includes: After the module restarts, obtain the boot reason code; If the boot reason code indicates that this boot is an abnormal restart, then read the kernel crash call stack log saved in the persistent storage space; The kernel crash call stack log is correlated with the phase information corresponding to the previous sleep lifecycle to determine whether a crash event occurred during sleep.

[0063] In this embodiment, the detection and diagnostic information acquisition method for abnormal restart events is triggered after the module completes a restart. After the module restarts, it first acquires the boot reason code, which reflects the trigger source and boot type of this boot. In this embodiment, the boot reason code may, but is not limited to, originate from boot register information, boot record unit, or underlying boot flag bits, and is used to distinguish between normal boot and abnormally triggered boot.

[0064] After obtaining the boot reason code, the code is processed. If the boot reason code indicates that this startup is an abnormal restart, it means that the module terminated abnormally in the previous operating cycle. In this embodiment, this situation is treated as an abnormal restart event and entered into the subsequent processing flow. This judgment process is based on historical state information during the startup phase, enabling abnormal restarts to be quickly identified during the startup phase without relying on subsequent operating data.

[0065] After confirming the abnormal restart event, this embodiment further reads the kernel crash call stack log from the persistent storage space. This persistent storage space is used to save critical runtime information when the system terminates abnormally, and the kernel crash call stack log is used to record the function call path and execution status at the time of the crash. In this embodiment, pstore or a similar persistent storage area can be used to save and read the log, so that the crash information from the previous runtime cycle can still be obtained after the system restarts.

[0066] After obtaining the kernel crash call stack log, this embodiment performs time-series correlation processing on the log and the stage information corresponding to the previous sleep lifecycle. This correlation process is based on the correspondence between the stage time information and the crash log recording time to analyze whether the crash event occurred during the sleep process. When the time corresponding to the call stack log falls within the time range of the sleep lifecycle, it can be determined that a crash event occurred during sleep, thereby establishing a correspondence between the abnormal restart and the sleep process. Through this method, this embodiment enables not only the abnormal restart event to be identified but also to be correlated with a specific sleep stage, thus providing a time-dimensional basis for subsequent tracing of the cause of the anomaly.

[0067] In one exemplary embodiment, the plurality of preset key stages include at least two of the following stages: The hibernation request initiation phase is used to respond to hibernation commands and execute actions related to those commands. The device freeze phase is used to stop the execution of upper-layer applications or threads; The interrupt shutdown phase is used to stop the operation of the driver and put each driver into sleep mode; The central processing unit enters a low-power phase, which is used to control the central processing unit to enter a low-power state after the upper-layer applications and drivers have stopped. The system wake-up phase is used to respond to wake-up commands or external interrupts to wake up the central processing unit; The device recovery phase is used to restore the operation of the driver and the upper-layer application or thread.

[0068] In this embodiment, multiple preset key stages are used to divide the key execution nodes in the process of the module entering the hibernation state from the normal operation state and recovering from the hibernation state. In this embodiment, the key stages can be configured according to the actual power management process of the module, but are not limited to, and include at least two stages to form the basis for segmented description of the hibernation and wake-up process.

[0069] The hibernation request initiation phase is used to respond to hibernation commands and execute actions related to those commands. In this phase, after receiving a hibernation command from an upper layer or external source, the module enters a hibernation preparation process, such as stopping the reception of some service requests or entering a hibernation preparation state. In this embodiment, this phase is used to identify the start time of the hibernation process, providing a starting point for subsequent phase time recording.

[0070] The device freeze phase is used to stop the execution of upper-layer applications or threads. During this phase, the system pauses running user-mode tasks or application threads, preventing them from continuing to execute new task scheduling. In this embodiment, the purpose of this phase is to gradually converge user-mode running activities, providing conditions for subsequent drivers and the underlying layer to enter a low-power state.

[0071] The interrupt shutdown phase is used to stop the operation of drivers and put each driver into hibernation mode. During this phase, the system disables or masks peripheral interrupts, and the driver module enters the corresponding hibernation control flow, preventing peripherals from responding to new interrupt requests. In this embodiment, this phase is used to reduce the impact of peripheral activity on the hibernation entry process.

[0072] The CPU enters a low-power phase to control the CPU into a low-power state after upper-layer applications and drivers have stopped. In this phase, the CPU performs final power-reduction operations, such as entering idle or deep sleep mode, causing the entire module to enter a low-power operating mode. In this embodiment, this phase marks the core node where the module enters a sleep state.

[0073] The system wake-up phase is used to respond to wake-up commands or external interrupts to wake up the central processing unit. During this phase, the module resumes operation from a low-power state, possibly triggered by a timing event, external input, or communication event. In this embodiment, this phase marks the end of the hibernation state and the start of the recovery process.

[0074] The device recovery phase is used to restore the operation of drivers and upper-layer applications or threads. During this phase, the system gradually restores peripheral drivers and user-mode tasks, bringing the module back to normal operating status. In this embodiment, this phase completes the full switchover process from a low-power state to a normal operating state.

[0075] like Figure 2As shown, the module hibernation anomaly diagnosis method provided in this application includes the following process: During system operation, when the module enters the hibernation process, the hibernation-wake-up cycle management module writes stage timestamps at multiple preset key stages of the hibernation process. Then, it determines whether the system enters the autosleep state within the preset hibernation timer T_suspend: if it does not enter autosleep within T_suspend, the hibernation timeout detection module is triggered, collecting wakelock lists, wakeupsources, CPU idle statistics, and process and thread stacks, generating a hibernation failure diagnosis log, and the process ends; if it enters autosleep within T_suspend, the system enters low-power hibernation. After the system is woken up, the abnormal wake-up identification module determines whether the wake-up is abnormal: if it is a normal wake-up, the process ends; if it is determined to be an abnormal wake-up, the targeted log collection module is triggered, matching the corresponding log type according to the current wake-up source type and capturing the targeted log, completing log archiving. If an abnormal restart occurs during hibernation or wake-up, the pstore is read after startup to obtain the kernel panic call stack, and it is associated with the previous hibernation timeline to form a closed loop of hibernation crash evidence.

[0076] In this embodiment, the processing methods and corresponding effects under different abnormal scenarios are described as follows.

[0077] Regarding log acquisition methods, traditional methods typically rely on manually reproducing abnormal scenarios and manually capturing logs, often requiring repeated operations at the problem site to obtain limited log information. In this embodiment, however, the corresponding information collection process is automatically triggered after an abnormal event is detected, realizing automatic detection and automatic evidence collection. This allows key operational information at the time of the anomaly to be recorded directly on-site, reducing the reliance on repeated reproduction.

[0078] In terms of visualizing the hibernation process, traditional methods often lack a unified time reference point, making it difficult to continuously record the states of each stage during the hibernation entry process. In this embodiment, stage identifiers and stage time information are recorded at multiple preset key stages of the hibernation process to form a hibernation lifecycle. This allows the hibernation entry and recovery process to be retrospectively analyzed in chronological order, which is beneficial for determining the specific stage where anomalies occur.

[0079] In diagnosing hibernation failures, traditional methods often struggle to obtain timely operational information when the system cannot enter hibernation mode. In this embodiment, upon detecting a hibernation timeout anomaly, the system acquires a wake-up lock list, wake-up source status, CPU idle statistics, and active process and thread stack information to reflect the current system occupancy. This records the source of the blockage from multiple dimensions, ensuring that the cause of the hibernation failure is synchronously retained when the anomaly occurs.

[0080] In handling abnormal wake-ups, traditional methods typically log the entire wake-up behavior, which can easily introduce a large amount of irrelevant information. In this embodiment, the corresponding target log type is matched based on the wake-up source type, and targeted log fetching is performed. Only log content related to the current wake-up source is obtained, ensuring that the log collection scope remains consistent with the source of the anomaly, thereby reducing redundant data recording.

[0081] In abnormal restart analysis, traditional methods often store crash logs and runtime logs separately, lacking a correlation. In this embodiment, after system restart, the kernel crash call stack log in the persistent storage space is read and correlated with the stage information corresponding to the previous sleep lifecycle. This allows for determination of whether the crash occurred during sleep from a time perspective, thereby achieving cross-cycle abnormal correlation analysis.

[0082] Regarding mass production adaptability, traditional methods rely on on-site reproduction to obtain logs, which is time-consuming and unstable. In this embodiment, by automatically collecting key operational information when an anomaly is triggered and combining it with persistent logging, the anomaly information can be directly retained on-site and automatically analyzed later, thereby reducing the reliance on repeated on-site reproduction.

[0083] Secondly, this application provides a module sleep anomaly diagnostic system, comprising: The lifecycle recording module is used to respond to the module entering the hibernation process. It records the corresponding stage identifier and stage time information at multiple preset key stages of the hibernation process to establish the hibernation lifecycle of the module. The anomaly detection module is used to monitor the operating status of the module based on the stage time information during the hibernation life cycle, and to obtain the diagnostic information corresponding to the anomaly event based on the type of the anomaly event when an anomaly event is detected. The stage association module is used to associate diagnostic information with the stage information corresponding to the hibernation life cycle in order to determine the occurrence stage of the abnormal event. The diagnosis result generation module is used to generate abnormal diagnosis results for the module based on the associated diagnosis information.

[0084] like Figure 3 As shown, the module hibernation anomaly diagnosis system provided in this application includes a user-mode power management layer and a kernel power management layer. The user-mode power management layer deploys a hibernation timeout detection module, an abnormal wake-up identification module, and a targeted log collection module; the kernel power management layer deploys a hibernation wake-up cycle management module and a Panic persistent log integration module. The modules communicate with each other through a unified event distribution mechanism, forming a closed-loop anomaly diagnosis system covering the entire hibernation process. For a detailed description of the module hibernation anomaly diagnosis system, please refer to the embodiments of the above-described module hibernation anomaly diagnosis method; further details will not be repeated here.

[0085] Thirdly, this application provides a module sleep abnormality diagnostic device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of the module hibernation anomaly diagnosis method described above when executing a computer program.

[0086] The device includes a memory and a processor. The memory stores a computer program that implements logic related to module hibernation anomaly diagnosis. The processor, connected to the memory, executes the computer program to perform all steps of the aforementioned module hibernation anomaly diagnosis method, such as hibernation lifecycle recording, abnormal event identification, diagnostic information acquisition, stage correlation, and abnormal diagnosis result generation. This allows for the automatic identification and recording of abnormal situations during hibernation and wake-up at the hardware execution level.

[0087] For a description of the module sleep abnormality diagnosis device, please refer to the embodiments of the above-described module sleep abnormality diagnosis method; this application will not repeat the details here.

[0088] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the module hibernation anomaly diagnosis method described above.

[0089] This storage medium enables the relevant methods to run as software programs on different types of devices, such as communication modules or terminal devices with processing capabilities, thereby achieving unified diagnosis and recording of sleep timeout anomalies, abnormal wake-up events, and abnormal restart events.

[0090] For a description of the computer-readable storage medium, please refer to the embodiments of the above-described module hibernation anomaly diagnosis method; this application will not repeat them here.

[0091] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0092] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for diagnosing module hibernation anomalies, characterized in that, include: When the response module enters the hibernation process, the corresponding stage identifier and stage time information are recorded at multiple preset key stages of the hibernation process to establish the hibernation life cycle corresponding to the module. During the dormancy lifecycle, the operating status of the module is monitored based on the stage time information, and when an abnormal event is detected, diagnostic information corresponding to the abnormal event is obtained according to the type of the abnormal event. The diagnostic information is associated with the stage information corresponding to the hibernation life cycle to determine the occurrence stage of the abnormal event. Anomaly diagnosis results for the module are generated based on the associated diagnostic information.

2. The module sleep abnormality diagnosis method according to claim 1, characterized in that, The abnormal event includes at least one of the following: The sleep timeout exception corresponding to the module failing to enter sleep state within a preset time threshold; the abnormal wake-up event corresponding to the module being unexpectedly woken up from sleep state; The abnormal restart event corresponds to the module crashing during hibernation and restarting after the crash.

3. The module sleep abnormality diagnosis method according to claim 2, characterized in that, The detection methods for the hibernation timeout anomaly include: A sleep timer is started when the module enters the sleep process; If the module fails to enter sleep mode when the sleep timer exceeds a preset time threshold, it is determined that there is a sleep timeout abnormality. The step of obtaining diagnostic information corresponding to the abnormal event based on the type of the abnormal event includes: The module's running status information is obtained, which includes at least one of the following: a wake-up lock list, wake-up source status, CPU idle statistics, and active process and thread stack information. The running status information is used to diagnose the blocking sources that prevent the module from successfully entering sleep mode. A hibernation failure diagnostic log is generated based on the aforementioned operating status information.

4. The module sleep abnormality diagnosis method according to claim 2, characterized in that, The detection methods for the abnormal wake-up event include: When the module is woken up from sleep mode, the type of the current wake-up source that triggered the wake-up is identified; Get the current wake-up time window and the current wake-up frequency; If the current wake-up source type is not in the preset allowed wake-up source whitelist, and / or the current wake-up time window is less than the preset time window threshold, and / or the current wake-up frequency exceeds the preset frequency threshold, then it is determined that the abnormal wake-up event exists. The step of obtaining diagnostic information corresponding to the abnormal event based on the type of the abnormal event includes: Match the target log type corresponding to the current wake-up source type according to the preset mapping strategy; Perform targeted log fetching on the module based on the target log type.

5. The module sleep abnormality diagnosis method according to claim 4, characterized in that, The preset mapping strategy includes: When the current wake-up source type is modem wake-up, the matched target log types include at least modem crash logs and network status logs; When the current wake-up source type is a general input / output interface wake-up, the matching target log type includes at least interrupt driver log and general input / output interface configuration log; When the current wake-up source type is Wake-up from the network, the matched target log types include at least TCP / IP protocol stack logs and wireless interface layer logs; When the current wake-up source type is real-time clock wake-up, the matched target log type includes at least timer logs and system task logs.

6. The module sleep abnormality diagnosis method according to claim 2, characterized in that, The methods for obtaining detection and diagnostic information for abnormal restart events include: After the module restarts, obtain the power-on reason code; If the boot reason code indicates that this boot is an abnormal restart, then read the kernel crash call stack log saved in the persistent storage space; The kernel crash call stack log is correlated with the phase information corresponding to the previous sleep lifecycle to determine whether a crash event occurred during sleep.

7. The module sleep abnormality diagnosis method according to any one of claims 1-6, characterized in that, The plurality of preset key stages include at least two of the following stages: The hibernation request initiation phase is used to respond to a hibernation command and perform actions related to the hibernation command; The device freeze phase is used to stop the execution of upper-layer applications or threads; The interrupt shutdown phase is used to stop the operation of the driver and put each driver into sleep mode; The central processing unit enters a low-power phase, which is used to control the central processing unit to enter a low-power state after the upper-layer application and the driver have both stopped. The system wake-up phase is used to respond to a wake-up command or external interrupt to wake up the central processing unit; The device recovery phase is used to restore the operation of the driver and the upper-layer application or thread.

8. A module sleep abnormality diagnosis system, characterized in that, include: The lifecycle recording module is used to respond to the module entering the hibernation process, and to record the corresponding stage identifier and stage time information in multiple preset key stages of the hibernation process, so as to establish the hibernation lifecycle corresponding to the module. An anomaly detection module is used to monitor the operating status of the module based on the stage time information during the hibernation life cycle, and to obtain diagnostic information corresponding to the anomaly event according to the type of the anomaly event when an anomaly event is detected. The stage association module is used to associate the diagnostic information with the stage information corresponding to the hibernation life cycle in order to determine the occurrence stage of the abnormal event. The diagnosis result generation module is used to generate the abnormal diagnosis result of the module based on the associated diagnosis information.

9. A module sleep abnormality diagnostic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to, when executing a computer program, implement the steps of the module hibernation anomaly diagnosis method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the module hibernation anomaly diagnosis method as described in any one of claims 1-7.

Images