Re: [PATCH][2.5] Honour dont_enable_local_apic flag

["Brian J. Murrell" <brian@interlinx.bc.ca>]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

On Sun, 2003-06-01 at 19:08, mikpe@csd.uu.se wrote:
> 
> Details, please. What does `cat /proc/cpuinfo` say?

Oops.  Sorry.  Problem is that VMware just reports the underlying (host)
system's CPU, so it will vary from (real) machine to machine.  So for
instance, both my host system and my VMware virtual machine running on
it report:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 796.626
cache size      : 256 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 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1589.24

With the exception of the "apic" flag (and cpu MHz values and bogomips
values differ).  The above is from the host system.  The VMware virtual
system has the same flags minus the apic flag because the only way to
boot it such that I can get the /proc/cpuinfo is by using the nolapic
command arg in the patch I sent earlier.

> My intention here is that we should be able to detect
> this apparently broken "CPU" by its vendor/model and
> clear cpu_has_apic for it.

Not doable by CPU identification I don't think.

> Alternatively the no_apic label in detect_init_APIC()
> could clear cpu_has_apic.

Fair enough, but what would cause the code at the no_apic label to be
executed without any of the command line arg patches proposed?  We could
use Zwane's __setup() for nolapic and instead of doing:

if (dont_enable_local_apic)
	return -1;

in detect_init_APIC() we can do:

if (dont_enable_local_apic)
	goto no_apic;

> Hmm, obviously a 2.4 kernel.

Yes indeed.  This is for testing production systems, so I need stable
kernels.

b.

-- 
Brian J. Murrell <brian@interlinx.bc.ca>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]