2

I own a Lenovo S10 and it runs Arch Linux as the only OS. For some odd reason which I still haven't been able to figure out, it keeps losing the time. In the BIOS is has the right settings though.

Under linux, the time zone is correctly set, and everything works fine for a few hours. If I set the right time and restart the computer, it will show the right time settings. However if i turn off the computer and turn it back on a few hours later, the time is all messed up again.

I have tried using NTP and while it fixes the problem temporarily, it is not always an option since its not always connected to the internet.

Any ideas on how to fix this problem permanently?

7 Answers 7

5
+50

Make sure your NTP client also sets the hardware clock (through the BIOS), and not just the Linux software clock.

You can check your hardware clock using the hwclock program (located in /usr/sbin or /sbin) and compare it to the software clock using the date command.

Boring explanation:

Your computer has a small chip in it, which is called "the real-time clock" or RTC. This clock runs on a battery, and counts time just like a wrist-watch. When the computer goes on, the clock is read, and that's how your operating system knows what time it is when it starts up. But after that first read, the operating systems doesn't have to use the RTC - it can simply continue counting time (seconds, hours and whatever) by itself. Whenever the user asks what time its, it can simply report its own time (instead of the time that the RTC reports).

The tricky bit comes when the RTC doesn't have the right time. When you try to correct the clock, it's really the operating system that does that for you. The operating system may only update its internal, software, clock. In that case, once you reboot the incorrect time will be loaded again from the RTC. I still remember this from the DOS days. You had to go into the BIOS to change the clock. ugh.

Anyway, the final nail in the coffin is this: the time read from the RTC is just a number. And the operating system is allowed to change that number. For example, it might want to add 3,600,000 milliseconds (1 hour) to that number, so that GMT+1 users feel comfortable. Other times, there's something screwy with the timezone settings.

Either way, setting the hardware clock from within the operating system tends to fix this, since it goes through the same filtering process. So even if your OS adds 5 minutes to the RTC, it will also subtract 5 minutes before updating the RTC.

Good luck!

1
  • great explanation, thank you. i will check this out more deeply when i get home.
    – nmuntz
    Jul 27, 2009 at 16:30
2

There is a setup question which throws some people off which can cause this problem. It is the "Is this system's BIOS time set to UTC". If you selected "Yes" to this, then the system will always be X number of hours off when it boots, because it is taking the BIOS time and subtracting X number of hours.

You would have to check the docs for your distro to find out how to change this setting if that is the case.

4
  • i'm not using UTC, its set to localtime.
    – nmuntz
    Jul 20, 2009 at 18:00
  • 1
    Did you tell your OS that when you installed? How much is the time off by? A set amount of time each time, or always random?
    – Jack M.
    Jul 20, 2009 at 18:04
  • i am 100% positive i did not select UTC for the time settings. the time seems to be off randomly. right now its off by an hour, but i've seen it off for 4 hours in the past.
    – nmuntz
    Jul 20, 2009 at 18:09
  • 2
    Well then that is just plain kookie. I've never seen it be off by more than 5-10 seconds at boot. I toss ntpdate ntp.nasa.gov into rc.local. Never a problem.
    – Jack M.
    Jul 20, 2009 at 18:12
2

It sounds like the battery that keeps the clock running is dead. I have a feeling that if you replace the battery the time will keep when it is turned off.

Since you mentioned in the comment that the bios has the correct time, it could be a processor issue, which also makes sense. The timing on the processor is different when you have it plugged into the wall and when you don't. It could be that if you are on battery a second isn't calculated in the same way because the processor's ticks are different. If it is still under warranty I would give support a call and ask.

7
  • the netbook is only a few months old and has not been heavily used - is this still possible? besides, the BIOS seems to have the right time.
    – nmuntz
    Jul 20, 2009 at 17:49
  • You don't know how long the netbook has been sitting on the shelf, the battery could have been installed long before you bought it.
    – scheibk
    Jul 20, 2009 at 17:58
  • i bought it from newegg.com so i don't think it was "on the shelf". still, how do you explain that the BIOS has the right time?
    – nmuntz
    Jul 20, 2009 at 18:03
  • I added another explanation that could possibly affect the time. It's a long shot, but it might be causing it to happen.
    – scheibk
    Jul 20, 2009 at 18:22
  • @nmuntz: Even from newegg, the computer sat in their warehouses. Jul 20, 2009 at 18:45
2

If you are sure it's not the system battery or your OS that is causing the time problem I would suggest you contact the manufacturer while it is still under warranty you say it's only a few months old so I would think that Lenovo would still cover any hardware problems. You may want to install XP on the system and replicate the problem there before contacting them to speed up the process many manufactures will only support the OS that was shipped on the computer.

2

Clocks running with incorrect time seems be a common problem with ArchLinux judging by the number of posts on their forums, like this one.

The problem seems to be with the /var/lib/hwclock/adjtime file. Quoting from the above forum post:

Look in /var/lib/hwclock/adjtime. If the first number on the first line is large (bigger than 10 or so), delete this file, set your clock again, and reboot. (The file will be recreated with a small number.)

This number is supposed to show how many seconds your hardware clock drifts each day. It's not too hard to accidentally compare the software clock with the hardware clock when they're not set up right yet, which tricks the system into believing your hardware clock is very inaccurate, and overcompensating.

If that doesn't solve your problem it may be a hibernation issue. When you say

if i turn off the computer and turn it back on a few hours later, the time is all messed up again.

Are you powering the system down or hibernating it? If it's the latter, then my guess would be is that the clock is resuming from the time that you hibernated the netbook. If the clock is always running slow then this is probably the answer.

If you have suspend and resume scripts they should store the system time to the hardware clock during suspend and then restore it from the hardware on resume. You can use the hwclock command for this.

I don't know ArchLinux so I'm not sure where this scripts are but you might find this article on the ArchLinux Wiki helpful.

1

I have tried using NTP and while it fixes the problem temporarily, it is not always an option since its not always connected to the internet.

NTP will do two things. The first is continually compare your time with network time servers, and adjust as necessary.

The second thing NTP will do is calculate an accurate drift for your system clock. So even when you're not connected, NTP can still keep adjusting your clock. It won't be as accurate as when you're online, but will be better than nothing. I'm not sure how it will adjust after your netbook has been powered off for a while. Running ntpdate as part of the startup will set the correct time if you have an internet connection.

0

I've had similar problem on my laptop with Archlinux. This thread helped.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .