lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <SNT111-DS115B558E5855C0FAEA860CA7F60@phx.gbl>
Date:	Fri, 7 May 2010 12:10:33 +0100
From:	"limp" <johnkyr83@...mail.com>
To:	<linux-kernel@...r.kernel.org>
Subject: Weird timer handler used with LAPIC selected

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ