Messages in this thread | | | From | "limp" <> | Subject | Weird timer handler used with LAPIC selected | Date | Fri, 7 May 2010 12:10:33 +0100 |
| |
Hi all,
I have configured my kernel (2.6.31.6) so that I get periodic ticks from the timer interrupt (i.e. tickless is not configured) with a rate determined by the HZ value. I have also selected the "Local APIC support on uniprocessors" option so that the LAPIC timer is used as a tick source. The problem is that the handler used for the timer is not the "local_apic_timer_interrupt" handler as I was excepted but the "tick_handle_periodic" handler. This can be verified by seeing the output of /proc/timer_list:
Tick Device: mode: 0 Per CPU device: 0 Clock Event Device: lapic max_delta_ns: 1006457290 min_delta_ns: 1799 mult: 35797637 shift: 32 mode: 1 next_event: 9223372036854775807 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: tick_handle_periodic
Is there an explanation for that? The board in which I am running the kernel is a Kontron 986LCD-M/mITX one with an Intel Celeron M 440 installed on it. I have verified that Intel Celeron M Processors have a LAPIC and consequently, a LAPIC timer.
-------------------------------------------- Another weird thing that I noticed is that by running the same kernel but configured for "Core 2/newer Xeon" processors, the timer handler used is the "hrtimer_interrupt" handler. Again, this is verified by /proc/timer_list:
Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: lapic event_handler: hrtimer_interrupt
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. However, when I execute a user process which is just a long time delay, the printks from the "local_apic_timer_interrupt" are printed.
If you need more info about something, please ask.
Any help will be much appreciated.
Thanks in advance.
P.S. please CC me.
-John
| |