Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Fri, 2011-05-06 at 09:41 +0200, Borislav Petkov wrote:
> Hey Ben,
> 
> On Thu, May 05, 2011 at 03:53:02PM -0700, Greg KH wrote:
> > On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
> > > > We got a few new quirks added for AMD hardware platforms that fix
> > > > problems.
> > > 
> > > Maybe, but I still haven't seen anyone explain what those problems are!
> > 
> > I'll let the AMD people answer this.
> 
> it's hard to follow back in this thread to what exactly you'd like to
> have answered. Can you please repeat your questions concerning the AMD
> backports? Is it, per chance, about Erratum 400 CPU f/m/s ranges that
> got changed?

I read that:

"
    Support for Always Running APIC timer (ARAT) was introduced in
    commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
    allows us to avoid switching timers from LAPIC to something else
    (e.g. HPET) and go into timer broadcasts when entering deep
    C-states.
    
    AMD processors don't provide a CPUID bit for that feature but
    they also keep APIC timers running in deep C-states (except for
    cases when the processor is affected by erratum 400). Therefore
    we should set ARAT feature bit on AMD CPUs.
"

This implies that the HPET was previously used during deep C-states, and
that all this erratum checking is about deciding whether the CPU has
ARAT.  So what bug is being fixed by using ARAT instead of the HPET?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]