From: Rene Herman <rene.herman@keyaccess.nl>
To: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Suresh B Siddha <suresh.b.siddha@intel.com>,
qt@alberich.amd.com
Subject: Re: [PATCH 2/5] x86: PAT: fix ambiguous paranoia check in pat_init()
Date: Wed, 11 Jun 2008 14:58:49 +0200 [thread overview]
Message-ID: <484FCC09.7020606@keyaccess.nl> (raw)
In-Reply-To: <20080611094130.GA5889@alberich.amd.com>
On 11-06-08 11:41, Andreas Herrmann wrote:
> As I had no Transmeta or Centaur CPU at hand I just cleared the PAT
> flag in the CPU identification code to simulate the case that all CPUs
> of a Vendor are whitelisted (even those w/o PAT support). The first
> time pat_init() is entered you get
>
> PAT enabled, but CPU feature cleared
> (=> which is wrong as no flag was cleared)
Again, you are misreading this. Please just replace the message mentally
by "PAT enabled, but CPU claims to not support PAT". "cleared" here does
not signify that we ourselves cleared anything, just that flag IS clear
(unset). Yes, maybe the wording could be better but it's not wrong.
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> (=> which is wrong as PAT shouldn't be enabled on such CPUs)
Again not wrong, or at least by design. Thomas Gleixner did it this way
and with that "paranoia check" explicitly bombing out only for SMP this
wouldn't have been by accident. He no doubt knows why he did so (and
he's in CC so if we're real lucky we might also now...)
> IMHO the current state is:
>
> We can whitelist all Transmeta, Centaur and AMD CPUs (no errata wrt
> PAT are known). So the assumption is that for those CPUs PAT works if
> advertised.
>
> Then we have Intel for which all family 0xf CPUs, and family 6 CPUs
> starting with model 15 are whitelisted. AFAIK there are other Intel
> CPUs that advertise PAT support.
Definitely. Even my P2 (family 6, model 5) does. The whitelist was
discussed to be a temporary measure in an attempt to for now not muddy
testing of the feature with reports from CPUs in which the feature
designers weren't particularly interested. It should be turned into a
blacklist at a relatively nearby point after which also no whitelisting
command line switches are needed anymore.
I have myself been applying a patch to whitelist all of AMD family 6 but
with things just temporary this is no big deal...
Rene.
next prev parent reply other threads:[~2008-06-11 12:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 14:05 [PATCH 2/5] x86: PAT: fix ambiguous paranoia check in pat_init() Andreas Herrmann
2008-06-10 22:55 ` Rene Herman
2008-06-10 23:33 ` H. Peter Anvin
2008-06-11 9:47 ` Andreas Herrmann
2008-06-11 15:05 ` [PATCH] x86: enable PAT on (almost) all CPUs that advertise it Andreas Herrmann
2008-06-11 16:44 ` H. Peter Anvin
2008-06-11 17:35 ` [PATCH 2/5] x86: PAT: fix ambiguous paranoia check in pat_init() H. Peter Anvin
2008-06-11 9:41 ` Andreas Herrmann
2008-06-11 12:58 ` Rene Herman [this message]
2008-06-11 16:12 ` Andreas Herrmann
2008-06-12 4:32 ` Rene Herman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484FCC09.7020606@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=andreas.herrmann3@amd.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=qt@alberich.amd.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox