# Setting system clock to hardware clock -> Reboot

## Silenzium

Everytime I boot my computer, it reboots after printing "Setting system clock to hardware clock [Local Time] ..." The second time it passes this step without problems. This procedure returns with the next reboot.

I always need two (or three, see below) startups to use my Gentoo box. It doesn't kill me, but it's extremly annoying.   :Mad: 

I just upgraded gentoo-sources from 2.6.11 to 2.6.13 which didn't fix the problem.

"crc errors" and "invalid compression format"-errors also occur randomly.

I'm using a AMD Athlon XP on a ASUS A7V333 motherboard, if it helps.

```

# /etc/conf.d/clock

# Set CLOCK to "UTC" if your system clock is set to UTC (also known as

# Greenwich Mean Time).  If your clock is set to the local time, then

# set CLOCK to "local".

CLOCK="local"

# If you wish to pass any other arguments to hwclock during bootup,

# you may do so here.

CLOCK_OPTS=""

# If you want to set the Hardware Clock to the current System Time

# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="no"

```

Last edited by Silenzium on Sun Jan 08, 2006 4:53 pm; edited 2 times in total

----------

## Silenzium

I should add that it wasn't always like that, but I often switch on my computer and don't look at him, so I don't know when the problem occured.

Any idea?

----------

## Silenzium

Not yet solved. Could someone please help me?

----------

## arghnoname

What does 

```
hwclock --debug
```

 do?

----------

## augury

i have this in /etc/conf.d/local.start

```
ntpdate 128.118.25.3

rm /etc/localtime

ln -sf /usr/share/zoneinfo/posix/America/New_York /etc/localtime

hwclock --localtime --systohc
```

----------

## arghnoname

hwclock is what is called during bootup on most machines and calling it with the --debug flag gives you some more verbose information. I had a problem once with the time and it is how I figured out that I just was missing a kernel module.

----------

## alex6z

sounds like buggy hardware.  Is anything over clocked? faulty memory?  The crc errors thing make me think of this.  Since you aren't getting random Seg faults, I don't think it could be the CPU or memory.  but who knows.  A hardware conflict with the IO port of the hardware clock? bad bios option triggering this conflict? Some isa board is shorting the RESET line when you use that IO port to set the clock?  reboot in single user mode and run hwclock by hand.

----------

## Silenzium

 *arghnoname wrote:*   

> hwclock is what is called during bootup on most machines and calling it with the --debug flag gives you some more verbose information. I had a problem once with the time and it is how I figured out that I just was missing a kernel module.

 

Do you remember the kernel module?

Here is the output of "hwclock --debug":

```
hwclock from util-linux-2.12r

Using /dev/rtc interface to clock.

Last drift adjustment done at 1129976768 seconds after 1969

Last calibration done at 1124040813 seconds after 1969

Hardware clock is on local time

Assuming hardware clock is kept in local time.

Waiting for clock tick...

...got clock tick

Time read from Hardware Clock: 2005/10/22 14:35:28

Hw clock time : 2005/10/22 14:35:28 = 1129984528 seconds since 1969

Sat 22 Oct 2005 02:35:28 PM CEST  -0.922365 seconds

```

 *alex6z wrote:*   

> sounds like buggy hardware.  Is anything over clocked? faulty memory?  The crc errors thing make me think of this.  Since you aren't getting random Seg faults, I don't think it could be the CPU or memory.  but who knows.  A hardware conflict with the IO port of the hardware clock? bad bios option triggering this conflict? Some isa board is shorting the RESET line when you use that IO port to set the clock?  reboot in single user mode and run hwclock by hand.

 

Nothing is over clocked. How do I check, if my memory is faulty?

----------

## Silenzium

Tried to reset to BIOS defaults and to boot with one of my two memory chips removed, but it didn't help.

----------

## arghnoname

The kernel was RTC support (or some such thing), but from the output of --debug, it looks like you have it. 

It might be something that occurs on bootup after the clock is set, as --debug doesn't flag any warnings of note. I'd cast your net in that direction, though honestly I can't tell you what it may be.

----------

## alex6z

When I refer to your problem, I am using the work 'resets' meaning your computer does just that.

The trick is finding out exactly when it resets(crashes whatever). It could be the thing just before or after setting hardware clock.  Try # rc-update del clock boot (don't forget to add it again) and see if it still resets with out the clock.  If it doesn't, run /etc/init.d/clock start  and try to reproduce the problem.  Then, hwclock --hwtosys(?) to try to reproduce it again.  Then try removing hardware, especially ISA if you have any.  I was just thinking of a watchdog times. maybe you have a software or hardware watchdog timer that is reseting the computer, somehow getting activated by setting the clock?  For testing your memory, boot off the liveCD and run memtest86.

----------

## Silenzium

"# rc-update del clock boot" doesn't help. My computer reboots the first time and the second time "Setting system clock to hardware clock ..." appears even twice.

My memory is ok, I testet it several times.

I don't have ISA-cards in my computer.

----------

## matlj

I have exactly the same reboot problem. I didn't post about it because it always works correctly the second time, but now I see that I'm not alone..  I'm running 2.6.14-ck4 on ~amd64.

----------

## azmotus

I had this same problem about a year ago, it then disappeared but now it's back again. I can't tell what package upgrade fixed it the first time, because this computer gets rebooted so rarely.   :Confused: 

----------

## alex6z

Try to boot into single user mode. I forget how to do this... putting single on the kernel coptions list used to work.  If it resets that way too, then the problem has to be kernel related.  IF it doesn't, try init 3 to go regular or /etc/init.d/clock start and see if that will reset it.

----------

## Al_Kane

I now have the same restart problem after upgrading my baselayout last night. 

It restarts on the first boot right after the "Setting system clock...", but it boots okay on the second try. 

I am using the default /etc/conf.d/clock config, except that I set CLOCK="local".

Any ideas?

----------

## bedazzled

glad to see i am not alone  :Razz: 

same problem here, it happened after upgrading the baselayout (i switched from arch to ~arch testing, x86 laptop and amd64 desktop)

i also have local time instead of UTC...

maybe we should file a bug report?

----------

## spiralvoice

Same here...

----------

## Vla

On my notebook I have the same error. I can't reproduce it, it appears irregularly.

----------

## Al_Kane

I'm still having the same restart problem... and I'm also on a laptop.

I upgraded my baselayout (1.12.0_pre12) and linux kernel (gentoo-sources-2.6.14-r5) a couple of days ago, but that didn't fix it. 

The only thing that's worked so far is to boot up an older kernel (linux-2.6.5-gentoo-r1). 

I now think this may be related to a new power management kernel option (e.g. sleep, suspend, etc...) because someone else had a similar problem.

I'm not using suspend-sources though, so that thread didn't help me out too much.

----------

## kpep01

Augury,

Interesting code you offered. I've been wondering and looking for ntp stuff to emerge (on a limited and unsuccesful basis).

If I'm understanding your code correctly, this should automatically set my clock to the current and correct time, and allow the system time to override the hwclock. it will further create the proper links for the system to read the timezone (which, I believe, is already set on my system).

Just two questions:

1) in your final command, what does --systohc refer to and accomplish?

2) since I don't often reboot my computer (except for a kernal tweak, etc.) what is it that needs to be emerged so that ntp works on configured basis to insure consistant system time stability?

Thanx

----------

## spiralvoice

 *Vla wrote:*   

> it appears irregularly.

 

Here it appears all the time. Today I tested that:

- turned on PC

- worked some time in another OS

- rebooted to Gentoo

- Gentoo rebooted itself during startup when setting local time

- rebooted to another OS and worked there

- turned off PC for several hours

- turned on PC

- worked some time in another OS

- rebooted to Gentoo

- Gentoo booted well

This leads me to the conclusion that something is written to the HDD

during first boot which allows the second boot to succeed.

But what can that be? I have an ASUS A7N8X-X mobo which has

a nForce2 chipset. I read on several forums that this hardware

could have problems with the hardware clock on Linux.

Ah, I forgot:

 *Quote:*   

> # /etc/conf.d/clock
> 
> # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> 
> # Greenwich Mean Time).  If your clock is set to the local time, then
> ...

 

 *Quote:*   

> Portage 2.1_pre3-r1 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.5-r3, 2.6.13-gentoo-r5 i686)
> 
> =================================================================
> 
> System uname: 2.6.13-gentoo-r5 i686 AMD Athlon(tm) XP 2600+
> ...

 

----------

## kandid

This problem does not seem to be correlated with hwclock itself or the corresponding init script. I did some research on this by replacing /etc/init.d/clock with a complete harmless version (just counting down) and I can still see the machine rebooting.

So I had a look at bugzilla and found the following:

https://bugs.gentoo.org/show_bug.cgi?id=104139

And indeed after removing my NIC module (b44) from /etc/modules.autoload.d/kernel-2.6 no automatic reboot occurs.

After an upgrade to (masked) gentoo-sources-2.6.15 I could readd my NIC module

----------

## Al_Kane

Nice detective work kandid!!

I commented out my NIC module too (eepro100 in /etc/modules.autoload.d/kernel-2.6) and the reboot problem disappeared!!

Now here's the strange thing.... 

* My NIC is compiled in as a module (grep -i eepro100 /usr/src/linux/.config  -->  CONFIG_EEPRO100=m)

* My NIC module is commented out (grep -i eepro100 /etc/modules.autoload.d/kernel-2.6  -->  #eepro100)

* But, when I boot up, lsmod lists eepro100

Why is my NIC module autoloading? Anyone know why?

----------

## Silenzium

Not Solved! Look at my next post for details!

#YES! Upgrading to gentoo-sources-2.6.15 solved my problem.   :Very Happy: 

#

#btw: I don't have "eepro100" in /etc/modules.autoload.d/kernel-2.6.

#

#

#I'll put a [SOLVED] into the title, hoping that upgrading the kernel will solve the double-boot for most users. 

#Thanks for your help.

#

#(Now ivtv is broken, but that's a different story.  :Wink:  )Last edited by Silenzium on Sun Jan 08, 2006 4:53 pm; edited 1 time in total

----------

## spiralvoice

Updating to gentoo-sources-2.6.15 did not help.

I am using the nForce2 network connection provided

by my motherboard ASUS A7N8X-X with the forcedeth

driver compiled as module and loaded by

/etc/modules.autoload.d/kernel-2.6

It shows the same restart bug as with other kernel versions.

Compiling forcedeth driver into the kernel solved the problem.

No restart anymore!

I will test compiling it again as module and leave the

forcedeth line out of /etc/modules.autoload.d/kernel-2.6

as it worked that way for Al_Kane.

----------

## Silenzium

Damn, upgrading to 2.6.15 was not the solution.

I thought so, but that was before I solved the problem with ivtv and the new kernel. I rebooted several times for testing with a incompatible version of ivtv and kernel 2.6.15, so the module failed to load. After rebooting with ivtv correctly enabled again, I got the double-rebooting back. So I commented out ivtv in /etc/modules.autoload.d/kernel-2.6 and the double-reboot was gone.

Looks like we already have two modules (eepro100/ivtv) which make the compute boot twice.

Removing the [SOLVED]-tag again...   :Crying or Very sad: 

----------

## spiralvoice

 *Silenzium wrote:*   

> Looks like we already have two modules (eepro100/ivtv) which make the compute boot twice.

 

forcedeth makes it 3

----------

