• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: My sheeva starts with system clock set to april 1960...  (Read 2314 times)
hr.punio
Newbie
*

Karma: 0
Posts: 26


View Profile
« on: October 05, 2010, 12:23:15 AM »

Hi,

The time is in sync within a few minutes (thanks to ntpd I presume).
I was even not aware about the problem;
until I have looked into /var/log/apache/access.log recently

/sbin/hwclock --show
Is not working:
The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
And the system installed is Debian Lenny from cyrius.com

I wonder if is this a annoying feature or there is somethig I can do about it?
 
Logged

MarkF
Full Member
***

Karma: 7
Posts: 144


View Profile
« Reply #1 on: October 05, 2010, 07:46:48 AM »

After ntpd has set the system time, have you done this:

/sbin/hwclock --systohc

To set the hardware clock to the current System Time?
Logged

Mark

hr.punio
Newbie
*

Karma: 0
Posts: 26


View Profile
« Reply #2 on: October 05, 2010, 10:55:48 AM »

Of course not. Thanks Mark
Logged

hargoth
Newbie
*

Karma: 0
Posts: 6


View Profile
« Reply #3 on: October 05, 2010, 03:54:11 PM »

That gives me:

sheevaplug-debian:~# /sbin/hwclock --systohc
Timed out waiting for time change.
Logged

MarkF
Full Member
***

Karma: 7
Posts: 144


View Profile
« Reply #4 on: October 07, 2010, 10:41:33 AM »

hargoth - Have you built your own kernel or are you using one of the recent pre-made kernels?
Logged

Mark

hargoth
Newbie
*

Karma: 0
Posts: 6


View Profile
« Reply #5 on: October 11, 2010, 09:17:23 AM »

sheevaplug-debian:~ -> uname -r
2.6.32-00007-g56678ec

This is the kernel installed by Globalscale on the updated Guru Plugs. I received these units in September of 2010.

Logged

MarkF
Full Member
***

Karma: 7
Posts: 144


View Profile
« Reply #6 on: October 12, 2010, 06:56:19 AM »

Rats!  Everything I found about the "Timed out waiting for time change." message says the Real-Time Clock (RTC) hardware support is not compiled into the kernel, the hardware is toast or there is no battery.

Another idea I had was this might be a symptom of the known problem with kernels before 2.6.32 on newer hardware; but, since you are using a .32 kernel, you should not be experiencing that particular problem.  Just to be sure, could you use the dmesg command and check for a line that contains "Kirkwood: MV88F6281" and make sure it has a valid chip revision value?  While looking at the dmesg output, you could also look at any RTC messages for possible problems.

I'm running out of ideas. Sad
Logged

Mark

Pages: [1]
Print
Jump to: