A device startup abnormality recovery method and a computing device

Abstract

Embodiments of the present application relate to the technical field of electronic equipment, and provide a device startup abnormality recovery method and a computing device. The method is applied to a CPU in the computing device, and the method comprises: in response to detecting a CPU abnormality event, identifying a firmware stage in which the computing device currently locates; the firmware stage comprises a power-on self-test (POST) stage and a runtime (Runtime) stage; when the computing device is in the Runtime stage, sending abnormality context information corresponding to the CPU abnormality event to a baseboard management controller (BMC) in the computing device; and when the computing device is in the POST stage, if the computing device satisfies a restart condition, cold restarting the computing device. Based on the present solution, the CPU uses a BIOS to adopt an adaptive processing manner for CPU abnormality events in different firmware stages, retains complete abnormality context, improves the efficiency of fault analysis and repair, and meets the requirement of service stability of the computing device.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a device startup anomaly recovery method and computing device. Background Technology

[0002] During the startup process, computing devices such as computers and servers utilize the Basic Input / Output System (BIOS) to complete a series of Power-On Self-Test (POST) operations, including hardware initialization, memory setup, and peripheral enumeration. During the POST phase, the BIOS may trigger a Central Processing Unit Exception due to hardware transients, unstable memory timings, firmware initialization logic defects, or external electromagnetic noise, causing the computing device to hang or unexpectedly restart.

[0003] A common method for anomaly recovery is to restart the computing device to reset its hardware state and restore it to a usable state. While this method can restore the computing device to a usable state in some transient anomaly scenarios, it cannot effectively retain the context information at the time of the anomaly, making it difficult to pinpoint the root cause. Furthermore, if the anomaly is repeatedly triggered, a direct restart can trap the computing device in a vicious cycle of "anomaly-restart-anomaly," preventing it from entering an operable state for fault analysis. This significantly increases the time cost of fault repair and fails to meet the anomaly handling needs of high-stability computing devices such as servers. Summary of the Invention

[0004] This application provides a device startup anomaly recovery method and computing device. By identifying the firmware stage of the computing device when the anomaly occurs, and adopting an appropriate processing method for different firmware stages, the method meets the requirements of business stability and improves fault repair efficiency.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a device startup anomaly recovery method, applied to a central processing unit (CPU) in a computing device. The method includes: in response to detecting a CPU anomaly event, identifying the current firmware stage of the computing device; the firmware stage includes a power-on self-test (POST) stage and a runtime stage; when the computing device is in the runtime stage, sending the anomaly context information corresponding to the CPU anomaly event to the baseboard control manager (BMC) in the computing device; when the computing device is in the POST stage, if the computing device meets the restart conditions, performing a cold restart of the computing device.

[0006] Based on this solution, the CPU in the computing device can utilize firmware to distinguish the different firmware stages at which the computing device is located when a CPU anomaly occurs. This allows for the adoption of appropriate handling methods at different firmware stages, meeting the requirements of business stability. For anomalies occurring in the Runtime stage, the anomaly context information can be directly recorded to the BMC for persistent storage. For anomalies occurring in the POST stage, the computing device is evaluated based on restart conditions. Devices meeting the restart conditions can undergo a cold restart, providing an opportunity for automatic recovery from transient anomalies. This also ensures the complete retention of the anomaly context in the event of recurring anomalies, preventing repeated restarts from overwriting anomaly information. This effectively solves the problem of being unable to locate the root cause of CPU anomalies at the firmware stage, improving the efficiency of fault analysis and repair.

[0007] In one possible implementation, if the computing device meets the restart conditions, a cold restart of the computing device is performed, including: obtaining a restart trigger flag; the restart trigger flag is used to indicate whether the computing device has triggered an abnormal restart during the startup cycle; if the restart trigger flag is triggered, the computing device does not meet the restart conditions; if the restart trigger flag is not triggered, the computing device meets the restart conditions; the method further includes: pausing the startup process of the computing device when the computing device does not meet the restart conditions.

[0008] Based on this solution, the CPU can control abnormal restart behavior within the current startup cycle through a restart trigger flag. By using a mechanism that only allows an abnormal restart to be triggered once within a single startup cycle, it provides an opportunity for automatic recovery startup for occasional abnormalities caused by hardware transient interference and other reasons. It also avoids the repeated restarts caused by the same abnormality, which would lead to the abnormality's initial context being overwritten by multiple restarts. It can retain abnormal context information for subsequent fault analysis and ensure the data integrity for abnormal root cause localization.

[0009] In another possible implementation, cold restarting the computing device includes: setting a restart trigger flag to triggered; restarting the computing device; and setting the restart trigger flag to untriggered in response to the computing device's firmware phase switching to the Runtime phase.

[0010] Based on this solution, the CPU utilizes the BIOS to trigger the status update of the flags through a reboot, which can accurately record whether an abnormal reboot has been triggered in the current boot cycle, avoid multiple reboot cycles in the same boot cycle, ensure that the exception context can be completely preserved when the final exception occurs, and reset the flags in a timely manner after successful boot to prepare for exception handling in the next boot process. The flag management logic is simple, clear, and highly reliable.

[0011] In another possible implementation, identifying the current firmware stage of the computing device includes: obtaining a POST completion flag; the POST completion flag is used to indicate whether the POST process of the computing device has been completed; when the POST completion flag is incomplete, the computing device is determined to be in the POST stage; when the POST completion flag is complete, the computing device is determined to be in the Runtime stage.

[0012] Based on this solution, the CPU can use POST to complete the identification and determination of the firmware stage, which can easily and accurately identify the current stage without adding any additional complex detection logic, thus achieving low cost and high identification accuracy.

[0013] In another possible implementation, identifying the current firmware stage of the computing device also includes: detecting the startup status of the BootService corresponding to the computing device; setting the POST completion flag to incomplete when the BootService is started; and setting the POST completion flag to complete when the BootService is stopped.

[0014] Based on this solution, the CPU can directly update the stage identifier based on the native BootService state of the computing device, without the need for an additional state detection module. It can complete stage identification by relying on the state information of the existing startup process, further reducing the implementation complexity and ensuring accurate and reliable identification results.

[0015] In another possible implementation, the exception context information includes at least one of the following: CPU exception type, CPU register state, instruction address at the time the exception occurred, stack pointer, timestamp, and firmware stage of the computing device.

[0016] Based on this solution, the anomaly context information recorded by BMC can cover the core dimensions required for anomaly analysis, providing sufficient and complete information support for operations and maintenance personnel to locate the root cause, and improving the efficiency and accuracy of root cause analysis.

[0017] In another possible implementation, the startup process of the computing device is suspended, including: putting the CPU into a suspended state; the suspended state is used to block the execution of instructions in the CPU; and the exception log corresponding to the suspended state is recorded by the BMC.

[0018] Based on this solution, the startup process can be directly blocked and a complete exception log can be retained after the CPU exception is reproduced. This avoids the computing device from getting stuck in a loop of repeated restarts and ensures that the exception information is not overwritten by the restart. The operation and maintenance personnel can export the exception log through BMC to complete the root cause analysis without having to disassemble the device to capture the exception information, thus reducing the cost of exception investigation.

[0019] In another possible implementation, identifying the current firmware stage of the computing device also includes: detecting the exception type of the CPU exception event; performing recovery processing on the CPU exception event based on the exception type; and identifying the current firmware stage of the computing device if the CPU exception event recovery fails.

[0020] Based on this solution, for CPU anomalies that can be eliminated through simple recovery processing, the BIOS can first attempt automatic repair without directly entering the process of recording the anomaly and restarting. This further enhances the self-healing capability of the computing device's startup process, reduces unnecessary restarts and anomaly recording, and optimizes the reliability of the startup process.

[0021] In another possible implementation, CPU exception events include at least one of overflow exception, invalid opcode exception, page fault, and general protection exception.

[0022] Based on this solution, the CPU can identify and handle most common CPU anomaly types during the startup process of computing devices through firmware. It has strong adaptability and can uniformly handle various CPU anomalies common in the firmware stage, thus improving the applicability of anomaly recovery.

[0023] In a second aspect, embodiments of this application also provide a computing device, including: a processor and a BIOS chip; the processor and the BIOS chip are coupled; the BIOS chip is used to store program instructions; the processor is used to execute the program instructions to perform a device startup exception recovery method as described in any of the first aspects above.

[0024] Thirdly, embodiments of this application provide a BIOS chip that stores computer execution instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0025] Fourthly, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0026] Figure 1 A flowchart illustrating a device startup anomaly recovery method provided in this application embodiment; Figure 2 A flowchart illustrating the process of determining the state of satisfaction of restart conditions provided in an embodiment of this application; Figure 3 A schematic diagram of a firmware stage identification process provided for an embodiment of this application; Figure 4 A schematic diagram illustrating a process for updating an identifier, provided as an embodiment of this application; Figure 5This is a schematic diagram of a process for restarting a computing device provided in an embodiment of this application; Figure 6 A schematic diagram illustrating a process for pausing CPU startup, provided as an embodiment of this application; Figure 7 A schematic diagram illustrating another firmware stage identification process provided in this application embodiment; Figure 8 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0028] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0029] The Central Processing Unit (CPU) is used to execute instructions and perform logical control; it is the core processing unit of a computing device.

[0030] The Basic Input / Output System (BIOS) is firmware embedded in the motherboard chip of a computing device. It performs functions such as hardware initialization, loading the bootloader, and transferring control to the operating system during the startup process of the computing device.

[0031] The Baseboard Management Controller (BMC) is an independent controller integrated on the motherboard of a computing device. It is used to monitor the hardware status of the device, perform remote management operations, and provide monitoring and control functions for the device, ensuring that the computing device has stable out-of-band management capabilities in complex operating environments.

[0032] The firmware stage refers to the initialization and self-test process led by the BIOS firmware during the period from power-on to the completion of operating system loading of a computing device. In the embodiments of this application, it may include a power-on self-test stage and a runtime stage.

[0033] The Power-On Self-Test (POST) is the first stage of the hardware self-test process executed by the BIOS after a computing device is powered on. It is designed to detect whether critical hardware such as the CPU, memory, graphics processing unit (GPU), and storage devices are working properly.

[0034] The runtime phase refers to the firmware execution phase after the computing device completes the POST process through the BIOS and enters the operating system's control. At this time, the system resources have been initialized by the BIOS and handed over to the operating system for resource scheduling and task management. The BIOS only retains a limited number of firmware service interfaces for the operating system to call.

[0035] CPU exceptions are abnormal events detected by the CPU during instruction execution. Their triggering mechanisms cover a variety of situations, including hardware errors, illegal instructions, memory access violations, and privilege level out-of-bounds violations.

[0036] The application scenarios of the embodiments of this application will be described below.

[0037] After a computing device is powered on, it first executes the POST process. At this time, the BIOS takes over hardware control and starts the self-test program. The computing device is in the hardware self-test process, the operating system has not yet been loaded, and the system runs under the control of the firmware. After the BIOS in the computing device completes the POST process, the operating system enters the Runtime stage. The BIOS transfers control to the operating system, and the hardware resources are uniformly called by the operating system.

[0038] As a piece of hardware in a computing device, the CPU also triggers corresponding hardware initialization and self-test operations during the POST phase of the BIOS. However, during the CPU self-test, occasional CPU anomalies can occur due to factors such as hardware failure, voltage instability, or transient interference.

[0039] Although these CPU anomalies do not directly affect user services, they may cause system hangs or unexpected restarts, affecting the reliability and startup success rate of computing devices, while also prolonging the startup time of computing devices and reducing the user experience.

[0040] Based on this, the embodiments of this application provide a device startup anomaly recovery method. By identifying stages, different processing strategies are executed at different firmware stages of the computing device to handle CPU anomalies and retain the corresponding anomaly context information, thereby improving the operational stability of the computing device without interrupting services.

[0041] It should be noted that this application provides a method for recovering from device startup anomalies. This method can be applied to computing devices, such as servers, workstations, or embedded computing platforms. The computing device may include a central processing unit (CPU), a basic input / output system (BIOS), and a baseboard controller (BMC). The CPU is connected to both the BIOS and the BMC. Under the control of the CPU, the BIOS performs functions such as power-on self-tests and firmware initialization for the hardware in the computing device. The BMC is responsible for hardware monitoring and anomaly management. The three components work together to achieve real-time capture, stage-based judgment, and automatic recovery from CPU anomalies.

[0042] Figure 1 This is a flowchart illustrating a device startup anomaly recovery method provided in an embodiment of this application. The following is in conjunction with... Figure 1 The content shown herein provides a detailed explanation of the process by which a computing device recovers from an anomaly during startup, as described in the embodiments of this application.

[0043] like Figure 1 As shown, the process of recovering from an anomaly during the startup of a computing device in this embodiment of the application may include the following steps S100 to S300.

[0044] S100: In response to the detection of a CPU abnormal event, identify the current firmware stage of the computing device.

[0045] In step S100, after power-on, the computing device can initiate a power-on self-test (POST) process using the BIOS and simultaneously receive feedback information from the CPU to determine whether a CPU abnormal event has occurred. In this embodiment, the firmware stage may include a POST stage and a runtime stage, and the actions performed by the computing device in these two stages are significantly different. When the computing device is in the POST stage, the CPU will use the BIOS to perform firmware initialization and hardware self-test, and no user service data will be generated at this time; while when the computing device is in the Runtime stage, the system has entered the operating system loading and service running state, and user service data is being generated and processed in real time.

[0046] It's important to note that in computing devices, the BIOS is the firmware program on the motherboard, used to initialize the entire system's state after the device powers on. The CPU, on the other hand, is the execution unit; after power-on, it executes instructions contained in the BIOS to complete hardware initialization and self-test. If a CPU anomaly is detected during execution, it can be sent to the BIOS. The BIOS then uses preset instructions to determine the current firmware stage and execute the corresponding processing.

[0047] Correspondingly, when the computing device is in the POST phase, CPU exception events generated in the CPU will not directly affect user business data; however, when the computing device is in the Runtime phase, CPU exceptions or the computing device's handling measures for CPU exceptions may directly lead to business interruption or data loss, affecting the user's actual experience.

[0048] Therefore, after the CPU detects a CPU abnormal event using the BIOS, it can first identify the current firmware stage of the computing device to determine the execution path of the subsequent exception handling strategy: if it is in the POST stage, the computing device can execute the subsequent step S300; if it is in the Runtime stage, the computing device can execute step S200, thereby realizing a differentiated exception handling process based on the firmware stage.

[0049] In this embodiment of the application, the abnormal events that the CPU in the computing device can generate may include at least one of the following: overflow exception (#OF), invalid opcode exception (#UD), page fault (#PF), and general protection exception (#GP). Specifically, an overflow exception is triggered when the result of an arithmetic operation performed by the CPU exceeds the representable range of a register; an invalid opcode exception is triggered when the CPU encounters an undefined or illegal instruction; a page fault is triggered when the CPU accesses an illegal memory address or has insufficient privileges; and a general protection exception is caused by violations of segment protection mechanisms, out-of-bounds access, or privilege level violations.

[0050] When the CPU generates the above-mentioned exception, it can automatically trigger the exception callback handling function to capture context information such as exception type, register state, instruction pointer and stack frame information in real time, and pass it to the BIOS through the exception handling mechanism, so that the BIOS can obtain the corresponding CPU exception event.

[0051] In this embodiment, the exception callback handling function can be pre-registered by the BIOS and attached to the CPU's exception vector table. When the CPU triggers an exception of the corresponding type, it will automatically jump to the preset exception vector address to execute the exception callback handling function, thereby realizing the rapid capture and reporting of CPU exception events, ensuring that the BIOS can obtain all information related to the exception as soon as possible, and providing a basis for subsequent stage identification and exception handling.

[0052] After the computing device detects a CPU abnormal event, the corresponding function in the BIOS can determine the current firmware stage of the computing device: if TRUE is returned, the computing device is currently in the Runtime stage, and step S200 can be executed to avoid user service interruption and data loss caused by a restart in the Runtime stage; if FALSE is returned, the computing device is currently in the POST stage, and the computing device can execute step S300 to start the abnormal recovery process based on the stage determination result.

[0053] It should be understood that the above method of determining the firmware stage of a computing device through a function is only an exemplary implementation. In actual applications, other stage identification mechanisms can also be used, such as reading specific register bit fields or parsing the firmware runtime service call stack depth. In this application embodiment, there are no restrictions on the method by which the CPU determines the firmware stage of the computing device.

[0054] S200: When the computing device is in the Runtime phase, send the exception context information corresponding to the CPU exception event to the BMC in the computing device.

[0055] In step S200, after the CPU detects that the computing device is currently in the Runtime phase using the BIOS, it can send the exception context information corresponding to the CPU exception event to the BMC. The BMC then stores this information in the non-volatile memory reserved in the BMC, so that maintenance personnel can export the exception information through the BMC's management interface to complete fault location and root cause analysis.

[0056] In some embodiments, the CPU can also use the BIOS to combine the above-mentioned exception context information with the underlying hardware status log of the computing device, and encapsulate them together into a structured exception report, which is then submitted to the BMC through a standardized interface to ensure log integrity and traceability, and optimize fault diagnosis efficiency.

[0057] In one example, after completing the exception context storage, the computing device can perform lightweight on-site repairs for CPU exceptions, such as register state rollback, instruction redirection, or dynamic adjustment of memory page permissions, thereby restoring stable system operation while ensuring business continuity. If the exception repair is successful, the computing device can continue executing subsequent instruction flows through the CPU without the need for a forced restart, thus avoiding the impact of a runtime restart on user services.

[0058] If the same anomaly is repeatedly triggered or fails to recover for an extended period, the BIOS can, based on the current workload, trigger a hang-up or pause command to put the CPU into a controlled pause state. This will cause the computing device to suspend processing commands, safely shut down the system, and preserve the current state for maintenance personnel to debug and analyze in subsequent processes.

[0059] In this embodiment of the application, the exception context information stored by the computing device through the BMC may include at least one of the following: CPU exception type, CPU register state, instruction address at the time of the exception, stack pointer, timestamp, and current firmware stage.

[0060] Among them, the CPU anomaly type can clearly indicate the specific classification of the current anomaly, which can help the BIOS quickly determine the risk level and potential causes of the anomaly, providing a direct basis for selecting the appropriate recovery strategy. In the subsequent fault analysis stage, it can enable maintenance personnel to quickly locate the source of the anomaly.

[0061] CPU register states include the current values ​​of core registers such as general-purpose registers, segment registers, and control registers. They can fully present the CPU's operating state at the moment an exception is triggered, helping to reconstruct the instruction execution scenario when the exception occurs.

[0062] The address of the instruction that triggered the CPU exception can be directly located to the specific instruction that triggered the exception, making it easy to trace back the complete execution path that triggered the exception.

[0063] Stack pointers can be used to locate exception stack frame information, allowing operations and maintenance personnel to extract the function call chain before the exception occurred and trace the exception propagation process.

[0064] Timestamps can clearly identify the trigger time of an anomaly, making it easier to correlate changes in environmental parameters of concurrent computing devices and assisting in troubleshooting environmental factors such as voltage fluctuations and temperature anomalies.

[0065] The firmware stage of the computing device can clearly indicate the operating state of the system when the anomaly occurs, helping to distinguish whether the anomaly is in the POST stage or the Runtime stage, and further narrowing down the scope of troubleshooting.

[0066] Based on the above-obtained anomaly context information, and through persistent storage via BMC, the loss of anomaly information due to system restart or hang can be avoided, providing complete and reliable raw data support for subsequent root cause analysis of faults, and also providing data basis for subsequent optimization of anomaly handling strategies.

[0067] S300: If the computing device meets the restart conditions while it is in the POST phase, then perform a cold restart of the computing device.

[0068] In step S300, after the CPU uses the BIOS to identify that the current firmware stage is the POST stage, since the hardware self-test process has not been completed in this stage and the hardware control has not been transferred to the operating system, there are no running user services. Therefore, triggering an abnormal reset will not cause service data loss or service interruption.

[0069] Therefore, the CPU can determine whether the restart conditions are met based on the number of times the exception occurs. For example, if the cumulative number of CPU exception restarts in the current startup cycle does not exceed a preset threshold, the restart conditions are met. The CPU can encapsulate the context information such as the type of the CPU exception, register status, and trigger address through the BIOS and send it to the BMC. The exception is stored in the non-volatile memory space of the BMC to preserve the exception context. Then, the computing device is triggered to perform a full-link cold restart reset, allowing the computing device to be powered on again and execute the POST process. The device attempts to recover from the occasional exception through a second startup and completes the normal startup process.

[0070] The boot cycle refers to the complete process from the moment the computing device is powered on until it successfully enters the operating system, and it can be marked by entering the operating system. In this embodiment, since the Runtime stage is the running stage where the operating system has taken over hardware control, the entry of the computing device into the Runtime stage can be taken as the end point of the boot cycle.

[0071] If the number of abnormal CPU restarts accumulated during the current POST phase exceeds the preset threshold, the restart conditions are deemed not met. The BIOS will stop cold restart attempts and report the abnormal fault information to the BMC. The BMC will then send an abnormal alarm to the maintenance personnel through the out-of-band management channel, prompting manual intervention to investigate permanent hardware faults, thus preventing the device from falling into an infinite restart loop. At the same time, the abnormal scene is completely preserved for fault location and analysis.

[0072] In this embodiment, the preset restart threshold can be set to 1 time. Those skilled in the art can flexibly adjust the threshold according to the application scenario and hardware reliability requirements of the computing device. This application does not limit this.

[0073] By using the above-mentioned exception handling logic when the computing device is in the POST phase, it is possible to solve the occasional CPU exception problem caused by transient interference and voltage fluctuations, improve the startup success rate of the computing device, and promptly identify permanent hardware faults, avoiding unnecessary repeated restarts that would shorten the device's lifespan. This balances the effectiveness of exception recovery with the safety of device operation.

[0074] Through steps S100 to S300, the computing device can execute differentiated anomaly recovery strategies based on the current firmware stage. In the Runtime stage, it prioritizes service continuity, retaining only the anomaly context corresponding to the anomaly event to avoid service interruption caused by forced restart. In the POST stage, it attempts to recover from occasional anomalies through a limited number of cold retries, improving the startup success rate while avoiding infinite restart loops. It can recover from occasional CPU anomalies, preserving the anomaly context for fault analysis while improving the startup success rate and operational stability of the computing device.

[0075] Figure 2 This is a flowchart illustrating the process of determining the satisfaction status of restart conditions, as provided in an embodiment of this application. The following is based on... Figure 2 The content shown is used to illustrate the process by which the computing device determines the state in which the restart conditions are met in the embodiments of this application.

[0076] The steps S100 to S300 described above will be explained in detail below with reference to the accompanying drawings.

[0077] like Figure 2 As shown, in this embodiment of the application, the process by which the computing device determines the state in which the restart conditions are met may include the following steps S310 to S330.

[0078] S310: Get the restart trigger flag.

[0079] In step S310, after the BIOS recognizes that the current firmware stage is the POST stage, the CPU can obtain the corresponding restart trigger flag to determine whether an abnormal restart has already been triggered. The restart trigger flag indicates whether the BIOS has triggered an abnormal restart during the boot cycle, and the value of the restart trigger flag can be 0 or 1.

[0080] If the BIOS reads a restart trigger flag of 0, indicating that it has not been triggered, it means that the CPU has not yet triggered a restart operation during the current boot cycle. The CPU can then execute the subsequent step S330 through the BIOS to cold restart the computing device, thereby resetting the system and clearing the CPU's abnormal state. If the BIOS reads a restart trigger flag of 1, indicating that it has been triggered, it means that the computing device has already performed a cold restart during the current boot cycle. In this case, the CPU can then execute step S320 through the BIOS to determine that the computing device does not meet the restart conditions, and then trigger the corresponding handling method for not meeting the restart conditions.

[0081] In this embodiment, the startup cycle of a computing device refers to the process from powering on to entering the operating system. Once the computing device successfully enters the operating system, i.e., enters the Runtime stage, the current startup cycle ends. At the end of the startup cycle, the computing device can reset the restart trigger flag, i.e., change the restart trigger flag to not triggered, so that when the computing device starts a new startup cycle by powering on in subsequent processes, it can still trigger the corresponding restart condition judgment and execute the corresponding operations.

[0082] In one example, the restart trigger flag can be stored in complementary metal-oxide-semiconductor (CMOS) non-volatile memory in the computing device, ensuring that the flag state is retained after the system is powered off. It should be understood that the CMOS non-volatile memory can be independently located on the motherboard of the computing device, or it can be located in the Platform Controller Hub (PCH). The PCH connects the CPU to various low- and medium-speed devices and manages the communication between the CPU and peripheral devices. Accordingly, the CMOS non-volatile memory can interact with the CPU and BIOS through the interface provided by the PCH, ensuring the transfer of flag states between various components.

[0083] Because CMOS non-volatile memory is powered by the motherboard battery, capacitors, or standby power supply, its stored contents remain stable even when the computing device is completely powered off. This ensures the consistency and reliability of the restart trigger flag across boot cycles and prevents it from being lost due to a cold restart of the computing device, thus ensuring that the BIOS can correctly read the restart flag information within the current boot cycle.

[0084] S320: If the restart trigger flag is already triggered, the computing device does not meet the restart conditions.

[0085] In step S320, if the BIOS determines that the restart trigger flag has been triggered, the computing device does not meet the restart conditions. Accordingly, when the computing device does not meet the restart conditions, the CPU executes the corresponding instruction in the BIOS to suspend the startup process of the computing device, thereby suspending the CPU initialization operation and writing an abnormal suspension event to the system log. At the same time, it reports the abnormal alarm information to the BMC through the corresponding communication interface, reminding the operation and maintenance personnel to intervene and troubleshoot the fault in a timely manner.

[0086] At this point, the BIOS will retain all hardware status information from the current self-test process and send it to the BMC. It will not actively perform a second restart, avoiding repeated restarts for the same fault that would prolong boot time, and will also preserve the fault context for subsequent debugging and analysis. After completing the suspend operation, the BIOS will enter a low-power standby state, waiting for maintenance personnel to perform on-site debugging or manual reset via the BMC remote management interface.

[0087] In this embodiment of the application, when the computing device does not meet the restart conditions, the CPU can first use the BIOS to organize and encapsulate key exception context information such as CPU exception type, CPU register state, instruction address when the exception occurred, stack pointer, timestamp, and current firmware stage into a standard format exception log, and then send it to the BMC for independent storage through the interface.

[0088] Because the BMC has its own storage medium and power supply module that are independent of the main system, even if the computing device is subsequently suspended or powered off, the abnormal logs can be stably retained, and the data will not be lost due to the abnormality of the main system. This makes it convenient for maintenance personnel to export the abnormal logs from the BMC for fault analysis at any time.

[0089] After receiving the exception context information from the BIOS, the BMC directly writes it to its own non-volatile storage unit for storage. It does not rely on the participation of the computing device's CPU or memory. Even if the main system fails to boot later, the BMC can still maintain the storage state of the exception log, preserving the complete original scene for subsequent root cause analysis of the fault, further improving the storage reliability of the exception context information, and avoiding the loss of the exception scene due to the restart of the computing device.

[0090] In this way, the abnormal scene information generated by the computing device can be completely and reliably preserved during the cold restart process. It will not lose data due to abnormal power outage or suspension of the main system, and can also provide a complete and accurate basis for subsequent root cause analysis of the fault, solving the problem that occasional CPU abnormalities are difficult to reproduce and troubleshoot due to the lack of a complete scene.

[0091] S330: If the restart trigger flag is not triggered, then the computing device meets the restart conditions.

[0092] In step S330, if the BIOS determines that the restart trigger flag is not triggered, the computing device meets the restart conditions. Accordingly, the computing device can execute a cold restart process to recover from the CPU abnormality. In this embodiment, a cold restart refers to a restart method that resets the CPU and other hardware powered by the main power supply by cutting off the main power and then powering it back on. Unlike a hot restart without cutting off the power, a cold restart can clear the abnormal state latches, register error flags, and transient interference residues inside the CPU, minimizing the impact of occasional abnormalities.

[0093] Before performing a cold restart, the CPU can use the BIOS to modify the restart trigger flag to the triggered state and save it to the CMOS non-volatile memory. This ensures that after the cold restart is completed and the POST stage is re-entered, the BIOS can recognize that an abnormal restart has been performed once in this boot cycle, thus avoiding unlimited repeated triggering of cold restarts in the same boot cycle, which would cause the computing device to fall into a dead loop of repeated restarts.

[0094] After updating the restart trigger flag, the CPU can control the computing device's power management chip via the BMC to cut off the main power output, wait for a preset reset delay time, and then re-output the main power to allow the computing device to fully power on and start up. At this time, the CPU will be reset and will re-execute the initialization and self-test process. If the CPU abnormality was caused by an intermittent factor, the abnormal state will be cleared after the reset, and the boot process will be completed normally to enter the operating system. After successfully entering the Runtime stage, the BIOS can clear the restart trigger flag, end the current boot cycle, and prepare for the next boot.

[0095] Through steps S310 to S330, the computing device can accurately determine the number of restarts within the current startup cycle based on the status of the restart trigger flag. If no restart has been triggered, a cold restart is performed to attempt to recover from occasional anomalies. If a restart has already been triggered, retrying is stopped directly, the anomaly context is preserved, and an alarm is reported. This not only improves the success rate of recovering from occasional anomalies through a limited number of retries, but also avoids equipment wear and startup timeouts caused by unlimited repeated restarts, ensuring the reliable operation of the anomaly handling process.

[0096] Figure 3 This is a schematic diagram illustrating a firmware stage identification process provided in an embodiment of this application. The following is based on... Figure 3 The content shown is used to illustrate the process of the computing device identification firmware stage in the embodiments of this application.

[0097] like Figure 3 As shown, the process of the computing device identifying firmware stage in this embodiment may include the following steps S111 to S113.

[0098] S111: Get the POST completion flag.

[0099] In step S111, the CPU can obtain the POST completion flag using the BIOS to determine the current firmware stage of the computing device based on the flag's status. In this embodiment, the POST completion flag indicates whether the POST process of the computing device has been completed. It can be stored in CMOS non-volatile memory to avoid data loss due to power failure and to provide a complete context for subsequent fault analysis.

[0100] By obtaining the POST completion flag, the BIOS can accurately determine the firmware stage of the computing device, improving the BIOS's recognition accuracy of firmware stages and thus providing a reliable basis for subsequent differentiated anomaly handling strategies.

[0101] In one example, the POST completion flag can also be either 0 or 1. A value of 0 indicates that the POST phase is not complete, while a value of 1 indicates that the POST phase is complete.

[0102] The process by which the CPU obtains the POST completion flag using the BIOS can be accomplished by sending corresponding read / write instructions to the CMOS non-volatile memory. For example, a read instruction can read the corresponding register value, and then the current firmware stage and PSOT stage completion status can be resolved according to the preset mapping relationship.

[0103] It should be understood that the above-mentioned identifier values ​​are only examples. In actual applications, they can be flexibly defined according to hardware specifications. For example, they can also be Boolean (true, false) or enumerated (Initializing, Booting, Running), etc. The specific value form of the POST completion identifier is not limited in the embodiments of this application.

[0104] S112: When the POST completion flag is incomplete, the computing device is determined to be in the POST stage.

[0105] In step S112, the BIOS can determine whether the computing device is currently in the POST phase or the Runtime phase by reading the current status of the POST completion flag. In one example, if the POST completion flag is incomplete, it is determined that the computing device is still in the POST phase.

[0106] S113: When the POST completion flag is marked as complete, the computing device is determined to be in the Runtime phase.

[0107] In step S113, when the BIOS reads the POST completion flag as completed, it can determine that the computing device has successfully completed the POST process and entered the Runtime stage. After completing the above stage determination, the BIOS can use the determination result as the basis for subsequent differentiated anomaly recovery process determination, jump to the corresponding processing step to perform the operation, thereby realizing phased adaptation anomaly recovery processing.

[0108] Through steps S111 to S113, the BIOS establishes a dynamic and traceable state awareness capability during the boot cycle, improving its ability to identify firmware stages of the computing device. This avoids recovery strategy mismatches due to stage identification errors, thereby increasing the success rate of abnormal recovery. Simultaneously, the two identifiers are stored in non-volatile memory, ensuring that the identifier state is stably retained even after a cold restart following an abnormal trigger. This guarantees that the BIOS can still correctly identify firmware stages after the computing device restarts, without losing the stage determination criteria.

[0109] Figure 4 This is a schematic diagram illustrating a process for updating an identifier, provided in an embodiment of this application. The following is based on... Figure 4 The content shown is used to illustrate the process of updating the PSOT completion identifier of the computing device in the embodiments of this application.

[0110] like Figure 4 As shown, the process of updating the PSOT completion identifier by the computing device in this embodiment may include the following steps S121 to S123.

[0111] S121: Detect the startup status of the BootService corresponding to the computing device.

[0112] In step S121, the CPU can use the BIOS to periodically or at critical nodes check the running status of the computing device boot service BootService, using this as the trigger for updating the identifier. BootService is a module in the BIOS that provides basic services for operating system booting; its on / off status directly corresponds to the execution progress of the POST process.

[0113] It should be understood that BootService is a combination of interfaces used to implement functions such as managing system resources, loading drivers, and starting the operating system. Its lifecycle is strictly bound to the POST phase: it is activated when the POST phase starts, maintains service provision during the POST phase, and terminates when the POST phase is completed based on the operating system calling the shutdown function.

[0114] Therefore, when the BIOS detects that the BootService is enabled, it means that the computing device is in the POST process. When the BIOS detects that the BootService is disabled, it means that the POST process has ended and the computing device has entered the Runtime stage.

[0115] S122: When BootService is started, set the POST completion flag to incomplete.

[0116] In step S122, the BIOS can update the PSOT completion flag in the CMOS non-volatile register in real time according to the status changes of BootService. In this embodiment, when the BIOS detects that BootService is enabled, it can immediately set the POST completion flag to an incomplete value to ensure that the flag status is synchronized with the current boot progress in real time, so that the BIOS can read the latest stage status when the CPU is abnormally triggered in subsequent processes.

[0117] In one example, the BIOS can set the two flags to their corresponding values ​​using write commands. For instance, setting the PSOT completion flag to 0 indicates that the process is not complete.

[0118] S123: When BootService is shut down, set the POST completion flag to complete.

[0119] In step S123, when it is detected that the BootService has been shut down normally, it means that the POST process has been completed and the computing device is about to enter or has already entered the Runtime stage. At this time, the BIOS modifies the value of the POST completion flag, updates the POST completion flag to the value of completion, and updates the flag status to provide an accurate initial state for the next abnormal stage judgment.

[0120] For example, the BIOS can use write commands to set the POST completion flag to 1 to indicate that the process is complete. This allows the BIOS to accurately determine the current stage when the CPU is subsequently triggered by an exception by reading the flag in the CMOS non-volatile register, thus avoiding unnecessary restarts caused by misjudgments that could affect the computing device's business data.

[0121] By triggering dynamic updates of two flags through changes in the BootService state, the flag states can be made to closely match the actual boot progress of the computing device. This does not require additional complex state detection logic and can be achieved by relying on the native BIOS boot process. It does not add any additional hardware or software overhead, and is compatible with the boot specifications of most computing devices, resulting in better compatibility.

[0122] It should be understood that the computing device can also directly obtain its own startup state through the above step S121, that is, use the startup state of BootService read by BIOS, determine it to be in the POST stage when BootService is on, and determine it to be in the Runtime stage when BootService is off, thereby achieving lightweight and high-precision identification of firmware stage.

[0123] Figure 5 This is a schematic diagram illustrating a process for restarting a computing device, provided as an embodiment of this application. The following is based on... Figure 5 The content shown is used to illustrate the process of cold restarting a computing device in the embodiments of this application.

[0124] like Figure 5 As shown, the cold restart process of the computing device in this embodiment may include the following steps S510 to S530.

[0125] S510: Set the restart trigger flag to triggered.

[0126] In step S510, before performing a cold restart, the computing device can first set the restart trigger flag in the CMOS non-volatile memory to triggered via the BIOS. This flag is used to mark that a cold restart has been triggered once for this abnormal startup, so as to avoid repeated restarts due to the same abnormality. This flag will also be retained after the device cold restarts, ensuring that the CPU can read the correct restart count record using the BIOS after the computing device cold restarts.

[0127] S520: Restart the computing device.

[0128] In step S520, the CPU can execute the cold reboot command provided by the BIOS, disconnect the main system power supply and then power on again to complete the complete cold reboot process of the computing device. Compared with a warm reboot, a cold reboot can thoroughly clear abnormal residual data in the CPU's internal registers and cache, allowing the hardware state to return to its initial value, and is more likely to clear occasional hardware anomalies, thus improving the success rate of anomaly recovery.

[0129] S530: In response to the computing device switching from the firmware stage to the runtime stage, the reboot trigger flag is set to not triggered.

[0130] In step S530, after the cold restart is successfully completed and the computing device successfully enters the Runtime stage and starts the service, the CPU can use the BIOS to reset the restart trigger flag in the CMOS to not triggered, so as to reset the restart count for the next possible abnormal recovery. This ensures that when a new abnormality occurs in the future, the single cold restart process can still be executed normally without affecting the subsequent abnormal recovery logic.

[0131] By designing the above-mentioned single cold restart process, occasional anomalies are cleared by cold restart, and the number of restarts is strictly limited to only one, so as not to cause the problem of repeated restarts leading to an indefinite extension of the startup time. This balances the success rate of anomaly recovery and startup efficiency, and solves the problem of repeated restarts in traditional solutions that fail to start and cause the device to be unusable for a long time.

[0132] Figure 6 This is a schematic diagram illustrating a process for pausing CPU startup, provided as an embodiment of this application. The following is based on... Figure 6 The content shown is used to illustrate the process of pausing CPU startup in a computing device in the embodiments of this application.

[0133] like Figure 6 As shown, the process of pausing CPU startup in the computing device in this embodiment may include the following steps S410 to S420.

[0134] S410: Puts the CPU into a suspended state.

[0135] In step S410, if it is determined that the current firmware stage of the computing device is the POST stage, but the restart trigger flag is already triggered, the CPU can suspend the CPU boot process through the firmware program provided by the BIOS, causing the CPU to enter a suspended state. In this embodiment, the suspended state is used to block the execution of instructions in the CPU. At this time, the subsequent boot process will not continue to be executed, and a restart will not be actively triggered. This facilitates maintenance personnel to connect to the device through the out-of-band interface, read the abnormal context information stored in the BMC for fault diagnosis, and avoid directly and repeatedly restarting to prolong the boot time and cover up the real cause of the fault.

[0136] S420: Records the exception log corresponding to the hangup state through BMC.

[0137] In step S420, after setting the CPU to a suspended state, the BIOS can actively send the triggering reason for the current CPU suspension and the CPU exception context information to the BMC, and the BMC will supplement the information into the stored exception log to complete the complete recording of the exception scene.

[0138] At this time, the BMC can still respond to out-of-band management access requests normally. Maintenance personnel can log in to the BMC at any time through the remote out-of-band interface, export complete abnormal logs for fault analysis, and can also directly perform remote debugging operations on the device without on-site disassembly and troubleshooting, which greatly improves the efficiency of fault troubleshooting.

[0139] In some embodiments, the BIOS will send a CPU anomaly alarm to the remote operation and maintenance management terminal through the BMC, informing the operation and maintenance personnel that the current device has been suspended due to repeated CPU anomaly triggers during the POST phase, reminding the operation and maintenance personnel to intervene in time and avoid the device being in an abnormal state for a long time without anyone noticing.

[0140] Through the above-described hang-up handling process, if a single cold restart fails to resolve the anomaly, the startup process can be promptly blocked, avoiding prolonged device unavailability caused by repeated restarts of the computing device. It also preserves the anomaly scene for maintenance and troubleshooting, thus balancing the reliability and maintainability of anomaly handling.

[0141] Figure 7 This is a schematic diagram illustrating another firmware stage identification process provided in an embodiment of this application. The following is based on... Figure 7 The content shown is used to illustrate the process of the computing device identification firmware stage in the embodiments of this application.

[0142] like Figure 7 As shown, the process of the computing device identifying firmware stage in this embodiment may include the following steps S131 to S133.

[0143] S131: Detect the exception type of CPU exception events.

[0144] In step S131, during the firmware identification phase using the BIOS, the computing device can first perform preliminary detection and recovery processing on CPU anomalies generated by the CPU, distinguish the impact of different anomaly types on the system startup process, filter out non-fatal anomalies that do not affect the continued startup of the device, and trigger the anomaly recovery process only for serious anomalies that will cause the startup process to be interrupted, so as to avoid unnecessary startup interruption.

[0145] In one example, the BIOS can receive CPU exception callback processing signals to obtain exception information sent by the CPU, determine the corresponding exception type, and map the CPU exception event into two categories, "recoverable" or "unrecoverable", according to a preset exception classification strategy.

[0146] For a "recoverable" exception, the computing device can execute the subsequent step S132 to attempt exception recovery and continue the startup process; for a "non-recoverable" exception, the computing device can execute the subsequent step S133 to identify the current firmware stage and then execute steps S200 to S300 to handle the exception.

[0147] It should be noted that the BIOS can determine whether a preset repair policy for this type of anomaly exists in the computing device. If it does, the corresponding repair process will be started; if it does not exist, it will be directly determined as an "unrecoverable" anomaly and the firmware stage identification mechanism will be triggered immediately to ensure that the anomaly handling policy is accurately matched with the current firmware stage, thereby avoiding secondary failures caused by policy mismatch.

[0148] S132: Perform recovery processing on CPU exception events based on exception type.

[0149] In step S132, for recoverable exceptions, the CPU will call the default exception recovery handling logic in the BIOS to try to clear the exception state inside the CPU, reset the processing unit that caused the exception, reload the configuration parameters corresponding to the exception, and after the exception handling is completed, directly continue to execute the subsequent POST boot process without triggering a cold restart or hangup operation. This can effectively handle mild and occasional exceptions while ensuring the smooth progress of the boot process, reduce unnecessary boot interruptions, and improve the boot success rate of computing devices.

[0150] For example, for overflow exceptions, the BIOS can clear the relevant register states and skip the instruction that caused the exception, allowing the CPU to proceed to the next instruction execution flow; for invalid opcode exceptions, the BIOS can dynamically replace it with a default security instruction or trigger a microcode patch loading mechanism, or convert the instruction into equivalent code for execution and continue the corresponding process; for page fault exceptions, the BIOS can determine whether the address recorded in the register is located in a legal memory area managed by the firmware. If it is within the legal range, it can dynamically map the corresponding page table entry and retry the instruction; for general protection exceptions, the BIOS can check the matching degree between the current permission level and the permission required for the target operation. If the permission is insufficient, it can temporarily elevate the execution permission or roll back the instruction.

[0151] It should be understood that the above-mentioned abnormal recovery mechanism is only an example. In actual deployment, the recovery logic needs to be dynamically adjusted according to the specific CPU architecture, firmware version and security policy. This application embodiment does not limit the specific CPU abnormal recovery processing method.

[0152] In this embodiment of the application, after the recovery process of the CPU abnormal event fails, the CPU can mark the failed CPU abnormal event as an "unrecoverable" exception through the BIOS and proceed to step S133 to perform firmware stage identification.

[0153] S133: If CPU exception event recovery fails, identify the current firmware stage of the computing device.

[0154] In step S133, after recovering from a CPU anomaly and confirming recovery failure, the CPU can identify the current firmware stage of the computing device through the BIOS, and then execute subsequent anomaly handling procedures for unrecoverable anomalies. By first classifying and categorizing anomalies and attempting mild recovery first, unnecessary cold restarts and hangs can be effectively reduced, further improving the overall boot success rate of the device and preventing easily repairable minor anomalies from escalating into major faults requiring manual intervention.

[0155] In this embodiment, when it is identified that the current firmware stage of the computing device is the Runtime stage, and the currently triggered CPU exception is an unrecoverable exception or an exception recovery failure, the BIOS can send a stop command to the CPU to suspend the operation of the service, and at the same time send the complete exception context information to the BMC storage for subsequent fault analysis and remote diagnosis.

[0156] When the firmware is in the POST stage, if the currently triggered CPU exception is an unrecoverable exception or the exception recovery fails, the BIOS can determine the handling method for the computing device based on the reboot trigger flag.

[0157] Through steps S131 to S133, the computing device can perform tiered processing of CPU abnormal events. It first makes a light attempt to repair recoverable abnormalities, and only triggers the subsequent abnormal recovery process for serious abnormalities that cannot be repaired. This minimizes unnecessary startup interruptions and manual intervention, and further balances the device startup success rate and abnormal handling efficiency.

[0158] Figure 8 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0159] Corresponding to the aforementioned embodiments of the device startup anomaly recovery method, this application also provides an embodiment of a computing device. For example... Figure 8 As shown, the computing device 800 includes a processor 801, a memory 802, a BIOS 806, and a BMC 807. Exemplarily, the computing device 800 may also include a communications interface 803 and a communications bus 804.

[0160] The processor 801, memory 802, and communication interface 803 communicate with each other via communication bus 804. The communication interface 803 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0161] In this embodiment, the communication interface 803 can be used to enable communication between the computing device 800 and the terminal device operated by the user, so that the computing device 800 can receive user input operations, provide a visual interface for the terminal device and execute operations to generate corresponding operation results, thereby configuring the interface of the management system deployed in the computing device 800.

[0162] In some embodiments, the BIOS 806 may be a separate chip storing a program 805. The processor 801 executes the program 805, specifically performing the relevant steps in the device startup anomaly recovery method embodiments described above. Specifically, the program 805 may include program code comprising computer-executable instructions. The program 805 may be invoked by the processor 801 to cause the computing device 800 to execute the device startup anomaly recovery method described above.

[0163] For example, processor 801 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 800 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0164] In this embodiment, BIOS806 and BMC807 are connected to processor 801 and memory 802 via communication bus 804. BMC807 operates independently of processor 801, can be powered independently, and is responsible for storing exception logs and responding to out-of-band management access requests. It can provide management capabilities even if processor 801 is in a suspended state.

[0165] In this embodiment, the processor 801, BIOS 806, and BMC 807 interact with each other through the communication bus 804 inside the computing device 800 to collaboratively complete a full-process anomaly recovery method from anomaly detection, hierarchical processing to on-site retention.

[0166] The memory 802 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. The CMOS non-volatile memory may be integrated separately into the BIOS module to store the aforementioned restart trigger flag, ensuring that the state is not lost after power failure.

[0167] Some embodiments of this application provide a BIOS chip that stores at least one computer-executable instruction. When the computer-executable instruction is executed on a computing device 800, it causes the computing device 800 to perform the device startup anomaly recovery method described in the above embodiments.

[0168] The beneficial effects that the computer-readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding device startup anomaly recovery method provided above, and will not be repeated here.

[0169] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method for recovering from a device startup anomaly, characterized in that, The method, applied to a central processing unit (CPU) in a computing device, includes: In response to the detection of a CPU abnormal event, the current firmware stage of the computing device is identified; the firmware stage includes the Power-On Self-Test (POST) stage and the Runtime stage. When the computing device is in the Runtime phase, the exception context information corresponding to the CPU exception event is sent to the Baseboard Control Manager (BMC) in the computing device. If the computing device meets the restart conditions while it is in the POST phase, then the computing device is cold-restarted.

2. The method according to claim 1, characterized in that, If the computing device meets the restart conditions, then cold restarting the computing device includes: Obtain a restart trigger flag; the restart trigger flag is used to indicate whether the computing device has triggered an abnormal restart during the startup cycle; If the restart trigger flag is already triggered, then the computing device does not meet the restart conditions; If the restart trigger flag is not triggered, then the computing device meets the restart conditions; The method further includes: If the computing device does not meet the restart conditions, the startup process of the computing device is paused.

3. The method according to claim 2, characterized in that, The cold restart of the computing device includes: Set the restart trigger flag to triggered; Restart the computing device; In response to the switching of the computing device's firmware phase to the Runtime phase, the reboot trigger flag is set to not triggered.

4. The method according to any one of claims 1 to 3, characterized in that, The process of identifying the current firmware stage of the computing device includes: Obtain the POST completion flag; the POST completion flag is used to indicate whether the POST process of the computing device has been completed. When the POST completion flag is incomplete, the computing device is determined to be in the POST stage; When the POST completion flag is marked as complete, the computing device is determined to be in the Runtime phase.

5. The method according to claim 4, characterized in that, The step of identifying the current firmware stage of the computing device further includes: Detect the startup status of the BootService corresponding to the computing device; When BootService starts, the POST completion flag is set to incomplete; When BootService shuts down, the POST completion flag is set to complete.

6. The method according to claim 1, characterized in that, The exception context information includes at least one of the following: CPU exception type, CPU register state, instruction address at the time of the exception, stack pointer, timestamp, and firmware stage of the computing device.

7. The method according to claim 2, characterized in that, The process of pausing the startup of the computing device includes: The CPU is put into a suspended state; the suspended state is used to block instruction execution in the CPU. The BMC records the exception logs corresponding to the suspended state.

8. The method according to any one of claims 1 to 7, characterized in that, The step of identifying the current firmware stage of the computing device further includes: Detect the exception type of the CPU exception event; Based on the aforementioned exception type, the CPU exception event is processed for recovery. If the CPU exception event recovery fails, the current firmware stage of the computing device is identified.

9. The method according to any one of claims 1 to 8, characterized in that, The CPU exception events include at least one of overflow exception, invalid opcode exception, page fault, and general protection exception.

10. A computing device, characterized in that, include: Processor and BIOS chip; The processor and the BIOS chip are coupled; the BIOS chip is used to store program instructions. The processor is used to execute the program instructions to perform the device startup anomaly recovery method as described in any one of claims 1 to 9.

Images