Re: 2.6.26, PAT and AMD family 6

[Rene Herman <rene.herman@keyaccess.nl>]

On 07-05-08 16:24, Arjan van de Ven wrote:

> On Wed, 07 May 2008 16:09:05 +0200
> Rene Herman <rene.herman@keyaccess.nl> wrote:

> [as for which cpus]
> 
> The errata docs have these errata, at least for Intel I know they're
> there. We can add back older cpus over time, but again.. think of it as
> a risk/reward thing ;( Right now, breaking all kinds of well working
> older systems without benefits on the upside.....

What/who do you break, when they are not selecting CONFIG_X86_PAT? The
help text can be suitably alarming. I feel this is no argument at all.

> that's not very popular on lkml. Once PAT is rock solid I hope we can
> relax this check greatly...

A blacklist would seem to be really much preferred. All of AMD family 6
has been excluded in one fell swoop now for example, while I sort of
expect not any of them should be.

>> A blacklist would be a better idea I feel, but in ANY case I think
>> it's really bad form to clear the feature flag. They are provided by
>> hardware; if arch/x86/mm/pat.c won't risk running except on a select
>> few tested models, whatever, but my /proc/cpuinfo shouldn't be lying
>> to me.
> 
> we filter those for all kinds of things already, sorry.
> What good is showing "pat" if "pat" isn't deemed usable (yet)????
> Now *that* is deception :)

The trouble is -- if you hide that the CPU _should_ have PAT, how many
people do you expect are going to look further and test? I knew that I
should have PAT so I distrusted my CPU feature flag display but you've
now limited your testers to people who've read the CPU datasheet.
That's really no good.

If Linux messes around with those flags already, it's doing things
wrong already. /proc/cpuinfo is not a display of software features
but of hardware features -- anything else is outright wrong. Being
wrong for PAT also doesn't improve things.

Rene.