TSC calibration sometimes not correct with RT patch.

TSC calibration sometimes not correct with RT patch.

[Henri Hunnekens]

I've seen that the calbration of the TSC timer was not always done
correctly, which resulted in incorrect timers.

I found out that local_irq_disable is used before the calibration is
started. However with the RT patch applied this does not mean that the
interrupts are disabled and therefore the calibration may fails when
it's interrupted by an interrupt. Correct me if I'm wrong.

I think that this local_irq_disable must be replaced with the
raw_local_irq_disable which does disable the interrupts.

I'm not able to verify if this solves the problem because it is very
hard to reproduce. Maybe someone can verify if my assumption is
correcly.

Currently I'm using kernel version 2.6.20-RT8, but I've checked that
latest kernel version with the latest RT patch and they have the same
implementation.

Re: TSC calibration sometimes not correct with RT patch.

[Ingo Molnar]

* Henri Hunnekens <henrihunnekens@gmail.com> wrote:

> I've seen that the calbration of the TSC timer was not always done 
> correctly, which resulted in incorrect timers.
> 
> I found out that local_irq_disable is used before the calibration is 
> started. However with the RT patch applied this does not mean that the 
> interrupts are disabled and therefore the calibration may fails when 
> it's interrupted by an interrupt. Correct me if I'm wrong.

local_irq_disable() still disables interrupts, even in PREEMPT_RT. So 
the problem should be elsewhere. Can you see similar problems on .22-rt 
too? The hrt code saw a number of updates there.

	Ingo

Re: TSC calibration sometimes not correct with RT patch.

[Henri Hunnekens]

Some more information, the problems occurs on a SMP machine. I've
added the system logging which displays the CPU speed. The last line
shows an inaccurate processor speed! I'll try an update, but I expect
this has something to do with the TSC calibration and that hasn't
changed, If I'm correct.

Jul 23 07:50:53 localhost kernel: Detected 1795.663 MHz processor.
Jul 23 08:07:35 localhost kernel: Detected 1795.707 MHz processor.
Jul 23 08:27:44 localhost kernel: Detected 1795.623 MHz processor.
Jul 23 08:36:56 localhost kernel: Detected 1795.599 MHz processor.
Jul 23 08:43:36 localhost kernel: Detected 1795.641 MHz processor.
Jul 23 08:55:12 localhost kernel: Detected 1795.587 MHz processor.
Jul 23 09:13:26 localhost kernel: Detected 1795.625 MHz processor.
Jul 23 09:38:31 localhost kernel: Detected 1795.573 MHz processor.
Jul 23 09:54:39 localhost kernel: Detected 1795.662 MHz processor.
Jul 23 10:01:57 localhost kernel: Detected 1795.645 MHz processor.
Jul 23 10:22:18 localhost kernel: Detected 1795.648 MHz processor.
Jul 23 10:55:43 localhost kernel: Detected 1795.582 MHz processor.
Jul 23 11:00:29 localhost kernel: Detected 1795.589 MHz processor.
Jul 23 11:08:32 localhost kernel: Detected 1795.632 MHz processor.
Jul 23 11:24:30 localhost kernel: Detected 1795.610 MHz processor.
Jul 23 13:40:28 localhost kernel: Detected 1795.607 MHz processor.
Jul 23 13:47:15 localhost kernel: Detected 1795.557 MHz processor.
Jul 23 13:51:40 localhost kernel: Detected 1795.641 MHz processor.
Jul 23 14:20:38 localhost kernel: Detected 1795.646 MHz processor.
Jul 23 14:41:08 localhost kernel: Detected 1795.615 MHz processor.
Jul 23 14:49:27 localhost kernel: Detected 1795.677 MHz processor.
Jul 23 14:56:51 localhost kernel: Detected 1795.596 MHz processor.
Jul 24 07:44:17 localhost kernel: Detected 1795.651 MHz processor.
Jul 24 07:51:07 localhost kernel: Detected 1795.585 MHz processor.
Jul 24 09:05:18 localhost kernel: Detected 1795.660 MHz processor.
Jul 24 10:32:21 localhost kernel: Detected 1795.614 MHz processor.
Jul 24 10:42:39 localhost kernel: Detected 1823.703 MHz processor.
<--------------


2007/7/25, Ingo Molnar <mingo@elte.hu>:
>
> * Henri Hunnekens <henrihunnekens@gmail.com> wrote:
>
> > I've seen that the calbration of the TSC timer was not always done
> > correctly, which resulted in incorrect timers.
> >
> > I found out that local_irq_disable is used before the calibration is
> > started. However with the RT patch applied this does not mean that the
> > interrupts are disabled and therefore the calibration may fails when
> > it's interrupted by an interrupt. Correct me if I'm wrong.
>
> local_irq_disable() still disables interrupts, even in PREEMPT_RT. So
> the problem should be elsewhere. Can you see similar problems on .22-rt
> too? The hrt code saw a number of updates there.
>
>         Ingo
>

Re: TSC calibration sometimes not correct with RT patch.

[Joachim Deguara]

On Wednesday 25 July 2007 09:56:38 Henri Hunnekens wrote:
> Some more information, the problems occurs on a SMP machine. I've
> added the system logging which displays the CPU speed. The last line
> shows an inaccurate processor speed! I'll try an update, but I expect
> this has something to do with the TSC calibration and that hasn't
> changed, If I'm correct.

Could it just be that an SMI happened during the calibration?

-Joachim

Re: TSC calibration sometimes not correct with RT patch.

[Henri Hunnekens]

That was also my first idea, however the local_irq_disable() routine
disables the interrupts according to Ingo, so an SMI is not possible.


2007/7/25, Joachim Deguara <joachim.deguara@amd.com>:
> On Wednesday 25 July 2007 09:56:38 Henri Hunnekens wrote:
> > Some more information, the problems occurs on a SMP machine. I've
> > added the system logging which displays the CPU speed. The last line
> > shows an inaccurate processor speed! I'll try an update, but I expect
> > this has something to do with the TSC calibration and that hasn't
> > changed, If I'm correct.
>
> Could it just be that an SMI happened during the calibration?
>
> -Joachim
>
>
>

Re: TSC calibration sometimes not correct with RT patch.

[Ingo Molnar]

* Henri Hunnekens <henrihunnekens@gmail.com> wrote:

> That was also my first idea, however the local_irq_disable() routine 
> disables the interrupts according to Ingo, so an SMI is not possible.

both NMIs and SMIs are still possible even in a CLI-ed section.

	Ingo