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: <CAKA=qzbqN--3Ra+syiwM17z_Nue9aH9Ec1-pz-QwWt7OCHcbrA@mail.gmail.com>
Date:	Tue, 10 Nov 2015 12:27:17 -0600
From:	Josh Hunt <joshhunt00@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	gratian.crisan@...com, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Borislav Petkov <bp@...en8.de>, Josh Cartwright <joshc@...com>,
	gratian@...il.com
Subject: Re: [RFC PATCH] tsc: synchronize TSCs on buggy Intel Xeon E5 CPUs
 with offset error

On Tue, Nov 10, 2015 at 12:24 PM, Josh Hunt <joshhunt00@...il.com> wrote:
>
> On Mon, Nov 9, 2015 at 4:02 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>>
>> On Mon, Nov 09, 2015 at 01:59:02PM -0600, gratian.crisan@...com wrote:
>>
>> > The Intel Xeon E5 processor family suffers from errata[1] BT81:
>>
>> > +#ifdef CONFIG_X86_TSC
>> > +     /*
>> > +      * Xeon E5 BT81 errata: TSC is not affected by warm reset.
>> > +      * The TSC registers for CPUs other than CPU0 are not cleared by a warm
>> > +      * reset resulting in a constant offset error.
>> > +      */
>> > +     if ((c->x86 == 6) && (c->x86_model == 0x3f))
>> > +             set_cpu_bug(c, X86_BUG_TSC_OFFSET);
>> > +#endif
>>
>> That's hardly a family, that's just one, Haswell server.
>
>
> Are you actually observing this problem on this processor?
>
> The document you've referenced and the x86_model # above do not match up. The errata should be for Intel processors with an x86_model value of 0x2d by my calculations:
>
> Model: 1101b
> Extended Model: 0010b
>
> The calc from cpu_detect() is:
>                  if (c->x86 >= 0x6)
>                         c->x86_model += ((tfms >> 16) & 0xf) << 4;
>
> 0x3f is a different CPU.
> --
> Josh

Resending, as gmail inserted html and lkml dropped the previous reply...


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