LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.

Notices


Reply
  Search this Thread
Old 10-15-2014, 04:12 AM   #1
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Rep: Reputation: Disabled
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
-----------------------------------------------------------------------------------
 
Old 10-15-2014, 04:31 AM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,001

Rep: Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276
Have you tried using the date command?
 
Old 10-15-2014, 04:45 AM   #3
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by business_kid View Post
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
 
Old 10-15-2014, 07:05 AM   #4
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,001

Rep: Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276
Code:
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.
 
Old 10-15-2014, 09:15 PM   #5
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by business_kid View Post
Code:
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"

Last edited by hardikgohil1988; 10-15-2014 at 09:17 PM.
 
Old 10-16-2014, 10:16 AM   #6
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,001

Rep: Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276Reputation: 2276
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.
 
Old 10-17-2014, 02:38 PM   #7
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929
You can use hwclock to re-read the information stored on your RTC.
Code:
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.
 
Old 10-27-2014, 02:32 AM   #8
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rtmistler View Post
You can use hwclock to re-read the information stored on your RTC.
Code:
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
 
Old 10-27-2014, 07:35 AM   #9
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929
Quote:
Originally Posted by hardikgohil1988 View Post
# hwclock -w
Fine
Quote:
Originally Posted by hardikgohil1988 View Post
# hwclock
Mon Oct 27 02:28:15 2014 0.000000 seconds
Also fine
Quote:
Originally Posted by hardikgohil1988 View Post
# hwclock -r
Mon Oct 27 02:28:19 2014 0.000000 seconds
Redundant, but also fine. Also means it works.
Quote:
Originally Posted by hardikgohil1988 View Post
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.
 
Old 10-28-2014, 10:55 PM   #10
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
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.
 
Old 10-31-2014, 08:39 AM   #11
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929
Quote:
Originally Posted by hardikgohil1988 View Post
# 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:
Code:
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:
Code:
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.
 
Old 11-02-2014, 10:58 PM   #12
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rtmistler View Post
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:
Code:
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:
Code:
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
 
Old 11-03-2014, 10:41 AM   #13
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929
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?

Last edited by rtmistler; 11-03-2014 at 10:43 AM.
 
Old 11-03-2014, 08:27 PM   #14
hardikgohil1988
Member
 
Registered: Sep 2014
Posts: 63

Original Poster
Rep: Reputation: Disabled
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

Last edited by hardikgohil1988; 11-03-2014 at 08:31 PM.
 
Old 11-04-2014, 01:54 PM   #15
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929Reputation: 4929
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?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
difference time by hwclock and date command massy Linux - Server 2 01-18-2014 05:00 AM
hwclock configuration issue DeeGee Linux - Newbie 1 05-06-2013 07:22 PM
Issue with hwclock suraj.mandhare Linux - Kernel 0 11-01-2012 07:26 AM
Setting system date and time affecting the clock and date on BIOS satimis Ubuntu 7 09-21-2007 09:02 AM
date command counts time quicker than hwclock (RTC) carl0ski Linux - Software 2 12-29-2005 06:32 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer

All times are GMT -5. The time now is 05:27 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration