[gentoo-user] clock problems software clock 20x fast

[gentoo-user] clock problems software clock 20x fast

[Noah J Norris]

my hardware clock stays correct but the software clock is like going 20x fast 
im on a laptop and using noapic the problem goes away but leads to other 
problems like  network problems happing like errors with internal ethernet 
card and ndiswrapper stops working . the processer is amd64 running as x86 
(32bit mode)  i get apic errors and lost tick errors .  if i leave this on 
for a couple hours it becomes days ahead can anyone shead some light on 
this ?  kernel being used is 2.6.14-r2 i believe


thanks

'hwclock --hctosys' works to set the time back to what the hardware clock says 

-- 
life is linux
linux is life
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Richard Fish]

On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> my hardware clock stays correct but the software clock is like going 20x fast
> im on a laptop and using noapic the problem goes away but leads to other
> problems like  network problems happing like errors with internal ethernet
> card and ndiswrapper stops working . the processer is amd64 running as x86
> (32bit mode)  i get apic errors and lost tick errors .  if i leave this on
> for a couple hours it becomes days ahead can anyone shead some light on
> this ?  kernel being used is 2.6.14-r2 i believe

A couple of things to investigate:

1. Make sure that the first line of /etc/adjtime contains very small
values.  In fact, you might just want to replace the first line with
"0.0 0 0.0".

2. Take a look at the clock= settings in
/usr/src/linux/Documentation/kernel-parameters.txt.  Maybe you need
clock=pit.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Noah J Norris]

On Wednesday 14 December 2005 05:39 pm, Richard Fish wrote:
> On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> > my hardware clock stays correct but the software clock is like going 20x
> > fast im on a laptop and using noapic the problem goes away but leads to
> > other problems like  network problems happing like errors with internal
> > ethernet card and ndiswrapper stops working . the processer is amd64
> > running as x86 (32bit mode)  i get apic errors and lost tick errors .  if
> > i leave this on for a couple hours it becomes days ahead can anyone shead
> > some light on this ?  kernel being used is 2.6.14-r2 i believe
>
> A couple of things to investigate:
>
> 1. Make sure that the first line of /etc/adjtime contains very small
> values.  In fact, you might just want to replace the first line with
> "0.0 0 0.0".
i tried changeing this is this for the hardware clock drift ? i dont have any 
problem with the hardware clock its the software clock thats fast

>
> 2. Take a look at the clock= settings in
> /usr/src/linux/Documentation/kernel-parameters.txt.  Maybe you need
> clock=pit.
>
> -Richard

looking in this file saw some other options that may help the problem.
i have an ati chipset (newer laptop chipset) ouput of lspci below

0000:00:00.0 Host bridge: ATI Technologies Inc ATI Radeon Xpress 200 
(RS480/RS482/RX480/RX482) Chipset - Host bridge (rev 01)
0000:00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port
0000:00:06.0 PCI bridge: ATI Technologies Inc: Unknown device 5a38
0000:00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host 
Controller
0000:00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host 
Controller
0000:00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host 
Controller
0000:00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 11)
0000:00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE 
Controller ATI
0000:00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
0000:00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge
0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 
Audio Controller (rev 02)
0000:00:14.6 Modem: ATI Technologies Inc ATI SB400 - AC'97 Modem Controller 
(rev 02)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon 
Mobility X600]
0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast 
Ethernet Controller (rev 10)
0000:03:05.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 
01)
0000:03:07.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 
54g] 802.11g Wireless LAN Controller (rev 02)
0000:03:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 80)

some options i saw in that file that i may try

acpi_skip_timer_override [HW,ACPI]
                        Recognize and ignore IRQ0/pin2 Interrupt Override.
                        For broken nForce2 BIOS resulting in XT-PIC timer.

enable_timer_pin_1 [i386,x86-64]
                        Enable PIN 1 of APIC timer
                        Can be useful to work around chipset bugs
                        (in particular on some ATI chipsets).
                        The kernel tries to set a reasonable default.

        disable_timer_pin_1 [i386,x86-64]
                        Disable PIN 1 of APIC timer
                        Can be useful to work around chipset bugs.


-- 
life is linux
linux is life
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Richard Fish]

On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> On Wednesday 14 December 2005 05:39 pm, Richard Fish wrote:
> > 1. Make sure that the first line of /etc/adjtime contains very small
> > values.  In fact, you might just want to replace the first line with
> > "0.0 0 0.0".
> i tried changeing this is this for the hardware clock drift ? i dont have any
> problem with the hardware clock its the software clock thats fast

Oh, you are correct.  Sorry.

> >
> > 2. Take a look at the clock= settings in
> > /usr/src/linux/Documentation/kernel-parameters.txt.  Maybe you need
> > clock=pit.
>
> looking in this file saw some other options that may help the problem.
> i have an ati chipset (newer laptop chipset) ouput of lspci below
>

<snip>

>
> some options i saw in that file that i may try
>
> acpi_skip_timer_override [HW,ACPI]
>                         Recognize and ignore IRQ0/pin2 Interrupt Override.
>                         For broken nForce2 BIOS resulting in XT-PIC timer.
>
> enable_timer_pin_1 [i386,x86-64]
>                         Enable PIN 1 of APIC timer
>                         Can be useful to work around chipset bugs
>                         (in particular on some ATI chipsets).
>                         The kernel tries to set a reasonable default.
>
>         disable_timer_pin_1 [i386,x86-64]
>                         Disable PIN 1 of APIC timer
>                         Can be useful to work around chipset bugs.

I'm not sure these will help.  They seem to be more related to setting
up the frequency for the IRQ0 timer interrupt, for things like running
the scheduler.  This should not be related at all to the behavior of
gettimeofday.

I think if you were getting messages about lost ticks or got extra
ticks or something like that, these might be helpful, or if your
system seemed either to slow or too unresponsive.  Of course, if your
clock is defaulting to TSC (which would be bad, BTW), then I guess
these could have a big impact.

Take a look at dmesg or /var/log/messages for the following lines:

Using TSC for gettimeofday
Using HPET for gettimeofday
Using .* for high-res timesource

These will tell us what signal the kernel is using for gettimeofday on
your system.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Noah J Norris]

On Thursday 15 December 2005 02:03 am, Richard Fish wrote:
> On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> > On Wednesday 14 December 2005 05:39 pm, Richard Fish wrote:
> > > 1. Make sure that the first line of /etc/adjtime contains very small
> > > values.  In fact, you might just want to replace the first line with
> > > "0.0 0 0.0".
> >
> > i tried changeing this is this for the hardware clock drift ? i dont have
> > any problem with the hardware clock its the software clock thats fast
>
> Oh, you are correct.  Sorry.
>
> > > 2. Take a look at the clock= settings in
> > > /usr/src/linux/Documentation/kernel-parameters.txt.  Maybe you need
> > > clock=pit.
> >
> > looking in this file saw some other options that may help the problem.
> > i have an ati chipset (newer laptop chipset) ouput of lspci below
>
> <snip>
>
> > some options i saw in that file that i may try
> >
> > acpi_skip_timer_override [HW,ACPI]
> >                         Recognize and ignore IRQ0/pin2 Interrupt
> > Override. For broken nForce2 BIOS resulting in XT-PIC timer.
> >
> > enable_timer_pin_1 [i386,x86-64]
> >                         Enable PIN 1 of APIC timer
> >                         Can be useful to work around chipset bugs
> >                         (in particular on some ATI chipsets).
> >                         The kernel tries to set a reasonable default.
> >
> >         disable_timer_pin_1 [i386,x86-64]
> >                         Disable PIN 1 of APIC timer
> >                         Can be useful to work around chipset bugs.
>
> I'm not sure these will help.  They seem to be more related to setting
> up the frequency for the IRQ0 timer interrupt, for things like running
> the scheduler.  This should not be related at all to the behavior of
> gettimeofday.
>
> I think if you were getting messages about lost ticks or got extra
> ticks or something like that, these might be helpful, or if your
> system seemed either to slow or too unresponsive.  Of course, if your
> clock is defaulting to TSC (which would be bad, BTW), then I guess
> these could have a big impact.
>
i have gotton lost tick messages 
and apic errors mostly

> Take a look at dmesg or /var/log/messages for the following lines:
>
> Using TSC for gettimeofday
> Using HPET for gettimeofday
> Using .* for high-res timesource
Using pmtmr for high-res timesource

should an amd64 use HPET ? i do not have this enabled in kernel config  (note 
running in 32 bit mode ) 

>
> These will tell us what signal the kernel is using for gettimeofday on
> your system.
>
> -Richard
other thing i noticed in dmesg do i need to enable smp support in the kernel ?
this is a single processor system that i know of . does amd do any type of 
hyperthreading ?

found SMP MP-table at 000f8510
Using ACPI (MADT) for SMP configuration information

ouput of cat  /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 36
model name      : Mobile AMD Athlon(tm) 64 Processor 4000+
stepping        : 2
cpu MHz         : 2587.282
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 
3dnowext 3dnow pni lahf_lm
bogomips        : 5181.75
 
note here is an example of some errors about apic

APIC error on CPU0: 00(40)
APIC error on CPU0: 40(40)  # this get repeated alot

cat  /proc/interrupts 
0:   39865554    IO-APIC-edge  timer
  1:      23952    IO-APIC-edge  i8042
  8:          8    IO-APIC-edge  rtc
 12:    1559783    IO-APIC-edge  i8042
 14:     543485    IO-APIC-edge  ide0
 15:    1427625    IO-APIC-edge  ide1
 16:    1841139   IO-APIC-level  yenta, ndiswrapper
 17:       1419   IO-APIC-level  ATI IXP
 19:        124   IO-APIC-level  eth0
 20:          1   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3
 21:     453349   IO-APIC-level  acpi
NMI:          0
LOC:   19934340
ERR:         18  #notice errors here 
MIS:          0

-- 
life is linux
linux is life
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Richard Fish]

On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> On Thursday 15 December 2005 02:03 am, Richard Fish wrote:
> > I think if you were getting messages about lost ticks or got extra
> > ticks or something like that, these might be helpful, or if your
> > system seemed either to slow or too unresponsive.  Of course, if your
> > clock is defaulting to TSC (which would be bad, BTW), then I guess
> > these could have a big impact.
>
> i have gotton lost tick messages
> and apic errors mostly

Hmm, didn't you mention that somewhere already....oh yeah, your
orignal message!  (bangs head on desk).

Plus, you also said noapic fixes the problem, so forget everything I
said, and try these options.

> > Take a look at dmesg or /var/log/messages for the following lines:
> >
> > Using TSC for gettimeofday
> > Using HPET for gettimeofday
> > Using .* for high-res timesource
> Using pmtmr for high-res timesource

Looks good...pmtmr is what I get on my pentium-m laptop, and is the
default, and should be fairly reliable...

Did you try any other clock= options? Any better results?

> should an amd64 use HPET ? i do not have this enabled in kernel config  (note
> running in 32 bit mode )

Not sure about this one...just got my first AMD64 system this past
weekend, and I am still trying to get things setup...maybe someone
else can answer.

One other boot option that might help: no_timer_check

It is a x86_64 specific option (see
/usr/src/linux/Documentation/x86_64/boot-options.txt).  I don't think
this has anything to do with 32/64 bit code though...so maybe you have
this already (does your kernel build as x86_64/arch/boot/bzImage?)

> other thing i noticed in dmesg do i need to enable smp support in the kernel ?
> this is a single processor system that i know of . does amd do any type of
> hyperthreading ?

Nope, no hyperthreading in AMD.  And I think AMD is expected to
release their first dual-core mobile chips sometime next year. 
Unfortunately Intel is going to beat them to market and my wallet.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Noah J Norris]

ok its fixed its a bug with ati / nvidia chipsets making the clock 2x+ fast 
disable_timer_pin_1 fixes the clock ^^ 

On Wednesday 14 December 2005 09:04 pm, Richard Fish wrote:
> On 12/14/05, Noah J Norris <preludelinux@mchsi.com> wrote:
> > On Thursday 15 December 2005 02:03 am, Richard Fish wrote:
> > > I think if you were getting messages about lost ticks or got extra
> > > ticks or something like that, these might be helpful, or if your
> > > system seemed either to slow or too unresponsive.  Of course, if your
> > > clock is defaulting to TSC (which would be bad, BTW), then I guess
> > > these could have a big impact.
> >
> > i have gotton lost tick messages
> > and apic errors mostly
>
> Hmm, didn't you mention that somewhere already....oh yeah, your
> orignal message!  (bangs head on desk).
>
> Plus, you also said noapic fixes the problem, so forget everything I
> said, and try these options.
>
> > > Take a look at dmesg or /var/log/messages for the following lines:
> > >
> > > Using TSC for gettimeofday
> > > Using HPET for gettimeofday
> > > Using .* for high-res timesource
> >
> > Using pmtmr for high-res timesource
>
> Looks good...pmtmr is what I get on my pentium-m laptop, and is the
> default, and should be fairly reliable...
>
> Did you try any other clock= options? Any better results?
>
> > should an amd64 use HPET ? i do not have this enabled in kernel config 
> > (note running in 32 bit mode )
>
> Not sure about this one...just got my first AMD64 system this past
> weekend, and I am still trying to get things setup...maybe someone
> else can answer.
>
> One other boot option that might help: no_timer_check
>
> It is a x86_64 specific option (see
> /usr/src/linux/Documentation/x86_64/boot-options.txt).  I don't think
> this has anything to do with 32/64 bit code though...so maybe you have
> this already (does your kernel build as x86_64/arch/boot/bzImage?)
>
> > other thing i noticed in dmesg do i need to enable smp support in the
> > kernel ? this is a single processor system that i know of . does amd do
> > any type of hyperthreading ?
>
> Nope, no hyperthreading in AMD.  And I think AMD is expected to
> release their first dual-core mobile chips sometime next year.
> Unfortunately Intel is going to beat them to market and my wallet.
>
> -Richard

-- 
life is linux
linux is life
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[William Kenworthy]

Things to check:
are you using speedfreq or cpufreq? - if the kernel timing sets itself
when throtting is in effect, it may not be right when running fast

batterystat applets can cause problems with blocking in /proc - this
usually causes a loss in time, and I have not seen it with recent
kernels.

BillK

On Wed, 2005-12-14 at 11:30 +0000, Noah J Norris wrote:
> my hardware clock stays correct but the software clock is like going 20x fast 
> im on a laptop and using noapic the problem goes away but leads to other 
> problems like  network problems happing like errors with internal ethernet 
> card and ndiswrapper stops working . the processer is amd64 running as x86 
> (32bit mode)  i get apic errors and lost tick errors .  if i leave this on 
> for a couple hours it becomes days ahead can anyone shead some light on 
> this ?  kernel being used is 2.6.14-r2 i believe
> 
> 
> thanks
> 
> 'hwclock --hctosys' works to set the time back to what the hardware clock says 
> 
> -- 
> life is linux
> linux is life
-- 
William Kenworthy <billk@iinet.net.au>
Home!
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] clock problems software clock 20x fast

[Noah J Norris]

hardware clock = 6:53 pm software clock = 11:01 pm ....  
hardware clock is correct but the software is already 4 hours fast after a day 
it gets days ahead

using cpu freq but have no driver loaded for changing the cpu speed so 
currently uses default speed all the time at 2.5ghz 

On Wednesday 14 December 2005 11:01 pm, William Kenworthy wrote:
> Things to check:
> are you using speedfreq or cpufreq? - if the kernel timing sets itself
> when throtting is in effect, it may not be right when running fast
>
> batterystat applets can cause problems with blocking in /proc - this
> usually causes a loss in time, and I have not seen it with recent
> kernels.
>
> BillK
>
> On Wed, 2005-12-14 at 11:30 +0000, Noah J Norris wrote:
> > my hardware clock stays correct but the software clock is like going 20x
> > fast im on a laptop and using noapic the problem goes away but leads to
> > other problems like  network problems happing like errors with internal
> > ethernet card and ndiswrapper stops working . the processer is amd64
> > running as x86 (32bit mode)  i get apic errors and lost tick errors .  if
> > i leave this on for a couple hours it becomes days ahead can anyone shead
> > some light on this ?  kernel being used is 2.6.14-r2 i believe
> >
> >
> > thanks
> >
> > 'hwclock --hctosys' works to set the time back to what the hardware clock
> > says
> >
> > --
> > life is linux
> > linux is life
>
> --
> William Kenworthy <billk@iinet.net.au>
> Home!

-- 
life is linux
linux is life
-- 
gentoo-user@gentoo.org mailing list