Discussion:
clock messed up
Giuseppe Ghibò
2006-07-13 10:55:44 UTC
Permalink
Anyone knows a way to fix clock problems which occurs into
kernel 2.6.12-22mdksmp (x86-64)? Basically under
motherboard MSI K8N Diamond, and MSI K8N Diamond plus
(the same happens on three different machines so sound
a problem of our kernel), the internal clock is not
going to be right (and even trying to sincronize
to an external source using NTP is not enough, since
the drift happens anyway). The
differences between internal clock and right clock
goes after one day to 8-10 hours.

I tried to boot the machines specifying on both the option
clock=tsc in lilo.conf, but it's not enough. The error
between internal clock and official time is always high.

Is there a way to fix this? And why ntp is not enough
to keep the time in sync?

Thanks
Bye
Giuseppe.
Luiz Fernando N. Capitulino
2006-07-13 12:54:37 UTC
Permalink
Hi Giuseppe,

On Thu, 13 Jul 2006 12:55:44 +0200
Giuseppe Ghibò <***@mandriva.com> wrote:

| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
|
| I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
|
| Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?

You can try two boot options:

enable_timer_pin_1=1

or

disable_timer_pin_1=1
--
Luiz Fernando N. Capitulino
Thomas Backlund
2006-07-13 13:03:05 UTC
Permalink
Post by Luiz Fernando N. Capitulino
Hi Giuseppe,
On Thu, 13 Jul 2006 12:55:44 +0200
| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
|
| I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
|
| Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?
enable_timer_pin_1=1
or
disable_timer_pin_1=1
If IRC nVidia posted a fix for the timer problems they had that none of
the then known workarounds not fixed completely...
I'll try to dig it up and see...

--
Thomas
Giuseppe Ghibò
2006-07-13 20:44:33 UTC
Permalink
Post by Thomas Backlund
Post by Luiz Fernando N. Capitulino
Hi Giuseppe,
On Thu, 13 Jul 2006 12:55:44 +0200
| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
| | I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
| | Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?
enable_timer_pin_1=1
or
disable_timer_pin_1=1
If IRC nVidia posted a fix for the timer problems they had that none of
the then known workarounds not fixed completely...
I'll try to dig it up and see...
When you mention nVidia, you mean chipset (e.g. NForce4) or video
card?

Bye
Giuseppe.
Thomas Backlund
2006-07-13 20:50:43 UTC
Permalink
Post by Giuseppe Ghibò
Post by Thomas Backlund
Post by Luiz Fernando N. Capitulino
Hi Giuseppe,
On Thu, 13 Jul 2006 12:55:44 +0200
| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
| | I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
| | Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?
enable_timer_pin_1=1
or
disable_timer_pin_1=1
If IRC nVidia posted a fix for the timer problems they had that none
of the then known workarounds not fixed completely...
I'll try to dig it up and see...
When you mention nVidia, you mean chipset (e.g. NForce4) or video
card?
Bye
Giuseppe.
It was chipset-related...
I'll try to find the patches again and build a testkernel based on
2.6.12.23mdk for you....

--
Thomas
Giuseppe Ghibò
2006-07-14 06:02:13 UTC
Permalink
Post by Thomas Backlund
Post by Giuseppe Ghibò
Post by Thomas Backlund
Post by Luiz Fernando N. Capitulino
Hi Giuseppe,
On Thu, 13 Jul 2006 12:55:44 +0200
| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
| | I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
| | Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?
enable_timer_pin_1=1
or
disable_timer_pin_1=1
If IRC nVidia posted a fix for the timer problems they had that none
of the then known workarounds not fixed completely...
I'll try to dig it up and see...
When you mention nVidia, you mean chipset (e.g. NForce4) or video
card?
Bye
Giuseppe.
It was chipset-related...
I'll try to find the patches again and build a testkernel based on
2.6.12.23mdk for you....
Anyway the enable_timer_pin_1=1 has no effect. Booting and using
then the command:

watch -n 1 "ntpdate -d <timesource> 2>&1|grep offset"

will show a drift of 0.1s or 0.01s growing every second, while
in a normal machine this drift doesn't grow every second and
is usually < 0.0001s.

Booting with disable_timer_pin_1=1 seems not working at all (I'll
see what happened, but machine was no longer accessible).

Bye
Giuseppe.
Thomas Backlund
2006-07-30 17:09:23 UTC
Permalink
Finally a testkernel set I'm happy with for you to try:
http://tmb.kkc.fi/Kernels/2006.0/tmb/x86_64/

The i586 set is still building...

And the patches are here:
http://tmb.kkc.fi/Kernels/2006.0/tmb/patches/

I've tested the powernow-k8 on Turion64 / ATI Chipset and Athlon64/ nForce3
chipset and it works perfect....
I couldn't check my AthlonX2 /nForce4 workstation for now as It's otherwise
occupied for now...


* Sun Jul 30 11:00:00 2006 Thomas Backlund <***@mandriva.org>
2.6.12-25.tmb1mdk
- based on 2.6.12.25-uc1mdk
- redo patch CD02_mdk_logo.patch: s/MandrakeSoft/Mandriva/g
- Add fixes and updates for nVidia:
- CA08_nVidia_32bit_platform_HPET_operation_fix.patch
- CA09_nVidia_64bit_platform_HPET_operation_fix.patch
- DI22_nForce_MCP55-61-65.patch
- DU31_nForce_USB_EHCI_mem_over_2GB_workaround.patch
- HB17_powernow-k8_v2.00.00.patch
- HB19_Make_powernow-k7_work_on_SMP_kernels.patch
- HB20_cpufreq-nforce2_minimum_PLL_divider_to_2.patch
- Other bugfixes:
- DA93_alsa_hda_intel_Realtek_Asus_W6A.patch (#19962)
- MD06_enable_LIRC_SERIAL_TRANSMITTER.patch (#21434)
- additional support:
- DI20_ati_sb600_ide_support.patch
- DI21_alim15x3_ide_m1673_sb_support.patch
- DN89_sundance_add_uli_m1689.patch


Please report if it works ... (or not)
(I'll post the testkenel links in MDV Bugzilla as soon as i586 are built...)

Have fun
--
Thomas
Giuseppe Ghibò
2006-07-31 16:19:40 UTC
Permalink
Post by Thomas Backlund
http://tmb.kkc.fi/Kernels/2006.0/tmb/x86_64/
The i586 set is still building...
http://tmb.kkc.fi/Kernels/2006.0/tmb/patches/
I've tested the powernow-k8 on Turion64 / ATI Chipset and Athlon64/ nForce3
chipset and it works perfect....
I couldn't check my AthlonX2 /nForce4 workstation for now as It's otherwise
occupied for now...
2.6.12-25.tmb1mdk
- based on 2.6.12.25-uc1mdk
- redo patch CD02_mdk_logo.patch: s/MandrakeSoft/Mandriva/g
- CA08_nVidia_32bit_platform_HPET_operation_fix.patch
- CA09_nVidia_64bit_platform_HPET_operation_fix.patch
- DI22_nForce_MCP55-61-65.patch
- DU31_nForce_USB_EHCI_mem_over_2GB_workaround.patch
- HB17_powernow-k8_v2.00.00.patch
- HB19_Make_powernow-k7_work_on_SMP_kernels.patch
- HB20_cpufreq-nforce2_minimum_PLL_divider_to_2.patch
- DA93_alsa_hda_intel_Realtek_Asus_W6A.patch (#19962)
- MD06_enable_LIRC_SERIAL_TRANSMITTER.patch (#21434)
- DI20_ati_sb600_ide_support.patch
- DI21_alim15x3_ide_m1673_sb_support.patch
- DN89_sundance_add_uli_m1689.patch
Which one is the patch for the clock? BTW, I've seen you
added a patch for newer MCP55. I had a similar thing, but
seems the forcedeth driver was left out, see old mines:

http://peoples.mandriva.com/~ghibo/DN83_forcedeth_mcp55_support.patch
http://peoples.mandriva.com/~ghibo/DI20_sata_nv_mcp51_55_support.patch

Bye
Giuseppe.
Giuseppe Ghibò
2006-07-31 16:48:39 UTC
Permalink
Post by Thomas Backlund
http://tmb.kkc.fi/Kernels/2006.0/tmb/x86_64/
The i586 set is still building...
http://tmb.kkc.fi/Kernels/2006.0/tmb/patches/
I've tested the powernow-k8 on Turion64 / ATI Chipset and Athlon64/ nForce3
chipset and it works perfect....
I couldn't check my AthlonX2 /nForce4 workstation for now as It's otherwise
occupied for now...
2.6.12-25.tmb1mdk
- based on 2.6.12.25-uc1mdk
- redo patch CD02_mdk_logo.patch: s/MandrakeSoft/Mandriva/g
- CA08_nVidia_32bit_platform_HPET_operation_fix.patch
- CA09_nVidia_64bit_platform_HPET_operation_fix.patch
- DI22_nForce_MCP55-61-65.patch
- DU31_nForce_USB_EHCI_mem_over_2GB_workaround.patch
- HB17_powernow-k8_v2.00.00.patch
- HB19_Make_powernow-k7_work_on_SMP_kernels.patch
- HB20_cpufreq-nforce2_minimum_PLL_divider_to_2.patch
- DA93_alsa_hda_intel_Realtek_Asus_W6A.patch (#19962)
- MD06_enable_LIRC_SERIAL_TRANSMITTER.patch (#21434)
- DI20_ati_sb600_ide_support.patch
- DI21_alim15x3_ide_m1673_sb_support.patch
- DN89_sundance_add_uli_m1689.patch
Please report if it works ... (or not)
(I'll post the testkenel links in MDV Bugzilla as soon as i586 are built...)
Sound that the fix for clock is not enough. With
2.6.12-25.tmb1mdksmp, running:

watch -n 1 "ntpdate -d <timesource> 2>&1|grep offset"

will show that after a few minutes (3-4) the drift is already >= 0.1s,
while on a working machine it won't go beyond 0.001s. Which means
clock is 100-1000 times less precise.

Bye
Giuseppe.
Thomas Backlund
2006-07-31 21:32:47 UTC
Permalink
Post by Giuseppe Ghibò
Sound that the fix for clock is not enough. With
watch -n 1 "ntpdate -d <timesource> 2>&1|grep offset"
will show that after a few minutes (3-4) the drift is already >= 0.1s,
while on a working machine it won't go beyond 0.001s. Which means
clock is 100-1000 times less precise.
Are you using powernow-k7 & powernowd ?

If not, can you try it?

If you are using them, can you try without them ?

Does it make any difference?

The reason I ask is that I read on VMVare forum that the AMD Cool&Quiet
driver fixed similar problems on Windows XP x64 edition...

The powernow-k8 is the closest thing we have to that...

BTW,
I have a MSI K8N Neo4-FI with an AthlonX2 3800+ that I'll be installing
2007 Beta1 on in Tomorrow or the day after, so I'll install a 2006.0 too
to have an own testsystem ;-)

--
Thomas
Giuseppe Ghibò
2006-08-01 10:03:25 UTC
Permalink
Post by Thomas Backlund
Post by Giuseppe Ghibò
Sound that the fix for clock is not enough. With
watch -n 1 "ntpdate -d <timesource> 2>&1|grep offset"
will show that after a few minutes (3-4) the drift is already >= 0.1s,
while on a working machine it won't go beyond 0.001s. Which means
clock is 100-1000 times less precise.
Are you using powernow-k7 & powernowd ?
No.
Post by Thomas Backlund
If not, can you try it?
no, which version? Note that I'm not on cooker and
there isn't the powernow package. Which version should
be backported?
Post by Thomas Backlund
If you are using them, can you try without them ?
Does it make any difference?
The reason I ask is that I read on VMVare forum that the AMD Cool&Quiet
driver fixed similar problems on Windows XP x64 edition...
The powernow-k8 is the closest thing we have to that...
On 2007.0 (but not the same motherboard) powernow has the
side effect of dropping the clock from 2.4 to 1.0Ghz on both cores.

Bye
Giuseppe.
Thomas Backlund
2006-08-01 11:29:18 UTC
Permalink
Post by Giuseppe Ghibò
Post by Thomas Backlund
Post by Giuseppe Ghibò
Sound that the fix for clock is not enough. With
watch -n 1 "ntpdate -d <timesource> 2>&1|grep offset"
will show that after a few minutes (3-4) the drift is already >= 0.1s,
while on a working machine it won't go beyond 0.001s. Which means
clock is 100-1000 times less precise.
Are you using powernow-k7 & powernowd ?
That was of course powernow-k8..
Post by Giuseppe Ghibò
No.
Post by Thomas Backlund
If not, can you try it?
no, which version? Note that I'm not on cooker and
there isn't the powernow package. Which version should
be backported?
It already exists atleast Community Contrib for 2006 x86_64
Post by Giuseppe Ghibò
Post by Thomas Backlund
If you are using them, can you try without them ?
Does it make any difference?
The reason I ask is that I read on VMVare forum that the AMD
Cool&Quiet driver fixed similar problems on Windows XP x64 edition...
The powernow-k8 is the closest thing we have to that...
On 2007.0 (but not the same motherboard) powernow has the
side effect of dropping the clock from 2.4 to 1.0Ghz on both cores.
Yep.
Thats why you need the powernowd demon to manage the powernow-k8 module...

It works great here
...
Thomas
Giuseppe Ghibò
2006-08-01 16:11:30 UTC
Permalink
Post by Thomas Backlund
It already exists atleast Community Contrib for 2006 x86_64
Doesn't work:

# urpmi powernowd-0.96-2mdk.x86_64.rpm

powernowd: Found 2 cpus: -- 1 thread (or core) per physical cpu
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory

as well as:

# modprobe powerknow-k8:

FATAL: Error inserting powernow-k8
(/lib/modules/2.6.12-25.tmb1mdksmp/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko.gz):
No such device

Bye
Giuseppe.
Thomas Backlund
2006-08-01 18:02:40 UTC
Permalink
Post by Giuseppe Ghibò
Post by Thomas Backlund
It already exists atleast Community Contrib for 2006 x86_64
# urpmi powernowd-0.96-2mdk.x86_64.rpm
powernowd: Found 2 cpus: -- 1 thread (or core) per physical cpu
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory
This happends beacuse of the second error below...
Post by Giuseppe Ghibò
FATAL: Error inserting powernow-k8
No such device
What processor do you have ??

The powernow-k8 v2.00.00 is supposed to work with every amd 64bit
processor, including a branch that is not even released yet...


--
Thomas
Giuseppe Ghibò
2006-08-01 22:05:30 UTC
Permalink
Post by Thomas Backlund
What processor do you have ??
The powernow-k8 v2.00.00 is supposed to work with every amd 64bit
processor, including a branch that is not even released yet...
4800-X2
Giuseppe Ghibò
2006-08-03 10:58:25 UTC
Permalink
Post by Thomas Backlund
2.6.12-25.tmb1mdk
- based on 2.6.12.25-uc1mdk
- redo patch CD02_mdk_logo.patch: s/MandrakeSoft/Mandriva/g
- CA08_nVidia_32bit_platform_HPET_operation_fix.patch
- CA09_nVidia_64bit_platform_HPET_operation_fix.patch
- DI22_nForce_MCP55-61-65.patch
- DU31_nForce_USB_EHCI_mem_over_2GB_workaround.patch
- HB17_powernow-k8_v2.00.00.patch
- HB19_Make_powernow-k7_work_on_SMP_kernels.patch
- HB20_cpufreq-nforce2_minimum_PLL_divider_to_2.patch
- DA93_alsa_hda_intel_Realtek_Asus_W6A.patch (#19962)
- MD06_enable_LIRC_SERIAL_TRANSMITTER.patch (#21434)
- DI20_ati_sb600_ide_support.patch
- DI21_alim15x3_ide_m1673_sb_support.patch
- DN89_sundance_add_uli_m1689.patch
FYI the drift with that kernel is now more than -7800 seconds in 2 days of wake
up time. It's not a matter than 1 second per hours or like that...That's almost
3 minutes per hour.

Bye
Giuseppe.

Giuseppe Ghibò
2006-07-13 20:43:14 UTC
Permalink
Post by Luiz Fernando N. Capitulino
Hi Giuseppe,
On Thu, 13 Jul 2006 12:55:44 +0200
| Anyone knows a way to fix clock problems which occurs into
| kernel 2.6.12-22mdksmp (x86-64)? Basically under
| motherboard MSI K8N Diamond, and MSI K8N Diamond plus
| (the same happens on three different machines so sound
| a problem of our kernel), the internal clock is not
| going to be right (and even trying to sincronize
| to an external source using NTP is not enough, since
| the drift happens anyway). The
| differences between internal clock and right clock
| goes after one day to 8-10 hours.
|
| I tried to boot the machines specifying on both the option
| clock=tsc in lilo.conf, but it's not enough. The error
| between internal clock and official time is always high.
|
| Is there a way to fix this? And why ntp is not enough
| to keep the time in sync?
enable_timer_pin_1=1
I will try this. Thanks.
Post by Luiz Fernando N. Capitulino
or
disable_timer_pin_1=1
Bye
Giuseppe.
patrick
2006-07-13 14:18:47 UTC
Permalink
Post by Giuseppe Ghibò
Anyone knows a way to fix clock problems which occurs into
kernel 2.6.12-22mdksmp (x86-64)? Basically under
motherboard MSI K8N Diamond, and MSI K8N Diamond plus
(the same happens on three different machines so sound
a problem of our kernel), the internal clock is not
going to be right (and even trying to sincronize
to an external source using NTP is not enough, since
the drift happens anyway). The
differences between internal clock and right clock
goes after one day to 8-10 hours.
I tried to boot the machines specifying on both the option
clock=tsc in lilo.conf, but it's not enough. The error
between internal clock and official time is always high.
Is there a way to fix this? And why ntp is not enough
to keep the time in sync?
Thanks
Bye
Giuseppe.
i am having the same problem. the game nexiuz will play
just fine while armagetronad will not.

i just run regular kernel for now.

i read a couple of days ago that amd released a driver
fix for the dual cores for windoes because they had the same
problem.

sorry i cant help u more.
patrick
2006-07-14 00:25:06 UTC
Permalink
Post by Giuseppe Ghibò
Anyone knows a way to fix clock problems which occurs into
kernel 2.6.12-22mdksmp (x86-64)? Basically under
motherboard MSI K8N Diamond, and MSI K8N Diamond plus
(the same happens on three different machines so sound
a problem of our kernel), the internal clock is not
going to be right (and even trying to sincronize
to an external source using NTP is not enough, since
the drift happens anyway). The
differences between internal clock and right clock
goes after one day to 8-10 hours.
I tried to boot the machines specifying on both the option
clock=tsc in lilo.conf, but it's not enough. The error
between internal clock and official time is always high.
Is there a way to fix this? And why ntp is not enough
to keep the time in sync?
Thanks
Bye
Giuseppe.
i am having the same problem. the only fix i know for now
is not to run smp kernel.

if i use smp my clock runs fast and armagetronad, the game
i play the most, the motorcycles just take off and run much
to fast and u dont have any control of the game.

nexuiz plays fine though.

i did read something a couple of days ago that amd released
a driver for windoes that brings theis problem which is in windoes
environments under control.
Loading...