About This Document
The bmc_time component itself does not "generate" time. It only transfers Network Time Protocol (NTP) or Real-Time Clock (RTC) time. Therefore, 99% of issues such as inaccurate time or time jumps are not caused by this component.
Note: Do not habitually assume that the component is faulty.
1. Common Issues
1.1 BMC Time Restored to 1970 After Each Restart
The starting point for timestamps is 1970-01-01T00:00:00, where a value of 1 represents one second elapsed since that time.
After a reset, the BMC does not have a timestamp, so it displays 1970. The time returns to normal once the BMC obtains a valid timestamp.
1.2 Time Jumps
Time jumps typically occur in the following scenarios:
1.2.1 Resetting to 1970
This is normal behavior. The reasons are described above.
1.2.2 Initial Jump from 1970 Followed by a Second Jump
To ensure that services use a "relatively valid" timestamp instead of 1970 as soon as possible after starting, the system persists the timestamp from before the reset and uses it temporarily afterward.
Persistence is triggered at the following times:
- Immediately after startup
- Automatically every day
- Whenever a time jump occurs
- During a graceful restart
Therefore, operations such as a forced reboot may result in an old persisted timestamp because the system had no opportunity to persist the most recent time.
In this scenario, the application log displays set bmc_time time_stamp=%s by persistent data.
1.2.3 Time Source Jumps
Check whether NTP is enabled. If NTP is enabled, the system only obtains time from the NTP source.
ipmcget -d ntpIf the Status is set to enabled, NTP is enabled. The Synchronize field indicates whether the synchronization is successful.
This situation is further divided into two cases:
- Jumps after successful NTP synchronization: This indicates a discrepancy between the RTC and NTP times. You need to check which one is faulty.
- Jumps while NTP remains enabled: This indicates an issue with the NTP server.
If NTP is disabled, check the time on the RTC chip. If the BMC time matches the RTC chip time, contact hardware engineers to locate the fault.
Method 1: Run the hwclock command on the OS to check the OS time. In most cases, this matches the BMC time. If it does not, proceed to method 2.
Method 2: Read the registers. This typically involves CpuBrdSMC. If it is not, change it to the corresponding reading format.
Command:
mdbctl call Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read 0 201327872 8Parsing instructions: For example, 133.7.1.8.3.6.16.26 represents the year 100 + 133 + 7 × 256, January (1), day 8, at 6:16:26.
The year is offset by 100 because the RTC clock stores the year starting from 1800 in the System Management Controller (SMC), while the tm structure of Linux calculates time starting from 1900.
1.3 Time Reverts After the date -s Command Is Executed
First, understand this basic principle:
In normal cases, the BMC periodically synchronizes the accurate time from a time source, which is either an NTP server or the RTC.
Therefore, if you manually modify the local time, the system will refresh it back to the source time after a short interval.
The date -s command is a standard Linux system command and is not provided by the component.
You need to verify the time source used by the system using the following commands:
- Run
ipmcget -d ntpto check whether NTP is enabled. - Run
hwclockon the OS to check the RTC time.
If the time does not meet the expectation, contact the responsible personnel.
2. Interface Configuration Issues
2.1 Failed to Set the NTP Address Acquisition Mode (AddressMode)
Check whether the corresponding DHCP address mode is enabled for the network module. If the automatic acquisition mode is not enabled, enable it before modifying the NTP address acquisition mode. Otherwise, the modification will fail.
2.2 Failed to Set the Time Using Standard IPMITool Commands
Required format: %m/%d/%Y %H:%M:%S
Example:
ipmitool sel time set "06/13/2025 08:35:00"If NTP is enabled, the error message " Command not supported in present state" is displayed.
3. Time Query Issues
3.1 NTP Synchronization Failure
Connectivity of the NTP service is handled by open-source software instead of the bmc_time component. If an exception occurs, refer to related documents.
- Check whether the configured IP address is a valid NTP server IP address.
/usr/sbin/ntpdate -uD ipThe following figure shows an invalid IP address.
- If the IP address is valid, check whether it is written to the corresponding configuration file:
/data/trust/ntp/ntp.conf.
Note: After NTP is enabled, the system writes the settings to the configuration file. If the settings are missing, investigate potential code issues.
- Check the NTP server status.
ntpq -c asThe NTP server is considered trustworthy only when sys.peer is displayed.
- The IP address works in the V2 environment but fails in V3.
Check whether the IP address and port are reachable. Such cases are typically environment-related issues, such as discrepancies between different subnets.