Re: 2.5.x: arch/i386/kernel/cpu

[H. Peter Anvin]

Dave Jones wrote:
> On Tue, Jun 18, 2002 at 08:45:18PM -0700, H. Peter Anvin wrote:
>  > Whomever broke up arch/i386/kernel/setup.c and created the CPU
>  > directory (very good idea) messed up in at least one place:
> 
> Patrick Mochel takes credit/glory/fame/blame for this one.

Note that this is great.  We should do the same with bugs.h which is, if 
anything, an even worse mess.

>  > The *AMD-defined* CPUID flags (0x80000001) are not just used on AMD
>  > processors!  In fact, at least AMD, Transmeta, Cyrix and VIA all use
>  > them; I don't know about Centaur or Rise.  Intel supports the actual
>  > level starting with the P4 although it returns all zero.
> 
> Bugger, you're right.

Looked a little harder, and it should *definitely* be moved to generic, 
since it also includes the CPU name string check, which is supported 
even on Intel P4 CPUs.

> On my Cyrix III box before..
> 
>  CPU: After vendor init, caps: 00803135 80803035 00000000 00000000
>  CPU:     After generic, caps: 00803135 80803035 00000000 00000000
>  CPU:             Common caps: 00803135 80803035 00000000 00000000
> 
> and after..
> 
>  CPU: After vendor init, caps: 00803135 80000000 00000000 00000000
>  CPU:     After generic, caps: 00803135 80000000 00000000 00000000
>  CPU:             Common caps: 00803135 80000000 00000000 00000000
> 
> Interesting how it's picking up that 8 in the 2nd set of caps, but
> not any of the other bits..

That's the 3DNow! bit... I was thinking it might be handled specially, 
but it looks like that's only done for Centaur chips.  Are you sure your 
CPU isn't being mis-identified as Centaur by the new code?

>  > It should, in my opinion, be moved into generic_identify().  Anyone
>  > who has a reason why that shouldn't be done speak now or I'll send the
>  > patch to Linus.
> 
> Sounds reasonable to me, unless Patrick has a preferred way of fixing 
> this problem.
> 
>         Dave
> 
>