# AMD64 Insane Clock Rate 32-Bit & 64-Bit Solution

## mattbevan

Synopsis

Your new ACPI-only laptop's clock rate is exactly or almost exactly double that of realtime.  This differs from possible clock skew issues as it is not easily correctible using NTP.

Effected Systems

The following systems are known to be effected by this problem:

HP Pavilion zv6000-Series Notebook Computers

Compaq Presario r4000-Series Notebook ComputersThere is a possibility of future HP / Compaq laptops and other computers using a combination of ATI chipsets and AMD Athlon™ 64 processors also having this issue.

Defining the Problem / Symptoms

Symptoms of this problem include, and may not be limited to:

Running 'while true; do sleep 1; date; done' displays a second passing every half-second.

Animations in Xorg (KDE, Gnome, whatever) run exceptionally fast.

An insane keyboard repeat rate that may, in fact, make it nearly impossible to type anything.

Elevated system utilization (as much as 50% constant useage reported by some applications).

Warnings along the lines of 'clock skew detected: build may be incomplete' when compiling the kernel or applications from source.

Cache results will be quirky, as eventually the clock is so far in the future that no server in the world can report times in your future.  Similarily, rsync results will vary.

Worst case, you are excessively late to meetings; or, best case, excessively early.The Solution (32-Bit)

The following have been known to work, but are currently untested by myself on the latest kernels:

Apply the following patch (posted by Christopher Allen Wing) and add the "timerhack" option to your kernel command line.  (In GRUB add it to the end of the "kernel=" line, in LILO add it to the "append=" line.)  Malone pointed me to the original thread on LKML.  Thanks, malone!

```
--- linux-2.6.11.6/arch/x86_64/kernel/io_apic.c.orig   2005-03-25 22:28:21.000000000 -0500

+++ linux-2.6.11.6/arch/x86_64/kernel/io_apic.c   2005-04-06 17:56:46.486511088 -0400

@@ -1564,6 +1564,8 @@

  * is so screwy.  Thanks to Brian Perkins for testing/hacking this beast

  * fanatically on his truly buggy board.

  */

+static int timer_hack = 0;

+

 static inline void check_timer(void)

 {

    int pin1, pin2;

@@ -1592,6 +1594,10 @@

    apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);

+    if (timer_hack) {

+   /* for some reason this stops duplicate timer IRQ? */

+   clear_IO_APIC_pin(0, pin1);

+    } else {

    if (pin1 != -1) {

       /*

        * Ok, does IRQ0 through the IOAPIC work?

@@ -1633,6 +1639,7 @@

       clear_IO_APIC_pin(0, pin2);

    }

    printk(" failed.\n");

+    }

    if (nmi_watchdog) {

       printk(KERN_WARNING "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n");

@@ -1669,6 +1676,14 @@

    panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter\n");

 }

+static int __init timerhack(char *str)

+{

+   timer_hack = 1;

+   return 1;

+}

+__setup("timerhack", timerhack);

+

+

 /*

  *

  * IRQ's that are handled by the PIC in the MPS IOAPIC case.
```

Or, apply this second patch, also posted by Christopher.  It is a little less hackish than the first, but accomplishes the same thing.

```
--- arch/x86_64/kernel/io_apic.c.orig   2005-03-25 22:28:21.000000000 -0500

+++ arch/x86_64/kernel/io_apic.c   2005-04-07 13:13:58.813193024 -0400

@@ -1564,6 +1564,8 @@

  * is so screwy.  Thanks to Brian Perkins for testing/hacking this beast

  * fanatically on his truly buggy board.

  */

+static int timer_hack = 0;

+

 static inline void check_timer(void)

 {

    int pin1, pin2;

@@ -1597,7 +1599,7 @@

        * Ok, does IRQ0 through the IOAPIC work?

        */

       unmask_IO_APIC_irq(0);

-      if (timer_irq_works()) {

+      if ((!timer_hack) && timer_irq_works()) {

          nmi_watchdog_default();

          if (nmi_watchdog == NMI_IO_APIC) {

             disable_8259A_irq(0);

@@ -1669,6 +1671,14 @@

    panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter\n");

 }

+static int __init timerhack(char *str)

+{

+   timer_hack = 1;

+   return 1;

+}

+__setup("timerhack", timerhack);

+

+

 /*

  *

  * IRQ's that are handled by the PIC in the MPS IOAPIC case.

```

The Solution (64-Bit)

There are many proposed solutions.  A few of the more successful ones include:

Upgrading to the latest 2.6 kernel and keeping the support applications (like pci-utils) updated.  Remember - new features may have been added such as new drivers, an updated PCI-ID listing, etc.

Trying various combinations of the HPET, HPET_TIMER, HPET_EMULATE_RTC, X86_MCE, X86_PM_TIMER, and RTC options in the kernel.

Passing various kernel options at boot.  These include:

no_timer_checkpci=biosirqpci=noacpipci=irqrouteclock=pmtmrnotscnoapicnoapictimer (previousally used by 13Homer)Passing the no_timer_check option was all that was required to solve it for me!Last edited by mattbevan on Wed Sep 07, 2005 7:37 pm; edited 7 times in total

----------

## 13Homer

I'm using

```
noapictimer
```

kernel parameter.

I'll check your solution too.

----------

## asbud

i had problems with my broadcom drivers too, but, i found these drivers somewhere in the forums and wrote down the url, it turns out this is not the correct driver for my card (and not for yours either I believe) but it works except for an annoying error message I have yet to remove. It may work for you, it is a windows driver so you will need to extract it and then just use ndoswrapper and it should work, go to:

[url]

htp://ubuntuforums.org.attachment.php?attachmentid=186

[/url]

this is the braodcom BCM43XX driver but it is older than my 4306 card, driver 17 when I  need 18 or something like that

----------

## mattbevan

I managed to solve my 64-bit wireless woes early today.  I also used drivers available on the Ubuntu forums, hosted at the same place as drivers listed on the Gentoo Wiki article for my laptop.  I've updated the Wiki article to add the link to the working drivers.  They are Acer drivers for the same chip, and manage to load with only one warning!

----------

## malone

When I was using my compaq r4000 (almost identical to the hp you have) in 32bit mode, I used the patch found at http://lkml.org/lkml/2005/4/6/206  I have no idea if it applies nicely with a >= 2.6.12 kernel.  Just had to pass the option "timerhack" to the kernel.

Thanks for the link for the 64bit drivers, I'll try them when I get home.  Have you had any success getting the pcmcia slot working?

----------

## mattbevan

I'll try that patch tonight - hopefully It'll apply cleanly.

As for PCMCIA, I see no errors on boot-up about the PCMCIA/CardBus slot - the PCMCIA service starts cleanly.  Then again, I have no PCMCIA cards to test. ^_^;

----------

## prometheanfire

Thanks for posting this.  The noapictimer option worked like a charm.

----------

## ltracy

So.... did anyone find a good solution for 32 bit gentoo?????  A patch that works on 2.6.12?

I can get the clock fixed by passing noapic or noapictimer, but it then the network breaks unless I also pass acpi=off  :Smile: 

Trying to keep acpi on.

----------

## mattbevan

The patch given in my first post (see the Refrences section at the bottom) should work without much more than trivial modifications on 2.6.11 kernels.  If (after modifying the filenames in the patch) it does not work on a 2.6.12 kernel, you should be able to duplicate the changes fairly easily.  There are very few.

----------

## ltracy

It did work.  There is very little difference in patching the 2.6.12 kernel.  I just manually edited the io_apic file and it appears to do the job.  Thanks!!!!

----------

## darkgamorck

Ok I think the OP needs a few corrections.  I just spent the last few hours looking at this and here is what I've found:

1) The original timerhack patches for x86_64 as well as the official no_timer_check option for x86_64 do the exact same thing (at least when it comes to the second timerhack patch).  no_timer_check has been added to the x86_64 version of io_apic.c in the official kernel.

2) For 64-bit systems you can use the no_timer_check parameter to solve this problem.  The arch/x86_64/kernel/io_apic.c file has the code (at least in 2.6.13) to handle the no_timer_check parameter.

3) For 32-bit systems you cannot use no_timer_check as the code to handle it currently does NOT exist in arch/i386/kernel/io_apic.c - after fiddling around today I have come up with a patch that adds the very same functionality present in the x86_64 io_apic.c file:

```
--- arch/i386/kernel/io_apic.c.orig     2005-09-11 12:12:06.000000000 -0400

+++ arch/i386/kernel/io_apic.c  2005-09-11 14:54:55.000000000 -0400

@@ -46,6 +46,8 @@

 int (*ioapic_renumber_irq)(int ioapic, int irq);

 atomic_t irq_mis_count;

 

+static int no_timer_check;

+

 static DEFINE_SPINLOCK(ioapic_lock);

 

 /*

@@ -2204,7 +2206,7 @@

                 * Ok, does IRQ0 through the IOAPIC work?

                 */

                unmask_IO_APIC_irq(0);

-               if (timer_irq_works()) {

+               if (!no_timer_check && timer_irq_works()) {

                        if (nmi_watchdog == NMI_IO_APIC) {

                                disable_8259A_irq(0);

                                setup_nmi();

@@ -2278,6 +2280,14 @@

                "report.  Then try booting with the 'noapic' option");

 }

 

+static int __init notimercheck(char *s)

+{

+       no_timer_check = 1;

+       return 1;

+}

+

+__setup("no_timer_check", notimercheck);

+

 /*

  *

  * IRQ's that are handled by the PIC in the MPS IOAPIC case.
```

Using the above patch on a vanilla 2.6.13 or a gentoo-source 2.6.13 tree as well as passing the parameter "no_timer_check" to my 32bit kernel seems to solve in the problem for me.

I hope this helps.

----------

## user118696

the kernel bugzilla team is currently working on this

BUG #3927

----------

## mbar

Taken from 2.6.14-rc1 changelog:

```
[PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets

    

    Original patch from Bertro Simul
```

----------

## user118696

 *mbar wrote:*   

> Taken from 2.6.14-rc1 changelog:
> 
> ```
> [PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets
> 
> ...

 

Have you tested this patch? Does it simply bypass the timer (like passing the no_timer_check as a kernel param)? Because this causes some other problems.

In fact, I would be surprised that this patch solved it all because the buzilla.kernel.org team hasn't solved it yet and the gentoo kernel team has just registered as CC: on BUG#3927.

Let us know.

----------

## mbar

It may take a while, cause I changed my mobo form nf3 to nf4 and everything is segfaulting now, I'm reinstalling gentoo from scratch now  :Smile: 

Segfaults come form unstable overclock as of now (stock speed is OK). Anyway, even earlier (nf3 board) I haven't any issues with clock speed and I don't have ATI Xpress chipset... I only wanted you to know, that 2.6.14 kernel may bring much x86_64 patches/fixes.

----------

## user118696

New patch to try. Have a look   :Smile:  :

http://bugzilla.kernel.org/show_bug.cgi?id=3927

----------

## nykos

i have a TARGA Traveller 826 with a Turion 64 MT32 processor

my gentoo is 62bits-compiled

the noapictimer works very good for me  :Smile: 

thx a lot

----------

## ltiefland

I'm using an Acer Aspire 5024WLMI notebook and had the same problem. After using "no_timer_check" clock is O.K. again!

----------

## blotto

 *ltiefland wrote:*   

> I'm using an Acer Aspire 5024WLMI notebook and had the same problem. After using "no_timer_check" clock is O.K. again!

 

I have the acer 5024WLMI and

```
 noapictimer
```

works for me but if I use 

```
no_timer_check
```

then I see this in dmesg

 *Quote:*   

> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> 
> failed.
> 
> timer doesn't work through the IO-APIC - disabling NMI Watchdog! Uhhuh. 
> ...

 

do you ?

Also 

```
ec_burst=1
```

removes acpi errors for me and allows thermal zone stuff to work

----------

## ltiefland

 *blotto wrote:*   

>  *ltiefland wrote:*   I'm using an Acer Aspire 5024WLMI notebook and had the same problem. After using "no_timer_check" clock is O.K. again! 
> 
> I have the acer 5024WLMI and
> 
> ```
> ...

 Didn't check. However: When I used noapictimer nothing changed in the clock running. Perhaps I misspelled the option, but I don't think so.

 *blotto wrote:*   

> Also 
> 
> ```
> ec_burst=1
> ```
> ...

 

Will try that also.

----------

## proxyroot

noapictimer caused a kernel packet for me..  dont ask why, i was in a bit of a ruch so didn't get a chance to analyse it...

im gooona try some of the other options first, before attempting to debug the problem.....

great post thanks.. been waiting for a while for this post!

----------

## ltiefland

 *proxyroot wrote:*   

> noapictimer caused a kernel packet for me..  dont ask why, i was in a bit of a ruch so didn't get a chance to analyse it...
> 
> im gooona try some of the other options first, before attempting to debug the problem.....
> 
> great post thanks.. been waiting for a while for this post!

 

Is your OS 64-Bit or 32-Bit compiled? In the latter case, you have to use one of the patches, if I am not mistaken.

----------

## Kess

Just a small note:

Option noapictimer includes noapic, so all apic funtionality is diabled with noapictimer.

----------

## proxyroot

lads, the above options for some reason are not working for my amd64 ati chipset

can any body please help, im getting a kernel panic

Kernel panic: - not syncing: Aieee, killing interrupt handler

thats all, cant do anything, stalled.....

 *ltiefland wrote:*   

>  *proxyroot wrote:*   noapictimer caused a kernel packet for me..  dont ask why, i was in a bit of a ruch so didn't get a chance to analyse it...
> 
> im gooona try some of the other options first, before attempting to debug the problem.....
> 
> great post thanks.. been waiting for a while for this post! 
> ...

 

----------

## donut_ky

I have also tried the various "timer" commands at boot...some work, some don't..and also depends on the kernel .12? .13? 14?

anyways i have finally found a solution that fixes the speedy time problem on all my kernels, whether they are x86 or x86_64:

UPGRADE THE BIOS

just go to compaqs site...get the bios update...do it....problem solved

luckily i had a dual boot with windows...as it is a winflash utility

goodluck

donut_ky

----------

## sfabel

None of the above works for me, although I have to admit, I didn't patch my kernel (yet).

I'm currently running kernel 2.6.14-gentoo-r5 on a AMD64 X2 Dual-Core (x86_64). It's a HP Pavilion ti3818.de desktop system with a S-ATA hd which fails to load when using the "noapic" parameter. On kernel 2.6.12 "notsc" seemed to have alleviated it a little bit, but I'm not sure.

If I disable ACPI (using either "acpi=off" or "pci=noacpi"), my USB / IEEE1394 devices don't get an interrupt and promptly fail to initialize. This is hell!   :Evil or Very Mad: 

I don't have a dual-boot windows situation either, so I can't upgrade my BIOS, I guess.

Any help?

Thanks,

Stephan

----------

## ketema

I also have a HP Pavilion a1250n and the previously mentioned kernel paramenters do not work, and the noapci options cause a freeze on boot.  Any solutions for the HP family that it seems is left out in the cold?

----------

## Johan_V

Have you tried disable_timer_pin_1 parameter?

----------

## oraldlight

Gateway 7410gx laptop, 2.6.14/2.6.15 

  I've been fighting real time clock x2+ speed problem since day one. Initially overlooked as keyboard repeat rate was outrageously fast and could not slow down enough to make predictable. Works fine when booting under WindowsXP (daul boot) or off of Live CD(if I remember correctly). Been a while but don't recall this happening when I boot to command line only, normally boot to KDE, but never thought to look for this either until a freind pointed it out.

  noapic = cured timeclock issue but killed many other dependancies like nic

  nortc, noapictimer = no noticed affect

  no newer BIOS available

  no_timer_check seems to have resolved the issue

----------

## gentooBiH

I have the similar problem. Acer Aspire 5024 wlmi, 64-bit Gentoo, 2.6.15 r1 kernel and no dual boot.

```

no_timer_check

```

solved the problem with clock running twice as fast as it should, but still I have a constant clock skew whenever I reboot. The clock is running some 20 minutes behind, and I think the time it runs behind changes. When I set the clock with ntpd, everything is fine until I reboot.

I tried 

```

noapictimer

```

option but it didn't solve the problem. I have ATI chipset.

----------

## WarAngel

I have an Athlon XP 64 with an ATI chipset and I fixed the clock problem using 

```
noapic
```

 or 

```
noapictimer
```

But, when I do that, I can't use any USB device, i get the following while connecting a microsoft gamepad

```
usb 3-4: new low speed USB device using ohci_hcd and address 2

spurious 8259A interrupt: IRQ7.

ohci_hcd 0000:00:13.1: Unlink after no-IRQ?  Controller is probably using the wrong IRQ
```

Does anyone know what to do ?

----------

