[SOLVED] Issue with hwclock in setting date

I am working on Embedded Board,running on linux-2.6.

whenever I set the time in hardware clock using
hwclock -w command which copies system time to hardware clock

After reboot,It changes to some other date,but time remains the same.

I set date to Oct 15/16:06:00


-------------------------------------------------------------------------------

[ 0.950000] rtc-bq4802 rtc-bq4802: setting system clock to 2014-10-14 16:06:44 UTC (1413302804)
[ 6.253000] Empty flash at 0x005aa260 ends at 0x005aa400
[ 7.916000] VFS: Mounted root (jffs2 filesystem) on device 31:1.
[ 7.924000] Freeing unused kernel memory: 148k freed
Mounting SRAM disk.
e2fsck 1.42.7 (21-Jan-2013)
[ 13.417000] sram_open
[ 13.420000] sram_release
[ 13.667000] sram_checksum_reset crc 0x38c9bebf
[ 13.672000] sram_open
[ 13.683000] sram_open
[ 13.686000] sram_release
[ 13.934000] sram_checksum_reset crc 0x38c9bebf
Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set). Fix? yes

/dev/sram was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5:[ 13.992000] sram_release
Checking group summary information
/dev/sram: 13/256 files (0.0% non-contiguous), 137/2048 blocks
[ 14.240000] sram_checksum_reset crc 0x3b059896
[ 14.257000] sram_open
-----------------------------------------------------------------------------------

Have you tried using the date command?

Originally Posted by business_kid Have you tried using the date command?

Yes,first the set the required time/date in date command then run hwclock -w to make changes in hardware clock

Mounting SRAM disk.
e2fsck 1.42.7 (21-Jan-2013)
[ 13.417000] sram_open
[ 13.420000] sram_release
[ 13.667000] sram_checksum_reset crc 0x38c9bebf
[ 13.672000] sram_open
[ 13.683000] sram_open
[ 13.686000] sram_release
[ 13.934000] sram_checksum_reset crc 0x38c9bebf
Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set). Fix? yes

/dev/sram was not cleanly unmounted, check forced.

I'd fix that bit first. By the read of that, the sram is uncleanly unmounted, and an e2fsck is resetting the date. ext* are hardly the ideal filesystems for an sram, btw. There are specific filesystems for many special purposes. It might help to send a hup to whatever writes the sram on closedown or issue a sync instruction as part of that.

Originally Posted by business_kid Mounting SRAM disk. e2fsck 1.42.7 (21-Jan-2013) [ 13.417000] sram_open [ 13.420000] sram_release [ 13.667000] sram_checksum_reset crc 0x38c9bebf [ 13.672000] sram_open [ 13.683000] sram_open [ 13.686000] sram_release [ 13.934000] sram_checksum_reset crc 0x38c9bebf Superblock last write time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set). Fix? yes /dev/sram was not cleanly unmounted, check forced. I'd fix that bit first. By the read of that, the sram is uncleanly unmounted, and an e2fsck is resetting the date. ext* are hardly the ideal filesystems for an sram, btw. There are specific filesystems for many special purposes. It might help to send a hup to whatever writes the sram on closedown or issue a sync instruction as part of that.

But,the booting process is successfully done until the login screen.
What can be reason for message "/dev/sram was not cleanly unmonted"

Just guessing, as I don't have a clue really about your hardware

1. You didn't allow enough time to unmount it (e.g. power off)
2. Your shutdown routine hung.
3. you didn't unmount it cleanly last time you configured it.
4. it was somehow mounted and dropped without your knowledge.

You can use hwclock to re-read the information stored on your RTC.

hwclock -r

Set and verify your date/time using the "date" command. Next write to the RTC using hwclock with the -w option.

Once you written it, re-read it and see if the information is correct.

Other options for hwclock are that you can specify the /dev/rtc resource with the -f option. Usually not necessary.

My take is if you verify system date/time is correct via the "date" command. If you see no system errors or console errors when you execute "hwclock -w", and if you see the correct date/time when you read the RTC using "hwclock -r" then perhaps the interface to the RTC is not truly working correctly. I'm assuming there's no issue with the battery for the RTC. It's an embedded board, consider trying a different RTC module.

Originally Posted by rtmistler You can use hwclock to re-read the information stored on your RTC. hwclock -r Set and verify your date/time using the "date" command. Next write to the RTC using hwclock with the -w option. Once you written it, re-read it and see if the information is correct. Other options for hwclock are that you can specify the /dev/rtc resource with the -f option. Usually not necessary. My take is if you verify system date/time is correct via the "date" command. If you see no system errors or console errors when you execute "hwclock -w", and if you see the correct date/time when you read the RTC using "hwclock -r" then perhaps the interface to the RTC is not truly working correctly. I'm assuming there's no issue with the battery for the RTC. It's an embedded board, consider trying a different RTC module.

I have done as you said

# date 2014.10.27-02:28:00
Mon Oct 27 02:28:00 UTC 2014
# date
Mon Oct 27 02:28:01 UTC 2014
# hwclock -w
# hwclock
Mon Oct 27 02:28:15 2014 0.000000 seconds
# hwclock -r
Mon Oct 27 02:28:19 2014 0.000000 seconds



After reboot:

Superblock last write time (Mon Oct 27 02:30:12 2014,
now = Tue Oct 14 02:30:46 2014) is in the future.
Fix? yes

# date
Tue Oct 14 02:31:33 UTC 2014

Originally Posted by hardikgohil1988 # hwclock -w

Fine

Originally Posted by hardikgohil1988 # hwclock Mon Oct 27 02:28:15 2014 0.000000 seconds

Also fine

Originally Posted by hardikgohil1988 # hwclock -r Mon Oct 27 02:28:19 2014 0.000000 seconds

Redundant, but also fine. Also means it works.

Originally Posted by hardikgohil1988 After reboot: Superblock last write time (Mon Oct 27 02:30:12 2014, now = Tue Oct 14 02:30:46 2014) is in the future. Fix? yes # date Tue Oct 14 02:31:33 UTC 2014

Gotcha.

First I would say, do not fix right off. Let the system boot fully because maybe your read of the hwclock is being performed after this process which is detecting a time skew on your disk or other storage medium. Then issue the date command to determine what the system time is set too. Once it gets fully booted, the system time will either be correct or not. Either case, issue the hwclock -r command to see what the RTC device has on it. It may be that the RTC is fine and this is a parallel issue that is related, but also interfering with your intentions. If you do find that the RTC data is correct, then you'll need to track down what that complaint about the superblock is, and why that's happening. That is a new one to me so I don't have any recommendations for that particular problem. However one thing I might try to do is to initialize setting of the system time via the RTC in advance of whatever process that is which is making that complaint; if possible. And that's all once I'd verified that the RTC is OK. Maybe the RTC is not OK after boot. But you should determine that information first.

Another thing you may try is to do all the setting and verification of the RTC, then UNPLUG the RTC from the interface, thus causing it to have to rely on it's battery backup. Leave it disconnected for a few minutes, like 5 to 10, and then replug it in; verify that the driver attaches to it or recognizes it in the system, and then read what it has on it via the hwclock command. It should be current time and not off by the 5 to 10 minutes, or off by any other odd values. If it is off, then either change the battery on it and retest, or get a different or other RTC and try again. These are pretty simple devices, you write to them, you take their power away and they keep time using their battery until you power them again and read from them.

there is one observation

time part is fine.
In date part whatever year and month I set it remains same only date gets changed to 14.

Originally Posted by hardikgohil1988 # date 2014.10.27-02:28:00 Mon Oct 27 02:28:00 UTC 2014

Additional note: While that appears to work, if you look at the man page for the date command it shows the syntax in the way I also think about it, which is:

date MMDDhhmmYY

Granted there are added options for century and seconds, but for me I usually just set to the minute and since we're well into the 2000's, I don't worry about century. So like about the time I'm writing this in EST on Halloween morning, I would issue the command like:

date 1031083514

Although the way you've issued the command, it appeared to work.

And then based on your most recent posting, for whatever reason it is, the date is still incorrect. I do find it suspicious that the date happens to be "14" which matches the year. Does that always happen? If you issue the date command with no arguments, it should just print out the current date and time. Once you've set date and time via the date command, issue the date command again to re-verify that the system time is correct.

As far as the other diagnostics, you didn't mention whether or not you did them or what the results were, so I can't really vote yea or nay about the operation of your RTC.

Originally Posted by rtmistler Additional note: While that appears to work, if you look at the man page for the date command it shows the syntax in the way I also think about it, which is: date MMDDhhmmYY Granted there are added options for century and seconds, but for me I usually just set to the minute and since we're well into the 2000's, I don't worry about century. So like about the time I'm writing this in EST on Halloween morning, I would issue the command like: date 1031083514 Although the way you've issued the command, it appeared to work. And then based on your most recent posting, for whatever reason it is, the date is still incorrect. I do find it suspicious that the date happens to be "14" which matches the year. Does that always happen? If you issue the date command with no arguments, it should just print out the current date and time. Once you've set date and time via the date command, issue the date command again to re-verify that the system time is correct. As far as the other diagnostics, you didn't mention whether or not you did them or what the results were, so I can't really vote yea or nay about the operation of your RTC.

Whatever Date/time I set after reboot date will be 14.xx.xxxx-xx:xx:xx and this happens always.

ya after setting date i have verified the output of date.

next i set RTC using hwclock -w then check using hwclock -r

Reboot

It would seem to me that the RTC module is fine and there's something wrong with how time is being set or restored on your system. Worse, it is date. I could see the hour because if you set a timezone there are oddities where the RTC stored time either is or is not time zone based.

Here you're saying you always get the same date.

Maybe pore through your system log line for line until you find something suspect about date and time and work from there.

I mean ...

Power on = 1/1/1900, the epoch
System date and time are set by any of:
- NNTP
- Service reading a RTC
- User or startup script command execution

So to consider:

1. NNTP is usually not wrong, and also not wrong categorically over days/weeks/months - the level of wrong would be minute fractions of a second
2. Reading the RTC - well you've checked the RTC a few different ways, and a bet is if you do hwclock -r you'll see a correct date; either yes or no. Replacing the RTC when there's no proof is simple, but no guarantee of closure. I'm also betting it is reading the RTC because it appears to be doing so; or rather the question becomes "how does it get system time?" Unplug/disable the network to make sure NNTP can't do anything
3. Some script could be doing something, how you find it is investigation, seemingly a lot of that

I'd start with ensuring that NNTP is not involved by disabling the network, and then checking the system log to try to determine what's setting the clock. Because as I say, with no RTC and no NNTP, it really should then be 1/1/1900.

In fact with that final thought; pull BOTH the network and the RTC and verify that the date is 1/1/1900. It should be. If it isn't, what changed it?

I have unplug the network cable.

I disabled the HCTOSYS in kernel which sets the system date from hardware clock(RTC) on boot up.

now system date after bootup read as 1/1/1970 which is always same.

when read HWCLOCK it is still 14.xx.xx-xx:xx:xx when set to whatever date/time.

but,when time read from boot loader IODIAG application I can read the correct date/time set before.

once I boot from boot loader after login screen again to 14.xx.xx-xx:xx:xx

So you're saying that you feel the RTC has correct data because you can read it with an IODIAG program and this proves it has the correct data.

But next when you boot your system and use the RTC to set date/time it still comes up with the incorrect date.

That would be a situation where you'd go back and review the system log. Possibilities occuring to me are that something's screwy with your system when it starts up. Sort of unlikely actually. One might be that the hwclock program has a flaw; therefore you'd look to maybe download the latest source, build it, maybe add some debug if needed and retest. Another possibility is that hwclock is OK, but the way it is being used to set the system date/time has a simple flaw which is causing the date to always be 14.

I'm assuming that you can set your system date/time via NTP and that works fine, right?