On Fri, 30 May 2003 23:38:16 -0400, Brian J. Murrell wrote:
>
> I will take another stab at all of this tomorrow to double-verify what I
> am saying here regarding the use of local APIC timer interrupts even if
> the local apic usage flag is set to disable (dont_enable_local_apic = 1).
Just to confirm now, I have modified Zwane's patch add another kernel arg,
[no]locapictimer, which deals with dont_use_local_apic_timer in the same
way his patch deals with the dont_enable_local_apic flag, and indeed, a
kernel booted with "nolapic" does hang in the APIC timer calibration
however a kernel booted with "nolocapictimer" does not.
Is it really valid to go and try to calibrate the APIC timer if it was
disabled by the user, or even DMI?
b.
On Sat, 31 May 2003, Brian J. Murrell wrote:
> Just to confirm now, I have modified Zwane's patch add another kernel arg,
> [no]locapictimer, which deals with dont_use_local_apic_timer in the same
> way his patch deals with the dont_enable_local_apic flag, and indeed, a
> kernel booted with "nolapic" does hang in the APIC timer calibration
> however a kernel booted with "nolocapictimer" does not.
>
> Is it really valid to go and try to calibrate the APIC timer if it was
> disabled by the user, or even DMI?
bah, the early boot hacks are just ugly, we do detect_init_APIC early in
traps code and then just blindly go frobbing the APIC anyway.
The following patch will honour the dont_enable_local_apic flag in the
necessary places. If it works for you i'll forward 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.50
diff -u -p -B -r1.50 apic.c
--- linux-2.5/arch/i386/kernel/apic.c 30 May 2003 20:14:41 -0000 1.50
+++ linux-2.5/arch/i386/kernel/apic.c 31 May 2003 05:53:34 -0000
@@ -665,6 +665,7 @@ static int __init detect_init_APIC (void
return 0;
no_apic:
+ dont_enable_local_apic = 1;
printk("No local APIC present or hardware disabled\n");
return -1;
}
@@ -1127,6 +1128,9 @@ asmlinkage void smp_error_interrupt(void
*/
int __init APIC_init_uniprocessor (void)
{
+ if (dont_enable_local_apic)
+ return -1;
+
if (!smp_found_config && !cpu_has_apic)
return -1;
--
function.linuxpower.ca
On Sat, 31 May 2003, Brian J. Murrell wrote:
> Is it really valid to go and try to calibrate the APIC timer if it was
> disabled by the user, or even DMI?
Nope, could you add me to CC in future messages? It's easier for me to
spot messages which need replying.
Thanks,
Zwane
--
function.linuxpower.ca
On Sat, 31 May 2003, Zwane Mwaikambo wrote:
> > Is it really valid to go and try to calibrate the APIC timer if it was
> > disabled by the user, or even DMI?
>
> bah, the early boot hacks are just ugly, we do detect_init_APIC early in
> traps code and then just blindly go frobbing the APIC anyway.
How about clearing cpu_has_apic and smp_found_config instead? As I
understand the problem, the local APIC is useless so the kernel shouldn't
pretend it's present. And the MP-table is useless without a local APIC.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Tue, 3 Jun 2003, Maciej W. Rozycki wrote:
> On Sat, 31 May 2003, Zwane Mwaikambo wrote:
> How about clearing cpu_has_apic and smp_found_config instead? As I
> understand the problem, the local APIC is useless so the kernel shouldn't
> pretend it's present. And the MP-table is useless without a local APIC.
I agree, but there are already the appropriate checks for wether there is
an APIC enabled that should suffice.
Zwane
--
function.linuxpower.ca
On Wed, 4 Jun 2003, Zwane Mwaikambo wrote:
> > On Sat, 31 May 2003, Zwane Mwaikambo wrote:
> > How about clearing cpu_has_apic and smp_found_config instead? As I
> > understand the problem, the local APIC is useless so the kernel shouldn't
> > pretend it's present. And the MP-table is useless without a local APIC.
>
> I agree, but there are already the appropriate checks for wether there is
> an APIC enabled that should suffice.
You may have a valid SMP table and discrete local APICs (i82489DX) which
are not reported in CPU capability bits. The "nolocalapic" option should
handle them, too. Otherwise it would be a surprising inconsistency.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 5 Jun 2003, Maciej W. Rozycki wrote:
> You may have a valid SMP table and discrete local APICs (i82489DX) which
> are not reported in CPU capability bits. The "nolocalapic" option should
> handle them, too. Otherwise it would be a surprising inconsistency.
Good point, out of interest, have you come across broken system like that?
Regardless i'll update the patch.
Thanks,
Zwane
--
function.linuxpower.ca
On Thu, 5 Jun 2003, Zwane Mwaikambo wrote:
> > You may have a valid SMP table and discrete local APICs (i82489DX) which
> > are not reported in CPU capability bits. The "nolocalapic" option should
> > handle them, too. Otherwise it would be a surprising inconsistency.
>
> Good point, out of interest, have you come across broken system like that?
So far I've met three users of i82489DX-based systems, two of whom helped
me making them work with 2.4. So at least at the beginning of 2.4.x they
used to work; hopefully nothing has got broken since then (I try to
monitor changes, but without real hardware to do testing something might
have slipped in unnoticed). I don't know if these people have kept
upgrading their kernels nor whether they still use the systems. There
were no bug reports, either, which basically may mean anything.
Why do you consider the systems broken?
> Regardless i'll update the patch.
Great!
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Mon, 9 Jun 2003, Maciej W. Rozycki wrote:
> Why do you consider the systems broken?
Not necessarily broken, just no reporting of APIC capability. Not that i
should expect better from Intel (c.f. HT bit, SEP on PPro etc)
> > Regardless i'll update the patch.
>
> Great!
How about we only clear smp_found_config when forced.
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.42
diff -u -p -B -r1.42 apic.c
--- linux-2.5/arch/i386/kernel/apic.c 26 May 2003 23:59:58 -0000 1.42
+++ linux-2.5/arch/i386/kernel/apic.c 10 Jun 2003 00:14:37 -0000
@@ -602,6 +602,15 @@ 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;
+ smp_found_config = 0;
+ return 1;
+}
+
+__setup("nolapic", nolapic_setup);
+
static int __init detect_init_APIC (void)
{
u32 h, l, features;
@@ -609,7 +618,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 +674,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;
}
Index: linux-2.5/Documentation/kernel-parameters.txt
===================================================================
RCS file: /home/cvs/linux-2.5/Documentation/kernel-parameters.txt,v
retrieving revision 1.24
diff -u -p -B -r1.24 kernel-parameters.txt
--- linux-2.5/Documentation/kernel-parameters.txt 6 Jun 2003 15:55:40 -0000 1.24
+++ linux-2.5/Documentation/kernel-parameters.txt 10 Jun 2003 00:14:38 -0000
@@ -625,6 +625,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.
On Mon, 9 Jun 2003, Zwane Mwaikambo wrote:
> > Why do you consider the systems broken?
>
> Not necessarily broken, just no reporting of APIC capability. Not that i
> should expect better from Intel (c.f. HT bit, SEP on PPro etc)
Hmm, how could e.g. an i486 report it? Remember, the i82489DX is a
discrete APIC implementation, i.e. it's a chip external to the CPU. The
i82489DX is actually a complete APIC implementation, including both a
local and an I/O unit in a single chip. And it's also superior to
integrated APIC implementations -- it can address up to 255 units in the
physical destination mode and up to 32 ones in the logical one.
These APICs were used for i486 systems as well as for Pentium ones meant
to support more than two CPUs (although the Pentium integrated local APICs
can probably support more than two such units in a system, there was no
suitable I/O unit available; the i82093AA chip was introduced later and
the i82489DX is hardware-incompatible to later implementations, e.g.
using a five-wire inter-APIC bus).
> How about we only clear smp_found_config when forced.
Looks OK. Probably a message could be added to report handling of the
local APIC got disabled.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +