Notification to Fix a System Date Issue of NEC Express5800/ft Series
Servers
Published date: February 5, 2014
As we have informed you since January 2010, it is found that some NEC Express5800/ft series servers fail
to maintain the system date every other year starting from 2010.
Many of you have already applied the patch to fix the issue, however, if you have not yet applied it to
your server, please see below and take countermeasures as soon as possible.
Even if you already applied the patch, refer to "Calendar Correction Patch Behavior
Verification Manual" as mentioned in "4. Requests" and verify that the patch is installed
properly and running successfully so the issue can be surely avoided.
We apologize for the inconvenience and ask for your understanding.
1. Description of the Issue and Impact
Every other year starting on February 28th, 2010, this issue that the servers cannot maintain the system
date may occur.
Please note that the issue is caused by multiple conditions (described later in this document), and even
if it has never happened to your server before, different conditions may cause the issue next time.
(1) Affected Servers
Servers affected by this issue are as follows.
<Windows models>
- NEC Express320Fa-L [N8800-082F/82AF]
- NEC Express320Fa-LR [N8800-083F/083E/083AF/083AE]
- NEC Express320Fa-M [N8800-088F/088AF]
- NEC Express320Fa-MR [N8800-089F/089AF]
- NEC Express320Fb-L [N8800-096F/110F/116F]
- NEC Express320Fb-LR [N8800-097F/097E/111F/111E/117F]
- NEC Express320Fb-M [N8800-098F/112F/118F]
- NEC Express320Fb-MR [N8800-099F/113F/119F]
<Linux models>
- NEC Express320Fa-L [N8800-090F/90AF]
- NEC Express320Fa-LR [N8800-091F/091AF]
- NEC Express320Fb-L [N8800-100F/114F/120F]
- NEC Express320Fb-LR [N8800-101F/115F/121F]
(2) Conditions for Occurrence of this Issue and the Impact
<Windows models>
- When an affected ft series server is run uninterruptedly before and after the moment when
the date changes from February 28th to February 29th of a leap year
=> The date should be changed to "February 29th" of that year, however, it will be "March
1st" of that year in the system.
- When an affected ft series server running is shut down or restarted sometime between 11:45
p.m. on February 29th and 4:00 a.m. on March 1st of a leap year
=> The date should be changed to "March 1st" of that year, however, it will be "July 31st,
2003" in the system.
- When an affected ft series server running is shut down or restarted sometime between 11:45
p.m. on February 28th and 4:00 a.m. on March 1st of an even-numbered non-leap year
=> The date should be changed to "March 1st" of that year, however, it will be "July 31st,
2003" in the system.
<Linux models>
If an affected server is shut down (powered off) or restarted within the periods below, this issue
may occur.
- 15 minutes between 11:45 p.m. on February 28th of an even-numbered year and 0:00 a.m. on the
following day
- 15 minutes between 11:45 p.m. on February 29th of a leap year and 0:00 a.m. on the following
day
2. Causes
Those affected ft series servers control the behavior of the two duplexed systems with a large-scale
integration (LSI) called GeminiEngine®. This issue is caused by a failure in the date calculation method
of the hardware clock implemented in GeminiEngine®.
3. Workaround
(1) Applying the Patch
By applying the patch fixing this issue to an affected ft series server, the issue that the server
cannot maintain the system date can be avoided. The time required to install the patch is approximately
5 minutes.
No need to reboot the server after applying it. This patch is not a resident program, therefore, it will
not deteriorate the performance of your server.
(2) Other method to avoid the issue
Note that the workaround approach is varied depending on the year.
• For the even-numbered non-leap years (ex. 2010, 2014,
2018)
By conducting the following either "a." or "b.", the issue can be avoided without applying the
patch.
<Windows models>
- Shut down the affected ft series server by 11:45 p.m. on February 28th, and then restart it
after 0:05 a.m. on the following day, March 1st.
- Do not shut down or restart the affected ft series server running between 11:45 p.m. on
February 28th and 4:00 a.m. on the following day, March 1st.
<Linux models>
- Shut down the affected ft series server by 11:45 p.m. on February 28th, and then restart it
after 0:00 a.m. on the following day, March 1st.
- Do not shut down or restart the affected ft series server running between 11:45 p.m. on
February 28th and 0:00 a.m. on the following day, March 1st.
For the leap years (ex. 2012, 2016)
By conducting the following both "c." and "d.", the issue can be avoided without applying the
patch.
<Windows models>
- Shut down the affected ft series server by 11:45 p.m. on February 28th, and then restart it
after 0:05 a.m. on the following day, February 29th.
- Do not shut down or restart the affected ft series server running between 11:45 p.m. on
February 29th and 4:00 a.m. on the following day, March 1st.
<Linux models>
- Do not shut down or restart the affected ft series server running between 11:45 p.m. on
February 28th and 0:00 a.m. on the following day, February 29th.
- Do not shut down or restart the affected ft series server running between 11:45 p.m. on
February 29th and 0:00 a.m. on the following day, March 1st.
4. Requests
If the patch has not yet been applied to your server, be sure to apply it or take the other
countermeasure by the day before the date on which the issue occurs next time.
If the patch has already been applied, please check that it is running successfully. It requires
approximately five minutes or so to verify the patch running status. In addition, the verification
causes only the minimum load to the system (Time: approx. 2-3 seconds, CPU utilization: approx. 10%),
and thus it can be performed while the system is in operation.
- Calendar Correction Patch Behavior Verification Manual
5. URLs to Download the Patch
*Note: All date and time described above are local time.
Top of this page
