On 01 Jun 2003 12:26:56 -0400, Brian J. Murrell wrote:
>> So what vendor/model CPU is used in the failure case?
>
>VMware 2.0.4.
Details, please. What does `cat /proc/cpuinfo` say?
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.
Alternatively the no_apic label in detect_init_APIC()
could clear cpu_has_apic.
>> 3. What is the exact failure? Hang or crash?
>
>Normal boot until here:
>
>Using local APIC timer interrupts.
>calibrating APIC timer ...
>..... CPU clock speed is 1658.7651 MHz.
>..... host bus clock speed is 0.0000 MHz.
>cpu: 0, clocks: 0, slice: 0
Hmm, obviously a 2.4 kernel.
Looks like a hang in setup_APIC_timer(). My guess is that
the do loops in that procedure don't work if clocks==0
or the local APIC timer registers are frozen.
/Mikael
On Sun, 2003-06-01 at 19:08, [email protected] 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 <[email protected]>
I agree with doing the clear apic capability flag, Brian how does this
fare? This patch alone should fix it.
Index: linux-2.5/arch/i386/kernel/apic.c
===================================================================
RCS file: /home/cvs/linux-2.5/arch/i386/kernel/apic.c,v
retrieving revision 1.54
diff -u -p -B -r1.54 apic.c
--- linux-2.5/arch/i386/kernel/apic.c 31 May 2003 19:01:05 -0000 1.54
+++ linux-2.5/arch/i386/kernel/apic.c 2 Jun 2003 03:50:31 -0000
@@ -609,7 +609,7 @@ static int __init detect_init_APIC (void
/* Disabled by DMI scan or kernel option? */
if (dont_enable_local_apic)
- return -1;
+ goto no_apic;
/* Workaround for us being called before identify_cpu(). */
get_cpu_vendor(&boot_cpu_data);
@@ -665,6 +665,7 @@ static int __init detect_init_APIC (void
return 0;
no_apic:
+ clear_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability);
printk("No local APIC present or hardware disabled\n");
return -1;
}
--
function.linuxpower.ca
On Mon, 2003-06-02 at 00:50, Zwane Mwaikambo wrote:
> I agree with doing the clear apic capability flag,
Indeed. I sure does seem to be the right way to go.
> Brian how does this
> fare? This patch alone should fix it.
It looks good and will try it out. But before I do, should not:
set_bit(X86_FEATURE_APIC, &disabled_x86_caps);
also be done?
>
> Index: linux-2.5/arch/i386/kernel/apic.c
> ===================================================================
> RCS file: /home/cvs/linux-2.5/arch/i386/kernel/apic.c,v
> retrieving revision 1.54
> diff -u -p -B -r1.54 apic.c
> --- linux-2.5/arch/i386/kernel/apic.c 31 May 2003 19:01:05 -0000 1.54
> +++ linux-2.5/arch/i386/kernel/apic.c 2 Jun 2003 03:50:31 -0000
> @@ -609,7 +609,7 @@ static int __init detect_init_APIC (void
>
> /* Disabled by DMI scan or kernel option? */
> if (dont_enable_local_apic)
> - return -1;
> + goto no_apic;
>
> /* Workaround for us being called before identify_cpu(). */
> get_cpu_vendor(&boot_cpu_data);
> @@ -665,6 +665,7 @@ static int __init detect_init_APIC (void
> return 0;
>
> no_apic:
> + clear_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability);
> printk("No local APIC present or hardware disabled\n");
> return -1;
> }
b.
--
Brian J. Murrell <[email protected]>
Zwane Mwaikambo writes:
> I agree with doing the clear apic capability flag, Brian how does this
> fare? This patch alone should fix it.
>
> Index: linux-2.5/arch/i386/kernel/apic.c
> ===================================================================
> RCS file: /home/cvs/linux-2.5/arch/i386/kernel/apic.c,v
> retrieving revision 1.54
> diff -u -p -B -r1.54 apic.c
> --- linux-2.5/arch/i386/kernel/apic.c 31 May 2003 19:01:05 -0000 1.54
> +++ linux-2.5/arch/i386/kernel/apic.c 2 Jun 2003 03:50:31 -0000
> @@ -609,7 +609,7 @@ static int __init detect_init_APIC (void
>
> /* Disabled by DMI scan or kernel option? */
> if (dont_enable_local_apic)
> - return -1;
> + goto no_apic;
>
> /* Workaround for us being called before identify_cpu(). */
> get_cpu_vendor(&boot_cpu_data);
> @@ -665,6 +665,7 @@ static int __init detect_init_APIC (void
> return 0;
>
> no_apic:
> + clear_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability);
> printk("No local APIC present or hardware disabled\n");
> return -1;
> }
Looks good to me. Add a __setup to set dont_enable_local_apic and this
should be sufficient for users of severely broken HW or emulations.
On Mon, 2 Jun 2003 [email protected] wrote:
> Looks good to me. Add a __setup to set dont_enable_local_apic and this
> should be sufficient for users of severely broken HW or emulations.
This should do it then;
Thanks,
Zwane
Index: linux-2.5/Documentation/kernel-parameters.txt
===================================================================
RCS file: /home/cvs/linux-2.5/Documentation/kernel-parameters.txt,v
retrieving revision 1.36
diff -u -p -B -r1.36 kernel-parameters.txt
--- linux-2.5/Documentation/kernel-parameters.txt 2 Jun 2003 02:49:19 -0000 1.36
+++ linux-2.5/Documentation/kernel-parameters.txt 2 Jun 2003 15:20:46 -0000
@@ -624,6 +624,9 @@ running once the system is up.
nointroute [IA-64]
+ nolapic [IA-32, APIC]
+ Disable Local APIC.
+
nomce [IA-32] Machine Check Exception
noresume [SWSUSP] Disables resume and restore original swap space.
Index: linux-2.5/arch/i386/kernel/apic.c
===================================================================
RCS file: /home/cvs/linux-2.5/arch/i386/kernel/apic.c,v
retrieving revision 1.54
diff -u -p -B -r1.54 apic.c
--- linux-2.5/arch/i386/kernel/apic.c 31 May 2003 19:01:05 -0000 1.54
+++ linux-2.5/arch/i386/kernel/apic.c 2 Jun 2003 15:20:47 -0000
@@ -602,6 +602,14 @@ static void apic_pm_activate(void) { }
*/
int dont_enable_local_apic __initdata = 0;
+static int __init nolapic_setup(char *str)
+{
+ dont_enable_local_apic = 1;
+ return 1;
+}
+
+__setup("nolapic", nolapic_setup);
+
static int __init detect_init_APIC (void)
{
u32 h, l, features;
@@ -609,7 +617,7 @@ static int __init detect_init_APIC (void
/* Disabled by DMI scan or kernel option? */
if (dont_enable_local_apic)
- return -1;
+ goto no_apic;
/* Workaround for us being called before identify_cpu(). */
get_cpu_vendor(&boot_cpu_data);
@@ -665,6 +673,7 @@ static int __init detect_init_APIC (void
return 0;
no_apic:
+ clear_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability);
printk("No local APIC present or hardware disabled\n");
return -1;
}
--
function.linuxpower.ca
On Mon, 2003-06-02 at 12:20, Zwane Mwaikambo wrote:
>
> This should do it then;
For the record, this works perfect.
> Thanks,
> Zwane
Thanks Zwane.
b.
--
Brian J. Murrell <[email protected]>