Methods and electronic devices for verifying autonomous debugging data collection functions

Abstract

This invention discloses a method and electronic device for verifying autonomous debugging data collection functionality, relating to the field of computer technology. The method includes: acquiring logic signals from a target logic device and secondary readback data from a target controller, under preset verification conditions for autonomous debugging data collection functionality; verifying the target logic device based on the logic signals and the target controller based on the secondary readback data; if both verifications are successful, injecting a preset fault instruction into the target processor, causing the fault instruction to be transmitted to the input / output hub via the processor's internal bus; and collecting status data generated in response to the preset fault instruction through the collaborative acquisition of status data by the target logic device and the target controller, and generating a verification result. This solves the problem of insufficient initiative and controllability in testing caused by the difficulty in actively simulating chip link damage scenarios in related technologies. This application can actively trigger chip damage scenarios, reproduce faults, and improve testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and electronic device for verifying autonomous debugging data collection functions. Background Technology

[0002] With the rapid development of computer technology, servers have gradually become high-performance computers in network platforms. Their wide application and continuous technological progress have led to constant demands for server performance upgrades.

[0003] In server operation, the IOHUB (Input / Output Hub) chip integrates a coherence cache control logic unit, a DDR (Double Data Rate) controller, and an interconnect bus, forming a highly efficient data management system. Furthermore, the chip is equipped with a CXL (Compute Express Link Device) controller, which, along with other components, implements the functions of the CXL controller chip. The proper functioning of this chip directly impacts the integrity of server data transmission.

[0004] The IOHUB functional test has problems such as low coverage, weak fault reproduction capability and incomplete debugging data. In response, the relevant technologies propose the following test methods: (1) Find the faulty CPU in the CPU, install the faulty CPU into the machine, and check whether the web reports the CPU IOHUB chip problem; (2) Destroy the key parts of the CPU IOHUB chip, install this CPU into the machine, and check whether the web reports the CPU IOHUB problem.

[0005] However, the relevant technologies have the following problems: (1) The probability of finding a faulty CPU in the CPU is very low, and the CPU types are different for different servers and platforms. Therefore, the feasibility is poor and it is not universal; (2) Destroying the CPU IOHUB chip before testing increases the testing cost. Furthermore, the BIOS (Basic Input Output System) is constantly being upgraded and iterated in the CRB (Configuration Register Bank). The method of damaging the CPU is unsustainable. Moreover, a faulty CPU IOHUB chip will cause the server to fail to boot normally, which will prevent the BIOS from updating the code and ultimately make it impossible to create a scenario where the CPU IOHUB chip is damaged.

[0006] In summary, the relevant technologies are unable to proactively simulate scenarios where chip links are damaged, resulting in insufficient initiative and controllability in testing. Furthermore, when chip link damage causes server downtime, it is difficult to quickly locate the root cause of the downtime. Relying on manual operation for data debugging is inefficient and cannot fully cover all fault scenarios. Summary of the Invention

[0007] This invention provides a method and electronic device for verifying autonomous debugging data collection functions, which at least solves the problem that related technologies are difficult to actively simulate chip link damage scenarios, resulting in insufficient initiative and controllability of testing. This application can actively trigger chip damage scenarios, and by combining hardware-level error injection and full-link data capture technologies, a closed-loop testing system is constructed, which significantly improves the initiative and controllability of testing and enhances the ability to reproduce faults.

[0008] This invention provides a method for verifying the autonomous debugging data collection function, comprising the following steps:

[0009] Determine whether the preset verification conditions for the autonomous debugging data collection function are met;

[0010] Under the condition that the preset autonomous debugging data collection function verification conditions are met, the logic signals of the target logic device and the secondary readback data of the target controller are obtained, and the target logic device is verified according to the logic signals, and the target controller is verified according to the secondary readback data.

[0011] If both the target logic device and the target controller pass the verification, a preset fault instruction is injected into the target processor. The fault instruction is then transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller collaboratively collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on the status data.

[0012] The present invention also provides a device for verifying the autonomous debugging data collection function, comprising:

[0013] The judgment module is used to determine whether the preset verification conditions for the autonomous debugging data collection function are met.

[0014] The acquisition module is used to acquire the logic signals of the target logic device and the secondary readback data of the target controller when the preset autonomous debugging data collection function verification conditions are met, and to verify the target logic device based on the logic signals and the target controller based on the secondary readback data.

[0015] The verification module is used to inject a preset fault instruction into the target processor when both the target logic device and the target controller are verified as qualified. The fault instruction is then transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller work together to collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on the status data.

[0016] The present invention also provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for verifying autonomous debugging data collection function as described in the above embodiments.

[0017] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described methods for verifying autonomous debugging data collection functions.

[0018] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of any of the above-described methods for verifying autonomous debugging data collection functions.

[0019] This invention determines whether preset verification conditions for autonomous debugging data collection are met. If these conditions are met, it acquires the logic signals of the target logic device and the secondary readback data of the target controller. The target logic device is verified based on the logic signals, and the target controller is verified based on the secondary readback data. If both the target logic device and the target controller pass verification, a preset fault instruction is injected into the target processor. This fault instruction is transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller collaboratively collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on this status data. This solves the problem of insufficient initiative and controllability in testing caused by the difficulty of actively simulating chip link damage scenarios in related technologies. This invention can actively trigger chip damage scenarios, combining hardware-level error injection and full-link data capture technology to construct a closed-loop testing system, significantly improving the initiative and controllability of testing and enhancing fault reproduction capabilities. Attached Figure Description

[0020] 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.

[0021] Figure 1 A flowchart illustrating a method for verifying the autonomous debugging data collection function provided in an embodiment of the present invention;

[0022] Figure 2 A schematic diagram illustrating the principle of the method for verifying the autonomous debugging data collection function provided in an embodiment of the present invention;

[0023] Figure 3 A block diagram illustrating the device for verifying the autonomous debugging data collection function provided in an embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention. Detailed Implementation

[0025] 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, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0026] It should be noted that, in the description of this invention, 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. The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0027] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0028] The embodiments of the present invention provide a method for verifying the autonomous debugging data collection function. The method is described in detail below in conjunction with the execution flow of the method for verifying the autonomous debugging data collection function.

[0029] Specifically, Figure 1 This is a flowchart illustrating a method for verifying the autonomous debugging data collection function provided in an embodiment of the present invention.

[0030] like Figure 1 As shown, the method for verifying the autonomous debugging data collection function includes the following steps:

[0031] In step S101, it is determined whether the preset verification conditions for the autonomous debugging data collection function are met.

[0032] Among them, autonomous debugging refers to the target processor being able to automatically detect its own status and adjust itself according to preset rules or algorithms to achieve the best operating state; data collection function refers to the system or device being able to collect data related to its own operating status.

[0033] It is understood that the embodiments of the present invention require whether the target processor has met the preset verification conditions for the autonomous debugging data collection function. If the preset verification conditions for the autonomous debugging data collection function are met, the verification can begin; if the conditions are not met, the target processor needs to be adjusted until the conditions are met.

[0034] According to one embodiment of the present invention, determining whether a preset autonomous debugging data collection function verification condition is met includes: obtaining the current encryption state and the current protection function state of the target processor; and determining whether the preset autonomous debugging data collection function verification condition is met based on the current encryption state and the current protection function state.

[0035] Among them, the current encryption state refers to the state of the encryption technology or encryption measures adopted by the target processor at the current moment; the current protection function state refers to the state of the security protection functions adopted by the target processor at the current moment.

[0036] Understandably, when the processor is in Secure state, it is not possible to directly verify the error mechanism function of external devices. It is necessary to unlock the processor using AMD's (Advanced Micro Devices) Hardware Debug Tool. Only when the processor is in NO Secure state can the PCIE NBIO (PCI Express NorthBridge IO, the Northbridge input / output function related to PCI Express) information obtained through the command-line tool amdcmd be used to verify the error mechanism function of specific device models individually.

[0037] Specifically, in this embodiment of the invention, the security encryption status of the CPU can be viewed through the Hard Debug Tool, a virtual hardware debugging tool on the AMD platform, while the protection function status can be viewed through the SCE (Software Configuration Editor) to see if the SyncFlood function is enabled or disabled. This status information is an important basis for determining whether the target processor meets the preset verification conditions for autonomous debugging data collection function.

[0038] Therefore, the embodiments of the present invention can accurately determine the security encryption status and protection function status of the CPU, thereby providing a reliable basis for the verification of the autonomous debugging data collection function. By judging the preset conditions, it is ensured that the verification of the autonomous debugging data collection function is only carried out when the conditions are met, avoiding verification failure or data errors due to unmet conditions, thereby optimizing the entire verification process.

[0039] According to one embodiment of the present invention, determining whether the preset verification conditions for autonomous debugging data collection function are met based on the current encryption state and the current protection function state includes: determining whether the current encryption state is an insecure encryption state and whether the current protection function state is a closed state; if the current encryption state is an insecure encryption state and the current protection function state is a closed state, then it is determined that the preset verification conditions for autonomous debugging data collection function are met.

[0040] In actual implementation, the embodiments of the present invention can use the virtual Hard Debug Tool of the AMD platform to view the security encryption status of the CPU. If the CPU is in a secure encryption state, the unlock value will be 0; when the CPU is in a non-secure encryption state, the unlock value will not be 0. This situation satisfies one of the preset verification conditions for the autonomous debugging data collection function.

[0041] In this embodiment of the invention, the SCE tool can be used to check the on or off status of the SyncFlood function, and the recorded data is marked as T1. If the value of T1 is 1, it indicates that the SyncFlood function is on; if the value of T1 is 0, it indicates that the SyncFlood function is off. This is also one of the preset verification conditions for the autonomous debugging data collection function.

[0042] Based on the obtained status information, determine whether the preset verification conditions for the autonomous debugging data collection function are met. The specific conditions are: the current encryption state is a non-secure encryption state (i.e., the unlock value is not 0); the current protection function state is a closed state (i.e., the T1 value is 0). If both of the above conditions are met, it is determined that the preset verification conditions for the autonomous debugging data collection function are met.

[0043] Therefore, by making explicit condition judgments, the embodiments of the present invention can avoid verification under inappropriate conditions, save time and resources, and optimize the entire verification process.

[0044] In step S102, under the condition of meeting the preset verification conditions for autonomous debugging data collection function, the logic signals of the target logic device and the secondary readback data of the target controller are acquired, and the target logic device is verified according to the logic signals, and the target controller is verified according to the secondary readback data.

[0045] Among them, the target logic device can refer to a specific logic device that needs to be tested or verified; the logic signal refers to the electrical signal generated by the logic device during operation, which represents the internal state or output result of the logic device; the target controller refers to a specific controller that needs to be tested or verified; and the second data read from the target controller is used to verify whether the controller functions normally.

[0046] Understandably, when the preset verification conditions for the autonomous debugging data collection function are met, the IOHUB method can be used to create a scenario for verifying the autonomous debugging data collection function. This process has a clear logic and operation path. The IOHUB method can ensure that the verification scenario for this function is constructed under the given conditions.

[0047] Preferably, in this embodiment of the invention, the target logic device is a CPLD (Complex Programmable Logic Device), the logic signals are positioning signals and measurement signals, and the target controller is a Baseboard Management Controller.

[0048] Specifically, in combination Figure 2 As shown, in this embodiment of the invention, the logic signals generated by the target logic device during operation are captured through a specific test device or interface to reflect the operating status of the device. Secondary data is read from the target controller. Based on the acquired logic signals, the function of the target logic device is checked to see if it is normal. Based on the acquired secondary readback data, the function of the target controller is checked to see if it is normal.

[0049] Therefore, by verifying the functionality of the target logic devices and the target controller, potential hardware problems can be identified in a timely manner, and measures can be taken in advance to enhance the overall reliability of the system.

[0050] According to one embodiment of the present invention, acquiring the logic signal of the target logic device and the secondary readback data of the target controller, and verifying the target logic device based on the logic signal and verifying the target controller based on the secondary readback data, includes: acquiring the positioning signal of the target logic device; if the signal value of the positioning signal reaches a first peak state, acquiring the measurement signal of the target logic device, and determining whether the signal value of the measurement signal reaches a second peak state; if the signal value of the measurement signal reaches the second peak state, determining that the target logic device is verified as qualified.

[0051] Among them, the positioning signal refers to a specific signal used to determine the state or position of the target logic device; the first top state refers to a specific state reached by the positioning signal, which is usually a preset high level or a specific value, indicating that the positioning signal has been correctly triggered; the measurement signal refers to a signal used to verify the function of the target logic device; the second top state refers to a specific state reached by the measurement signal, which is usually a preset high level or a specific value, indicating that the measurement signal has been correctly triggered.

[0052] Specifically, in this embodiment of the invention, a testing device or interface is used to capture the positioning signal of the target logic device, and the position and state of the device in the system are confirmed by the positioning signal. If the signal value of the positioning signal reaches the preset first peak state, it indicates that the target logic device is in the correct position or state, and the next step of verification can be continued. If the positioning signal is qualified, the measurement signal of the target logic device is further obtained. The measurement signal is used to verify whether the output data of the device meets the expectations. If the signal value of the measurement signal reaches the preset second peak state, it indicates that the output data of the target logic device meets the expectations and the function is normal. If both the positioning signal and the measurement signal reach the preset qualified state, the target logic device is determined to be qualified.

[0053] In actual execution, during CPLD logic design, signal 1 must first be located and its value recorded as S1. Then, it is checked whether the S1 value reaches the first set condition. If the set condition is not met, it indicates a CPLD logic problem. This problem will prevent the fault signal from being transmitted to the BMC, meaning the BMC does not support receiving this fault signal. Next, signal 2 is measured and its value recorded as S2. Similarly, it is checked whether the S2 value reaches the second set condition. If the S2 value does not meet the set condition, this also indicates a CPLD logic problem, leading to the fault signal not being transmitted to the BMC, and the BMC not supporting receiving this fault signal. In summary, this reflects a problem with the CPLD logic, preventing correct information from being transmitted to the BMC.

[0054] Therefore, by acquiring and judging the positioning signal and measurement signal step by step, the functional state of the target logic device can be accurately verified. The positioning signal ensures the correct configuration of the device in the system, and the measurement signal ensures that the output data of the device meets expectations.

[0055] According to an embodiment of the present invention, after determining that the signal value of the positioning signal has not reached the first peak state, or the signal value of the measurement signal has not reached the second peak state, the method further includes: determining that the target logic device verification has failed, and generating logic verification failure information based on the first verification failure result; and sending the logic verification failure information to a preset mobile terminal.

[0056] The first verification failure result refers to the specific result that the target logic device fails the verification because the signal value of the positioning signal does not reach the first peak state or the signal value of the measurement signal does not reach the second peak state during the verification process. The logic verification failure information refers to the prompt information generated based on the first verification failure result, which is used to notify relevant personnel of the specific circumstances of the target logic device verification failure, including the reason for the failure and related parameters. The preset mobile terminal refers to the mobile device, such as a mobile phone or tablet computer, that is set in advance to receive the verification failure information, and is used to promptly notify maintenance personnel or relevant responsible persons.

[0057] Specifically, if the signal value of the positioning signal does not reach the first peak state, or the signal value of the measurement signal does not reach the second peak state, the system will determine that the target logic device verification has failed. Based on the first verification failure result, the system will generate detailed logic verification failure information, which will include the specific reason for the verification failure, such as the difference between the current value of the positioning signal or measurement signal and the preset qualified value. The generated logic verification failure information will be sent to the preset mobile terminal so that maintenance personnel or relevant responsible persons can receive the notification in a timely manner, respond quickly and handle the problem.

[0058] Therefore, by generating and sending logic verification failure information, maintenance personnel can quickly understand the specific reasons for the failure of the target logic device verification, and take timely measures to repair or adjust it, thereby reducing system downtime.

[0059] According to one embodiment of the present invention, acquiring the logic signals of a target logic device and the secondary readback data of a target controller, verifying the target logic device based on the logic signals, and verifying the target controller based on the secondary readback data, includes: the target controller acquiring a first register value of its register using an advanced platform management link, and determining whether the first register value is a preset valid flag bit; if the first register value is a preset valid flag bit, acquiring a second register value of the target controller's register using an advanced platform management link, and determining whether the second register value is a preset valid flag bit; if the second register value is a preset valid flag bit, determining that the target controller has passed verification.

[0060] APML (Advanced Platform Management Link) is a communication link used for system management and hardware monitoring. It is typically used to connect system controllers (such as BMC) and other hardware components to achieve data transmission and status monitoring. Registers are storage units in hardware used to store data or status information. First register value: The value read from the target controller's register, used to initially determine the controller's status. Second register value: The value read from the target controller's register, used to further confirm the controller's status. Preset valid flag: A pre-set specific value used to determine whether the register value indicates that the controller is in a normal working state.

[0061] Specifically, the target controller (BMC) reads the first register value of its register through the advanced platform management link. If the first register value is equal to the preset valid flag, it indicates that the initial state of the target controller is normal and can continue to the next step of verification. If the first register value is qualified, the target controller reads the second register value of its register through the advanced platform management link. If the second register value is also equal to the preset valid flag, it indicates that the further state check of the target controller has also passed. If both the first register value and the second register value meet the preset valid flag, the target controller is deemed to have passed the verification.

[0062] In actual execution, after the CPLD logic design meets conditions S1 and S2, it is necessary to confirm the software interaction functionality. The specific steps are as follows: First, check the BMC APML module. During this process, check the MSR register and record its value as MSR1. Then, check if this value is 1. If this value does not meet the requirement, it indicates that the ID identifier in the BMC APML module is missing, thus indicating that the BMC function is not supported. Next, check the MSR register again and record its value as MSR2, similarly checking if this value is 1. If this value does not meet the requirement, it means that the identification identifier in the BMC APML module is missing, again indicating that the BMC function is not supported. In summary, we can conclude that the BMC APML function module is not supported.

[0063] Therefore, by acquiring and judging the register values ​​step by step, the state of the target controller can be accurately verified. The first register value is used for preliminary judgment, and the second register value is used for further confirmation to ensure the accuracy of the verification.

[0064] According to one embodiment of the present invention, after determining that the first registered value is not a preset valid flag bit or the second registered value is not a preset valid flag bit, the method further includes: determining that the target controller verification failed, and generating functional verification failure information based on the second verification failure result; and sending the functional verification failure information to a preset mobile terminal.

[0065] The second verification failure result refers to the specific result that the target controller fails the verification because the first register value or the second register value fails to reach the preset valid flag bit during the verification process. The functional verification failure information is a prompt message generated based on the second verification failure result, which is used to notify relevant personnel of the specific circumstances of the target controller verification failure, including the reason for the failure and related parameters.

[0066] Specifically, if the first register value fails to reach the preset valid flag, or if the second register value fails to reach the preset valid flag, the system will determine that the target controller verification has failed. Based on the second verification failure result, the system will generate functional verification failure information, which may include the specific reason for the verification failure, such as the difference between the current value of the register and the preset valid flag. The generated functional verification failure information will be sent to a preset mobile terminal so that maintenance personnel or relevant responsible persons can receive the notification in a timely manner, respond quickly and handle the problem.

[0067] Therefore, by generating and sending function verification failure information, maintenance personnel can quickly understand the specific reasons for the target controller verification failure, take timely measures to repair or adjust, and reduce system downtime.

[0068] In step S103, if both the target logic device and the target controller pass the verification, a preset fault instruction is injected into the target processor, which is then transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller collaboratively collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on the status data.

[0069] Among them, the preset fault instruction is a pre-designed instruction used to simulate fault conditions in the system in order to test the system's autonomous debugging data collection function; the processor internal bus refers to the channel inside the processor used for data transmission, responsible for passing instructions and data from the processor to other hardware components, such as input / output hubs; the input / output hub (I / O hub) is a hardware component responsible for managing and coordinating input / output operations between the processor and external devices. It receives instructions from the processor and generates corresponding responses; status data: data generated by the I / O hub in response to the preset fault instruction, which reflects the system's operating status under fault conditions.

[0070] Specifically, in combination Figure 2 As shown, a preset fault command is sent to the target processor to simulate a fault condition in the system. The fault command is transmitted to the input / output hub through the processor's internal bus. After receiving the fault command, the input / output hub generates corresponding status data. This data reflects the operating status of the system under fault conditions. The target logic device (such as CPLD) and the target controller (such as BMC) work together to collect the status data generated by the input / output hub. Based on the collected status data, the system's autonomous debugging data collection function is evaluated to determine whether it is working properly, thereby obtaining the verification results.

[0071] In actual execution, the process of injecting a preset fault instruction into the target processor can be carried out through the following steps: Execute AMD platform commands under the OS to output CPU IOHUB chip-related information (cocket, die, NBIO) and record X. Use the AMD platform debugging tool - AMD System Debugger NDA, and combine it with CScripts to input the X parameter into the simulated error injection command.

[0072] Therefore, by injecting preset fault commands and collecting status data, the system's autonomous debugging data collection function under fault conditions can be fully verified, ensuring that the system can correctly respond to faults and collect relevant data.

[0073] According to one embodiment of the present invention, after injecting a preset fault instruction into the target processor, the method further includes: checking whether the current operating system is in a crash state; if the current operating system is in a crash state, determining that the input / output hub has failed.

[0074] In this context, "downtime" refers to a state in which a computer system or operating system is unable to function properly due to a malfunction. In this state, the system cannot respond to user operations or other requests.

[0075] Specifically, after injecting the preset fault command, the system checks whether the current operating system is in a crash state. This can be achieved by detecting the system's responsiveness, process running status, or other system health indicators. If the current operating system is in a crash state, the system will further determine whether the input / output hub is faulty. This is because the input / output hub may encounter problems when processing the fault command, causing the system to malfunction. If the operating system crashes and the input / output hub fails to respond correctly to the preset fault command, the system will determine that the input / output hub is faulty.

[0076] Therefore, by checking the status of the operating system and determining whether the input / output hub is faulty, the specific cause of the system crash can be quickly located. This helps maintenance personnel to take quick measures to solve the problem and reduce system downtime.

[0077] According to one embodiment of the present invention, obtaining the verification result of the autonomous debugging data collection function based on status data includes: determining whether the status data is consistent with the data corresponding to the preset fault command; if the status data is consistent with the data corresponding to the preset fault command, it is determined that the autonomous debugging data collection function has passed verification.

[0078] Specifically, after injecting a preset fault instruction into the target processor, the target logic device (such as a CPLD) and the target controller (such as a BMC) collaboratively collect the status data generated by the input / output hub. The collected status data is compared with the expected data corresponding to the preset fault instruction. The expected data corresponding to the preset fault instruction is the standard data that the system should generate when responding to the fault instruction normally. If the status data is consistent with the expected data corresponding to the preset fault instruction, it indicates that the system can correctly generate and collect status data under fault conditions, and the autonomous debugging data collection function is verified as passed.

[0079] Therefore, by comparing the status data with the expected data corresponding to the preset fault commands, it is possible to accurately determine whether the autonomous debugging data collection function is working properly. If the data match, the function is normal; if they do not match, the function may have a defect.

[0080] The embodiments of the present invention may employ a testing system to implement the method for verifying the autonomous debugging data collection function of the present invention. The testing system may include: a customization module, a hardware module, an environment module, and a data transmission module.

[0081] Among them, the customized module: by exploiting known vulnerabilities in the CPU microarchitecture (such as cache coherence protocol defects and bus race conditions), it induces the IOHUB chip into an error state through carefully designed instruction sequences or memory access patterns.

[0082] Hardware Module: When the IOHUB chip in the server system fails, the BIOS (Basic Input / Output System) and BMC (Baseboard Management Controller) will use a sophisticated collaborative mechanism to assess, transmit, and respond to the fault.

[0083] Environment Module: When the mass-produced CPU is in Secure state, it is not possible to directly verify the error mechanism function of external devices. The CPU needs to be unlocked through the AMDHardwareDebugTool. When the CPU is in NOSecure state, the PCIENBIO information obtained through the command line amdcmd can be used to verify the error mechanism function of specific device models individually.

[0084] Data transmission module: First, the baseboard management controller (BMC) pre-creates and maintains a mapping file, which establishes the correspondence between CPUIOHUB chip information and status registers. When the BMC detects that an error register is set, it immediately records the device downtime and triggers the autonomous debugging data collection function to start collecting status register information, while also recording the time node when the information collection is completed. After collection, the BMC instructs the firmware interface dump file tool to parse the faulty device information and error type, and records the corresponding time after parsing. Once the dump file tool successfully locates the faulty device, the BMC records the relevant information and promptly notifies the user to collect the fault diagnosis log.

[0085] In summary, this invention provides a method for proactively triggering a CPU IOHUB chip damage scenario. By combining hardware-level error injection and full-link data capture technologies, a closed-loop testing system is constructed, thereby improving the collection of autonomous debugging data. This allows customers to independently determine whether to resolve the issue by upgrading the code based on the data. Therefore, the method for verifying the autonomous debugging data collection function in this invention can verify the fault tolerance mechanism of a server system: test whether the system can continue to operate or gracefully degrade when critical components fail; it can also assess fault recovery capabilities: check whether the system can automatically detect and isolate faults and start backup devices; and it can optimize hardware design: discover potential weaknesses in the IOHUB chip or system architecture.

[0086] The method for verifying the autonomous debugging data collection function proposed in this embodiment of the invention determines whether preset verification conditions for the autonomous debugging data collection function are met. If these conditions are met, the method acquires the logic signals of the target logic device and the secondary readback data of the target controller. The target logic device is verified based on the logic signals, and the target controller is verified based on the secondary readback data. If both the target logic device and the target controller pass verification, a preset fault instruction is injected into the target processor. This fault instruction is transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller collaboratively collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on the status data. This solves the problem that related technologies struggle to actively simulate chip link damage scenarios, leading to insufficient initiative and controllability in testing. This invention can actively trigger chip damage scenarios, combining hardware-level error injection and full-link data capture technologies to construct a closed-loop testing system, significantly improving the initiative and controllability of testing and enhancing fault reproducibility.

[0087] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0088] Embodiments of the present invention also provide an apparatus for verifying the autonomous debugging data collection function.

[0089] Figure 3 This is a block diagram of a device for verifying the autonomous debugging data collection function according to an embodiment of the present invention.

[0090] like Figure 3 As shown, the device 10 for verifying the autonomous debugging data collection function includes: a judgment module 100, an acquisition module 200, and a verification module 300.

[0091] The judgment module 100 is used to determine whether the preset verification conditions for the autonomous debugging data collection function are met.

[0092] The acquisition module 200 is used to acquire the logic signals of the target logic device and the secondary readback data of the target controller when the preset self-debugging data collection function verification conditions are met, and to verify the target logic device based on the logic signals and the target controller based on the secondary readback data.

[0093] The verification module 300 is used to inject a preset fault instruction into the target processor when both the target logic device and the target controller are verified as qualified. The fault instruction is then transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller work together to collect the status data generated by the input / output hub in response to the preset fault instruction, and the verification result of the autonomous debugging data collection function is obtained based on the status data.

[0094] According to one embodiment of the present invention, the acquisition module 200 includes: a first acquisition unit, a first judgment unit, and a first determination unit.

[0095] The first acquisition unit is used to acquire the positioning signal of the target logic device.

[0096] The first judgment unit is used to acquire the measurement signal of the target logic device when the signal value of the positioning signal reaches the first peak state, and to determine whether the signal value of the measurement signal has reached the second peak state.

[0097] The first determination unit is used to determine that the target logic device is qualified when the signal value of the measured signal reaches the second peak state.

[0098] According to an embodiment of the present invention, after determining that the signal value of the positioning signal has not reached the first peak state, or the signal value of the measurement signal has not reached the second peak state, the acquisition module 200 further includes: a second determination unit and a first transmission unit.

[0099] The second determination unit is used to determine that the target logic device verification has failed, and to generate logic verification failure information based on the first verification failure result.

[0100] The first sending unit is used to send logical verification failure information to a preset mobile terminal.

[0101] According to one embodiment of the present invention, the acquisition module includes: a second acquisition unit, a third acquisition unit, and a second determination unit.

[0102] The second acquisition unit uses the advanced platform management link to acquire the first register value of the target controller's register and determines whether the first register value is a preset valid flag bit.

[0103] The third acquisition unit is used to acquire the second register value of the target controller's register using the advanced platform management link when the first register value is a preset valid flag bit, and to determine whether the second register value is a preset valid flag bit.

[0104] The second determination unit is used to determine whether the target controller verification is qualified when the second register value is a preset valid flag bit.

[0105] According to an embodiment of the present invention, after determining that the first registered value is not a preset valid flag bit or the second registered value is not a preset valid flag bit, the acquisition module 200 further includes: a third determination unit and a second transmission unit.

[0106] The third determination unit is used to determine that the target controller verification failed and to generate functional verification failure information based on the second verification failure result.

[0107] The second sending unit is used to send a function verification failure message to a preset mobile terminal.

[0108] According to one embodiment of the present invention, the judgment module 100 includes: a fourth acquisition unit and a second judgment unit.

[0109] The fourth acquisition unit is used to acquire the current encryption status and current protection function status of the target processor.

[0110] The second judgment unit is used to determine whether the preset verification conditions for the autonomous debugging data collection function are met based on the current encryption status and the current protection function status.

[0111] According to one embodiment of the present invention, the second judgment unit includes: a judgment subunit and a determination subunit.

[0112] The judgment subunit is used to determine whether the current encryption state is an insecure encryption state and whether the current protection function is in a closed state.

[0113] The determination subunit is used to determine whether the preset verification conditions for the autonomous debugging data collection function are met when the current encryption state is an insecure encryption state and the current protection function state is off.

[0114] According to one embodiment of the present invention, after injecting a preset fault instruction into the target processor, the system further includes a verification module 300, which includes a third judgment unit and a fourth judgment unit.

[0115] The third judgment unit is used to determine whether the current operating system is in a crash state.

[0116] The fourth determination unit is used to determine if the input / output hub has failed when the current operating system is in a crash state.

[0117] According to one embodiment of the present invention, the verification module 300 includes: a fourth judgment unit and a fifth determination unit.

[0118] The fourth judgment unit is used to determine whether the status data is consistent with the data corresponding to the preset fault command.

[0119] The fifth determination unit is used to determine that the autonomous debugging data collection function has passed verification if the status data is consistent with the data corresponding to the preset fault command.

[0120] In summary, the description of the features in the embodiment corresponding to the device for verifying the autonomous debugging data collection function can be found in the relevant description of the embodiment corresponding to the method for verifying the autonomous debugging data collection function, and will not be repeated here.

[0121] Embodiments of the present invention also provide an electronic device, which may include:

[0122] The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0123] When the processor 402 executes the program, it implements the method for verifying the autonomous debugging data collection function provided in the above embodiments.

[0124] Furthermore, electronic devices also include:

[0125] Communication interface 403 is used for communication between memory 401 and processor 402.

[0126] The memory 401 is used to store computer programs that can run on the processor 402.

[0127] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0128] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized into address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0129] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0130] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0131] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the method for verifying autonomous debugging data collection function when run.

[0132] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0133] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for verifying autonomous debugging data collection functions.

[0134] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0135] The above provides a detailed description of a method for verifying the autonomous debugging data collection function provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

Claims

1. A method for verifying the autonomous debugging data collection function, characterized in that, Includes the following steps: Determine whether the preset verification conditions for the autonomous debugging data collection function are met; Under the condition that the preset autonomous debugging data collection function verification conditions are met, the logic signals of the target logic device and the secondary readback data of the target controller are obtained, and the target logic device is verified according to the logic signals, and the target controller is verified according to the secondary readback data. If both the target logic device and the target controller pass verification, a preset fault instruction is injected into the target processor. This fault instruction is then transmitted to the input / output hub via the processor's internal bus. The target logic device and the target controller collaboratively collect status data generated by the input / output hub in response to the preset fault instruction. Based on this status data, the verification result of the autonomous debugging data collection function is obtained. The step of acquiring the logic signal of the target logic device and the secondary readback data of the target controller, and verifying the target logic device based on the logic signal and the target controller based on the secondary readback data, includes: acquiring the positioning signal of the target logic device; If the signal value of the positioning signal reaches the first peak state, the measurement signal of the target logic device is acquired, and it is determined whether the signal value of the measurement signal reaches the second peak state; if the signal value of the measurement signal reaches the second peak state, the target logic device is determined to be qualified.

2. The method according to claim 1, characterized in that, After determining that the signal value of the positioning signal has not reached the first peak state, or the signal value of the measurement signal has not reached the second peak state, the method further includes: The target logic device is determined to have failed verification, and logic verification failure information is generated based on the first verification failure result; Send the logic verification failure message to the preset mobile terminal.

3. The method according to claim 1, characterized in that, The step of acquiring the logic signals of the target logic device and the secondary readback data of the target controller, verifying the target logic device based on the logic signals, and verifying the target controller based on the secondary readback data includes: The target controller uses the advanced platform management link to obtain the first register value of the target controller's register and determines whether the first register value is a preset valid flag bit; If the first register value is the preset valid flag bit, then the second register value of the target controller's register is obtained using the advanced platform management link, and it is determined whether the second register value is the preset valid flag bit; If the second register value is the preset valid flag bit, then the target controller is deemed to have passed verification.

4. The method according to claim 3, characterized in that, After determining that the first registered value is not a preset valid flag bit, or the second registered value is not a preset valid flag bit, the method further includes: The target controller verification is determined to have failed, and functional verification failure information is generated based on the second verification failure result; Send the function verification failure message to the preset mobile terminal.

5. The method according to claim 1, characterized in that, The determination of whether the preset verification conditions for the autonomous debugging data collection function are met includes: Obtain the current encryption status and current protection function status of the target processor; Based on the current encryption state and the current protection function state, determine whether the preset verification conditions for the autonomous debugging data collection function are met.

6. The method according to claim 5, characterized in that, The step of determining whether the preset verification conditions for the autonomous debugging data collection function are met based on the current encryption state and the current protection function state includes: Determine whether the current encryption state is an insecure encryption state and whether the current protection function state is off; If the current encryption state is the insecure encryption state and the current protection function state is the off state, then it is determined that the preset verification conditions for the autonomous debugging data collection function are met.

7. The method according to claim 1, characterized in that, After injecting a preset fault instruction into the target processor, the method further includes: Determine if the current operating system is in a crash state; If the current operating system is in a crash state, then the input / output hub is determined to be faulty.

8. The method according to claim 7, characterized in that, The verification results of the autonomous debugging data collection function obtained based on the status data include: Determine whether the status data is consistent with the data corresponding to the preset fault command; If the status data matches the data corresponding to the preset fault instruction, the autonomous debugging data collection function is deemed to have passed verification.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the steps of the method for verifying autonomous debugging data collection functionality as described in any one of claims 1 to 8.

Images