Re: PIT clocksource makes invalid assumptions

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 3 Jan 2008, Dan Hecht wrote:
> Seems these problems can happen when the PIT is used as the clocksource or
> even just the clocksource watchdog.  It looks like there is some code in
> clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for
> the PIT clocksource, but it doesn't seem to be strong enough to prevent these
> problematic scenarios (and it's not clear if that is the intent of
> IS_CONTINUOUS anyway).
>
> To verify this really can happen, when I boot a kernel, I can see this
> sequence:
> 
>   init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC)
>   init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED)
>   init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN)
>   pit_read() and count > LATCH (I believe the PIT is the watchdog at this
> point), which causes the PIT to raise periodic interrupts.

Darn, yes. This might happen on UP when we have local apic timer
available.

There is another caveat, when we have HPET and enable it.

> (Shortly after, the acpi pm clocksource is registered and replaces the PIT as
> the watchdog.  Later, the PIT clockevent is used as the broadcast clockevent
> and reprogrammed into one-shot mode, stopping the PIT interrupts.)
> 
> Also, the user could force the PIT clocksource to be current_clocksource even
> though the PIT is in one-shot mode (and therefore the calculation in pit_read
> is bogus).

Yup, we need to prevent that.

> Of course, all this can only happen for 32-bit UP.  I'm not sure what the
> preferred fix for this is...

I guess disabling PIT clocksource there is the way to go. Not sure
yet, need to look into all the odds and ends.

Thanks for pointing this out,

	tglx