linux-kernel - RE: tsc reliability for Intel Core 2 Duo "Conroe"

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:	Wed, 26 May 2010 16:26:31 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Venkatesh Pallipadi <venki@...gle.com>, Len Brown <lenb@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: RE: tsc reliability for Intel Core 2 Duo "Conroe"

> From: Venkatesh Pallipadi [mailto:venki@...gle.com]
> 
> On Wed, May 26, 2010 at 10:41 AM, Dan Magenheimer
> <dan.magenheimer@...cle.com> wrote:
> > Looking through code following up on the separate TSC-related
> > thread, I noticed that my Intel Core 2 Duo "Conroe" box
> > is determined to have an unstable TSC, so falls back
> > to clocksource==hpet.
> >
> > While a Conroe has X86_FEATURE_CONSTANT_TSC and not
> > X86_FEATURE_NONSTOP_TSC, a Conroe is only able to enter
> > C0 and C1 (unlike its sister Intel Core 2 Duo processor
> > "Merom" which can enter C0-C3).
> >
> > I was under the impression (possibly from an earlier kernel
> > version?) that tsc_constant PLUS inability to enter deep-C
> > states would result in an acceptably stable TSC to use
> > as a clocksource (assuming it passes a TSC warp test).
> >
> > So is this a bug?  Or is my impression incorrect?
> >
> > See tsc_check_state() in drivers/acpi/processor_idle.c.
> > I can submit a patch, but wanted to check first.
> 
> Adding Len.
> 
> tsc_check_state(0 should only mark TSC unstable when state > C1 and
> !NONSTOP_TSC. Are you seeing TSC marked even with only C1?
> 
> Or may be you are hitting the bug in acpi_pad.c that marks TSC
> unstable more aggressively. I recently sent out a patch for that here
> -
> https://patchwork.kernel.org/patch/100633/


Hi Venki and Len --

(all code references to 2.6.34)

I noticed the acpi_pad code also but that's not where I'm
getting the mark_tsc_unstable call from.

After digging deeper, it appears that this processor is entering
C2 (as can be seen /sys/devices/system/cpu/cpu*/cpuidle/ output below)
despite the documentation I have, as well as this posting from Len:
http://forum.soft32.com/linux/ACPI-states-Conroe-ftopict339089.html 
I wonder if C1E state is somehow incorrectly getting recorded as
C2 state?  Or maybe TSC doesn't stop in C2 (TSC is most certainly
not stopping), in which case the test in tsc_check_state() should
be againt ACPI_STATE_C2?

In any case, this appears to now be an ACPI C-state question
so thanks, Venki, for cc'ing Len... and tglx is off the hook :-)

Len, note that this box is an Intel SDP so if it is an odd
duck, please just let me know... though I think I may have
some Xen code to fix depending on the answer to the above.

Thanks,
Dan

/sys/devices/system/cpu/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency: 0
/sys/devices/system/cpu/cpu0/cpuidle/state0/name: C0
/sys/devices/system/cpu/cpu0/cpuidle/state0/power: 4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/time: 0
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage: 0
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc: ACPI FFH INTEL MWAIT 0x0
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency: 1
/sys/devices/system/cpu/cpu0/cpuidle/state1/name: C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/power: 1000
/sys/devices/system/cpu/cpu0/cpuidle/state1/time: 1946
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage: 7
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc: ACPI IOPORT 0x814
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency: 1
/sys/devices/system/cpu/cpu0/cpuidle/state2/name: C2
/sys/devices/system/cpu/cpu0/cpuidle/state2/power: 500
/sys/devices/system/cpu/cpu0/cpuidle/state2/time: 12636559121
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage: 19779974
/sys/devices/system/cpu/cpu1/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu1/cpuidle/state0/latency: 0
/sys/devices/system/cpu/cpu1/cpuidle/state0/name: C0
/sys/devices/system/cpu/cpu1/cpuidle/state0/power: 4294967295
/sys/devices/system/cpu/cpu1/cpuidle/state0/time: 0
/sys/devices/system/cpu/cpu1/cpuidle/state0/usage: 0
/sys/devices/system/cpu/cpu1/cpuidle/state1/desc: ACPI FFH INTEL MWAIT 0x0
/sys/devices/system/cpu/cpu1/cpuidle/state1/latency: 1
/sys/devices/system/cpu/cpu1/cpuidle/state1/name: C1
/sys/devices/system/cpu/cpu1/cpuidle/state1/power: 1000
/sys/devices/system/cpu/cpu1/cpuidle/state1/time: 656
/sys/devices/system/cpu/cpu1/cpuidle/state1/usage: 4
/sys/devices/system/cpu/cpu1/cpuidle/state2/desc: ACPI IOPORT 0x814
/sys/devices/system/cpu/cpu1/cpuidle/state2/latency: 1
/sys/devices/system/cpu/cpu1/cpuidle/state2/name: C2
/sys/devices/system/cpu/cpu1/cpuidle/state2/power: 500
/sys/devices/system/cpu/cpu1/cpuidle/state2/time: 12652644397
/sys/devices/system/cpu/cpu1/cpuidle/state2/usage: 19717956
--
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/