RE: Weird timer handler used with LAPIC selected

[john stultz]

On Thu, 2010-05-13 at 11:42 +0100, limp wrote:
> >> I have put some printks inside "local_apic_timer_interrupt" handler which
> >> should never be executed as the handler selected for the timer is
> >> "hrtimer_interrupt" and not "local_apic_timer_interrupt" as verified.
> >
> >Nope. Again, local_apic_timer_interrupt is the actual irq hook. It
> >then calls the lapic clockevent device's event_handler() method, which
> >is hrtimer_interrupt.
> 
> Hmm, I am quite sure that hrtimer_interrupt() event_handler is called from
> timer_interrupt() and not from local_apic_timer_interrupt()..

It can actually be called from both. From your earlier mail:
	Tick Device: mode:     1
	Per CPU device: 0
	Clock Event Device: lapic
	event_handler:  hrtimer_interrupt

That means when local_apic_timer_interrupt calls the lapic clockevent
device's event_handler() method, it will call hrtimer_interrupt.


> The reason for not getting any printks from the "local_apic_timer_interrupt"
> irq hook was because I was getting about 318-360 LOC (Local timer
> interrupts)
> - the number was varied at every system boot - and then they were stopped
> and the
> LOC number was not incremented!!!! I've put a printk in lapic_timer_setup
> and it
> seems that LAPIC was going to shutdown mode after a while. 
> 
> 01[14:43] <limp> ...
> 01[14:43] <limp> [    0.046999] LIMP: lapic_timer_setup: the mode used is 1
> 01[14:43] <limp> [    0.046999] LIMP: lapic_timer_setup: the mode used is 2
> 01[14:43] <limp> ...
> 01[14:43] <limp> [    0.699077] LIMP: lapic_timer_setup: the mode used is 1
> 
> This solved by disabling ACPI from the kernel command line. After that, I
> was
> Getting LOCs at HZ rate and irq0_timer were stalled at boot time after some
> initial ones (I guess there is no sense of getting LOCs and irq0_timer ticks
> simultaneously on a uniprocessor target).  

Right, depending on the system and the configuration, we try to not have
duplicate irqs landing on the same cpu. So either the irq0 will be
shutdown once the lapic is up, or the lapic will be stopped if we're in
broadcast mode.

> It seems that the system were entering a deep sleep state and was never
> waking
> up. Again, this seems a bit weird as the irq0 timer interrupt was still
> triggered
> periodically at HZ rate and should have not let ACPI to put LAPIC timer into
> sleep...

Right. So on this system, its likely the LAPIC halts in deep idle states
(normally C3). So there will be another tick device (hpet or pit
usually) which is configured in broadcast mode and will trigger
frequently to wake the specified idled cpus up. If you look at your
timer_list in detail it should provide some info to that effect.


> Another question is this: Is there a way to know when my target enters an
> ACPI
> power state? Also, is there a way to prevent my target for entering into
> power
> states, without having to disable the whole ACPI support (something like 
> acpi_sleep=false)? 

There's a couple of ways. idle=poll will keep the system from going into
deep sleep modes, but at the cost of burning energy when there's nothing
to do. You might read over the idle= options in
Documentation/kernel-parameters.txt

Good luck!

thanks
-john


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