[PATCH] fix to clock running too fast

[PATCH] fix to clock running too fast

[Akira Tsukamoto]

This one line patch adds upper bound testing when evaluating irq timer 
on boot up.

It fix the machine having problem with clock running too fast.

What this patch do is,
if  timer interrupts running too fast through IO-APIC IRQ then false back to 
i8259A IRQ.

I really appreciate for the feedback from ATI Xpress 200 chipset user,
It should eliminate the needs of adding no_timer_check on kernel options.

I have NEC laptop using ATI Xpress 200 chipset with Pentium M 1.8GHz and 
its clock keep going forward when kernel compiled with local APIC support.
Many machines based on RS200 chipset seem to have the same problem, 
including Acer Ferrari 400X AMD notebook or Compaq R4000.

Also I would like to have comments on upper bound limit, 16 ticks, which 
I chose in this patch. My laptop always reports around 20, which is double from normal.


--- linux-2.6.14/arch/i386/kernel/io_apic.c	2005-10-28 09:02:08.000000000 +0900
+++ linux-2.6.14-io_apic-atifix/arch/i386/kernel/io_apic.c	2005-11-09 00:31:56.000000000 +0900
@@ -1798,21 +1798,21 @@
 	/* Let ten ticks pass... */
 	mdelay((10 * 1000) / HZ);
 
 	/*
 	 * Expect a few ticks at least, to be sure some possible
 	 * glue logic does not lock up after one or two first
 	 * ticks in a non-ExtINT mode.  Also the local APIC
 	 * might have cached one ExtINT interrupt.  Finally, at
 	 * least one tick may be lost due to delays.
 	 */
-	if (jiffies - t1 > 4)
+	if (jiffies - t1 > 4 && jiffies - t1 < 16)
 		return 1;
 
 	return 0;
 }
 
 /*
  * In the SMP+IOAPIC case it might happen that there are an unspecified
  * number of pending IRQ events unhandled. These cases are very rare,
  * so we 'resend' these IRQs via IPIs, to the same CPU. It's much
  * better to do it this way as thus we do not have to be aware of


-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <akira-t@suna-asobi.com>

Fw: [PATCH] fix to clock running too fast

[Akira Tsukamoto]

Hi Ingo,

Are you still the maintainer of IO-APIC support?
I really appreciated if you could forward the following patch to 
a right person.


Forwarded by Akira Tsukamoto <akira-t@suna-asobi.com>
----------------------- Original Message -----------------------
 From:    Akira Tsukamoto <akira-t@s9.dion.ne.jp>
 To:      linux-kernel@vger.kernel.org
 Date:    Sun, 20 Nov 2005 23:41:07 +0900
 Subject: [PATCH] fix to clock running too fast
----


This one line patch adds upper bound testing inside timer_irq_works()
when evaluating whether irq timer works or not on boot up.

It fix the machines having problem with clock running too fast.

What this patch do is,
if  timer interrupts running too fast through IO-APIC IRQ then false back to 
i8259A IRQ.

I really appreciate for the feedback from ATI Xpress 200 chipset user,
It should eliminate the needs of adding no_timer_check on kernel options.

I have NEC laptop using ATI Xpress 200 chipset with Pentium M 1.8GHz and 
its clock keep going forward when kernel compiled with local APIC support.
Many machines based on RS200 chipset seem to have the same problem, 
including Acer Ferrari 400X AMD notebook or Compaq R4000.

Also I would like to have comments on upper bound limit, 16 ticks, which 
I chose in this patch. My laptop always reports around 20, which is double from normal.


--- linux-2.6.14/arch/i386/kernel/io_apic.c	2005-10-28 09:02:08.000000000 +0900
+++ linux-2.6.14-io_apic-atifix/arch/i386/kernel/io_apic.c	2005-11-09 00:31:56.000000000 +0900
@@ -1798,21 +1798,21 @@
 	/* Let ten ticks pass... */
 	mdelay((10 * 1000) / HZ);
 
 	/*
 	 * Expect a few ticks at least, to be sure some possible
 	 * glue logic does not lock up after one or two first
 	 * ticks in a non-ExtINT mode.  Also the local APIC
 	 * might have cached one ExtINT interrupt.  Finally, at
 	 * least one tick may be lost due to delays.
 	 */
-	if (jiffies - t1 > 4)
+	if (jiffies - t1 > 4 && jiffies - t1 < 16)
 		return 1;
 
 	return 0;
 }
 
 /*
  * In the SMP+IOAPIC case it might happen that there are an unspecified
  * number of pending IRQ events unhandled. These cases are very rare,
  * so we 'resend' these IRQs via IPIs, to the same CPU. It's much
  * better to do it this way as thus we do not have to be aware of


-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <akira-t@suna-asobi.com>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


--------------------- Original Message Ends --------------------

-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <>

Re: [PATCH] fix to clock running too fast

[Ingo Molnar]

* Akira Tsukamoto <akira-t@s9.dion.ne.jp> wrote:

> This one line patch adds upper bound testing inside timer_irq_works() 
> when evaluating whether irq timer works or not on boot up.
> 
> It fix the machines having problem with clock running too fast.
> 
> What this patch do is, if  timer interrupts running too fast through 
> IO-APIC IRQ then false back to i8259A IRQ.

thanks - looks good to me.

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

Re: [PATCH] fix to clock running too fast

[Akira Tsukamoto]

Ingo Molnar <mingo@elte.hu> mentioned:
> 
> * Akira Tsukamoto <akira-t@s9.dion.ne.jp> wrote:
> 
> > This one line patch adds upper bound testing inside timer_irq_works() 
> > when evaluating whether irq timer works or not on boot up.
> > 
> > It fix the machines having problem with clock running too fast.
> > 
> > What this patch do is, if  timer interrupts running too fast through 
> > IO-APIC IRQ then false back to i8259A IRQ.
> 
> thanks - looks good to me.
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>
> 
> 	Ingo

Thanks,
I regenerated my patch to the latest kernel.

Signed-off-by: Akira Tsukamoto <akira-t@s9.dion.ne.jp>

--- linux-2.6.15-rc2-atiix/arch/i386/kernel/io_apic.c.orig	2005-11-20 12:25:03.000000000 +0900
+++ linux-2.6.15-rc2-atiix/arch/i386/kernel/io_apic.c	2005-11-25 02:43:40.000000000 +0900
@@ -1877,7 +1877,7 @@ static int __init timer_irq_works(void)
 	 * might have cached one ExtINT interrupt.  Finally, at
 	 * least one tick may be lost due to delays.
 	 */
-	if (jiffies - t1 > 4)
+	if (jiffies - t1 > 4 && jiffies - t1 < 16)
 		return 1;
 
 	return 0;




-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <>

[PATCH 2.4] fix for clock running too fast

[Akira Tsukamoto]

Ingo Molnar <mingo@elte.hu> mentioned:
> 
> * Akira Tsukamoto <akira-t@s9.dion.ne.jp> wrote:
> 
> > This one line patch adds upper bound testing inside timer_irq_works() 
> > when evaluating whether irq timer works or not on boot up.
> > 
> > It fix the machines having problem with clock running too fast.
> > 
> > What this patch do is, if  timer interrupts running too fast through 
> > IO-APIC IRQ then false back to i8259A IRQ.
> 
> thanks - looks good to me.
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>
> 
> 	Ingo

This patch is against kernel 2.4.

Signed-off-by: Akira Tsukamoto <akira-t@s9.dion.ne.jp>

--- linux-2.4.32-atifix/arch/i386/kernel/io_apic.c.orig	2004-11-17 20:54:21.000000000 +0900
+++ linux-2.4.32-atifix/arch/i386/kernel/io_apic.c	2005-11-25 02:27:32.000000000 +0900
@@ -1194,7 +1194,7 @@ static int __init timer_irq_works(void)
 	 * might have cached one ExtINT interrupt.  Finally, at
 	 * least one tick may be lost due to delays.
 	 */
-	if (jiffies - t1 > 4)
+	if (jiffies - t1 > 4 && jiffies - t1 < 16)
 		return 1;
 
 	return 0;



> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <>

Re: [PATCH] fix to clock running too fast

[Akira Tsukamoto]

I saw my previous one line fix for fast clock problems under 32 bits, 
included in 2.4 kernel, 
but not on 2.6 yet. Please apply the following patch.

This patch will avoid clock running too fast on many ATI IXP and nforce boards.

Firstly, motherboard and bios should give the right irq pin info, but if it fails
It should be tweaked inside kernel by chipset id and etc, but if it fails,
my patch will works as a general purpose fail safe.

Under amd 64 bits, many people have been already working on tweaking 
irq pins detection and seems to be ok on most motherboard now, 
but not so many people working on 32 bits or 2.4 kernel.

I have ATI IXP chipset with Pentium M CPU, so the fast clock problem is not 
AMD64 specific.

It is not a optimal solution to use i8259A IRQ, but better than not working right.


On Fri, 25 Nov 2005 02:49:19 +0900
Akira Tsukamoto <akira-t@s9.dion.ne.jp> mentioned:
> 
> Ingo Molnar <mingo@elte.hu> mentioned:
> > 
> > * Akira Tsukamoto <akira-t@s9.dion.ne.jp> wrote:
> > 
> > > This one line patch adds upper bound testing inside timer_irq_works() 
> > > when evaluating whether irq timer works or not on boot up.
> > > 
> > > It fix the machines having problem with clock running too fast.
> > > 
> > > What this patch do is, if  timer interrupts running too fast through 
> > > IO-APIC IRQ then falls back to i8259A IRQ.
> > 
> > thanks - looks good to me.
> > 
> > Acked-by: Ingo Molnar <mingo@elte.hu>
> > 
> > 	Ingo
> 
> Thanks,
> I regenerated my patch to the latest kernel.
> 
> Signed-off-by: Akira Tsukamoto <akira-t@s9.dion.ne.jp>
> 
> --- linux-2.6.15-rc2-atiix/arch/i386/kernel/io_apic.c.orig	2005-11-20 12:25:03.000000000 +0900
> +++ linux-2.6.15-rc2-atiix/arch/i386/kernel/io_apic.c	2005-11-25 02:43:40.000000000 +0900
> @@ -1877,7 +1877,7 @@ static int __init timer_irq_works(void)
>  	 * might have cached one ExtINT interrupt.  Finally, at
>  	 * least one tick may be lost due to delays.
>  	 */
> -	if (jiffies - t1 > 4)
> +	if (jiffies - t1 > 4 && jiffies - t1 < 16)
>  		return 1;
>  
>  	return 0;
> 
> 
> 
> 
> -- 
> Akira Tsukamoto <akira-t@s9.dion.ne.jp> <>
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Akira Tsukamoto <akira-t@s9.dion.ne.jp> <at541@columbia.edu>