2.6.26, PAT and AMD family 6
in [Kernel]
|
From: Rene Herman on 6 May 2008 21:50 Good day. On 2.6.25 and below, my /proc/cpuinfo looks like: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 7 model name : AMD Duron(tm) Processor stepping : 1 cpu MHz : 1312.969 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts bogomips : 2628.68 clflush size : 32 while on current mainline PAT and TS (Temperature Sensor) drop from the feature flags: flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow With respect to PAT, I guess it's 9307cacad0dfe3749f00303125c6f7f0523e5616, "x86: pat cpu feature bit setting for known cpus" but what's this about? Did my cpuinfo lie upto this point or shouldn't the flag be cleared? The commit message for that change is completely and totally unhelpful. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rene Herman on 7 May 2008 09:00 On 07-05-08 04:39, Yinghai Lu wrote: > On Tue, May 6, 2008 at 6:48 PM, Rene Herman <rene.herman(a)keyaccess.nl> wrote: >> On 2.6.25 and below, my /proc/cpuinfo looks like: >> >> processor : 0 >> vendor_id : AuthenticAMD >> cpu family : 6 >> model : 7 >> model name : AMD Duron(tm) Processor [ ... ] >> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov >> pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts >> while on current mainline PAT and TS (Temperature Sensor) drop from the >> feature flags: >> >> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov >> pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow >> >> With respect to PAT, I guess it's 9307cacad0dfe3749f00303125c6f7f0523e5616, >> "x86: pat cpu feature bit setting for known cpus" but what's this about? >> >> Did my cpuinfo lie upto this point or shouldn't the flag be cleared? The >> commit message for that change is completely and totally unhelpful. > > others like to to whitebox methods, ..., please try attach patch to > see if duron support PAT. > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index a428ffc..81483ec 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -314,6 +314,8 @@ static void __cpuinit early_get_cap(struct cpuinfo_x86 *c) > case X86_VENDOR_AMD: > if (c->x86 >= 0xf && c->x86 <= 0x11) > set_cpu_cap(c, X86_FEATURE_PAT); > + if (c->x86 == 6 && c->x86_modes == 7) > + set_cpu_cap(c, X86_FEATURE_PAT); > break; > case X86_VENDOR_INTEL: > if (c->x86 == 0xF || (c->x86 == 6 && c->x86_model >= 15)) s/modes/model/ but, as far as I'm aware, works fine other than that. When I boot with CONFIG_X86_PAT after applying that, I see: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 and PAT is retained in the feature flags. However, this I do not consider very surprising. Why is this code doing what it is doing in the first place? These feature flags are read from hardware in the CPUID instruction. Why is this code then going "ah, this CPU may _claim_ PAT but we won't actually believe it unless it's model foo, bar or baz". Is that feature flag buggy? That is, why is the attached not the better fix? Works fine for me as well and will retain the PAT feature flag also for for example the AMD family 6, model 1 and model 4 that both also advertise PAT in their feature flags, but wil have lost them now as well in the same way. If for some or other reason this explicit PAT white listing is in fact necessary, in addition to the above, it seems you also need/want the same in generic_identify() in that same file. And what it definitely wanted was a changelog... Rene.
From: Arjan van de Ven on 7 May 2008 09:50 On Wed, 07 May 2008 15:00:18 +0200 Rene Herman <rene.herman(a)keyaccess.nl> wrote: > On 07-05-08 04:39, Yinghai Lu wrote: > > > On Tue, May 6, 2008 at 6:48 PM, Rene Herman > > <rene.herman(a)keyaccess.nl> wrote: > > >> On 2.6.25 and below, my /proc/cpuinfo looks like: > >> > >> processor : 0 > >> vendor_id : AuthenticAMD > >> cpu family : 6 > >> model : 7 > >> model name : AMD Duron(tm) Processor > > [ ... ] > > >> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge > >> mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts > > >> while on current mainline PAT and TS (Temperature Sensor) drop > >> from the feature flags: > >> > >> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge > >> mca cmov pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow > >> > >> With respect to PAT, I guess it's > >> 9307cacad0dfe3749f00303125c6f7f0523e5616, "x86: pat cpu feature > >> bit setting for known cpus" but what's this about? > >> > >> Did my cpuinfo lie upto this point or shouldn't the flag be > >> cleared? The commit message for that change is completely and > >> totally unhelpful. > > > > others like to to whitebox methods, ..., please try attach patch to > > see if duron support PAT. > > > diff --git a/arch/x86/kernel/cpu/common.c > > b/arch/x86/kernel/cpu/common.c index a428ffc..81483ec 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -314,6 +314,8 @@ static void __cpuinit early_get_cap(struct > > cpuinfo_x86 *c) case X86_VENDOR_AMD: > > if (c->x86 >= 0xf && c->x86 <= 0x11) > > set_cpu_cap(c, X86_FEATURE_PAT); > > + if (c->x86 == 6 && c->x86_modes == 7) > > + set_cpu_cap(c, X86_FEATURE_PAT); > > break; > > case X86_VENDOR_INTEL: > > if (c->x86 == 0xF || (c->x86 == 6 && c->x86_model > > >= 15)) > > s/modes/model/ but, as far as I'm aware, works fine other than that. > When I boot with CONFIG_X86_PAT after applying that, I see: > > x86 PAT enabled: cpu 0, old 0x7040600070406, new > 0x7010600070106 > > and PAT is retained in the feature flags. However, this I do not > consider very surprising. Why is this code doing what it is doing in > the first place? > > These feature flags are read from hardware in the CPUID instruction. > Why is this code then going "ah, this CPU may _claim_ PAT but we > won't actually believe it unless it's model foo, bar or baz". Is that > feature flag buggy? > older cpus had various issues with PAT, some blatently obvious, some more subtle. Since for old systems the mtrrs clearly work fine... the idea was to not take the risk (since there's no reward) and just leave them as is, in a working state. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rene Herman on 7 May 2008 10:10 On 07-05-08 15:42, Arjan van de Ven wrote: > On Wed, 07 May 2008 15:00:18 +0200 > Rene Herman <rene.herman(a)keyaccess.nl> wrote: > >> On 07-05-08 04:39, Yinghai Lu wrote: >> >>> On Tue, May 6, 2008 at 6:48 PM, Rene Herman >>> <rene.herman(a)keyaccess.nl> wrote: >>>> On 2.6.25 and below, my /proc/cpuinfo looks like: >>>> >>>> processor : 0 >>>> vendor_id : AuthenticAMD >>>> cpu family : 6 >>>> model : 7 >>>> model name : AMD Duron(tm) Processor >> [ ... ] >> >>>> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge >>>> mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts >>>> while on current mainline PAT and TS (Temperature Sensor) drop >>>> from the feature flags: >>>> >>>> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge >>>> mca cmov pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow >>>> >>>> With respect to PAT, I guess it's >>>> 9307cacad0dfe3749f00303125c6f7f0523e5616, "x86: pat cpu feature >>>> bit setting for known cpus" but what's this about? >>>> >>>> Did my cpuinfo lie upto this point or shouldn't the flag be >>>> cleared? The commit message for that change is completely and >>>> totally unhelpful. >>> others like to to whitebox methods, ..., please try attach patch to >>> see if duron support PAT. >>> diff --git a/arch/x86/kernel/cpu/common.c >>> b/arch/x86/kernel/cpu/common.c index a428ffc..81483ec 100644 >>> --- a/arch/x86/kernel/cpu/common.c >>> +++ b/arch/x86/kernel/cpu/common.c >>> @@ -314,6 +314,8 @@ static void __cpuinit early_get_cap(struct >>> cpuinfo_x86 *c) case X86_VENDOR_AMD: >>> if (c->x86 >= 0xf && c->x86 <= 0x11) >>> set_cpu_cap(c, X86_FEATURE_PAT); >>> + if (c->x86 == 6 && c->x86_modes == 7) >>> + set_cpu_cap(c, X86_FEATURE_PAT); >>> break; >>> case X86_VENDOR_INTEL: >>> if (c->x86 == 0xF || (c->x86 == 6 && c->x86_model >>>> = 15)) >> s/modes/model/ but, as far as I'm aware, works fine other than that. >> When I boot with CONFIG_X86_PAT after applying that, I see: >> >> x86 PAT enabled: cpu 0, old 0x7040600070406, new >> 0x7010600070106 >> >> and PAT is retained in the feature flags. However, this I do not >> consider very surprising. Why is this code doing what it is doing in >> the first place? >> >> These feature flags are read from hardware in the CPUID instruction. >> Why is this code then going "ah, this CPU may _claim_ PAT but we >> won't actually believe it unless it's model foo, bar or baz". Is that >> feature flag buggy? >> > > older cpus had various issues with PAT, some blatently obvious, some > more subtle. And I suppose you have a list of these older CPUs or is this going to be one of these things where in 5 years time I say to yet another person "ah yes, I remember someone once telling me that old CPUs apparently had some issues, some blatantly obvious, some more subtle" and the saga continues on from there again? > Since for old systems the mtrrs clearly work fine... the idea was to > not take the risk (since there's no reward) and just leave them as > is, in a working state. With CONFIG_X86_PAT, you now see "CPU and/or kernel does not support PAT." at the top of your dmesg which is going to make people wonder. I did a cat /proc/cpuinfo, saw no PAT flag and was just suspicious enough that I didn't trust it. 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. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 7 May 2008 10:30
On Wed, 07 May 2008 16:09:05 +0200 Rene Herman <rene.herman(a)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..... that's not very popular on lkml. Once PAT is rock solid I hope we can relax this check greatly... > 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 :) > > Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |