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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 1 Sep 2008 20:35:57 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Larry Finger <Larry.Finger@...inger.net>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alok Kataria <akataria@...are.com>,
	Michael Buesch <mb@...sch.de>
Subject: Re: Regression in 2.6.27 caused by commit bfc0f59



On Mon, 1 Sep 2008, Linus Torvalds wrote:
> 
> Well, the biggest problem is actually _detection_.
> 
> We have three different timers, and they all have their own problems. How 
> do you reliably detect which one to use? The PM_TIMER clearly is _not_ 
> always the answer here, but the code just assumes it is!

On the machine you have trouble with the PIT on, does this thing trigger?

If it does, that could be a simple way to say whether you prefer PM_TIMER 
over PIT.

For me, even on a modern machine, I get a pit_count of 46321, which 
matches the "about one microsecond for an ISA/LPC read" timing pretty 
well. What do you get? 

		Linus

---
 arch/x86/kernel/tsc.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 8e786b0..7cf7543 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -131,6 +131,7 @@ unsigned long native_calibrate_tsc(void)
 	u64 tsc1, tsc2, tr1, tr2, delta, pm1, pm2, hpet1, hpet2;
 	int hpet = is_hpet_enabled();
 	unsigned int tsc_khz_val = 0;
+	unsigned int pit_count;
 
 	local_irq_save(flags);
 
@@ -142,7 +143,9 @@ unsigned long native_calibrate_tsc(void)
 	outb((CLOCK_TICK_RATE / (1000 / 50)) & 0xff, 0x42);
 	outb((CLOCK_TICK_RATE / (1000 / 50)) >> 8, 0x42);
 	tr1 = get_cycles();
-	while ((inb(0x61) & 0x20) == 0);
+	pit_count = 0;
+	while ((inb(0x61) & 0x20) == 0)
+		pit_count++;
 	tr2 = get_cycles();
 
 	tsc2 = tsc_read_refs(&pm2, hpet ? &hpet2 : NULL);
@@ -150,6 +153,18 @@ unsigned long native_calibrate_tsc(void)
 	local_irq_restore(flags);
 
 	/*
+	 * We should have waited for about 50ms, and a real hardware
+	 * PIT access _should_ take about a microsecond even if it's
+	 * over an ISA bus (or something that tries to emulate timings).
+	 *
+	 * So pit_count should be 50,000+. If it's a lot lower, that
+	 * implies it might be some emulated device rather than real
+	 * hardware..
+	 */
+	if (pit_count < 25000)
+		printk("Slow PIT device (%u) - emulated using SMI?\n", pit_count);
+
+	/*
 	 * Preset the result with the raw and inaccurate PIT
 	 * calibration value
 	 */
--
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