Bug 3767 - Wrong CPU flags on Cyrix MII CPU
Wrong CPU flags on Cyrix MII CPU
Status: CLOSED CODE_FIX
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386
i386 Linux
: P2 normal
Assigned To: Zwane Mwaikambo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-18 09:42 UTC by Ondrej Zary
Modified: 2004-11-30 21:25 UTC (History)
0 users

See Also:
Kernel Version: 2.4.x, 2.6.x
Tree: Mainline
Regression: ---


Attachments
Print more capabilities (1.53 KB, patch)
2004-11-24 08:16 UTC, Zwane Mwaikambo
Details | Diff
Clear ECX before CPUID (366 bytes, patch)
2004-11-24 13:14 UTC, Ondrej Zary
Details | Diff

Description Ondrej Zary 2004-11-18 09:42:04 UTC
Distribution: Slackware 10
Hardware Environment: PCPartner TXB820DS board (i430TX chipset), Cyrix MII PR300
CPU (3x75MHz)

Problem Description:
I've noticed some new CPU flags in /proc/cpuinfo that never used to be there.
These flags varies with kernel versions:
2.6.8.1:    fpu de tsc msr cx8 pge cmov mmx cyrix_arr tm2
2.6.9:      fpu de tsc msr cx8 pge cmov mmx cyrix_arr tm2 xtpr
2.6.10-rc1: fpu de tsc msr cx8 pge cmov mmx cyrix_arr est xtpr

Steps to reproduce:
Do 'cat /proc/cpuinfo' with Cyrix MII CPU
Comment 1 Zwane Mwaikambo 2004-11-22 09:23:47 UTC
I take it this behaviour only  started with 2.6.8?
Comment 2 Ondrej Zary 2004-11-22 14:13:08 UTC
I did not remember this in previous versions. So, I've just tested 2.6.10-rc2,
two different builds of 2.6.7 and one 2.6.0:
2.6.10-rc2: fpu de tsc msr cx8 pge cmov mmx cyrix_arr est
2.6.7:      fpu de tsc msr cx8 pge cmov mmx cyrix_arr tm2
2.6.7min:   fpu de tsc msr cx8 pge cmov mmx cyrix_arr cid
2.6.0min:   fpu de tsc msr cx8 pge cmov mmx cyrix_arr cid

The 2.6.0min and 2.6.7min were compiled with minimal configuration required to
boot from IDE drive and do 'cat /proc/cpuinfo'.
According to include/asm/cpufeature.h, all these bogus (on my system) flags
(EST, TM2, CID and XTPR) are for recent Intel CPUs. It looks like they depend on
kernel configuration (two different 2.6.7 kernels show different flags) - I
think that some garbage gets into the "recent Intel" part of flags somehow.
Comment 3 Zwane Mwaikambo 2004-11-22 14:16:59 UTC
Thank you for testing those older versions, it should help a lot tracking down
the source of the problem.
Comment 4 Ondrej Zary 2004-11-22 14:33:58 UTC
dmesg - it's always the same with all kernels:
CPU: After generic identify, caps: 0080a135 00000000 00000000 00000000
CPU: After vendor identify, caps:  0080a135 00000000 00000000 00000000
CPU: After all inits, caps:        0080a135 00000000 00000000 00000004
CPU: Cyrix M II 3x Core/Bus Clock stepping 04

and complete /proc/cpuinfo (from 2.6.9):
processor       : 0
vendor_id       : CyrixInstead
cpu family      : 6
model           : 2
model name      : M II 3x Core/Bus Clock
stepping        : 4
cpu MHz         : 225.006
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 pge cmov mmx cyrix_arr tm2 xtpr
bogomips        : 443.39
Comment 5 Ondrej Zary 2004-11-23 14:08:54 UTC
Now I really wonder what's wrong...
Tried Slackware 10.0 Install CD (2.4.26):
fpu de tsc msr cx8 pge cmov mmx cyrix_arr ds_cpl est cid
and Knoppix 3.6:
2.4.27 - same as Slackware
2.6.7 - everything OK: fpu de tsc msr cx8 pge cmov mmx cyrix_arr
Comment 6 Zwane Mwaikambo 2004-11-23 14:16:54 UTC
Could you compare header files? /usr/include/asm/cpufeature.h
Comment 7 Zwane Mwaikambo 2004-11-24 08:16:53 UTC
Created attachment 4133 [details]
Print more capabilities

Could you please test the latest kernel with this patch? Thanks
Comment 8 Ondrej Zary 2004-11-24 13:14:25 UTC
Created attachment 4134 [details]
Clear ECX before CPUID

With your patch, the last number displayed in all CPU capabilities changed from
kernel to kernel. Then I tried manually how CPUID instruction works on my CPU -
and found out that it does not update ebx and ecx registers. The attached patch
fixes the bug by clearing ecx register before calling CPUID (no need to clear
ebx as its value does not seem to be used by kernel). Is it OK or will it break
anything?
Comment 9 Zwane Mwaikambo 2004-11-24 13:49:29 UTC
Interesting, Intel actually lists %ecx as reserved too on older processors, so i
think the kernel is at fault, we probably should only be printing those extended
capabilities on specific cpus which list valid values for ecx return. The cpus
in question would be newer P4 etc.

Note You need to log in before you can comment on or make changes to this bug.