linux-kernel - Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1412101539200.13233@nanos>
Date:	Wed, 10 Dec 2014 15:59:03 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Santosh Shukla <santosh.shukla@...aro.org>
cc:	fweisbec@...il.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linaro-kernel <linaro-kernel@...ts.linaro.org>,
	preeti@...ux.vnet.ibm.com, daniel.lezcano@...aro.org,
	Kevin Hilman <khilman@...aro.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [Query] Spurious interrupts from clockevent device on X86
 Ivybridge

On Wed, 10 Dec 2014, Santosh Shukla wrote:
> The causes I could find:
> - Clockevent device's counter overflow: When we need to program a clockevt
>   device for times larger than it can handle, we program it for max time and
>   then reprogram again on expiration. Because of hardware counter limitations we
>   have to do it this way and this isn't really a spurious interrupt as we
>   programmed it that way.
> 
> - Hardware timer firing before its expiration: Yes, its hard to digest but from
>   my tests it looks like this does happen. Will circulate another mail once I am
>   sure about it.

Nothing we can do about.

> - Difference between time returned by hrtimer_update_base() and clockevt
>   device's notion of time: Wanted to discuss this here..

The clock event device and the clock source can run at different
frequencies. So the conversion from nsec to event ticks can cause
slight errors which are only observable when the delta gets larger.

The clock event device conversion from nsecs to timer ticks is
calculated at setup time once. It's known to be not completely
precise.

The clock source conversion which we use for reading time can be
changed by recalibration (we do that for TSC) and by NTP adjustments.

So even if we would calibrate the clock event device better, then we
still would need to take the NTP adjustments into account. And given
the zoo of timers we have, certainly not a trivial exercise.

Need to think about a bit more.

Thanks,

	tglx

--
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/