Method and device for testing server sensor

Abstract

The invention discloses a server sensor testing method and device, and the method comprises the steps: carrying out the traversal according to an intelligent platform management interface (IPMI) command specification, and determining a sensor name of a to-be-tested sensor in a server system; after executing a preset test operation on the to-be-tested sensor, searching an event log generated by the to-be-tested sensor in response to the test operation in the system event log according to the sensor name; and determining a test result of the to-be-tested sensor according to the event log.

Description

Technical Field

[0001] The present application relates to the technical field of server testing, and in particular to a testing method and device for a server sensor. Background Art

[0002] Server equipment is generally equipped with a baseboard management controller (BMC). BMC can monitor the system's temperature, voltage, fan, power supply and other sensors, and perform corresponding adjustments based on the monitored readings to ensure stable system operation. Therefore, testing the BMC is an important part of ensuring the normal operation of the server.

[0003] When testing the BMC, it is often necessary to perform functional tests on each sensor monitored by the BMC. A testing solution in the related technical field is to load test scripts written based on the names of each sensor on a server and run these test scripts to obtain test results of the corresponding sensors.

[0004] The problem with this test solution is that with the update and iteration of hardware, the name of the sensor often changes. Once the name of a sensor is changed, the test script written based on the previous name cannot be used to test the sensor. Therefore, the applicability of this test solution is poor. Summary of the invention

[0005] To this end, this application discloses the following technical solutions:

[0006] The first aspect of the present application provides a method for testing server sensors. On the one hand, the method can use IPMI command specifications to collect the names of various sensors of the server, so the method can be applicable to various servers that comply with the Intelligent Platform Management Interface (IPMI) specification; on the other hand, the method retrieves and tests the sensors in sequence according to the in-place status, reading status and threshold status of each sensor, and records the retrieved sensors of different categories in different files, so the method has strong compatibility and is compatible with various types of sensors in different servers.

[0007] The method may include:

[0008] According to the IPMI command specification, determine the sensor name to be tested in the server system;

[0009] After performing a preset test operation on the sensor to be tested, searching the system event log for an event log generated by the sensor to be tested in response to the test operation according to the sensor name;

[0010] A test result of the sensor to be tested is determined according to the event log.

[0011] Optionally, the traversing and determining the sensor name of the sensor to be tested in the server system according to the IPMI command specification includes:

[0012] Traverse the status of each sensor in the server system according to the IPMI command specification;

[0013] The sensor whose state meets the target condition is determined as a sensor to be tested, and a sensor name of the sensor to be tested is obtained according to the IPMI command specification, wherein the target condition includes at least one of being in a position state, having a reading state, and having a threshold state.

[0014] Optionally, determining the test result of the sensor to be tested according to the event log includes:

[0015] If the event log is found, determining that the sensor to be tested corresponding to the event log has passed the test;

[0016] If the event log is not found, it is determined that the sensor to be tested corresponding to the event log fails the test.

[0017] Optionally, also include:

[0018] If the event log is found, the event log is stored in an event log file created according to the sensor name;

[0019] If the event log is not found, it is recorded that the sensor to be tested does not generate the event log.

[0020] Optionally, performing a test operation on the sensor to be tested includes:

[0021] Obtaining a threshold type of the sensor to be tested according to the IPMI command specification; the threshold type of the sensor to be tested includes at least one of an upper non-critical threshold (UpperNon-Critical, UNC), an upper critical threshold (Upper Critical, UCR), an upper unrecoverable threshold (UpperNon-Recoverable, UNR), a lower non-critical threshold (LowerNon-Critical, LNC), a lower critical threshold (Lower Critical, LCR), and a lower unrecoverable threshold (LowerNon-Recoverable, LNR);

[0022] Performing a simulated trigger operation on the sensor to be tested by using a simulated trigger function corresponding to the threshold type;

[0023] A simulated release operation is performed on the sensor to be tested.

[0024] Optionally, searching, in a system event log according to the sensor name, for an event log generated by the sensor to be tested in response to the test operation, includes:

[0025] Searching, in the system event log, for a trigger event log generated by the sensor to be tested in response to the simulated trigger operation according to the sensor name;

[0026] The release event log generated by the sensor to be tested in response to the simulated release operation is searched in the system event log according to the sensor name.

[0027] Optionally, performing a simulation trigger operation on the sensor to be tested by using a simulation trigger function corresponding to the threshold type includes:

[0028] Obtaining the initial threshold and current reading of the sensor to be tested;

[0029] determining a simulation threshold value according to the current reading and a threshold trigger condition corresponding to the threshold type;

[0030] The initial threshold of the sensor to be tested is changed to the simulation threshold.

[0031] Optionally, performing a simulated release operation on the sensor to be tested includes:

[0032] The analog threshold of the sensor to be tested is restored to the initial threshold.

[0033] Optionally, searching, in a system event log according to the sensor name, for an event log generated by the sensor to be tested in response to the test operation, includes:

[0034] Calling the search function keyword corresponding to the threshold type;

[0035] According to the search function keyword and the sensor name, the event log generated by the sensor to be tested in response to the test operation is searched in the system event log.

[0036] A second aspect of the present application provides a server sensor testing device, comprising:

[0037] a name determination unit, configured to determine a sensor name of a sensor to be tested in a server system according to an Intelligent Platform Management Interface (IPMI) command specification;

[0038] A search unit, configured to search, after executing a preset test operation on the sensor to be tested, the event log generated by the sensor to be tested in response to the test operation in the system event log according to the sensor name;

[0039] A result determination unit is used to determine the test result of the sensor to be tested according to the event log. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0041] Figure 1 is a flow chart of a server sensor testing method provided in an embodiment of the present application;

[0042] Figure 2 is a flow chart of another server sensor testing method provided in an embodiment of the present application;

[0043] Figure 3 is a flow chart of a method for performing a test operation on a sensor to be tested provided by an embodiment of the present application;

[0044] Figure 4 It is a structural schematic diagram of a server sensor testing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0046] This application embodiment provides a method for testing a server sensor. Figure 1 , the method may include the following steps.

[0047] S101, determining the sensor name of the sensor to be tested in the server system according to the IPMI command specification.

[0048] In step S101, an electronic device (hereinafter referred to as the test device) used to execute the test method of this embodiment can establish a communication connection with the server system to be tested, and then the test device executes the command for reading the sensor name in the IPMI command specification to obtain the sensor name and number of the sensors to be tested in the server system.

[0049] The communication connection between the test device and the server system may be a communication connection established based on the SSH protocol, where the full name of SSH is Secure Shell.

[0050] Optionally, before executing S101, parameters related to the remote communication connection in the server system being tested may be pre-configured, including but not limited to the IP address, user name and login password information of the BMC of the server system, to ensure that the test equipment can establish a communication connection with the server system and operate the sensors monitored by the BMC.

[0051] The sensor to be tested may include every sensor in the server system. In this case, the test device may directly read the name of the sensor in the server system through an IPMI command for reading the sensor name.

[0052] The sensor to be tested may also include a sensor in the server system that meets specific conditions. In this case, step S101 may include:

[0053] Traverse the status of each sensor in the server system based on IPMI commands and regular expressions;

[0054] A sensor whose state meets a target condition is determined as a sensor to be tested, and a sensor name of the sensor to be tested is obtained according to an intelligent platform management interface (IPMI) command specification, wherein the target condition includes at least one of being in a position state, having a reading state, and having a threshold state.

[0055] The test device can execute an IPMI command for detecting the status of a sensor to obtain the status of each sensor in the server system, and then determine that the sensors whose statuses meet the target conditions are sensors to be tested, and execute subsequent steps according to the sensor names of these sensors to be tested.

[0056] As an example, the target condition may include being in a state of being in place, having a reading, and having a threshold. That is, the sensor to be tested may be a sensor that is in place, has a reading, and has a threshold.

[0057] For any sensor in the server system, the sensor can be in an in-place state or an out-of-place state. The in-place state can be a state where the BMC of the server system can monitor the sensor; the out-of-place state can be a state where the BMC cannot monitor the sensor. In this embodiment, the out-of-place state can be represented by disabled.

[0058] The sensor may also be in a state of having a reading or a state of not having a reading. The state of having a reading may be a state in which the BMC can receive the measured value fed back by the sensor, that is, the state of the sensor's reading. The state of not having a reading may be a state in which the BMC cannot receive the reading fed back by the sensor. Exemplarily, for a temperature sensor, if the BMC can receive the temperature reading fed back by the sensor, such as 40 degrees Celsius or 45 degrees Celsius, the sensor is in a state of having a reading. If the BMC cannot receive the temperature reading fed back by the sensor, the sensor is in a state of not having a reading. In this embodiment, the state of not having a reading may be represented by no reading.

[0059] Sensors can also be divided into threshold sensors and non-threshold sensors. Threshold sensors are sensors that have been configured with thresholds corresponding to the readings, while non-threshold sensors are sensors that have not been configured with corresponding thresholds. When a sensor is a threshold sensor, if the reading of the sensor is greater than or less than the corresponding threshold, the BMC will record the event corresponding to the sensor to indicate that the current reading is greater than or less than the corresponding threshold. When a sensor is a non-threshold sensor, the BMC will not record the event that the sensor reading is greater than or less than the corresponding threshold. In this embodiment, the non-threshold sensor can be represented by no_thr.

[0060] The advantage of screening the sensors to be tested according to the target conditions is that sensors that do not meet the target conditions generally cannot obtain test results through the method of this embodiment. Screening based on the target conditions can avoid testing these sensors in subsequent steps to improve test efficiency.

[0061] S102, after performing a preset test operation on the sensor to be tested, searching the system event log for an event log generated by the sensor to be tested in response to the test operation according to the sensor name.

[0062] The test operation in step S102 includes an operation capable of triggering the BMC to record a sensor-specific event.

[0063] For example, the simulated threshold trigger test operation is to modify the threshold of the sensor to be tested to be lower than the reading. For this operation, the BMC will record the corresponding threshold type trigger event log; the simulated threshold release test operation is to modify the threshold of the sensor to be tested to the original threshold. For this operation, the BMC will record the corresponding threshold type release event log.

[0064] Generally, after a sensor outputs an event, the BMC will record the event in the BMC's system event log in the form of an event log, which includes the name of the sensor that outputs the event. Therefore, in S102, the test device can search the system event log for a log containing the name of the sensor to be tested and the corresponding threshold event after performing a test operation on the sensor to be tested, thereby determining whether the sensor to be tested can output a corresponding event in response to the previously performed test operation.

[0065] S103: Determine the test result of the sensor to be tested according to the event log.

[0066] In step S103, the testing device may determine the test result of the sensor to be tested according to whether the event log corresponding to the sensor to be tested is found.

[0067] For any sensor to be tested, if after performing a test operation on it, no log containing the name of the sensor to be tested and the corresponding threshold event is found in the system event log, it means that the sensor to be tested did not respond to the test operation and output the corresponding event, and the sensor to be tested has an abnormality. Therefore, it can be determined that the test of the sensor to be tested corresponding to the event log has failed.

[0068] For any sensor to be tested, if after performing a test operation on it, no log containing the name of the sensor to be tested and the corresponding threshold event is found in the system event log, it means that the sensor to be tested outputs the corresponding event in response to the test operation, and the sensor to be tested can work normally. Therefore, it can be determined that the test of the sensor to be tested corresponding to the event log has passed.

[0069] As an example, assume that the sensor name of a sensor to be tested is CPU0_Temp, and the sensor is used to monitor the temperature of processor 0 (CPU0), and is used to output a corresponding event when the temperature of CPU0 is higher than a certain threshold.

[0070] After performing the simulated UNC threshold trigger test operation on CPU0_Temp in S102, if no event log containing CPU0_Temp and Upper Non-critical going high|Asserted is found in the system event log, it means that CPU0_Temp cannot output the corresponding event when the temperature of CPU0 is too high, CPU0_Temp is abnormal, and the test fails; if an event log containing CPU0_Temp and Upper Non-critical going high|Asserted is found in the system event log, it means that CPU0_Temp can output the corresponding event when the temperature of CPU0 is too high, CPU0_Temp works normally, and the test passes.

[0071] After performing the simulated UNC threshold release test operation on CPU0_Temp in S102, if no event log containing CPU0_Temp and Upper Non-critical going high|Deasserted is found in the system event log, it means that CPU0_Temp cannot output the corresponding event when the temperature of CPU0 is too high, CPU0_Temp is abnormal, and the test fails; if an event log containing CPU0_Temp and Upper Non-critical going high|Deasserted is found in the system event log, it means that CPU0_Temp can output the corresponding event when the temperature of CPU0 is too high, CPU0_Temp works normally, and the test passes.

[0072] Optionally, in order to facilitate viewing of the test results of all sensors in the server, after the test results of the sensors to be tested are determined in S103, the following steps may be performed to record the corresponding test results:

[0073] If an event log is found, the event log is stored in an event log file created according to the sensor name;

[0074] If no event log is found, the information of the relevant sensor is recorded in a file in which no event log is generated for the sensor to be tested.

[0075] For the sensor under test for which the corresponding event log can be found, the test device will create an event log file named after the sensor under test, and then record the corresponding event log of the sensor under test in the event log file.

[0076] Exemplarily, for the sensor CPU0_Temp to be tested, the test device will create an event log file named CPU0_Temp.txt. If the event log of CPU0_Temp can be found after executing the test operation in S102, the test device will record the event log of CPU0_Temp in CPU0_Temp.txt.

[0077] The test device may create an event log file named after a sensor to be tested has passed the test. If a sensor to be tested has not passed the test, the test device may not create an event log file named after the sensor to be tested.

[0078] For the sensors under test for which no event log is found, the test device may record the information by creating a file for recording the failure of the test. If a sensor under test fails to find the corresponding event log after performing the test operation, the corresponding information of the sensor under test may be recorded in this file.

[0079] Exemplarily, the test device can create a file named sel_no_record_sensor.txt. If the UNC threshold trigger release test of the sensor CPU0_Temp to be tested fails, the test device records in this file "UNC threshold trigger release operation was performed on CPU0_Temp, and BMC did not record the corresponding event log". In this way, it is indicated that the event log of CPU0_Temp could not be found after executing the test operation, and the CPU0_Temp test failed.

[0080] Optionally, in order to avoid missing the event log of the sensor to be tested during the search and obtaining an erroneous test result, the corresponding event log can be repeatedly queried N times in the system event log in S102, with an interval of 60 seconds between each query. As long as the event log of the sensor to be tested is found at any time, it can be determined that the test of the sensor to be tested has passed. If the event log of the sensor to be tested is not found after N searches, it can be determined that the test of the sensor to be tested has failed. N can be a preset positive integer, and its value can be set as needed without limitation. As an example, N can be set to 3.

[0081] The beneficial effects of this embodiment are:

[0082] When testing, this embodiment can obtain the sensor name of each sensor to be tested in the server system through IPMI commands without relying on specific names written in the script. Therefore, the method of this embodiment will not be affected by changes in the sensor names in the server, and can test any sensor of a server that complies with the IPMI command specification, and has a wide range of applications.

[0083] In addition, during testing, the method of this embodiment can automatically collect test results and record the test results in corresponding files. The test process does not require the attention of relevant personnel. Therefore, this method can effectively improve test efficiency and shorten test time. For example, when performing actual testing on the server, it only takes about 90 minutes to complete the test of more than 300 sensors.

[0084] Moreover, the method retrieves and tests the sensors in sequence according to the in-place status, reading status and threshold status of each sensor, and records the retrieved sensors of different categories in different files. Therefore, the method has strong compatibility and can be compatible with various types of sensors in different servers.

[0085] In the test method provided in this embodiment, the test device can traverse each sensor to be tested in the server system in a loop. That is, the test device can first determine the sensor name of a sensor to be tested, execute S102 and S103 based on the sensor name to obtain the test result of the sensor to be tested, and then determine the sensor name of the next sensor to be tested, execute S102 and S103 to obtain the test result of the next sensor to be tested, and so on, until each sensor to be tested in the server system is traversed.

[0086] When testing in the above manner, the testing method of this embodiment may include: Figure 2 Steps shown.

[0087] S201, reading the sensor name of each sensor in the server system that is in a position state, and recording the information of the sensors that are not in a position state.

[0088] The sensor is not in the in-position state, which is equivalent to the sensor being in the unavailable state.

[0089] The test device can first execute the IPMI command for detecting the status of the sensor, filter out the sensors in the server system that are in place and the sensors that are unavailable, and then execute the IPMI command for reading the sensor name for the sensors in place to obtain their sensor names, and record the information of the sensors in the unavailable state in the corresponding files.

[0090] The test device can execute the ipmitool sdr elist|grep-i disabled command in the server system to filter out the sensors ${disabled_sensor} that are not in place in the server. The test device can also execute the ipmitool sdr elist|grep-v disabled command in the server system to filter out the sensors ${now_sensor} that are in place.

[0091] Then the test device can execute the echo'${now_sensor}'|wc -l command on the server system to obtain the number of sensors in place ${sdr_len}, and execute the echo'${now_sensor}'|awk'{print$1}' command to obtain the names of all sensors in place ${sensor_name_info}.

[0092] As an example, information about sensors in an unavailable state may be recorded in a file named disabled_sensor.txt. The file may record information as shown in Table 1.

[0093] Table 1

[0094] CPS_Temp 09h N 10.0 Disabled OCP_Temp 12h N 10.0 Disabled CPS_Opt_Temp 13h N 10.0 Disabled

[0095] The first column of Table 1 may be the names of sensors in an unavailable state, and the last column of Table 1 may indicate that these sensors are in an unavailable state (Disabled).

[0096] The file recording the information of the sensor in the unavailable state may be created by the test device before S201 .

[0097] S202, obtaining a sensor name of an untested in-position sensor.

[0098] In S202, the range 1 to RANK traversed by the FOR loop is determined, where RANK is the number of sensors actually in place plus 1. Multiple sensors in place can be arranged in order. When S202 is executed for the first time, the first sensor in place is selected. When S202 is executed again, the second sensor in place is selected, and so on, until the last sensor in place is selected.

[0099] If there are no untested in-place sensors when executing S202, and each in-place sensor has been tested according to the process from step S203 to step S209, then this embodiment ends; if there are still untested in-place sensors when executing S202, execute S203.

[0100] S203, determining whether the currently selected sensor is in a threshold state.

[0101] If the currently selected sensor is in a state with a threshold, step S204 may be executed; if the currently selected sensor is in a state without a threshold, step S2031 may be executed.

[0102] The test device may execute an IPMI command for detecting the state of a sensor to determine whether the sensor is in a threshold state or a non-threshold state.

[0103] In some examples, the test device can execute the ipmitool raw 0x040x27${sensor_number} command to obtain the command response offset ${offset} and return code ${rc} of the currently selected sensor. If the response offset and return code meet the conditions of ${offset}=00 and ${rc}=0, it means that the currently selected sensor is in a threshold state. If the conditions are not met, it means that the currently selected sensor is in a non-threshold state. The sensor_number in the above command can be the identifier of the current sensor.

[0104] S2031, record that the currently selected sensor is in a no-threshold state.

[0105] Recording these sensors in the non-threshold state in step S2031 can more comprehensively collect the conditions of each sensor in the server.

[0106] The recording method may be that the test device creates a file specifically used to record sensors in the no-threshold state, and records the sensor name of the currently selected sensor in the file. Exemplarily, the test device may create a file named no_thr_sensor.txt, and record the name of the sensor in the no-threshold state in the file.

[0107] For example, the no_thr_sensor.txt file may contain the following information:

[0108] "Outlet_Temp has no threshold value and belongs to a discrete sensor or a sensor that does not perform regulation

[0109] PSU0_Temp has no threshold and is a discrete sensor or a sensor that does not perform regulation.

[0110] PSU1_Temp has no threshold and belongs to a discrete sensor or a sensor that is not regulated."

[0111] "Outlet_Temp" and "PSU0_Temp" are the sensor names of the sensors in the no-threshold state recorded each time S2031 is executed. After the test, the tester needs to check whether the information recorded in the no_thr_sensor.txt file is consistent with the actual situation.

[0112] The above-mentioned file for recording may be pre-created by the test device before executing S201, or may be created when S2031 is executed for the first time.

[0113] S204, determining whether the currently selected sensor is in a reading state.

[0114] If the currently selected sensor is in a reading state, step S205 may be executed, and if the currently selected sensor is in a no reading state, step S2041 may be executed.

[0115] The test device may execute an IPMI command for detecting the state of a sensor to determine whether the sensor is in a read-with state or a no-read-with state.

[0116] The test device can execute the ipmitool raw 0x040x2d${sensor_number} command to obtain the command return value of the server system. When the return value is equal to 00, it means that the currently selected sensor is in a reading state. When the return value is not equal to 00, it means that the currently selected sensor is in a no reading state. The sensor_number in the above command can be the identifier of the current sensor.

[0117] S2041, record that the currently selected sensor is in a no-reading state.

[0118] Recording these sensors in the no-reading state in step S2041 can more comprehensively collect the conditions of each sensor in the server.

[0119] The recording method may be that the test device creates a file specifically used to record sensors in a no-reading state, and records the sensor name of the currently selected sensor in the file. Exemplarily, the test device may create a file named no_reading_sensor.txt, and record the name of the sensor in a no-reading state in the file.

[0120] The above-mentioned file for recording may be created in advance by the test device before executing S201, or may be created when S2041 is executed for the first time.

[0121] In this embodiment, steps S201 to S204 are equivalent to step S101 in the above embodiment. The sensors in the in-position state, the threshold state and the reading state after screening in S205 are equivalent to the sensors to be tested in the above embodiment.

[0122] S205, performing a test operation on the currently selected sensor to be tested.

[0123] S206, searching the system event log to see whether there is an event log of the sensor to be tested.

[0124] If there is an event log of the sensor to be tested in the system event log, execute S207; if there is no event log of the sensor to be tested in the system event log, execute S209.

[0125] S207: Create a corresponding event log file according to the sensor name of the currently selected sensor.

[0126] Exemplarily, the currently selected sensor is the CPU0_Temp sensor. In S207 , a file named CPU0_Temp.txt may be created as an event log file corresponding to the sensor.

[0127] Steps S205 and S207 are equivalent to step S102 of the aforementioned embodiment.

[0128] S208, recording the event log of the currently selected sensor to be tested into a corresponding event log file.

[0129] The corresponding event log file may be a file created with the sensor name of the currently selected sensor to be tested, and used to record its event log. In combination with the above example, if the currently selected sensor to be tested is the CPU0_Temp sensor, after finding the event log of the sensor, the event log may be recorded in the CPU0_Temp.txt file in S208.

[0130] As an example, the content recorded in the CPU0_Temp.txt file can be represented by the following Table 2.

[0131] Table 2

[0132]

[0133] The first column of Table 2 indicates the date and event of the event corresponding to the output of the sensor to be tested, the second column of Table 2 indicates the type and name of the sensor to be tested, for example, the type is temperature (Temperature), and the name is CPU0_Temp, the third column of Table 2 can indicate the description of the event, for example, in the above example, "Upper Non-Critical going high" indicates that the output event is that the sensor reading exceeds the upper non-critical threshold (UpperNon-Critical, UNC), the fourth column of Table 2 can indicate whether the corresponding event is a threshold trigger event or a threshold release event, Asserted indicates that the corresponding event belongs to a threshold trigger event, and Deasserted indicates that the corresponding event belongs to a threshold trigger event, the fifth column of Table 2 indicates the specific content of the event, for example, the specific content in the fifth column of the first row is that the current reading (Reading) is 51 degrees Celsius, which is greater than the threshold (Threshold) of 41 degrees Celsius, and the specific content in the fifth column of the second row is that the current reading (Reading) is 51 degrees Celsius, which is greater than the threshold (Threshold) of 91 degrees Celsius.

[0134] Optionally, when there are multiple event log files of the tested sensors that have passed the test, the multiple event log files can be recorded in a file for storing the test results. For example, the file names of these event log files are recorded in the sel_elist.txt file to facilitate finding the event logs generated by the tested sensors during the test.

[0135] S209, recording the information of the currently selected sensor to be tested into a file that fails the test.

[0136] Exemplarily, the test device may record the sensor name of the sensor to be tested into the aforementioned sel_no_record_sensor.txt file.

[0137] Steps S208 and S209 are equivalent to step S103 of the aforementioned embodiment.

[0138] After executing S208 or S209, the process returns to executing S202 until each sensor in the in-position state is tested according to the process from S203 to S209.

[0139] Optional, see Figure 3 For any sensor to be tested, the test equipment can perform the test operation on the sensor to be tested in the following manner:

[0140] S301, obtaining a threshold type of a sensor to be tested according to an IPMI command specification.

[0141] S302 , performing an analog trigger operation on the sensor to be tested by using an analog trigger function corresponding to the threshold type.

[0142] S303, performing a simulated release operation on the sensor to be tested.

[0143] The test operation may include a simulated trigger operation and a simulated release operation.

[0144] In step S301 , the testing device may execute an IPMI command for obtaining a threshold type of the sensor on the sensor to be tested, so as to determine which types of thresholds are configured for the sensor to be tested.

[0145] Exemplarily, the threshold type of the sensor to be tested may include at least one of an upper non-critical (UNC) threshold, an upper critical (UCR) threshold, an upper non-recoverable (UNR) threshold, a lower non-critical (LNC) threshold, a lower critical (LCR) threshold, and a lower non-recoverable (LNR) threshold.

[0146] A sensor to be tested may be configured with one or more types of thresholds as described above. For example, CPU0_Temp may be configured with a UNC threshold, a UCR threshold and a UNR threshold, wherein the UNC threshold is smaller than the UCR threshold, and the UCR threshold is smaller than the UNR threshold.

[0147] In step S302, the testing device may call a simulation trigger function corresponding to the threshold type to perform a simulation trigger operation according to the threshold type of the sensor to be tested.

[0148] In this embodiment, the simulation trigger operation may refer to the following types of operations:

[0149] By adjusting the threshold value configured on the sensor to be tested, the magnitude relationship between the threshold value of the sensor to be tested and the current reading satisfies the threshold trigger condition of the sensor. The threshold trigger condition can be understood as the condition under which the sensor to be tested reports the threshold trigger event corresponding to the threshold value to the BMC.

[0150] For different types of thresholds, the corresponding threshold trigger conditions may be different.

[0151] In combination with the above example, the threshold trigger condition of the UNC threshold may be that the reading is greater than the UNC threshold and less than the UCR threshold and the UNR threshold;

[0152] The threshold trigger condition of the UCR threshold may be that the reading is greater than the UCR threshold and less than the UNR threshold;

[0153] The threshold trigger condition of the UNR threshold may be that the reading is greater than the UNR threshold;

[0154] The threshold trigger condition of the LNC threshold may be that the reading is less than the LNC threshold and greater than the LCR threshold and the LNR threshold;

[0155] The threshold trigger condition of the LCR threshold may be that the reading is less than the LCR threshold and greater than the LNR threshold;

[0156] The threshold trigger condition of the LNR threshold may be that the reading is less than the LNR threshold.

[0157] Optionally, if a sensor to be tested is configured with multiple types of thresholds, a simulated trigger operation may be performed for each type of threshold, so that the sensor to be tested reports a threshold trigger event corresponding to each type of threshold in turn.

[0158] For example, for the CPU0_Temp sensor in the aforementioned example, a simulation trigger operation may be performed for the UNC threshold of the sensor, a simulation trigger operation may be performed for the UCR threshold of the sensor, and a simulation trigger operation may be performed for the UNR threshold of the sensor.

[0159] Still see Figure 3 The process of performing the simulation trigger operation on any threshold type in step S302 may include:

[0160] S3021, obtaining the initial threshold and current reading of the sensor to be tested.

[0161] S3022, determining a simulation threshold value according to a threshold trigger condition corresponding to a current reading and a threshold type.

[0162] S3023, changing the initial threshold of the sensor to be tested to a simulation threshold.

[0163] In S3021, the initial threshold may be the threshold configured for the sensor to be tested before executing step S302.

[0164] In S3022, the simulation trigger function corresponding to the threshold type may be called. For example, if a simulation trigger operation needs to be performed on a UNC threshold, the UNC simulation trigger function assert_unc is called, if a simulation trigger operation needs to be performed on a UCR threshold, the UCR simulation trigger function assert_ucr is called, and if a simulation trigger operation needs to be performed on a UNR threshold, the UNR simulation trigger function assert_unr is called.

[0165] As some examples, the above-mentioned UNC simulation trigger function may include the following computer instructions.

[0166] [Arguments]${reading}${offset}${lnc}${lcr}${lnr}${unc}${ucr}${unr}#Current sensor reading value\#Threshold

[0167] ${result}Convert To Integer${reading}16#Convert hexadecimal to decimal

[0168] log${result}

[0169] ${lnc_set}BuiltIn.Set Variable${lnc}

[0170] ${lcr_set}BuiltIn.Set Variable${lcr}

[0171] ${lnr_set}BuiltIn.Set Variable${lnr}

[0172] Comment simulation trigger unc

[0173] ${unc_set0}evaluate${result}-5

[0174] log${unc_set0}

[0175] ${unc_set}Convert To Hex${unc_set0}

[0176] log${unc_set}

[0177] ${ucr_set}BuiltIn.Set Variable${ucr}

[0178] ${unr_set}BuiltIn.Set Variable${unr}

[0179] ${setted_thr}BuiltIn.Set Variable 0x${offset}0x${lnc_set}0x${lcr_set}0x${lnr_set}0x${unc_set}0x${ucr_set}0x${unr_set}

[0180] [Return]${setted_thr}

[0181] For other simulation trigger functions, please refer to the above UNC simulation trigger function settings, which will not be repeated here.

[0182] Generally, the threshold trigger condition corresponding to the UNC, UCR and UNR thresholds is that the current reading is greater than the corresponding threshold, so the analog trigger functions corresponding to these three types can determine an analog threshold less than the current reading based on the current reading to meet the threshold trigger condition that the reading is greater than the threshold.

[0183] The threshold trigger condition corresponding to the LNC, LCR and LNR thresholds is that the current reading is less than the corresponding threshold, so the analog trigger functions corresponding to these three types can determine an analog threshold greater than the current reading based on the current reading to meet the threshold trigger condition that the reading is less than the threshold.

[0184] In step S3023, the initial threshold originally configured for the sensor to be tested can be replaced with a corresponding type of analog threshold. Since the analog threshold is determined according to the standard that the threshold trigger condition can be met under the current reading, after the initial threshold is replaced with the analog threshold, the current reading of the sensor to be tested will meet the corresponding threshold trigger condition, so the sensor to be tested can report the threshold trigger event to the BMC.

[0185] For example, assuming that the current reading of CPU0_Temp is 45 degrees Celsius, and the initial UNR threshold of CPU0_Temp is 90 degrees Celsius, the reading is less than the UNR threshold, and CPU0_Temp does not report the threshold trigger event of the UNR threshold. By executing S3022, a UNR simulation threshold that is less than the current reading is determined, for example, the UNR simulation threshold is 40 degrees Celsius, and then in S3033, the UNR threshold of CPU0_Temp is changed from the initial 90 degrees Celsius to 40 degrees Celsius. After the change, the threshold trigger condition that the reading is greater than the UNR threshold is met, so CPU0_Temp reports the threshold trigger event of the UNR threshold.

[0186] Optionally, the analog trigger function may determine one or more analog thresholds of different threshold types as needed to ensure that after the sensor to be tested is configured according to the analog thresholds, the configured thresholds have an appropriate size relationship.

[0187] For example, if the analog trigger operation is performed for the UNR threshold, then in S3022, a UNR analog threshold slightly smaller than the current reading may be determined, then a UCR analog threshold smaller than the UNR analog threshold may be determined, and then a UNC analog threshold smaller than the UCR analog threshold may be determined.

[0188] In S3023, the test device may execute an IPMI command for configuring a sensor threshold, and configure the threshold of the sensor to be tested as a simulated threshold.

[0189] The following is an example to illustrate the process of performing the analog trigger operation for a certain threshold type of the sensor to be tested in step S302:

[0190] Assume that you need to perform a simulated trigger operation on the UNR type threshold of the CPU0_Temp sensor. First, you get the current reading of the CPU0_Temp sensor as 45 degrees Celsius, the initial UNC threshold as 70 degrees Celsius, the initial UCR threshold as 80 degrees Celsius, and the initial UNR threshold as 90 degrees Celsius.

[0191] Call the UNR simulation trigger function and input the above parameters into the UNR simulation trigger function. The simulation trigger function is based on the threshold trigger condition that the reading is greater than the threshold. The current reading minus 5 degrees Celsius is used as the UNR simulation threshold. In order to satisfy the size relationship between UNC, UCR and UNR, the current reading minus 10 degrees Celsius is used as the UCR simulation threshold, and the current reading minus 15 degrees Celsius is used as the UNC simulation threshold. The UNR simulation threshold is 40 degrees Celsius, the UCR simulation threshold is 35 degrees Celsius, and the UNC simulation threshold is 30 degrees Celsius.

[0192] Before determining the analog threshold in the above manner, if the sensor provides a hexadecimal reading, the UNR analog trigger function can convert the hexadecimal reading provided by the sensor into decimal before executing the subsequent steps;

[0193] Finally, the UNR simulation trigger function outputs the above simulation threshold, which can be represented by ${out6}. The test device executes the IPMI command for configuring the sensor threshold, and changes the UNR threshold of the CPU0_Temp sensor from 90 degrees Celsius to 40 degrees Celsius, the UCR threshold from 80 degrees Celsius to 35 degrees Celsius, and the UNC threshold from 70 degrees Celsius to 30 degrees Celsius. The test device can execute the ipmitool raw 0x040x26${sensor_number}${out6} command to configure the sensor threshold.

[0194] At this point, the simulation trigger operation for the UNR threshold of the CPU0_Temp sensor is completed.

[0195] Optionally, when performing an analog trigger operation on the UCR threshold of the CPU0_Temp sensor, a UCR analog threshold and a UNC analog threshold that are less than the current reading can be determined, and a UNR analog threshold that is greater than the current reading can be determined to ensure that after the initial threshold is changed to the analog threshold, the current reading is greater than the UCR threshold and less than the UNR threshold to meet the threshold trigger condition of the UCR threshold.

[0196] When performing an analog trigger operation on the UNC threshold of the CPU0_Temp sensor, you can determine a UNC analog threshold that is less than the current reading, and determine UNR and UCR analog thresholds that are greater than the current reading, ensuring that after changing the initial threshold to the analog threshold, the current reading is greater than the UNC threshold and less than the UCR threshold and the UNR threshold to meet the threshold trigger condition of the UNC threshold.

[0197] In step S303, the simulation release operation may refer to the following types of operations:

[0198] After the analog trigger operation is performed, the threshold configured on the sensor to be tested is adjusted so that the magnitude relationship between the threshold of the sensor to be tested and the current reading is restored to a state where the threshold trigger condition of the sensor is not satisfied.

[0199] In this embodiment, the simulation release operation may be performed by restoring the simulation threshold of the sensor to be tested to the initial threshold, that is, canceling the change of the threshold of the sensor to be tested in step S302 and restoring it to the value before executing S302.

[0200] In combination with the above example, after performing a simulated trigger operation on the UNR threshold of the CPU0_Temp sensor, the simulated release operation performed on the CPU0_Temp sensor may include:

[0201] Restore the UNR threshold of the CPU0_Temp sensor to 90 degrees Celsius, the UCR threshold to 80 degrees Celsius, and the UNC threshold to 70 degrees Celsius.

[0202] By performing a simulated release operation on the sensor to be tested, the sensor to be tested can report a threshold release event to the BMC.

[0203] Optionally, the test device may perform the step of searching the event log in S102 after performing the simulated trigger operation and the simulated release operation, or may divide the search for the event log into the following two steps:

[0204] Searching the system event log for the trigger event log generated by the sensor to be tested responding to the simulated trigger operation according to the sensor name and the corresponding threshold event log;

[0205] According to the sensor name and the log of the corresponding threshold event, the system event log is searched for the release event log generated by the sensor to be tested in response to the simulated release operation.

[0206] Correspondingly, the test equipment can search for the trigger event log of the sensor to be tested after executing the simulated trigger operation, and continue to search for the release event log of the sensor to be tested after executing the simulated release operation. If the trigger event log and release event log of each type of threshold value of the sensor to be tested can be found, it can be considered that the corresponding sensor to be tested has passed the test; if at least one of the logs cannot be found in the system event log, it can be considered that the sensor to be tested has failed the test.

[0207] The trigger event log can be understood as a log in the system event log that is used to record threshold trigger events reported by sensors; the release event log can be understood as a log in the system event log that is used to record threshold release events reported by sensors.

[0208] As an example, the content of the first row of Table 2 can be regarded as the trigger event log corresponding to the event obtained by searching the system event log after the CPU0_Temp sensor reports the threshold trigger event of the UNC threshold. The content of the second row of Table 2 can be regarded as the release event log corresponding to the event obtained by searching the system event log after the CPU0_Temp sensor reports the threshold release event of the UNC threshold.

[0209] If simulated trigger operations and simulated release operations are performed on the UNC threshold, UCR threshold and UNR threshold of the CPU0_Temp sensor respectively, and the trigger event log and release event log corresponding to the UNC threshold, the trigger event log and release event log corresponding to the UCR threshold, and the trigger event log and release event log corresponding to the UNR threshold can be found in the system event log, then the CPU0_Temp sensor test can be considered to have passed. If at least one of the logs cannot be found, then the CPU0_Temp sensor test can be considered to have failed.

[0210] The search for the trigger event log and the release event log may also be performed N times respectively to improve accuracy. That is, only when the trigger event log is not found after repeated searches N times, it is determined that there is no trigger event log, and only when the release event log is not found after repeated searches N times, it is determined that there is no release event log.

[0211] In any embodiment, the test device may search the event log in the following manner:

[0212] Call the search function keyword corresponding to the threshold type;

[0213] According to the search function keyword and the sensor name and the log of the corresponding threshold event, the event log generated by the sensor to be tested responding to the test operation is searched in the system event log.

[0214] As can be seen from the example in Table 2, the trigger event log generated by the sensor under test in response to the simulated trigger operation and the release event log generated in response to the simulated release operation both record the event corresponding threshold type. For example, in Table 2, the CPU0_Temp sensor reports the threshold trigger event of the UNC threshold in response to the simulated trigger operation performed on the UNC threshold. The corresponding trigger event log shown in the first row of Table 2 can be found, in which the third column records the event corresponding threshold type, that is, the threshold trigger event is triggered by the reading being greater than the UNC threshold. Similarly, the release event log shown in the second row of Table 2, in which the third column also records the event corresponding threshold type, that is, the threshold release event is triggered by the reading being less than the UNC threshold.

[0215] Based on the characteristics of the above event logs, several search function keywords corresponding to the threshold types can be pre-set in the test equipment, and each search function keyword is used to search for the trigger event log and release event log related to the corresponding threshold type. For example, the search trigger function keyword for_unc_assert corresponding to the UNC threshold can search for the trigger event log containing "Upper Non-critical going high|Asserted" in the system event log; the search release function keyword for_unc_deassert corresponding to the UNC threshold can search for the release event log containing "Upper Non-critical going high|Deasserted" in the system event log.

[0216] Therefore, after performing a simulated trigger operation on a certain threshold type of any sensor to be tested, the test equipment can call the search function keyword corresponding to the threshold type, and provide the sensor name of the sensor to be tested to the search function keyword. The search function keyword can then search for the trigger event log containing the specified sensor name and corresponding to the threshold type in the system event log. After performing a simulated release operation on the threshold type of the sensor to be tested, the search function keyword corresponding to the threshold type can be called to search for the release event log containing the specified sensor name and corresponding to the threshold type.

[0217] In combination with the above example, after performing a simulated trigger operation on the UNC threshold of CPU0_Temp, the search function keyword corresponding to the UNC threshold can be called, CPU0_Temp is input into the search function keyword, and then the search function keyword searches for a trigger event log containing "UpperNon-critical going high|Asserted" and "CPU0_Temp" in the system event log. After performing a simulated release operation on the UNC threshold of CPU0_Temp, the search function keyword corresponding to the UNC threshold is also called to search for a release event log containing "Upper Non-critical going high|Deasserted" and "CPU0_Temp" in the system event log.

[0218] The present application also provides a sensor testing device, see Figure 4 , the device may include the following units.

[0219] A name determination unit 401, configured to determine the sensor name of the sensor to be tested in the server system according to the IPMI command specification;

[0220] A search unit 402 is used to search the system event log for an event log generated by the sensor under test in response to the test operation according to the sensor name after the sensor under test performs a preset test operation on the sensor under test;

[0221] The result determination unit 403 is used to determine the test result of the sensor to be tested according to the event log.

[0222] Optionally, when the name determination unit 401 determines the sensor name of the sensor to be tested in the server system according to the IPMI command specification, it can be used to:

[0223] Traverse the status of each sensor in the server system according to the IPMI command specification;

[0224] A sensor whose state meets a target condition is determined as a sensor to be tested, and a sensor name of the sensor to be tested is obtained according to an IPMI command specification. The target condition includes at least one of being in a position state, having a reading, and having a threshold.

[0225] Optionally, when the result determination unit 403 determines the test result of the sensor to be tested according to the event log, it can be used to:

[0226] If the event log is found, it is determined that the sensor to be tested corresponding to the event log has passed the test;

[0227] If the event log is not found, it is determined that the sensor to be tested corresponding to the event log fails the test.

[0228] Optionally, the result determination unit 403 may also be used to:

[0229] If an event log is found, the event log is stored in an event log file created according to the sensor name;

[0230] If no event log is found, it is recorded that the sensor to be tested does not generate any event log.

[0231] Optionally, when performing a test operation on the sensor to be tested, the search unit 402 may be used to:

[0232] Obtaining a threshold type of the sensor to be tested according to the IPMI command specification; the threshold type of the sensor to be tested includes at least one of an upper non-critical threshold (UpperNon-Critical, UNC), an upper critical threshold (Upper Critical, UCR), an upper unrecoverable threshold (UpperNon-Recoverable, UNR), a lower non-critical threshold (LowerNon-Critical, LNC), a lower critical threshold (Lower Critical, LCR), and a lower unrecoverable threshold (LowerNon-Recoverable, LNR);

[0233] Perform analog trigger operation on the sensor to be tested through the analog trigger function corresponding to the threshold type;

[0234] Perform a simulated release operation on the sensor under test.

[0235] Optionally, when searching the system event log for the event log generated by the sensor to be tested in response to the test operation according to the sensor name, the searching unit 402 may be used to:

[0236] Searching the system event log for the trigger event log generated by the sensor to be tested in response to the simulated trigger operation according to the sensor name;

[0237] Search the system event log for the release event log generated by the sensor under test in response to the simulated release operation according to the sensor name.

[0238] Optionally, when the search unit 402 performs an analog trigger operation on the sensor to be tested by using an analog trigger function corresponding to the threshold type, it can be used to:

[0239] Get the initial threshold and current reading of the sensor to be tested;

[0240] Determine the analog threshold value based on the current reading and the threshold trigger condition corresponding to the threshold type;

[0241] Change the initial threshold of the sensor to be tested to the simulated threshold.

[0242] Optionally, when the search unit 402 performs a simulation release operation on the sensor to be tested, it can be used to:

[0243] Restore the analog threshold of the sensor under test to the initial threshold.

[0244] Optionally, when searching the system event log for the event log generated by the sensor to be tested in response to the test operation according to the sensor name, the searching unit 402 may be used to:

[0245] Call the search function keyword corresponding to the threshold type;

[0246] According to the search function keyword and the sensor name, the system event log is searched for the event log generated by the sensor under test responding to the test operation.

[0247] The working principle of the sensor testing device provided in this embodiment can refer to the relevant steps of the sensor testing method provided in any embodiment of the present application, and will not be repeated here.

[0248] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0249] For the convenience of description, the above system or device is described by dividing it into various modules or units according to its functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0250] It can be known from the description of the above implementation methods that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or partly contributed to the prior art in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application or certain parts of the embodiments.

[0251] Finally, it should be noted that, in this article, relational terms such as first, second, third and fourth are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0252] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for testing a server sensor, comprising: Determine sensor names of sensors to be tested in the server system according to the Intelligent Platform Management Interface (IPMI) command specification; After performing a preset test operation on the sensor to be tested, searching the system event log for an event log generated by the sensor to be tested in response to the test operation according to the sensor name; A test result of the sensor to be tested is determined according to the event log.

2. The method according to claim 1, wherein determining the sensor name of the sensor to be tested in the server system according to the Intelligent Platform Management Interface (IPMI) command specification traverses and comprises: Traverse the status of each sensor in the server system according to the Intelligent Platform Management Interface (IPMI) command specification; The sensor whose state meets the target condition is determined as a sensor to be tested, and a sensor name of the sensor to be tested is obtained according to the intelligent platform management interface (IPMI) command specification, wherein the target condition includes at least one of being in a position state, being in a reading state, and being in a threshold state.

3. The method according to claim 1, wherein determining the test result of the sensor to be tested according to the event log comprises: If the event log is found, determining that the sensor to be tested corresponding to the event log has passed the test; If the event log is not found, it is determined that the sensor to be tested corresponding to the event log fails the test.

4. The method according to claim 3, further comprising: If the event log is found, the event log is stored in an event log file created according to the sensor name; If the event log is not found, it is recorded that the sensor to be tested does not generate the event log.

5. The method according to claim 1, performing a test operation on the sensor to be tested, comprising: Obtaining a threshold type of the sensor to be tested according to the IPMI command specification; The threshold type of the sensor to be tested includes at least one of an upper non-critical threshold (UNC), an upper critical threshold (UCR), an upper unrecoverable threshold (UNR), a lower non-critical threshold (LNC), a lower critical threshold (LCR), and a lower unrecoverable threshold (LNR); Performing a simulated trigger operation on the sensor to be tested by using a simulated trigger function corresponding to the threshold type; A simulated release operation is performed on the sensor to be tested.

6. The method according to claim 5, wherein searching the system event log for the event log generated by the sensor to be tested in response to the test operation according to the sensor name comprises: Searching, in the system event log, for a trigger event log generated by the sensor to be tested in response to the simulated trigger operation according to the sensor name; The release event log generated by the sensor to be tested in response to the simulated release operation is searched in the system event log according to the sensor name.

7. The method according to claim 5, wherein the step of performing a simulated trigger operation on the sensor to be tested by using a simulated trigger function corresponding to the threshold type comprises: Obtaining the initial threshold and current reading of the sensor to be tested; determining a simulation threshold value according to the current reading and a threshold trigger condition corresponding to the threshold type; The initial threshold of the sensor to be tested is changed to the simulation threshold.

8. The method according to claim 7, wherein the performing a simulated release operation on the sensor to be tested comprises: The analog threshold of the sensor to be tested is restored to the initial threshold.

9. The method according to claim 5, wherein searching the system event log for the event log generated by the sensor to be tested in response to the test operation according to the sensor name comprises: Calling the search function keyword corresponding to the threshold type; According to the search function keyword and the sensor name, the event log generated by the sensor to be tested in response to the test operation is searched in the system event log.

10. A testing device for a server sensor, comprising: a name determination unit, configured to determine a sensor name of a sensor to be tested in a server system according to an Intelligent Platform Management Interface (IPMI) command specification; A search unit, configured to search, after executing a preset test operation on the sensor to be tested, the event log generated by the sensor to be tested in response to the test operation in the system event log according to the sensor name; A result determination unit is used to determine the test result of the sensor to be tested according to the event log.

Images