Buffalo Forums

Does the LS-X1 have a battery?
When I use the scheduled energy mode the date and time change to 1-1-2000. Resetting does not help. As long as the power stays on everything works correctly.

No it doesn't. I saw this issue on an of old kirkwood unit I own. It resets to January 1st 2000 starting 1st January 2020. Setting a valid NTP seems to make it work but doesn't fix the root cause. Did not have time yet to look further into it though.

There is no battery in that sense, nothing replaceable. Different ARM-based models use different types of RTC which are either built into the SoC or are an additional chip but as far as I know none have an external battery.

Even if there is something wrong with the RTC I would expect NTP would set the time without there being a noticable problem (assuming the device has access to the internet). You should probably start by checking the NTP settings.

Thank you for your reactions.
The problem indeed started at the beginning of this year.
The device is not connected to the internet so setting a valid NTP won't help...

You could run a NTP server locally and use that.

QuoteYou could run a NTP server locally and use that.

I am afraid that I have no idea how to do that.
Just an average Windows user using this device for back-ups and little further knowledge..

I haven't found any info about which RTC is used in this device (and I don't have one to check). There are some reports in the news of some devices running into trouble in 2020 due to a y2k-like issue but I haven't found anything specific to RTC chips or kirkwood SoCs in a brief google search to indicate that is your problem.

I took a look at a few of my devices which are of that same era and older and all seem to be reporting reasonable values from their respective RTC's. If something is physically wrong with your RTC you might see an error if you connected via command line and ran something like dmesg | grep -i rtc. If there is a physical problem with it there probably isn't a way to fix it.

If it's some sort of software problem it could be happening to other folks but they haven't noticed because NTP is correcting it for them automatically.

This is the result via the command line when running "dmesg | grep -i rtc".   I see no errors

riek@Linux:~$ dmesg | grep -i rtc
[    0.094965] RTC time: 19:43:50, date: 02/19/20
[    0.774412] rtc_cmos 00:03: RTC can wake from S4
[    0.774695] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[    0.774751] rtc0: alarms up to one month, 114 bytes nvram, hpet irqs
[    0.782896] Using IPI No-Shortcut mode
[    2.310102] rtc_cmos 00:03: setting system clock to 2020-02-19 19:43:52 UTC (1582141432)

That appears to show a working RTC setting the clock at startup, though rtc_cmos usually refers to a PC. Is this from the device or from your PC running Linux?

Either way, you can use this tool to run the same command on the device:
https://github.com/1000001101000/acp-commander

java -jar -t acp_commander.jar <ip address of device> -pw <admin password> -c "dmesg | grep -i rtc"

I was looking into this a bit more and here is a LS-QVL as an example. pretty much the same thing with an LS-WVL - both switch to 2000

rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
rtc-mv rtc-mv: setting system clock to 2000-01-01 00:00:00 UTC (946684800)

So yes, there is a general issue. guessing the sys clock is updating it though once it gets the correct time from an NTP

root@LS-xxxxxxx:~# hwclock -r
Thu Feb 20 02:55:43 2020  0.000000 seconds

Interesting!

I should have been more specific in my previous post. I checked an LS-WXL and TS-XEL which are both kirkwood devices of a similar era to the LS-XL as far as I know. They are both running Debian 10 and their SoC based RTCs are returning reasonable values. I tried uninstalling NTP and unplugging the LS-WXL but it always seems to come up with the right time in Debian.

I suppose this could be an issue with the RTC driver used by the stock firmware, though I don't fully understand how that would work.

Quote from: 1000001101000 on February 19, 2020, 10:28:24 AM
That appears to show a working RTC setting the clock at startup, though rtc_cmos usually refers to a PC. Is this from the device or from your PC running Linux?

Either way, you can use this tool to run the same command on the device:
https://github.com/1000001101000/acp-commander

Code Select Expand

java -jar -t acp_commander.jar <ip address of device> -pw <admin password> -c "dmesg | grep -i rtc"

This was run from a PC running linux.

However, your suggestions go a little to far for me to handle...

But thank you for your help!

It's an interesting issue. I think your only solution will be to connect the device in such a way that it has access to the internet so that it can rely on NTP.

Thanks.
My solution is to turn the energy saving mode off.
As long as the power stays on, the date/time works just fine.

That works too!

Since I read the post, I'm trying this on a TS-XEL.
Can someone explain why this tried to set an incorrect time on Debian 10.3?

Also, how can I check to see if the RTC in a TS-XEL unit- is working ok?

root@debian:/# dmesg | grep -i rtc
[    3.397464] rtc_cmos 00:01: RTC can wake from S4
[    3.397776] rtc_cmos 00:01: registered as rtc0
[    3.397842] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    3.707613] rtc_cmos 00:01: setting system clock to 2020-03-04 14:57:41 UTC (1583333861)


when I run date, the correct time is reported
root@debian:/# date
Mon 09 Mar 2020 05:21:12 PM CDT

are you checking on the nas or on your PC?

You appear to be comparing the rtc time at boot to your current time. Try comparing date to hwclock

I'm running it on the nas using an ssh session.
And I was wrong, those were for the TS-WVHL, not the TS-XEL.

When I run dmesg | grep -i rtc on the TS-XEL, it just comes back to the prompt, with no info.  Any ideas why?

date and hwclock both display correct info for the TS-XEL though.  Is that all that needs to be checked?

dmesg shows the buffer of kernel output, if you've had enough messages rtc initialization might not be there anymore.

If date and hwclock reflect the current time you're in good shape. Honestly, if ntp is working you likely wouldn't notice an rtc problem. In fact in many cases the rtc module isn't loaded until after the clock is set at boot but then gets fixed by ntp a few seconds later.