2.5.x: arch/i386/kernel/cpu
Whomever broke up arch/i386/kernel/setup.c and created the CPU directory (very good idea) messed up in at least one place:
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.
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.
-hpa
Signature · 3 lines
<[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]>
Quoted 2 lines · H. Peter Anvin
Whomever broke up
arch/i386/kernel/setup.cand created the CPU directory (very good idea) messed up in at least one place:
Patrick Mochel takes credit/glory/fame/blame for this one.
Quoted 4 lines
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.
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..
Quoted 3 lines
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
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 5 lines · Dave Jones
Quoted 2 lines · H. Peter Anvin
Whomever broke up
arch/i386/kernel/setup.cand 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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 6 lines
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
Quoted 8 lines
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 00000000Interesting 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?
Quoted 9 lines
Quoted 3 lines
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
Quoted 3 lines · H. Peter Anvin
Quoted 1 line
Patrick Mochel takes credit/glory/fame/blame for this one.
Note that this is great. We should do the same with
bugs.hwhich is, if anything, an even worse mess.
Agreed. Patrick also did similar work on the mtrr driver which isn't merged anywhere yet. That's something else that's been long overdue this treatment. (Also on my list for chopping into bits is agpgart_be.c, but that's another story..)
Quoted 7 lines
Quoted 3 lines
On my Cyrix III box before..
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 is being (correctly) identified as Centaur.
VIA Cyrixen are CentaurHauls family 6
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 8 lines · Dave Jones
Quoted 4 lines
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 is being (correctly) identified as Centaur.
VIA Cyrixen are CentaurHauls family 6
Well, then... there ya go :)
-hpa
Quoted 2 lines · H. Peter Anvin
Whomever broke up
arch/i386/kernel/setup.cand created the CPU directory (very good idea) messed up in at least one place:
Ah! I just noticed this (as I was cleaning out my inbox before I head off to Canada).
Quoted 8 lines
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.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.
If you've already sent it, good. If not, and you have something readily available, good. If not, I'll add it to my short list and look at it in the next few days (hopefully).
Thanks,
-pat