Bug 403557

Can you attach the output of 'hwinfo' run as root here?

I don't know if my problem is related, but I too have a system clock which shows the wrong time after a boot.

When I installed OpenSUSE 11.0, I had to set the clock.  From Yast, I left the "Hardware clock set to UTC" unchecked (so the computer was supposed to have the clock set to local time).  After a boot/restart, the system clock was 2 hours ahead.  As my timezone is UTC+1 and we are in DST, I suspected that when shutting down, the system saved the clock as local, but loaded it as UTC (and adjusted to local).
I set the clock again using Yast, this time checking the "Hardware clock set to UTC", but I still have a wrong system time after a boot/restart.  Today, the clock was 1 hour 15 minutes late.

Now, I've set the system clock again.  Here is what hwclock tells:

Linux1:/home/amigaphil # hwclock --show
jeu. 07 août 2008 20:05:42 CEST  -0.420596 secondes

which is the correct current LOCAL time (shouldn't it be UTC time, according to the checked hardware clock option in Yast ?).

I have exactly the same problem (2 hrs ahead) on a MSI Megabook s310 (Turion 64x2), hwclock --debug shows the same error message.

The problem appears after shutting down and restarting, not after reboot.

Hwinfo sais (I hope this is the releveant part):

[...]
06: None 00.0: 0802 Timer (8254)
  [Created at misc.230]         
  Unique ID: rdCR.AJKleuxpiP0   
  Hardware Class: unknown       
  Model: "Timer"                
  IRQ: 0 (83 events)            
  Config Status: cfg=new, avail=yes, need=no, active=unknown
[...]

There is no such problem on my desktop pc (Athlon XP 2100+).

Update to comment #2:

Using hwclock with the --debug option :

Linux1:/home/amigaphil # hwclock --show --debug
hwclock de util-linux-ng 2.13.1
Utilisant /dev interface to clock.
Le dernier ajustement de dérive a été fait 1218121440 secondes après 1969
La dernière calibration a été faite 1218121440 secondes après 1969
L'horloge matérielle fonctionne selon le temps UTC
On assume que l'horloge matérielle est conservée dans le temps de UTC.
En attente d'un tic d'horloge...
/dev/rtc n'a pas de fonction d'interruptionAttente dans un boucle pour que le
temps /dev/rtc se modifie
...a obtenu un tic d'horloge
Heure lu de l'horloge matérielle: 2008/08/07 19:55:37
Heure de l'horloge matérielle : 2008/08/07 19:55:37 = 1218138937 secondes
depuis 1969
jeu. 07 août 2008 21:55:37 CEST  -1.026962 secondes

So I now know my hardware clock is properly set to UTC time, and the system
clock is properly adjusted to local time.
What should I check to see what is modifying the clock during boot/shutdown ?

Note: I don't have any problem with the hwclock command.  My machine is a x86-32.

Update to comment #2 and comment #4 :

Again, my computer clock was about 1 hour 15 (?) late when I switched it on today.  I fixed the clock again, and restarted the computer.  The system clock was then still correct.
So it appears that indeed the corruption of the clock happen after a cold boot only...

If it can help to help:
- /etc/sysconfig/clock has SYSTOHC="yes"

- /etc/init.d/boot.clock is doing (I guess) at boot :
  echo -n Setting up the hardware clock
  #
  # Read out to hardware clock and for UTC calculate adjtime
  # write back the system time later at reboot/shutdown time.
  #
  if test "$SYSTOHC" = yes -a "$USE_ADJFILE" = yes ; then
    # For UTC calculate adjtime
    #
    if test ! -s /etc/adjtime ; then
        echo "0.0 0 0.0"	>  /etc/adjtime
        echo "0"		>> /etc/adjtime
        echo "UTC"		>> /etc/adjtime
    fi
    /sbin/hwclock --adjust $HWCLOCK
    rc_status
  fi
  /sbin/hwclock --hctosys $HWCLOCK
  rc_status -v -r

- /etc/adjtime has this :
  -10808.673458 1218205656 0.000000
  1218205599
  UTC

- the "11 minute mode" is off ('adjtimex --print' shows the line 'status: 64').

I assume that adjtime is maybe what is modifying my hardware clock.  According to hwclock's man pages, the first value indicate that my computer has a systematic drift rate of 10808 seconds per day (that is 3 hours !?!) but that does not match with the "1 hour 15 late" my system clock was at boot.


---

To Khairul Kamal Idris, Cyril Brosch :

Have you checked the man pages of hwclock ?  I saw a section about the RTC device that may help.

       --rtc=filename
              overrides the default /dev file name, which is /dev/rtc on  many
              platforms but may be /dev/rtc0, /dev/rtc1, and so on.

[...]

       hwclock  Uses many different ways to get and set Hardware Clock values.
       The most normal way is to do I/O to the device special  file  /dev/rtc,
       which is presumed to be driven by the rtc device driver.  However, this
       method is not always available.  For one thing, the  rtc  driver  is  a
       relatively  recent  addition  to  Linux.   Older systems don't have it.
       Also, though there are versions of the rtc  driver  that  work  on  DEC
       Alphas,  there  appear  to  be plenty of Alphas on which the rtc driver
       does not work (a common symptom is hwclock hanging).  Moreover,  recent
       Linux  systems  have  more  generic support for RTCs, even systems that
       have more than one, so you might need to override the default by speci-
       fying /dev/rtc0 or /dev/rtc1 instead.

[...]

       hwclock tries to use /dev/rtc.  If it is compiled  for  a  kernel  that
       doesn't  have  that  function  or it is unable to open /dev/rtc (or the
       alternative special file you've defined on the  command  line)  hwclock
       will  fall  back  to  another method, if available.  On an ISA or Alpha
       machine, you can force hwclock to use the direct  manipulation  of  the
       CMOS  registers without even trying /dev/rtc by specifying the --direc-
       tisa option.

@Philippe

I don't have rtc (rtc0 etc.) in /dev, nor do I have /dev/adjtime :-?

The driver is present (/lib/modules/2.6.25.11-0.1-default/kernel/drivers/rtc), but seemingly not installed automatically.

@Cyril

So far, it's not abnormal you don't have a /dev/adjtime file yet.  This file is created by hwclock, and as hwclock is failing due to a missing /dev/rtc ...

However, I can't tell why you don't have a rtc device (it seems the /dev/rtc is only missing in x86-64 installation).

Can you try this ?
hwclock --show --debug --directisa


---

Again, my system clock was 1 hour 15 (closer to 1 hour 20 now) late when I switch my computer on.  I didn't change the clock, but shut it down, and switch it on again.  To my surprise, the system clock was still 1 hour 15 late, not 2 hour 30 as I thought it would be.  But then, I remembered that hwclock skip any calibration if there is less than 24 hours elapsed.
So I fixed the clock once more; then, as root, I edited the /etc/adjtime file to reset all values to 0.  Finally, I saved the system clock to the hardware clock (hwclock --systohc) so that the /etc/adjtime is restored with the right values, but without that ugly "-10808.673458" systematic drift rate (which is now equal to 0).
I'll see tomorrow if my system clock is correct or not...

@Philippe

hwclock --debug --show --directisa shows just the same message as hwclock --debug, namely
"hwclock from util-linux-ng 2.13.1
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method."

@Cyril

Just curious (I mean, not sure it will help), do you have a /dev/adb ?
If yes, could you check if a hwclock --debug --show --rtc=/dev/adb
gives any better result ?

On the topic of the "missing /dev/rtc", I found that there was already a bug #326490 report about this.  Maybe you can check and re-open it ?

@Philippe 

Sorry, I don have /dev/adb, too.

I tried several things from the other thread, without success. In fact $modprobe rtc_cmos (resp. _lib, resp. _core) makes the error message at shutting down (couldn set hardware clock to system time) dissapear, but in fact it doesn't help, after cold boot the system can't get the hardware time again.

For curiosity, I copied the rtc0 from my working 11.0 to the notebook - after boot the system clock was even 4 hours ahead..
I synchronized the clock via NTP, after the next boot rtc0 wasn't anymore in /dev, I don't know how it disappeared. :-?

Today, the system clock was correct when I switched on my computer.  So it seems it was the systematic drift rate in /etc/adjtime that makes the clock step back once per day at boot up.  I still find it strange that a "-10808.673458" second per day (3 hours; I wonder how such a value has been set there) as systematic drift rate makes my system clock back by 1 hour 15 (-4500 seconds)...


---

@Cyril

I don't know much about Linux, and even less about the RTC device, but I believe that something is going wrong when you boot (one of the init scripts), and that is what is making /dev/rtc "missing".  

In a forum about Ubuntu, I read that someone has fixed the problem he had with RTC errors by changing the Timer frequency.  Here, in the bug #326490 discussion, there is also a suggestion about changing the Timer frequency...

Bug #326490 has been closed as Resolved and Fixed since OpenSUSE 10.3, in September 2007.  However, from what you are reporting here, it seems the same (?) bug is still present in OpenSUSE 11.0 (for x86-64).  As, AFAIK, the rule for duplicate bug reports is to keep the first submitted one, wouldn't be a good idea to re-open bug #326490 ?


---

@Greg

Do you still need the output of 'hwinfo' from the reporter ?

@Philippe

Changing timer frequency failed, for /proc/sys/dev/rtc/max-user-freq is missing, too.

I've re-opened the other bug therad.

*** This bug has been marked as a duplicate of bug 326490 ***

Today, my system clock is wrong again: 30 MINUTES LATE ?!?

Ok, there have been 2 issues discussed here.
The first one is related to the "missing /dev/rtc" problem introduced by the bug reporter.  (See bug #326490 for follow up)
The second issue introduced by me (see comment #2) is unrelated (no "missing /dev/rtc).
So I leave THIS bug report closed (duplicate of bug 326490), 
and open a new bug report for the second issue.  (See bug #416360)