Kernel parameters... X86_TSC

[Thomas Charron]

On 8/12/08, Paul Lussier <p.lussier at comcast.net> wrote:
> Hi all,
> Is anyone here familiar enough with the 'Clocksource tsc unstable'
> problem in recent 2.6 kernels to discuss the characteristics and
> manifestations of this bug?
>
> I'm looking to understand things like:
>
>  - When the clocksource goes unstable, what happens from a userspace
>   perspective?

  Time warps.  :-D

>  - Does time move at all?  If so, which way, forwards, backwards, either?

  Either, it depends on the reconciliation when it jumps from the old
source to the new one.

>  - If the TSC clocksource is registered unstable, and the another
>   clocksource is chosen, can it too become unstable?

  Generally, it will fall back to the ACPI clock.  The ACPI clock
isn't linked to the processor directly, so the likelyhood it will
become unstable is low.  The problem seems to be that some processors
will 'play' with the clock as it dynamically changes the actual clock
speed onchip.

>   - If so, how will I know?  Will it log a similar error to the TSC error?

  Yes, a simular error will be logged.  An example:"

[953628.159139] Clocksource tsc unstable (delta = 4686637338 ns)
[953628.169116] Time: acpi_pm clocksource has been installed.

>     Something like 'Clocksource [hpet,acpi_pm,jiffies] unstable' ?

  Exactly.

>   - What happens if the next clocksource goes unstable?

  It goes onto the next one, if there is one.  Note it *MAY* go back
to one that had in the past ALSO gone unstable.  Take a gander at:

ls /sys/devices/system/clocksource/


> Please note, I'm NOT looking for a solution to the TSC problem, that's
> readily available on the net.  I'm looking to understand the problem
> thoroughly.

  I'll take a gander at the sources, I looked at them before a while
ago when I had an embedded system that needed to use a high resolution
RTC offchip.

-- 
-- Thomas