linux-kernel - Re: Regression in 2.6.27 caused by commit bfc0f59

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 21:08:15 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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:
> On Mon, 1 Sep 2008, Larry Finger wrote:
> >
> > TSC calibrated against PIT
> > Detected 428.823 MHz processor.
> 
> Ok, Thomas, that means that the PIT is reliable (not surprising), and the 
> PM_TIMER isn't (again, I'm not horribly surprised). And HPET isn't 
> available, of course.
> 
> The old x86-32 code never even bothered with the PM_TIMER for calibration. 
> I don't understand why the x86-64 code bothers with it either. Why not 
> just drop that whole broken thing, and just depend on the PIT if there is 
> no HPET?

We had horrible results on some machines with the PIT especially in
the local APIC timer calibration code. One of my own laptops behaved
stupid until I verified the APIC timer versus the PM timer. Until
recently it also had occasional stupid TSC calibration values.

This was reported by others as well and is definitely caused by SMM
taking the CPU away and blocking the PIT interrupt.

> I would also like to point out that the 32-bit code actually had a much 
> nicer PIT setup, using the much better documented mach_prepare_counter() 
> and mach_countup() helper functions. I'm unhappy to note that the new 
> "common" code uses what appears to be the inferior code.
> 
> Also, note that this is _not_ a new issue. See "verify_pmtmr_rate()" in 
> drivers/clocksource/acpi_pm.c, along with all the code to check that the 
> reads are stable in "init_acpi_pm_clocksource()".

Yeah, I really forgot about this one.

> IOW, the PM_TIMER has been found to be broken before. Depending on it for 
> calibration is broken.

While on older machines, which might have pmtimer wreckage (I just
googled that some AMD K6 are known to have such issues), the SMM/SMI
wreckage is likely to be a non issue, while on modern systems the
SMM/SMI wreckage will bite us. So we have the choice between evil and
evil.

One way out would be to check on which CPU type we run and ignore the
pmtimer for older systems.

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/