Network card fault detection method and electronic device

Abstract

The application discloses a network card fault detection method and electronic equipment, and relates to the technical field of digital data processing, which can determine a corresponding detection mode according to different trigger scenes after triggering a network card detection instruction, so as to call different debugging information in different detection modes, realize targeted data in-depth collection, identify the fault type of a target network card through analysis of a register character segment, and solve the technical problems in the prior art, such as single and passive trigger mechanism of network card detection, poor active sensing capability for abnormal events, fault detection only by using polling data, large fault detection result error, and influence on the later maintenance duration, and the efficiency and detection result accuracy of server network card fault detection are improved.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to a network card fault detection method and electronic equipment. Background Technology

[0002] In related technologies, when network interface cards (NICs) have complex problems, there is a lack of efficient and reliable troubleshooting methods. Typically, fault diagnosis is performed based on anomalies in the polled NIC data during polling. However, the polling speed is fast, and the interval between two polls is extremely short, resulting in polled data that is usually only shallow and basic. It is difficult to make accurate fault diagnosis based solely on polled data. Furthermore, if anomalies are not identified in advance by the polled data, there is a lack of intervention methods for NIC fault detection. This leads to the identification of abnormal events only after the NIC has failed and the system has stopped operating, affecting business continuity. There is an urgent need for improvement. Summary of the Invention

[0003] This application provides a network card fault detection method and electronic device to at least solve the technical problems in related technologies, such as the network card detection trigger mechanism being single and passive, poor ability to actively perceive abnormal events, and the use of only polling data for fault detection, resulting in large errors in fault detection results and thus affecting the subsequent maintenance time.

[0004] This application provides a network interface card (NIC) fault detection method, comprising: responding to a NIC detection command, determining the detection mode of the target NIC; invoking the interface protocol between the target NIC and the baseboard management controller to collect debugging information corresponding to the detection mode; determining at least one register character segment reflecting the abnormal state of the target NIC based on the debugging information, and identifying the fault type of the target NIC when a fault occurs, or predicting the possible fault type of the target NIC based on the at least one register character segment.

[0005] This application also provides a network interface card (NIC) fault detection device, comprising: a determination module, configured to determine the detection mode of a target NIC in response to a NIC detection command; a data acquisition module, configured to invoke the interface protocol between the target NIC and the baseboard management controller to acquire debugging information corresponding to the detection mode; and a detection module, configured to determine at least one register character segment reflecting the abnormal state of the target NIC based on the debugging information, and to identify the fault type of the target NIC when a fault occurs, or to predict the possible fault type of the target NIC based on the at least one register character segment.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described network card fault detection methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described network card fault detection methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described network card fault detection methods.

[0009] This application enables the determination of corresponding detection modes based on different triggering scenarios after a network card detection command is triggered. Different debugging information can be retrieved under different detection modes, achieving targeted and in-depth data collection. By parsing the register character field, the fault type of the target network card can be identified. This solves the technical problems in related technologies, such as the single and passive triggering mechanism of network card detection, poor proactive perception of abnormal events, and the large error in fault detection results due to the use of only polling data for fault detection, which affects the subsequent maintenance time. This improves the efficiency and accuracy of server network card fault detection. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram illustrating the principle of network card fault detection in related technologies; Figure 2 This is a flowchart of a network card fault detection method provided according to an embodiment of this application; Figure 3 This is a flowchart of a network card fault detection method according to an embodiment of this application; Figure 4 This is a schematic diagram of a network card fault detection device provided according to an embodiment of this application.

[0012] Among them, 1-BMC (Baseboard Management Controller), 2-PCIe (Peripheral Component Interconnect Express), 3-BIOS (Basic Input Output System), 4-Network Card; 10-Network Card Fault Detection Device, 100-First Determination Module, 200-First Acquisition Module, 300-First Detection Module. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0014] It should be noted that, in the description of this application, 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., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

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

[0016] Understandably, as a key component of the physical layer and data link layer, the network interface card (NIC) needs to have high bandwidth transmission, low processor usage, and high security and reliability in scenarios where servers perform long-term, uninterrupted pre-training language model calculations, in order to fully unleash the computing power of the graphics processor and ensure the stability of core services and data security.

[0017] The operating mechanism of the baseboard management controller determines its core position in server operation and maintenance. The continuously rising performance of network interface cards (NICs) and the integration of various advanced functions have expanded the baseboard management controller's monitoring requirements for NICs from the original basic temperature monitoring to multi-dimensional and refined status awareness, including NIC chip core temperature, port link status, data transmission rate, queue load, power consumption, and error packet count.

[0018] Currently, while related technologies can quickly identify obvious hardware anomalies such as physical damage to network cards and loose interfaces, they often lack efficient troubleshooting methods when faced with more complex problems, such as compatibility conflicts between network cards and server motherboard slots, mismatches between network card firmware and baseboard management controller monitoring protocols, hidden faults in the internal data processing modules of network cards, and link instability in high-bandwidth scenarios.

[0019] In related technologies, the principle of network card fault detection in servers can be as follows: Figure 1As shown, BMC1 can use the MCTP over I2C (Management Component Transport Protocol over I2C bus) interface to obtain out-of-band information of NIC 4, including temperature, link status, NIC version, optical module information, etc.

[0020] BMC1 can also interact with BIOS3 through the PCIe2 channel to obtain network card asset information, read the network card 4's version number, manufacturer and model identifier, serial number, device model, and silkscreen information.

[0021] BMC1 can also utilize the KCS (Keyboard Controller Style) function to receive SEL (System Event Log) information thrown by BIOS3, thereby understanding device fault information. Network card 4 can obtain status information about PCIe2, including status anomalies such as PCI PERR (PCI ParityError), PCI SERR (PCI System Error), Bus Correctable Error, Bus Uncorrectable Error, and Bus Fatal Error.

[0022] After BMC1 obtains various information from NIC 4, it reports the information to the operations and maintenance personnel through commands such as web / redfish (server management interface standard) / IPMI (Intelligent Platform Management Interface). The operations and maintenance personnel then take corresponding maintenance measures based on the results.

[0023] Based on this, it is evident that the relevant technologies have significant limitations. For example, they can only acquire information such as the temperature, link status, and basic asset information of the network card 4, but cannot deeply analyze key diagnostic information such as PCI configuration space registers, error statistics, and resource allocation status, making it difficult to pinpoint the root cause of complex faults. The use of periodic data collection or simple threshold alarms cannot intelligently trigger debugging information collection based on business scenarios, lacking proactive perception and rapid response capabilities for abnormal events. The MCTP (Management Component Transport Protocol) protocol is mainly used to transmit basic status information and does not support the fragmented transmission of large amounts of debugging information, making it impossible to obtain in-depth diagnostic data such as network card internal operation logs and firmware operation trajectories. Relying on manual analysis of simple monitoring indicators lacks refined fault diagnosis rules based on registers, making it impossible to identify hidden faults (such as firmware version mismatch, abnormal power consumption fluctuations, temperature warnings, etc.). After fault information is reported, manual intervention by maintenance personnel is required, involving collecting debugging data, contacting the manufacturer, waiting for analysis, and on-site upgrades. The entire process can take several days or even weeks, failing to meet the requirements of long-term continuous operation of pre-trained language models. It cannot trigger network card diagnostics based on GPU (Graphics Processing Unit) performance degradation, and lacks cross-component correlation analysis and collaborative fault location capabilities.

[0024] To address the aforementioned technical issues, embodiments of this application can set up various scenarios that can trigger network card detection commands, intelligently collect debugging information based on different triggering scenarios, and perform fault diagnosis based on the collected data to effectively identify hidden faults, facilitate efficient maintenance of the network card, and ensure business operation.

[0025] like Figure 2 As shown in the figure, this application embodiment provides a network card fault detection method, including the following steps: In step S201, in response to the network card detection command, the detection mode of the target network card is determined.

[0026] In actual implementation, the embodiments of this application can be applied to the baseboard management controller. After the baseboard management controller receives the network card detection command, it can parse the network card detection command, determine the target network card to be detected in the network card detection command, and the detection mode for the target network card. Based on the detection mode, it can determine the relevant data of the target network card to be collected, realize targeted data collection, and avoid collecting all data in full, which would result in a long collection time and affect the normal polling of the network card.

[0027] Optionally, in one embodiment of this application, before determining the detection mode of the target network card in response to the network card detection command, the method further includes: detecting the current operating stage of the server; if the current operating stage is detected to be a startup stage or a reset stage, determining the startup duration of multiple components in the server; and generating a first network card detection command based on the startup duration, as the network card detection command.

[0028] In this application embodiment, the content of the network card detection instruction is different depending on the triggering scenario. Here, the first triggering scenario is described.

[0029] The first trigger scenario is when the server powers on or restarts.

[0030] The embodiments of this application can detect the current operating stage of the server and determine whether the server is currently in the startup stage (cold start after being plugged in), the reset stage (operating system restart (hot reset)), or the normal operating stage.

[0031] When the server is detected to be in the startup or reset phase, the server hardware has just been powered on. At this time, it is convenient to capture relevant data on the initial state of the hardware. This application embodiment can record the startup time of some components, such as the time required for the baseboard management controller to complete initialization (e.g., 10 seconds after power-on), the time required for memory initialization, the time required for PCIe bus enumeration (scanning network cards), etc. Based on the startup time, this application embodiment can determine the ready time point of each component. Based on the ready time point, this application embodiment can determine the time when the network card detection command is issued and what detection parameters are included in the network card detection command. This avoids the data collected when the component is not ready affecting fault diagnosis. Moreover, it can perform more targeted data collection based on whether the startup time of the component is abnormal (e.g., whether the deviation from the historical startup time is too large). (For example, under normal circumstances, the debugging information is collected in full. If no fault is detected after full collection, the full collection data can be used as the subsequent fault judgment benchmark. In the case of abnormal startup, the debugging information can be collected in a targeted manner for the abnormally started component.)

[0032] Optionally, in one embodiment of this application, before determining the detection mode of the network card in response to the network card detection command, the method further includes: receiving a detection request sent by a user; determining the network card identifier according to the detection request, and matching the target network card according to the network card identifier; and generating a second network card detection command based on the target network card, as the network card detection command.

[0033] The second trigger scenario is the detection scenario initiated by the user.

[0034] This application embodiment can receive detection requests sent by users, such as network card health detection commands issued by the upper-layer network management system, commands initiated by maintenance personnel remotely logging into the baseboard management controller, and commands triggered by users.

[0035] When a user initiates a detection request, they can set the network card to be detected and the debugging information to be invoked, thereby generating network card detection instructions based on the user's settings.

[0036] This application embodiment can support users to initiate targeted detection as needed, meeting the needs of operation and maintenance personnel for proactive troubleshooting; through network card identifier matching, it supports accurate location detection of specific network cards, avoiding interference from full detection to other normal network cards.

[0037] Optionally, in one embodiment of this application, before determining the network card detection mode in response to the network card detection command, the method further includes: collecting current operating data of multiple network cards of the server at preset time intervals; associating the current operating data with the network card identifiers of the multiple network cards respectively to generate corresponding mapping relationships, and storing the mapping relationships, current operating data and network card identifiers in a preset shared memory; extracting historical operating data corresponding to multiple network cards from the preset shared memory based on the mapping relationships; determining abnormal operating data that meets preset abnormal conditions by combining the historical operating data and the current operating data, and determining at least one target network card among all network cards by combining the abnormal operating data, the mapping relationships and the network card identifiers; and generating a third network card detection command using the target network card and the abnormal operating data as the network card detection command.

[0038] The third trigger scenario is the detection scenario where anomalies are discovered during the polling process.

[0039] In this embodiment, the network card's operating data, such as link status flags, link width, speed, and network card power consumption, can be polled at preset time intervals. During each poll, the polled operating data can be associated with the network card identifier, and the network card identifier, mapping relationship, and operating data can be stored in shared memory.

[0040] When diagnosing abnormal events, the historical running data corresponding to each network card can be retrieved from shared memory through network card identifiers and mapping relationships. Then, by combining the historical running data and the current running data, it can be determined whether there is abnormal running data. After abnormal running data is detected, the corresponding network card is found as the target network card according to the mapping relationship. Then, a network card detection command is generated based on the target network card and the abnormal running data. When responding to the network card detection command, the target network card to be detected and the debugging information to be retrieved can be determined.

[0041] This application embodiment achieves periodic proactive monitoring of multiple network interface cards (NICs) without relying on OS (Operating System) or driver reporting. Through joint analysis of historical and current data, it identifies trend anomalies (such as gradually increasing power consumption or slow deterioration of link quality) to trigger targeted data calls and analysis, thus avoiding the waste of resources caused by continuously performing full-scale testing on all NICs.

[0042] Optionally, in one embodiment of this application, determining abnormal operating data that meets preset abnormal conditions by combining historical operating data and current operating data includes: extracting historical status flag bits of the link status registers corresponding to multiple network cards from the historical operating data; extracting current status flag bits of the link status registers corresponding to multiple network cards from the current operating data; comparing the historical status flag bits and the current status flag bits to determine abnormal status flag bits where the historical status flag bits and the current status flag bits are inconsistent; and determining abnormal operating data based on the abnormal status flag bits.

[0043] This section explains how to identify abnormal operational data.

[0044] In this embodiment of the application, the corresponding historical status flag bit (such as the network card link status flag bit) can be extracted from the historical operation data according to the network card identifier, and the corresponding current status flag bit in the current operation data can be obtained. Then, the two are compared to see if they are consistent. For example, if the network card link status changes from up (connected) to down (disconnected), it indicates that the link has changed and an abnormal event has occurred. The current status flag bit in the current operation data is abnormal operation data.

[0045] By comparing historical and current operating data, transient events such as jumps can be effectively identified, misjudgments can be avoided, and the target network card with anomalies can be quickly located.

[0046] Optionally, in one embodiment of this application, determining abnormal operating data that meets preset abnormal conditions by combining historical operating data and current operating data includes: combining historical operating data and current operating data to sort the number of parallel transmission channels and the data transmission speed of multiple network cards according to the acquisition time sequence, and determining the changing trend of the number of channels and the data transmission speed; if the changing trend of the number of channels is a downward trend, or the changing trend of the data transmission speed is a preset fluctuation trend, then determining the abnormal operating data based on the number of channels and the data transmission speed.

[0047] The embodiments of this application can detect PCIe link slowdown / fluctuation to identify abnormal operating data.

[0048] Here, the number of parallel transmission channels refers to the PCIe link width (e.g., x16 means 16 channels transmitting simultaneously), and the data transmission speed of the channels refers to the PCIe link rate. In this embodiment, the width and rate values ​​collected each time can be arranged into a timeline in chronological order, and then the direction of change of this timeline can be observed.

[0049] If the width value continuously decreases over time (e.g., from x16 to x8, then to x4), it indicates a downward trend. If the rate value fluctuates, it indicates a fluctuating trend. If either of these trends occurs, this embodiment of the application can mark the number of channels and transmission speed of the network card as abnormal operating data.

[0050] This application embodiment can identify more subtle intermittent abnormal events (such as frequent rate jumps) through trend analysis, making it easier to detect network card anomalies in a timely manner and take effective measures to ensure service continuity.

[0051] Optionally, in one embodiment of this application, determining abnormal operating data that meets preset abnormal conditions by combining historical operating data and current operating data includes: calculating the power consumption fluctuations corresponding to multiple network cards by combining historical operating data and current operating data, and filtering out abnormal power consumption fluctuations that are greater than a preset fluctuation threshold; and determining abnormal operating data based on the abnormal power consumption fluctuations.

[0052] A sudden spike or drop in power consumption within a short period of time often indicates a problem with the power management module inside the network card, or the presence of potential hazards such as short circuit precursors or unstable power supply. This application embodiment can utilize network card power consumption fluctuations to identify abnormal operating data.

[0053] The embodiments of this application can continuously record the real-time power consumption value of each network card, forming a curve of power consumption changing over time. After each new power consumption value is collected, the difference between the current power consumption and the average power consumption over a previous period is calculated, thereby obtaining the power consumption fluctuation.

[0054] If the power consumption fluctuation exceeds a preset threshold (e.g., 15%), it can be identified as an abnormal power consumption fluctuation.

[0055] The embodiments of this application can detect network card anomalies in advance by identifying abnormal power consumption and take effective measures, thereby ensuring service continuity.

[0056] Optionally, in one embodiment of this application, determining abnormal operating data that meets preset abnormal conditions by combining historical operating data and current operating data includes: calculating the computing power utilization rate of the graphics processors corresponding to multiple network cards by combining historical operating data and current operating data, and filtering out abnormal computing power utilization rates that are greater than a preset utilization rate threshold; and determining abnormal operating data based on the abnormal computing power utilization rate.

[0057] GPU computing power utilization reflects the degree to which the GPU is utilized. In pre-trained language model training or inference scenarios, the GPU needs the network card to pull data from remote storage or other computing nodes. If the network card experiences bandwidth bottlenecks, packet loss, or speed reduction, the GPU will be forced to idle because it cannot obtain data, and the computing power utilization will decrease. This application's embodiments can identify abnormal operating data based on GPU computing power utilization.

[0058] This application embodiment can continuously record historical data of GPU computing power utilization. When it is found that the utilization suddenly drops below a preset threshold (e.g., from above 80% to below 50%), although an anomaly of the GPU is detected, it can be inferred that the problem may lie with the network card. Therefore, this application embodiment can mark the network card corresponding to this GPU as abnormal and use the GPU computing power utilization as abnormal operating data.

[0059] This application embodiment can avoid missing the investigation of network cards when the GPU computing power utilization is abnormal through correlation analysis based on GPU computing power, thereby detecting network card anomalies in advance and ensuring business operation.

[0060] Optionally, in one embodiment of this application, determining the detection mode of the target network card in response to a network card detection command includes: determining the detection mode as a full detection mode in response to a first network card detection command; determining the detection mode as a request detection mode in response to a second network card detection command; and determining the detection mode as a fault detection mode in response to a third network card detection command. Specifically, in the case of a full detection mode, the full debugging information of the target network card is invoked; in the case of a request detection mode, the second network card detection command is parsed to invoke the first part of debugging information associated with the second network card detection command; and in the case of a fault detection mode, the second part of debugging information associated with abnormal operation data is invoked.

[0061] Different fault detection modes can be determined for different triggering scenarios.

[0062] In the first trigger scenario, since the server has just started up, it is impossible to determine whether there is a fault, and the network card has not yet processed services. Therefore, the time-consuming full scan will not affect network card polling and service continuity. Thus, this embodiment can perform a full scan to check the network card's health status. If the network card is determined to be fault-free after the scan, the debugging information obtained from the full scan can be used as a baseline for the health status. Alternatively, the debugging information from historically collected full scans can be combined to analyze changes in the network card's health status. For startup anomalies, this embodiment can also treat them as an abnormal event and use them to trigger a third network card detection command after the server is running normally.

[0063] When the triggering scenario is the second type, since the detection is initiated by the user, the first part of the debugging information related to the user's request can be detected, such as the register fields that the user is interested in (e.g., the error count and frame loss count in the error statistics register), as well as the relevant register groups that are automatically matched based on the fault phenomenon keywords input by the user. This avoids the time consumption and resource occupation caused by full data collection and responds to the user's diagnostic needs as quickly as possible.

[0064] In the case of the third trigger scenario, since the baseboard management controller has already preliminarily determined that the network card is abnormal through shallow polling data and has initially identified the type of abnormality (such as suspected link slowdown or suspected power instability), this embodiment of the application can perform a fault detection mode to only call the second part of debugging information associated with the identified abnormal operating data. For example, if a decrease in PCIe link width is found during the polling phase, the fault detection mode only collects deep register data directly related to the abnormality, such as the link negotiation register, link training status register, and degradation reason register. If abnormal power fluctuation is found during the polling phase, only deep data related to power supply, such as the power management register, current detection register, and voltage alarm register, is collected. This allows for obtaining the most critical diagnostic evidence with minimal collection cost, avoiding redundant consumption when full collection is performed in the direction of fault localization.

[0065] It should be noted that in the third triggering scenario, the abnormal operation data determined by polling may not be able to initially identify the type of abnormality. In this case, the embodiments of this application can also directly enter the full detection mode to determine the actual fault type of the target network card through comprehensive data.

[0066] In step S202, the interface protocol between the target network card and the baseboard management controller is invoked to collect debugging information corresponding to the detection mode.

[0067] The network interface card (NIC) and the baseboard management controller can communicate via the I2C (Inter-Integrated Circuit) interface, based on the NCSI (Network Controller Sideband Interface) over MCTP (Management Component Transport Protocol) over I2C (NCSI over MCTP over I2C, complete protocol stack), and add a debug information interface protocol to collect debug information.

[0068] Optionally, in one embodiment of this application, the collection and detection of debugging information corresponding to the mode includes: the cumulative collection duration of debugging information; if the collection duration exceeds a preset duration threshold, the collection of debugging information is terminated, and a data collection anomaly alarm signal is generated.

[0069] It is understandable that polling is a periodic collection and monitoring process, but the amount of network card debugging information is very large. It is only triggered when the above three scenarios are met; otherwise, it will consume a lot of resources.

[0070] In this application embodiment, different queues are used to trigger tasks for collecting debugging information of different components. When the abnormality of network card monitoring is due to an internal problem of the network card, the collection of network card debugging information will be triggered. Since there are multiple network cards on a device, when collecting debugging information of the target network card, it is necessary to ensure that the power supply and other external components are normal.

[0071] This application embodiment can estimate the time for each call to debug information. Taking full detection as an example, it takes about 20 minutes to collect data. This application embodiment can add time detection during collection, exit if timeout occurs, avoid affecting normal monitoring logic, and confirm that there may be a fault in the communication link at this time, generate a data collection anomaly alarm to remind technicians to perform maintenance.

[0072] During the data retrieval process, due to the large amount of data exchanged for network card debugging information, it is necessary to handle unexpected situations during monitoring to prevent the program from freezing and to store the collected debugging information in files.

[0073] In step S203, at least one register character segment reflecting the abnormal state of the target network card is determined based on the debugging information, and the fault type when the target network card fails is identified or the possible fault type of the target network card is predicted based on the at least one register character segment.

[0074] As one possible implementation, embodiments of this application can parse the PCI configuration space register (a specific memory-mapped area on a PCI / PCIe device used to store device identity information, resource requests, status, and control bits) data in the debugging information, extract the values ​​of key register groups (i.e., register character segments), and then diagnose the faults of the target network card based on the register character segments, or diagnose the potential future faults of the target network card.

[0075] Optionally, in one embodiment of this application, identifying the fault type when the target network card fails based on at least one register character segment includes: obtaining the server's pre-stored compatibility list and the target network card's pre-stored identification character; determining the target network card's identification character based on at least one register character segment; and determining the fault type as a network card identification fault type if the pre-stored identification character is inconsistent with the identification character or if the identification character does not match the pre-stored compatibility list.

[0076] In some embodiments, the server's pre-stored compatibility list can be obtained, which is a list of network card models that the server has pre-stored and tested to be usable in the server, and the pre-stored identification characters can be obtained, which is the expected network card identification information pre-recorded by the server for each PCIe slot.

[0077] When the baseboard management controller performs network card detection, it can read the target network card's identification character from the register character field. The currently read identification character is compared with pre-stored identification characters. If they do not match, it indicates that the network card in that slot has been replaced, possibly by the user or due to unexplained changes to device information. The currently read identification character is matched against a pre-stored compatibility list. If it is not in the list, it indicates that the network card is not a type verified and supported by the server manufacturer, potentially due to driver incompatibility, inadequate heat dissipation, or PCIe signal mismatch. If any of the above comparisons fails, this embodiment of the application can determine the fault type as a network card identification fault, promptly detecting whether the network card has been replaced without authorization, thus improving asset management and security.

[0078] Optionally, in one embodiment of this application, identifying the fault type when the target network card fails based on at least one register character segment includes: determining the command character, memory space base address character, and link width character of the target network card based on at least one register character segment; determining the enable state of the target network card based on the command character; determining the address state of the target network card by combining the memory space base address character and a memory space base address character threshold determined by the network card type of the target network card; determining the deceleration state of the target network card by combining the link width character and the desired link configuration of the target network card; and determining the fault type as a resource allocation fault type when the enable state is disabled, the address state is an address abnormal state, or the deceleration state is a deceleration abnormal state.

[0079] In other embodiments, three key register fields can be extracted from the collected debugging information: command character, memory space base address character, and link width character.

[0080] In this embodiment, it can be determined whether the lower three bits of the command character are all 1. If not, it indicates that some functions of the target network card, such as memory space or bus mastering capability, are not enabled, and the target network card is in an disabled state.

[0081] This application embodiment can determine whether the memory space base address character is normal. For example, this application embodiment can obtain the corresponding memory space base address character threshold from the device specification database (such as a 400G network card requiring no less than 0x0A000000), and then compare the memory space base address character with it. If the memory space base address character does not match the threshold, it is determined to be an address abnormal state.

[0082] This application embodiment can determine the speed reduction status of the target network card based on the link width character. This application embodiment can obtain the PCIe link width currently negotiated by the target network card (such as x16, x8, x4) and compare it with the expected link configuration of the target network card model (such as x16 expected for a 400G network card). If the actual width is lower than the expected value, it is determined to be an abnormal speed reduction status.

[0083] If any one of the above three states is abnormal (disabled state, address abnormal state, or speed reduction abnormal state), this application embodiment can determine the fault type as a resource allocation fault. These three dimensions complement each other, jointly completing a comprehensive assessment of the network card resource allocation health status. Through cross-validation of the three dimensions, comprehensive coverage of resource allocation anomalies is ensured, facilitating subsequent accurate maintenance based on root causes.

[0084] Optionally, in one embodiment of this application, identifying the fault type when the target network card fails based on at least one register character field includes: determining the status character and error statistics character of the target network card based on at least one register character field; determining that the target network card is in a link connection state based on the link establishment flag and interrupt response flag of the status character, and determining that the link connection state is a link disconnect state if the link establishment flag is not established or the interrupt response flag is not responded; determining the transmission state of the target network card based on the error statistics character, and determining that the transmission state is a transmission abnormal state if the error statistics character is greater than a pre-designed value; and determining the fault type as a link transmission abnormal fault type if the target network card is in a link disconnect state or a transmission abnormal state.

[0085] In this embodiment, the link establishment flag and interrupt response flag can be extracted from the register character field. If the link establishment flag is 0, it indicates that the physical link between the target network card and the peer has not been established, which may be due to a faulty network cable, a damaged optical module, a failed PCIe link training, or the peer device not being powered on. If the interrupt response flag is 0, it indicates that the target network card cannot send or respond to an interrupt signal.

[0086] If any one of the flag bits is 0, the link connection status can be determined to be disconnected.

[0087] This application embodiment can also extract the error count from the error statistics register from the register character field. If the count value is greater than a preset value (usually 0), it indicates that although the link has been established, a data error occurred during transmission, and the target network card is in an abnormal transmission state.

[0088] If the target network card is in either a disconnected link state or a transmission abnormal state, this application embodiment can determine the fault type as a link transmission abnormality fault type.

[0089] The embodiments of this application can effectively distinguish between two different types of faults: link disconnection and transmission error. The introduction of the interrupt response flag can be used to detect hidden faults such as normal link but CPU not receiving interrupts, which facilitates subsequent maintenance by technicians.

[0090] Optionally, in one embodiment of this application, identifying the fault type when the target network card fails based on at least one register character segment includes: determining the chip temperature character of the target network card based on at least one register character segment; determining the actual temperature of the target network card based on the chip temperature character, and determining the fault type as a high-temperature fault type if the actual temperature is greater than a preset temperature threshold; determining the power consumption character of the target network card based on at least one register character segment; obtaining the actual power consumption of the target network card based on the power consumption character, and calculating the power consumption fluctuation amplitude of the target network card within a preset time interval; and determining the fault type as a load fault type if the power consumption fluctuation amplitude is greater than a preset amplitude threshold.

[0091] This application embodiment can extract the chip temperature character from the register character field to determine the actual temperature of the target network card chip, and then compare it with a preset temperature threshold (such as 85°C). If the actual temperature is less than or equal to 85°C, it is considered normal. If the actual temperature is greater than 85°C, it is determined to be a high-temperature fault type, triggering a high-temperature warning.

[0092] This application embodiment can extract power consumption characters from the register character field and calculate the power consumption fluctuation amplitude (i.e., the change amplitude between the maximum and minimum values) within a recent time interval (e.g., the past 5 minutes) based on all power consumption data. If the fluctuation amplitude exceeds the amplitude threshold (e.g., 20%), it is determined to be a load fault type.

[0093] This application embodiment can identify high temperature fault types to provide high temperature warnings, thereby triggering accelerated heat dissipation before the network card overheats and slows down, thus avoiding performance loss. By identifying load fault types such as abnormal power consumption fluctuations, a load reduction strategy can be triggered before the network card suddenly disconnects in high-concurrency scenarios, achieving proactive protection. By effectively identifying two types of hidden faults, temperature and power consumption, more accurate and comprehensive fault diagnosis can be achieved.

[0094] For different types of faults, the embodiments of this application can generate corresponding fault diagnosis reports and transmit the fault diagnosis reports and debugging information to the operation and maintenance platform. The operation and maintenance platform can then forward the data to the manufacturer for fault maintenance.

[0095] like Figure 3 As shown, the working principle of the network card fault detection method of this application embodiment is explained in detail with an example.

[0096] like Figure 3 As shown, embodiments of this application may include the following steps: Step S301: Identify the triggering scenario of the network card detection command.

[0097] The triggering scenarios can include those triggered after the server powers on / restarts, those triggered by the user, and those triggered after polling the network card to identify abnormal events.

[0098] Step S302: Retrieve the debugging information of the target network card.

[0099] In this application embodiment, a debug information interface protocol can be added based on the NCSI over MCTP over i2c protocol to collect debug information.

[0100] The instruction format for the baseboard management controller to actively send debugging information requests can be shown in Table 1, which is the first instruction format table.

[0101] Table 1

[0102] Where Byte:Bits represents bytes:bits. NC-SI HEADER (OEM Command) is the network controller sideband interface header (manufacturer-defined command). Manufacture ID is the manufacturer identifier. Command rev=0x00 is the command revision number (value 0x00). cmd ID=0x00 is the command identifier (value 0x00). Parameter=0x32 is the parameter (value hexadecimal 0x32, i.e., decimal 50). Info_Type is the debug information type, where 0 - device information, 1 - firmware information (future), and other - reserved; this field must not be changed during the entire debug information reading process. Request Handle is the request handle / request processing identifier, where Request is the identifier of the data segment, 0 is the first data segment, and other - should match the last next handle ID (identifier) ​​provided by the device. CheckSum is the checksum.

[0103] The instruction format received by the baseboard management controller can be as shown in Table 2, which is the second instruction format table.

[0104] Table 2

[0105] Here, Response Code is the response code. Reason Code is the reason code. Reserved is a reserved field. Length is the length of the segment data payload in bytes. Next Handle is the identifier of the data segment, where 0 is the last data segment, and others are used to request the next data segment. Segment Data is the number of bytes of debug information. CheckSum (40 + Length) is the total length of the standard response packet, and (43 + Length) is the extended total length with specific overhead. Info_Type is the debug information type, where 0 is device information, 1 is firmware information (future), and others are reserved.

[0106] In this embodiment of the application, the register group may include: Standard configuration registers (address range 0x00-0x3F): Vendor ID (0x00-0x03): Identifies the network card manufacturer (e.g., Intel Vendor ID=0x8086, Realtek=0x10EC). Device ID (Device Identifier) ​​(0x04-0x07): Identifies the network card model; Command Register (0x0C-0x0F): Identifies the enable status of I / O, memory, and interrupt resources. A normal value should include 0x07 (I / O + memory + interrupt enable). Status register (0x08-0x0B): identifies link status and interrupt response status, where bit5=0: link not established, bit4=0: no interrupt response; BAR (Base Address Register) memory address register (0x10-0x17): identifies the memory resource allocation address. Among them, the BAR memory address of a 100G network card must be no lower than 0x09000000, and the BAR memory address of a 400G network card must be no lower than 0x0A000000. Interrupt line registers (0x3C-0x3F): identify interrupt resource allocation.

[0107] Extended registers (address segment after 0x00040700): Among them, the link rate configuration register (e.g., 0x00040808) identifies the PCIe link rate configuration; Error statistics register (e.g., 0x00040780): identifies CRC errors and frame loss counts. Normal value: 0, abnormal value: greater than 0. PCIe Link Status Register (e.g., 0x000430c8): Identifies the link width and speed status. For 400G network cards, PCIe 4.0 x16 is required. If x8 is displayed, it indicates that the link speed has been reduced. Network card chip temperature register (e.g., 0x000427ec): indicates the core temperature of the network card chip, where the normal value is less than 85℃ and the warning value is greater than 85℃; Power consumption register (e.g., 0x00049204): identifies the network card power consumption value. A short-term fluctuation of more than 20% is considered unstable power consumption. Firmware version matching register (e.g., 0x000451e4): Identifies the network card firmware version, which must match the adaptation version pre-stored in the BMC.

[0108] Step S303: Analyze the debugging information to determine the fault type of the target network card.

[0109] This application embodiment can determine the fault type of the network card by judging the value of the key register group (i.e., the field in the register character segment) based on the pre-stored register standard value database and dynamic threshold calibration mechanism.

[0110] For example, this application embodiment can detect the following fields: Manufacturer ID (0x00-0x03) and Device ID (0x04-0x07). If the register value is 0x00000000 or 0xFFFFFFFF (multiple occurrences of all 0 / all F values ​​in the log), it is determined that the network card hardware is not responding, and the corresponding fault is poor contact of the PCI slot, network card damage, or failure of PCIe link initialization of the server motherboard. If the Manufacturer ID / Device ID does not match the pre-stored list of server-compatible network cards (e.g., the server requires a 400G network card, but a 10 Gigabit network card ID is recognized), it is determined that the network card model is incompatible, and the fault type is determined to be a network card recognition fault type.

[0111] This application embodiment can detect the following fields: command register (0x0C-0x0F), BAR memory address register (0x10-0x17), and PCIe link width register (e.g., 0x000430cc). If the command register is not set to 0x07 (i.e., bit0 / bit1 / bit2 are not simultaneously 1), it is determined that the resource is not enabled. At this time, the network card cannot occupy I / O and memory resources, and cannot support TB (Terabyte) level data transmission, directly causing GPU data supply interruption, and the fault type is determined to be a resource allocation fault type.

[0112] This application embodiment can detect the following fields: status register (0x08-0x0B), error statistics register (e.g., 0x00040780), and link negotiation register (0x0004080c). If bit5 of the status register is 0 (link not established) or bit4 is 0 (no interruption response), it is determined that the link is disconnected; if the error statistics register (e.g., CRC error, frame loss count) is greater than 0, it is determined that there is a transmission error, and the fault type is determined to be a link transmission abnormality fault type.

[0113] This application embodiment can detect the following fields: network card chip temperature (e.g., 0x000427ec) and power consumption register (e.g., 0x00049204). If the temperature register value exceeds a threshold (e.g., chip core temperature greater than 85°C), it is determined to be a high temperature warning, and the fault type is high temperature fault. If the power consumption register value fluctuates abnormally (e.g., fluctuation range greater than 20% in a short period of time), it is determined to be unstable power consumption, and the fault type is load fault. This application embodiment can also define the high temperature fault type and the load fault type as latent fault types.

[0114] The embodiments of this application can determine whether the fault can be resolved by itself. If it can be resolved by itself, for example, under high temperature fault, the fan control module of the baseboard management controller can be linked to accelerate heat dissipation and prevent the bandwidth from dropping from 400G to 100G due to overheating. In the case of load fault, a load reduction strategy can be triggered.

[0115] Step S304: Combining the fault handling strategies of the operation and maintenance platform and the network card manufacturer. For faults that cannot be resolved independently, this embodiment of the application can compress the collected debugging information. The compressed file size is approximately 30%-50% of the original file size. The compressed debugging information is transmitted to the operation and maintenance platform via a TLS (Transport Layer Security) encrypted channel to ensure data transmission security. After receiving the debugging information, the operation and maintenance platform automatically encapsulates it into a standard JSON (JavaScript Object Notation) format, including key fields such as device model, fault type, register status, and log file. The operation and maintenance platform automatically pushes the fault ticket to the manufacturer's collaboration platform via an HTTPS (Hypertext Transfer Protocol Secure) encrypted channel.

[0116] The operations and maintenance platform can receive repair solutions from manufacturers, including firmware upgrade packages or configuration parameter adjustment instructions.

[0117] For example, the vendor collaboration mechanism includes: vendor technicians receiving fault tickets; vendors analyzing debugging data and generating diagnostic reports and repair solutions, including firmware upgrade packages, driver patches, and configuration parameter adjustment suggestions; the repair solutions being digitally signed with the vendor's private key; and the vendor returning the repair solutions to the operations and maintenance platform via an HTTPS encrypted channel.

[0118] The baseboard management controller executes the repair scheme to complete the network interface card (NIC) fault repair. The baseboard management controller uses a pre-set public key to verify the digital signature of the repair scheme, ensuring its integrity and authenticity. The baseboard management controller then performs a firmware upgrade or configuration parameter update. The firmware upgrade process may include: the baseboard management controller receiving the firmware upgrade package, verifying the digital signature and version number of the firmware upgrade package, backing up the current firmware version, performing the firmware upgrade, verifying the upgrade result, and automatically rolling back to the backup version if the upgrade fails. The configuration parameter update process may include: the baseboard management controller receiving a configuration parameter adjustment command, verifying the legality of the configuration parameters, backing up the current configuration parameters, performing the configuration parameter update, verifying the update result, and automatically rolling back to the backup configuration if the update fails.

[0119] Through this series of automated methods, the embodiments of this application can achieve problem-solving with zero human intervention on-site.

[0120] In summary, the embodiments of this application can reduce labor costs and achieve end-to-end automation through automated debugging information collection and fault diagnosis. Based on fine-grained analysis of the PCI configuration space registers and combined with a dynamic threshold calibration mechanism, these embodiments can identify various network card faults, covering both explicit and implicit faults, thus improving the accuracy of fault diagnosis. Furthermore, through manufacturer collaboration mechanisms and remote firmware upgrade functionality, these embodiments can automate the entire fault process from location to repair, shortening the fault repair cycle. These embodiments are not only applicable to network card fault analysis but can also be extended to the fault diagnosis of other components (such as GPUs, memory, power supplies, etc.), providing necessary data support for the overall operational stability of the server.

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

[0122] like Figure 4 As shown, embodiments of this application also provide a network card fault detection device 10, comprising: Specifically, the first determining module 100 is used to determine the detection mode of the target network card in response to the network card detection command.

[0123] The first acquisition module 200 is used to call the interface protocol between the target network card and the baseboard management controller to acquire debugging information corresponding to the detection mode.

[0124] The first detection module 300 is used to determine at least one register character segment reflecting the abnormal state of the target network card based on the debugging information, and to identify the fault type when the target network card fails, or to predict the possible fault type of the target network card based on the at least one register character segment.

[0125] Optionally, in one embodiment of this application, the network card fault detection device 10 further includes: The second detection module is used to detect the current operating stage of the server.

[0126] The second determining module is used to determine the startup duration of multiple components in the server when the current running phase is detected to be either the startup phase or the reset phase.

[0127] The first generation module is used to generate the first network card detection command based on the startup duration, which serves as the network card detection command; The receiving module is used to receive detection requests sent by users.

[0128] The matching module is used to determine the network card identifier based on the detection request and to match the target network card based on the network card identifier.

[0129] The second generation module is used to generate a second network card detection command based on the target network card, which serves as the network card detection command.

[0130] Optionally, in one embodiment of this application, the network card fault detection device 10 further includes: The second acquisition module is used to collect the current operating data of multiple network cards of the server at preset intervals.

[0131] The storage module is used to associate the current running data with the network card identifiers of multiple network cards to generate corresponding mapping relationships, and to store the mapping relationships, the current running data and the network card identifiers in a preset shared memory.

[0132] The extraction module is used to extract historical operating data corresponding to multiple network cards from a preset shared memory based on the mapping relationship.

[0133] The third determination module is used to combine historical and current operating data to determine abnormal operating data that meets preset abnormal conditions, and to combine the abnormal operating data, mapping relationship and network card identifier to determine at least one target network card among all network cards.

[0134] The third generation module is used to generate a third network card detection command using the target network card and abnormal operation data, which serves as the network card detection command.

[0135] Optionally, in one embodiment of this application, the first determining module 100 includes: The first determining unit is used to determine the detection mode as full detection mode in response to the first network card detection command.

[0136] The second determining unit is used to determine the detection mode as a request detection mode in response to the second network card detection command.

[0137] The third determining unit is used to determine the detection mode as fault detection mode in response to the third network card detection command.

[0138] Optionally, in one embodiment of this application, the first acquisition module 200 includes: The first acquisition unit is used to retrieve the full debugging information of the target network card when the detection mode is full detection mode.

[0139] The second acquisition unit is used to parse the second network card detection command in the case of the detection mode being request detection mode, so as to call the first part of debugging information associated with the second network card detection command.

[0140] The third acquisition unit is used to call the second part of debugging information associated with abnormal operation data when the detection mode is fault detection mode.

[0141] Optionally, in one embodiment of this application, the third determining module includes: The first extraction unit is used to extract the historical status flag bits of the link status registers corresponding to multiple network cards from the historical operation data.

[0142] The second extraction unit is used to extract the current status flag bits of the link status registers corresponding to multiple network cards from the current running data.

[0143] The fourth determining unit is used to compare the historical status flag bit and the current status flag bit to determine the abnormal status flag bit where the historical status flag bit and the current status flag bit are inconsistent, and to determine the abnormal operation data based on the abnormal status flag bit.

[0144] Optionally, in one embodiment of this application, the third determining module includes: The fifth determining unit is used to combine historical and current operating data to sort the number of parallel transmission channels and the data transmission speed of multiple network cards according to the acquisition time sequence, and determine the changing trend of the number of channels and the data transmission speed.

[0145] The sixth determining unit is used to determine abnormal operating data based on the number of channels and the data transmission speed when the trend of change in the number of channels is downward or the trend of change in the data transmission speed is a preset fluctuation trend.

[0146] Optionally, in one embodiment of this application, the third determining module includes: The filtering unit is used to combine historical and current operating data to calculate the power consumption fluctuations of multiple network cards and filter out abnormal power consumption fluctuations that exceed a preset fluctuation threshold.

[0147] The seventh determining unit is used to determine abnormal operating data based on abnormal power consumption fluctuations.

[0148] Optionally, in one embodiment of this application, the third determining module includes: The first computing unit is used to combine historical and current operating data to calculate the computing power utilization of the graphics processors corresponding to multiple network cards, and to filter out abnormal computing power utilization rates that are greater than a preset utilization threshold.

[0149] The eighth determination unit is used to determine abnormal operation data based on abnormal computing power utilization.

[0150] Optionally, in one embodiment of this application, the first acquisition module 200 includes: The cumulative unit is used to accumulate the time for collecting debugging information.

[0151] The alarm unit is used to terminate the acquisition and debugging information and generate a data acquisition abnormality alarm signal when the acquisition time exceeds a preset time threshold.

[0152] Optionally, in one embodiment of this application, the first detection module 300 includes: The acquisition unit is used to acquire the server's pre-stored compatibility list and the target network card's pre-stored identification characters.

[0153] The ninth determining unit is used to determine the identification character of the target network card based on at least one register character field.

[0154] The first detection unit is used to determine the fault type as a network card identification fault type when the pre-stored identification characters are inconsistent or the identification characters do not match the pre-stored compatibility list.

[0155] Optionally, in one embodiment of this application, the first detection module 300 includes: The tenth determining unit is used to determine the command character, memory space base address character, and link width character of the target network card based on at least one register character segment.

[0156] The eleventh determination unit is used to determine the enable status of the target network card based on command characters.

[0157] The twelfth determining unit is used to determine the address status of the target network card by combining the memory space base address character and the memory space base address character threshold determined by the network card type of the target network card.

[0158] The thirteenth determining unit is used to determine the speed reduction state of the target network card by combining the link width character and the expected link configuration of the target network card.

[0159] The second detection unit is used to determine the fault type as a resource allocation fault type when the enabled state is disabled, the address state is an address abnormal state, or the speed reduction state is a speed reduction abnormal state.

[0160] Optionally, in one embodiment of this application, the first detection module 300 includes: The fourteenth determining unit is used to determine the status characters and error statistics characters of the target network card based on at least one register character segment.

[0161] The fifteenth determining unit is used to determine that the target network card is in a link connection state based on the link establishment flag and interruption response flag of the status character, and to determine the link connection state as a link disconnected state if the link establishment flag is not established or the interruption response flag is not responded.

[0162] The sixteenth determining unit is used to determine the transmission status of the target network card based on the error statistics characters, and to determine the transmission status as an abnormal transmission status if the error statistics characters are greater than the pre-designed value.

[0163] The third detection unit is used to determine the fault type as a link transmission abnormality fault type when the target network card is in a link disconnected state or a transmission abnormal state.

[0164] Optionally, in one embodiment of this application, the first detection module 300 includes: The seventeenth determining unit is used to determine the chip temperature character of the target network card based on at least one register character segment.

[0165] The eighteenth determining unit is used to determine the actual temperature of the target network card based on the chip temperature character, and to determine the fault type as a high temperature fault type if the actual temperature is greater than the preset temperature threshold.

[0166] The nineteenth determining unit is used to determine the power consumption character of the target network card based on at least one register character field.

[0167] The second calculation unit is used to obtain the actual power consumption of the target network card based on the power consumption character, and to calculate the power consumption fluctuation range of the target network card within a preset time interval.

[0168] The fourth detection unit is used to determine the fault type as a load fault type when the power consumption fluctuation amplitude is greater than a preset amplitude threshold.

[0169] For a description of the features in the embodiment of the network card fault detection device, please refer to the relevant description of the embodiment of the network card fault detection method, which will not be repeated here.

[0170] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the network card fault detection method embodiments described above.

[0171] Embodiments of this application 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 network card fault detection method embodiments described above when running.

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

[0173] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the network card fault detection method embodiments described above.

[0174] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the network card fault detection method embodiments described above.

[0175] 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 implementation should not be considered beyond the scope of this application.

[0176] The above provides a detailed description of a network card fault detection method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for detecting network card faults, characterized in that, Includes the following steps: In response to the network card detection command, determine the detection mode of the target network card; The interface protocol between the target network card and the baseboard management controller is invoked to collect debugging information corresponding to the detection mode; Based on the debugging information, at least one register character segment reflecting the abnormal state of the target network card is determined, and based on the at least one register character segment, the fault type when the target network card fails is identified, or the possible fault type of the target network card is predicted. The method further includes, before determining the detection mode of the target network card in response to the network card detection command, the following steps: detecting the current operating phase of the server; if the current operating phase is detected to be a startup phase or a reset phase, determining the startup duration of multiple components in the server; generating a first network card detection command based on the startup duration; receiving a detection request sent by the user; determining the network card identifier according to the detection request, and matching the target network card according to the network card identifier; and generating a second network card detection command based on the target network card. The method further includes, before determining the network card detection mode in response to the network card detection command, the following steps: collecting current operating data of multiple network cards of the server at preset intervals; associating the current operating data with the network card identifiers of the multiple network cards to generate corresponding mapping relationships, and storing the mapping relationships, the current operating data, and the network card identifiers in a preset shared memory; extracting historical operating data corresponding to the multiple network cards from the preset shared memory based on the mapping relationships; determining abnormal operating data that meets preset abnormal conditions by combining the historical operating data and the current operating data, and determining at least one target network card among all network cards by combining the abnormal operating data, the mapping relationships, and the network card identifiers; and generating a third network card detection command using the target network card and the abnormal operating data as the network card detection command. Specifically, in response to a network interface card (NIC) detection command, determining the detection mode of the target NIC includes: in response to the first NIC detection command, determining the detection mode as a full detection mode; in response to the second NIC detection command, determining the detection mode as a request detection mode; and in response to the third NIC detection command, determining the detection mode as a fault detection mode.

2. The network card fault detection method according to claim 1, characterized in that, The collected debugging information corresponding to the detection mode includes: When the detection mode is the full detection mode, the full debugging information of the target network card is invoked; When the detection mode is the request detection mode, the second network card detection command is parsed to call the first part of debugging information associated with the second network card detection command; When the detection mode is the fault detection mode, the second part of the debugging information associated with the abnormal operation data is invoked.

3. The network card fault detection method according to claim 1, characterized in that, The step of combining the historical operating data and the current operating data to determine abnormal operating data that meets preset abnormal conditions includes: Extract the historical status flag bits of the link status registers corresponding to the network cards from the historical operation data; Extract the current status flag bits of the link status registers corresponding to the network cards from the current running data; The historical status flag and the current status flag are compared to determine the abnormal status flag where the historical status flag and the current status flag are inconsistent, and the abnormal operation data is determined based on the abnormal status flag.

4. The network card fault detection method according to claim 1, characterized in that, The step of combining the historical operating data and the current operating data to determine abnormal operating data that meets preset abnormal conditions includes: By combining the historical operating data and the current operating data, the number of parallel transmission channels and the data transmission speed of the channels corresponding to multiple network cards are sorted according to the acquisition time sequence to determine the changing trend of the number of channels and the data transmission speed; If the trend of the number of channels is downward, or the trend of the data transmission speed is a preset fluctuation trend, the abnormal operation data is determined based on the number of channels and the data transmission speed.

5. The network card fault detection method according to claim 1, characterized in that, The step of combining the historical operating data and the current operating data to determine abnormal operating data that meets preset abnormal conditions includes: By combining the historical operating data and the current operating data, the power consumption fluctuations corresponding to multiple network cards are calculated respectively, and abnormal power consumption fluctuations that exceed a preset fluctuation threshold are filtered out. The abnormal operating data is determined based on the abnormal power consumption fluctuations.

6. The network card fault detection method according to claim 1, characterized in that, The step of combining the historical operating data and the current operating data to determine abnormal operating data that meets preset abnormal conditions includes: Combining the historical operating data and the current operating data, the computing power utilization rate of the graphics processors corresponding to the multiple network cards is calculated respectively, and abnormal computing power utilization rates that are greater than a preset utilization rate threshold are filtered out. The abnormal operation data is determined based on the abnormal computing power utilization rate.

7. The network card fault detection method according to claim 1, characterized in that, The collected debugging information corresponding to the detection mode includes: The total collection time of the debugging information; If the acquisition duration exceeds a preset duration threshold, the acquisition of the debugging information will be terminated, and a data acquisition anomaly alarm signal will be generated.

8. The network card fault detection method according to claim 1, characterized in that, The step of identifying the fault type when the target network card malfunctions based on the at least one register character field includes: Obtain the server's pre-stored compatibility list and the target network card's pre-stored identification characters; Based on the at least one register character segment, determine the identification character of the target network card; If the pre-stored identifier character is inconsistent with the identifier character, or if the identifier character does not match the pre-stored compatibility list, the fault type is determined to be a network card identification fault type.

9. The network card fault detection method according to claim 1, characterized in that, The step of identifying the fault type when the target network card malfunctions based on the at least one register character field includes: Based on the at least one register character segment, determine the command character, memory space base address character, and link width character of the target network interface card; Based on the command characters, determine the enable status of the target network card; The address status of the target network card is determined by combining the memory space base address character and the memory space base address character threshold determined by the network card type of the target network card; By combining the link width character and the desired link configuration of the target network card, the speed reduction state of the target network card is determined; If the enabled state is disabled, the address state is an address anomaly, or the deceleration state is a deceleration anomaly, the fault type is determined to be a resource allocation fault type.

10. The network card fault detection method according to claim 1, characterized in that, The step of identifying the fault type when the target network card malfunctions based on the at least one register character field includes: Based on the at least one register character field, determine the status character and error statistics character of the target network card; Based on the link establishment flag and interruption response flag of the status character, it is determined that the target network card is in a link connection state, and if the link establishment flag is not established or the interruption response flag is not responded, the link connection state is determined to be a link disconnect state. Based on the error statistics characters, the transmission status of the target network card is determined, and if the error statistics characters are greater than the preset value, the transmission status is determined to be an abnormal transmission status. If the target network card is in the state of link disconnection or transmission abnormality, the fault type is determined to be the link transmission abnormality fault type.

11. The network card fault detection method according to claim 1, characterized in that, The step of identifying the fault type when the target network card malfunctions based on the at least one register character field includes: Based on the at least one register character segment, determine the chip temperature character of the target network card; The actual temperature of the target network card is determined based on the chip temperature character, and if the actual temperature is greater than a preset temperature threshold, the fault type is determined to be a high temperature fault type. Based on the at least one register character segment, determine the power consumption character of the target network card; The actual power consumption of the target network card is obtained based on the power consumption character, and the power consumption fluctuation of the target network card within a preset time interval is calculated. If the power consumption fluctuation exceeds a preset threshold, the fault type is determined to be a load fault type.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the network interface card fault detection method as described in any one of claims 1 to 11 when executing the computer program.

Images