Hi hpa,
First test, the AMD K6-2.
Before your patch..
cpu family : 5
model : 8
stepping : 12
After..
cpu family : 5
model : 8
stepping : 4
Line 1826 of setup.c
c->x86_mask = tfms & 7;
Should be..
c->x86_mask = tfms & 15;
I think?
Also, look at the feature flags:
before:
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
after:
features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
Note, I lost MTRR & sep. This may be related to the stepping bug
though. I'll recompile a kernel with the &15 fix, and see if that cures
all.
btw, whilst all this is getting a shakedown, how about renaming
that 'x86_mask' field to the more obvious 'x86_stepping' ?
c->x86 would make more sense as c->x86_family too thinking about it.
regards,
Davej.
--
| Dave Jones <[email protected]> http://www.suse.de/~davej
| SuSE Labs
[email protected] wrote:
>
> Hi hpa,
>
> First test, the AMD K6-2.
>
> Before your patch..
> cpu family : 5
> model : 8
> stepping : 12
>
> After..
>
> cpu family : 5
> model : 8
> stepping : 4
>
> Line 1826 of setup.c
>
> c->x86_mask = tfms & 7;
>
> Should be..
>
> c->x86_mask = tfms & 15;
>
> I think?
>
> Also, look at the feature flags:
> before:
> flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
>
> after:
> features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
>
> Note, I lost MTRR & sep. This may be related to the stepping bug
> though. I'll recompile a kernel with the &15 fix, and see if that cures
> all.
>
That is actually correct -- the K6-2 doesn't actually have mtrr and sep,
but has syscall and k6_mtrr instead (the stepping bug causes k6_mtrr not
to show up.) Part of the bugginess of the old system was using one flag
for multiple purposes. This was Linux' doing, not AMD's, by the way.
> btw, whilst all this is getting a shakedown, how about renaming
> that 'x86_mask' field to the more obvious 'x86_stepping' ?
> c->x86 would make more sense as c->x86_family too thinking about it.
>
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
[email protected] wrote:
>
> Hi hpa,
>
> First test, the AMD K6-2.
>
> Also, look at the feature flags:
> before:
> flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
>
> after:
> features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
>
> Note, I lost MTRR & sep. This may be related to the stepping bug
> though. I'll recompile a kernel with the &15 fix, and see if that cures
> all.
The K6's don't support sysenter/sysexit. It really should have been
marked differently before. The early K6's used extended bit 10 to
indicate syscall/sysret capabality, but this version has some quirks
that make it pretty much unusable. Later K6's use extended bit 11 to
indicate syscall/sysret.
--
Brian Gerst
On Fri, 10 Nov 2000, Brian Gerst wrote:
> > features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
>
> The K6's don't support sysenter/sysexit.
The K6 datasheets suggests otherwise.
Some models seem to have sysenter/sysexit, whilst others have
syscall/sysret. No model seems to have both.
The datasheets are somewhat confusing, as it doesn't mention bit 10
at all, just an oversized box for bit 11.
> It really should have been marked differently before.
Before we weren't mentioning it at all, look..
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
> The early K6's used extended bit 10 to indicate syscall/sysret
> capabality, but this version has some quirks that make it pretty much
> unusable. Later K6's use extended bit 11 to indicate syscall/sysret.
And where does sysenter/sysexit fit in?
regards,
Davej.
--
| Dave Jones <[email protected]> http://www.suse.de/~davej
| SuSE Labs
On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> That is actually correct -- the K6-2 doesn't actually have mtrr and sep,
> but has syscall and k6_mtrr instead (the stepping bug causes k6_mtrr not
> to show up.) Part of the bugginess of the old system was using one flag
> for multiple purposes. This was Linux' doing, not AMD's, by the way.
Yep, after the c->x86_mask = tfms & 15; change I got the correct
stepping, and the flags are now correct:-
features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
regards,
davej.
--
| Dave Jones <[email protected]> http://www.suse.de/~davej
| SuSE Labs
[email protected] wrote:
> On Fri, 10 Nov 2000, Brian Gerst wrote:
>
> > > features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
> >
> > The K6's don't support sysenter/sysexit.
>
> The K6 datasheets suggests otherwise.
> Some models seem to have sysenter/sysexit, whilst others have
> syscall/sysret. No model seems to have both.
Athlons have both. Since the ext-bit 10 stuff is useless, I haven't
bothered reporting it at all.
> The datasheets are somewhat confusing, as it doesn't mention bit 10
> at all, just an oversized box for bit 11.
>
> > It really should have been marked differently before.
>
> Before we weren't mentioning it at all, look..
> flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
>
> > The early K6's used extended bit 10 to indicate syscall/sysret
> > capabality, but this version has some quirks that make it pretty much
> > unusable. Later K6's use extended bit 11 to indicate syscall/sysret.
>
> And where does sysenter/sysexit fit in?
sysenter/sysexit is the "sep" feature.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> > And where does sysenter/sysexit fit in?
> sysenter/sysexit is the "sep" feature.
Ah, of course.
*slaps head*
regards,
davej.
--
| Dave Jones <[email protected]> http://www.suse.de/~davej
| SuSE Labs
[email protected] wrote:
>
> On Fri, 10 Nov 2000, Brian Gerst wrote:
>
> > > features : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
> >
> > The K6's don't support sysenter/sysexit.
>
> The K6 datasheets suggests otherwise.
> Some models seem to have sysenter/sysexit, whilst others have
> syscall/sysret. No model seems to have both.
>
> The datasheets are somewhat confusing, as it doesn't mention bit 10
> at all, just an oversized box for bit 11.
The Athlons support sysenter and syscall, but the K6's only support
syscall. The earlier version of syscall (bit 10) is undocumented by
AMD.
--
Brian Gerst
On Fri, 10 Nov 2000, Brian Gerst wrote:
> > The datasheets are somewhat confusing, as it doesn't mention bit 10
> > at all, just an oversized box for bit 11.
> The Athlons support sysenter and syscall, but the K6's only support
> syscall. The earlier version of syscall (bit 10) is undocumented by
> AMD.
Ah, thanks for clearing that up.
regards,
davej.
--
| Dave Jones <[email protected]> http://www.suse.de/~davej
| SuSE Labs