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?
|
Quote:
|
Code:
Mounting SRAM disk. |
Quote:
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.
Code:
hwclock -r 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. |
Quote:
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 |
Quote:
Quote:
Quote:
Quote:
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. |
Quote:
Code:
date MMDDhhmmYY Code:
date 1031083514 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. |
Quote:
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:
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? |
All times are GMT -5. The time now is 09:50 AM. |