Re: Linux 2.4.0test11-ac1
On Wed, Nov 22, 2000 at 05:58:14PM +, Alan Cox wrote: > > > if(vendor!=INTEL && !has_apic) > > > /* No SMP */ > > > > And suddenly certain i486 systems do not work anymore? Well, I haven't > > i486 is an intel processor ... but is there a reason why for example AMD 486's couldn't work in a 82489DX-based SMP board? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan,
Here is a patch that should fix the problem. I could trim down
verify_local_APIC() now, but given the code freeze I guess it's for
post-2.4.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
diff -up --recursive --new-file
linux-2.4.0-test11-ac2.macro/arch/i386/kernel/mpparse.c
linux-2.4.0-test11-ac2/arch/i386/kernel/mpparse.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/mpparse.c Wed Nov 22 21:05:29
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/mpparse.c Mon Nov 20 18:01:58 2000
@@ -486,18 +486,6 @@ void __init get_smp_config (void)
{
struct intel_mp_floating *mpf = mpf_found;
printk("Intel MultiProcessor Specification v1.%d\n", mpf->mpf_specification);
-
- /* Spot non intel cpus in boards whose bios is a bit loose with the MP
- specification. If the CPU is intel then it may have an external APIC */
-
- if(boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
- !test_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability))
- {
- printk(KERN_WARNING "MP table found but your processor appears not to
be SMP capable.\n");
- printk(KERN_WARNING "Boot will continue single processor.\n");
- return;
- }
-
if (mpf->mpf_feature2 & (1<<7)) {
printk("IMCR and PIC compatibility mode.\n");
pic_mode = 1;
diff -up --recursive --new-file linux-2.4.0-test11-ac2.macro/arch/i386/kernel/setup.c
linux-2.4.0-test11-ac2/arch/i386/kernel/setup.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/setup.c Wed Nov 22 21:05:29
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/setup.c Wed Nov 22 22:22:15 2000
@@ -779,9 +779,7 @@ void __init setup_arch(char **cmdline_p)
paging_init();
#ifdef CONFIG_X86_IO_APIC
/*
-* get boot-time SMP configuration:
-* Don't try and use the SMP configuration/APIC unless the CPU
-* has a local APIC.
+* get boot-time SMP configuration:
*/
if (smp_found_config)
get_smp_config();
diff -up --recursive --new-file
linux-2.4.0-test11-ac2.macro/arch/i386/kernel/smpboot.c
linux-2.4.0-test11-ac2/arch/i386/kernel/smpboot.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/smpboot.c Mon Nov 20 18:01:59
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/smpboot.c Wed Nov 22 22:23:06 2000
@@ -886,8 +886,10 @@ void __init smp_boot_cpus(void)
/*
* If we couldn't find a local APIC, then get out of here now!
*/
- if (!verify_local_APIC()) {
- printk(KERN_ERR "BIOS bug, local APIC at 0x%lX not detected!...\n",
mp_lapic_addr);
+ if (APIC_INTEGRATED(apic_version[boot_cpu_id]) &&
+ !test_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability)) {
+ printk(KERN_ERR "BIOS bug, local APIC #%d not detected!...\n",
+ boot_cpu_id);
printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your
hw vendor)\n");
#ifndef CONFIG_VISWS
io_apic_irqs = 0;
@@ -896,6 +898,8 @@ void __init smp_boot_cpus(void)
smp_num_cpus = 1;
goto smp_done;
}
+
+ verify_local_APIC();
/*
* If SMP should be disabled, then really disable it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan,
Here is a patch that should fix the problem. I could trim down
verify_local_APIC() now, but given the code freeze I guess it's for
post-2.4.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
diff -up --recursive --new-file
linux-2.4.0-test11-ac2.macro/arch/i386/kernel/mpparse.c
linux-2.4.0-test11-ac2/arch/i386/kernel/mpparse.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/mpparse.c Wed Nov 22 21:05:29
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/mpparse.c Mon Nov 20 18:01:58 2000
@@ -486,18 +486,6 @@ void __init get_smp_config (void)
{
struct intel_mp_floating *mpf = mpf_found;
printk("Intel MultiProcessor Specification v1.%d\n", mpf-mpf_specification);
-
- /* Spot non intel cpus in boards whose bios is a bit loose with the MP
- specification. If the CPU is intel then it may have an external APIC */
-
- if(boot_cpu_data.x86_vendor != X86_VENDOR_INTEL
- !test_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability))
- {
- printk(KERN_WARNING "MP table found but your processor appears not to
be SMP capable.\n");
- printk(KERN_WARNING "Boot will continue single processor.\n");
- return;
- }
-
if (mpf-mpf_feature2 (17)) {
printk("IMCR and PIC compatibility mode.\n");
pic_mode = 1;
diff -up --recursive --new-file linux-2.4.0-test11-ac2.macro/arch/i386/kernel/setup.c
linux-2.4.0-test11-ac2/arch/i386/kernel/setup.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/setup.c Wed Nov 22 21:05:29
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/setup.c Wed Nov 22 22:22:15 2000
@@ -779,9 +779,7 @@ void __init setup_arch(char **cmdline_p)
paging_init();
#ifdef CONFIG_X86_IO_APIC
/*
-* get boot-time SMP configuration:
-* Don't try and use the SMP configuration/APIC unless the CPU
-* has a local APIC.
+* get boot-time SMP configuration:
*/
if (smp_found_config)
get_smp_config();
diff -up --recursive --new-file
linux-2.4.0-test11-ac2.macro/arch/i386/kernel/smpboot.c
linux-2.4.0-test11-ac2/arch/i386/kernel/smpboot.c
--- linux-2.4.0-test11-ac2.macro/arch/i386/kernel/smpboot.c Mon Nov 20 18:01:59
2000
+++ linux-2.4.0-test11-ac2/arch/i386/kernel/smpboot.c Wed Nov 22 22:23:06 2000
@@ -886,8 +886,10 @@ void __init smp_boot_cpus(void)
/*
* If we couldn't find a local APIC, then get out of here now!
*/
- if (!verify_local_APIC()) {
- printk(KERN_ERR "BIOS bug, local APIC at 0x%lX not detected!...\n",
mp_lapic_addr);
+ if (APIC_INTEGRATED(apic_version[boot_cpu_id])
+ !test_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability)) {
+ printk(KERN_ERR "BIOS bug, local APIC #%d not detected!...\n",
+ boot_cpu_id);
printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your
hw vendor)\n");
#ifndef CONFIG_VISWS
io_apic_irqs = 0;
@@ -896,6 +898,8 @@ void __init smp_boot_cpus(void)
smp_num_cpus = 1;
goto smp_done;
}
+
+ verify_local_APIC();
/*
* If SMP should be disabled, then really disable it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Hello,
I am a relative newcomer to Linux and recently watching the kernel lists.
FWIW, I have a quad Pentium 100 HP netserver that will panic kernel 2.2.x
and 2.4.x (last checked with 2.4 test9) when bios APIC is turned on. I
know this is not related to what your talking about, and that these are
probably rare systems, but I thought I would let you know.
Thanks,
Bruce H.
"H. Peter Anvin"
<[EMAIL PROTECTED]> To: Alan Cox
<[EMAIL PROTECTED]>
Sent by:cc: [EMAIL PROTECTED], "H.
Peter
linux-kernel-owner@vger.Anvin" <[EMAIL PROTECTED]>, Ingo
Molnar
kernel.org <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: Linux
2.4.0test11-ac1
11/22/2000 01:02 PM
Alan Cox wrote:
>
> > > if(vendor!=INTEL && !has_apic)
> > > /* No SMP */
> >
> > And suddenly certain i486 systems do not work anymore? Well, I
haven't
>
> i486 is an intel processor
>
... but doesn't announce itself as such.
> > if (boot_cpu_id != -1U
> > && APIC_INTEGRATED(apic_version[boot_cpu_id]) && !has_apic)
> > /* No SMP */
> >
> > It should filter broken MP-tables and work fine on all 82489DX-based
> > systems. I'll have a patch soon if we agree on this solution.
>
> we could try that. It doesnt seem unreasonable
Seems reasonable enough.
--
<[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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > > And suddenly certain i486 systems do not work anymore? Well, I haven't > > i486 is an intel processor > > > ... but doesn't announce itself as such. Depends which stepping. We can check for and allow 'unknown' vendor too. The socket7 chips all have cpuid or other id schemes. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote: > > > > if(vendor!=INTEL && !has_apic) > > > /* No SMP */ > > > > And suddenly certain i486 systems do not work anymore? Well, I haven't > > i486 is an intel processor > ... but doesn't announce itself as such. > > if (boot_cpu_id != -1U > > && APIC_INTEGRATED(apic_version[boot_cpu_id]) && !has_apic) > > /* No SMP */ > > > > It should filter broken MP-tables and work fine on all 82489DX-based > > systems. I'll have a patch soon if we agree on this solution. > > we could try that. It doesnt seem unreasonable Seems reasonable enough. -- <[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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > if(vendor!=INTEL && !has_apic) > > /* No SMP */ > > And suddenly certain i486 systems do not work anymore? Well, I haven't i486 is an intel processor > if (boot_cpu_id != -1U > && APIC_INTEGRATED(apic_version[boot_cpu_id]) && !has_apic) > /* No SMP */ > > It should filter broken MP-tables and work fine on all 82489DX-based > systems. I'll have a patch soon if we agree on this solution. we could try that. It doesnt seem unreasonable - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> APICs (probably due to the fact there was no standalone I/O APIC chip > available at that time) so CPUs report no APIC flag. And it starts in the > PIC mode as opposed to the Virtual Wire. I may send you his bootstrap log > if you want to (but not today -- I don't have it handy). Ok. That means my check is over zealous. > Could you please tell me what these broken boards report in MP-tables > when there is no APIC? Maybe we could find a way to distinguish them. > All 82489DX-based boards I've met report 0x1 as the APIC revision (I don't > think there are higher 82489DX revisions). I think it reports 1.1 apics from memory. Its simply hardcoded in the bios rather than the configurable flash area. The following change should make all of this work if(vendor!=INTEL && !has_apic) /* No SMP */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: > > It's not legal -- the MPS is very explicit the MP-table must reflect a > > real configuration. > > Intel tell me otherwise. The real world also disagrees which makes the > discussion a little pointless. We have to handle the real situation where > this occurs Quoting from "MultiProcessor Specification" version 1.4, p. 5-2: "The default system configurations are designed to support dual-processor systems with fixed configurations. Systems with dynamically configurable components, for example, a uniprocessor system with an upgrade socket for the second processor, must always generate the MP configuration table. Failure to do so may cause the operating system to install the wrong modules due to erroneous configuration information." This will not fix the broken work, unfortunately... > > OK, but how does it handle the 82489DX? There are valid configurations > > using this kind of APIC, including Pentium P54C ones... > > These processors don't report the APIC on the cpuid ? If so then I guess > the fix is something like this No, they don't, as they have their on-chip APICs disabled by hardware. Otherwise they wouldn't be able to utilize a discrete local APIC. > Intel stuff appears to always be happy poking in APIC space. I don't know > if this is related to the chip internals on the non APIC capable chips. It might be related to the chipset setup. I wonder whether would it crash on accessing another area of unoccupied space. Hmm, after thinking for I while I recall there exist an event that's called "PCI master abort" and that may happen when no device responds to a PCI cycle. What chipset do the affected systems use? Is it HX or NX? I have docs for both and I may search for a possible cause. Maybe we could fix it as a quirk... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Wed, 22 Nov 2000, Alan Cox wrote: > I know of no socket 7 board with an 82489DX, and no board on the planet which > has 82489DX and works SMP with a non intel processor. I accept its a heuristic > but so is the current behaviour, and the current heuristic isnt working for > as many cases. Do you want me to contact you with a user of such a system? A modular server with the ability to put up to four P54C CPUs. It uses 82489DX APICs (probably due to the fact there was no standalone I/O APIC chip available at that time) so CPUs report no APIC flag. And it starts in the PIC mode as opposed to the Virtual Wire. I may send you his bootstrap log if you want to (but not today -- I don't have it handy). Needless to say, it handles the MP-table fine. Anyway I certainly do not negate the existence of broken boards (and Tyan BIOSes seem to be among the worst ones). I just insist on having a sane way to detect a real APIC and I feel more likely to "punish" broken setups than perfecly good ones. These boards can run UP kernels with no problem, can't they? If so, then just tell their users not to use MP kernels. Could you please tell me what these broken boards report in MP-tables when there is no APIC? Maybe we could find a way to distinguish them. All 82489DX-based boards I've met report 0x1 as the APIC revision (I don't think there are higher 82489DX revisions). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: It's not legal -- the MPS is very explicit the MP-table must reflect a real configuration. Intel tell me otherwise. The real world also disagrees which makes the discussion a little pointless. We have to handle the real situation where this occurs Quoting from "MultiProcessor Specification" version 1.4, p. 5-2: "The default system configurations are designed to support dual-processor systems with fixed configurations. Systems with dynamically configurable components, for example, a uniprocessor system with an upgrade socket for the second processor, must always generate the MP configuration table. Failure to do so may cause the operating system to install the wrong modules due to erroneous configuration information." This will not fix the broken work, unfortunately... OK, but how does it handle the 82489DX? There are valid configurations using this kind of APIC, including Pentium P54C ones... These processors don't report the APIC on the cpuid ? If so then I guess the fix is something like this No, they don't, as they have their on-chip APICs disabled by hardware. Otherwise they wouldn't be able to utilize a discrete local APIC. Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. It might be related to the chipset setup. I wonder whether would it crash on accessing another area of unoccupied space. Hmm, after thinking for I while I recall there exist an event that's called "PCI master abort" and that may happen when no device responds to a PCI cycle. What chipset do the affected systems use? Is it HX or NX? I have docs for both and I may search for a possible cause. Maybe we could fix it as a quirk... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
APICs (probably due to the fact there was no standalone I/O APIC chip available at that time) so CPUs report no APIC flag. And it starts in the PIC mode as opposed to the Virtual Wire. I may send you his bootstrap log if you want to (but not today -- I don't have it handy). Ok. That means my check is over zealous. Could you please tell me what these broken boards report in MP-tables when there is no APIC? Maybe we could find a way to distinguish them. All 82489DX-based boards I've met report 0x1 as the APIC revision (I don't think there are higher 82489DX revisions). I think it reports 1.1 apics from memory. Its simply hardcoded in the bios rather than the configurable flash area. The following change should make all of this work if(vendor!=INTEL !has_apic) /* No SMP */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
if(vendor!=INTEL !has_apic) /* No SMP */ And suddenly certain i486 systems do not work anymore? Well, I haven't i486 is an intel processor if (boot_cpu_id != -1U APIC_INTEGRATED(apic_version[boot_cpu_id]) !has_apic) /* No SMP */ It should filter broken MP-tables and work fine on all 82489DX-based systems. I'll have a patch soon if we agree on this solution. we could try that. It doesnt seem unreasonable - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote: if(vendor!=INTEL !has_apic) /* No SMP */ And suddenly certain i486 systems do not work anymore? Well, I haven't i486 is an intel processor ... but doesn't announce itself as such. if (boot_cpu_id != -1U APIC_INTEGRATED(apic_version[boot_cpu_id]) !has_apic) /* No SMP */ It should filter broken MP-tables and work fine on all 82489DX-based systems. I'll have a patch soon if we agree on this solution. we could try that. It doesnt seem unreasonable Seems reasonable enough. -- [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
And suddenly certain i486 systems do not work anymore? Well, I haven't i486 is an intel processor ... but doesn't announce itself as such. Depends which stepping. We can check for and allow 'unknown' vendor too. The socket7 chips all have cpuid or other id schemes. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Hello,
I am a relative newcomer to Linux and recently watching the kernel lists.
FWIW, I have a quad Pentium 100 HP netserver that will panic kernel 2.2.x
and 2.4.x (last checked with 2.4 test9) when bios APIC is turned on. I
know this is not related to what your talking about, and that these are
probably rare systems, but I thought I would let you know.
Thanks,
Bruce H.
"H. Peter Anvin"
[EMAIL PROTECTED] To: Alan Cox
[EMAIL PROTECTED]
Sent by:cc: [EMAIL PROTECTED], "H.
Peter
linux-kernel-owner@vger.Anvin" [EMAIL PROTECTED], Ingo
Molnar
kernel.org [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Linux
2.4.0test11-ac1
11/22/2000 01:02 PM
Alan Cox wrote:
if(vendor!=INTEL !has_apic)
/* No SMP */
And suddenly certain i486 systems do not work anymore? Well, I
haven't
i486 is an intel processor
... but doesn't announce itself as such.
if (boot_cpu_id != -1U
APIC_INTEGRATED(apic_version[boot_cpu_id]) !has_apic)
/* No SMP */
It should filter broken MP-tables and work fine on all 82489DX-based
systems. I'll have a patch soon if we agree on this solution.
we could try that. It doesnt seem unreasonable
Seems reasonable enough.
--
[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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote:
>
>> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
>>
>> /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes
>> -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
>> sched.o sched.c
>> irq.c:182: conflicting types for `global_irq_lock'
>> /usr/src/linux/include/asm/hardirq.h:45: previous declaration of
>> `global_irq_lock'
>
>I'll check this. I take it you tried an SMP build ?
Yes, this above build attempt was for an SMP kernel. When I got home,
I tried to build an UP kernel with test11-ac1, and as I'm sure you know
already, it worked perfectly. I then tried to build another SMP kernel, with
the same results as above.
I submitted a tiny patchlet earlier for this. It seems to fix the symptoms.
I compiled and ran a kernel with this patch on the SMP box at work.
I replicated the associated comment for people searching on this pattern.
I'm at home now, please cc any questions or comments to [EMAIL PROTECTED]
Steven
Here is the patchlet again:
diff -u linux/include/asm/hardirq.h.orig linux/include/asm/hardirq.h
--- linux/include/asm/hardirq.h.origTue Nov 21 13:38:07 2000
+++ linux/include/asm/hardirq.h Tue Nov 21 13:40:13 2000
@@ -42,7 +42,7 @@
#include
extern unsigned char global_irq_holder;
-extern unsigned volatile int global_irq_lock;
+extern unsigned volatile long global_irq_lock; /* long for set_bit --RR */
static inline int irqs_running (void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > Nononono... the 82489DX is an *external* APIC, which should be usable > > on any Socket 5/7 CPU... > > I know of no socket 7 board with an 82489DX, and no board on the planet which > has 82489DX and works SMP with a non intel processor. I accept its a heuristic > but so is the current behaviour, and the current heuristic isnt working for > as many cases. > Fair enough. -hpa -- <[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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > Intel stuff appears to always be happy poking in APIC space. I don't know > > if this is related to the chip internals on the non APIC capable chips. > > Nononono... the 82489DX is an *external* APIC, which should be usable > on any Socket 5/7 CPU... I know of no socket 7 board with an 82489DX, and no board on the planet which has 82489DX and works SMP with a non intel processor. I accept its a heuristic but so is the current behaviour, and the current heuristic isnt working for as many cases. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > making any assumptions about APIC availability on a processor. > > > > OK, but how does it handle the 82489DX? There are valid configurations > > using this kind of APIC, including Pentium P54C ones... > > These processors don't report the APIC on the cpuid ? If so then I guess > the fix is something like this > > if( cpuid says there is no local apic && vendor != intel) > > Intel stuff appears to always be happy poking in APIC space. I don't know > if this is related to the chip internals on the non APIC capable chips. > Nononono... the 82489DX is an *external* APIC, which should be usable on any Socket 5/7 CPU... -hpa -- <[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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > MP table regardless of the capabilities of the CPU installed. Its apparently > > legal to do so. There is an apic capability flag that should be tested before > It's not legal -- the MPS is very explicit the MP-table must reflect a > real configuration. Intel tell me otherwise. The real world also disagrees which makes the discussion a little pointless. We have to handle the real situation where this occurs > > making any assumptions about APIC availability on a processor. > > OK, but how does it handle the 82489DX? There are valid configurations > using this kind of APIC, including Pentium P54C ones... These processors don't report the APIC on the cpuid ? If so then I guess the fix is something like this if( cpuid says there is no local apic && vendor != intel) Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out: > > /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o > sched.o sched.c > irq.c:182: conflicting types for `global_irq_lock' > /usr/src/linux/include/asm/hardirq.h:45: previous declaration of > `global_irq_lock' I'll check this. I take it you tried an SMP build ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > o Cleanup console_verbose() dunplication > include/linux/kernel.h: if we are adding new inlines to kernel headers, > they should be 'static inline'.. Agreed > > o Epic100 update > > dhinds seemed to question the epic100 fix which is enclosed in > CONFIG_CARDBUS... also I have a big endian fix for epic100 in my local > tree. I dont think its CONFIG_CARDBUS, we need to test the chip version. But as it stands without that newer cards dont work. Its a WiP > The change to hp-plus is totally unnecessary and backwards... > [un]load_8390_module is null, has been for a while. A bombing run was > made recently through most drivers to -remove- the now-null calls to > *_8390_module. Thats just cruft, already done > > o Tulip crash fix on weird eeproms > Hopefully an update with this and more will be out this week. Ok - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
"Maciej W. Rozycki" wrote: > > On Tue, 21 Nov 2000, Alan Cox wrote: > > > Quite a few dual pentium socket 7 boards report dual cpu and apic in the > > MP table regardless of the capabilities of the CPU installed. Its apparently > > legal to do so. There is an apic capability flag that should be tested before > > It's not legal -- the MPS is very explicit the MP-table must reflect a > real configuration. Legal or not, there are broken BIOSes out there. I had a Tyan Tomcat 4S that exhibited this behavior. Even though it was a single socket board, it had the same BIOS as the 4D (dual socket version) and would crash on an SMP kernel with a K6. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: > Quite a few dual pentium socket 7 boards report dual cpu and apic in the > MP table regardless of the capabilities of the CPU installed. Its apparently > legal to do so. There is an apic capability flag that should be tested before It's not legal -- the MPS is very explicit the MP-table must reflect a real configuration. > making any assumptions about APIC availability on a processor. OK, but how does it handle the 82489DX? There are valid configurations using this kind of APIC, including Pentium P54C ones... > And yes some boards crash otherwise. Hmm, the only solution I can see is to check the APIC version in the MP-table and only if an integrated version is reported then check capabilities. But can we trust the version reported given that amount of brokenness out there? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out: /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o sched.o sched.c irq.c:182: conflicting types for `global_irq_lock' /usr/src/linux/include/asm/hardirq.h:45: previous declaration of `global_irq_lock' make[1]: *** [irq.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-ac1/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 Some additional information: [root@spc linux]# which kgcc /usr/bin/kgcc [root@spc linux]# kgcc --version egcs-2.91.66 [root@spc linux]# which make /usr/bin/make [root@spc linux]# make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i586-mandrake-linux-gnu I also had the reiserfs-3.6.19 patch applied, but the compile made it through the reiserfs part successfully. This all works just fine with 2.4.0-test11, where I used gcc 2.95.3 as supplied by Linux-Mandrake 7.2. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> Well, does any SMP board map anything into the local APIC space? After > saying there a real APIC there??? Now *THAT* is completely unsafe. How > is that supposed to work when there actually is an APIC-equipped CPU put > in? Quite a few dual pentium socket 7 boards report dual cpu and apic in the MP table regardless of the capabilities of the CPU installed. Its apparently legal to do so. There is an apic capability flag that should be tested before making any assumptions about APIC availability on a processor. And yes some boards crash otherwise. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote: > Change Log > > o Cleanup console_verbose() dunplication include/linux/kernel.h: if we are adding new inlines to kernel headers, they should be 'static inline'.. > o 3c503 error return cleanup > o 8390 seperate tx timeout path > o Acenic update > o Network driver check/request region fixes > o Epic100 update dhinds seemed to question the epic100 fix which is enclosed in CONFIG_CARDBUS... also I have a big endian fix for epic100 in my local tree. The change to hp-plus is totally unnecessary and backwards... [un]load_8390_module is null, has been for a while. A bombing run was made recently through most drivers to -remove- the now-null calls to *_8390_module. > o Tulip crash fix on weird eeproms Hopefully an update with this and more will be out this week. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: > Its completely unsafe. The CPU in question is NOT intel. It has no APIC > instead you poke around randomly in MMIO space and the box dies. You have > to check the cpu capabilities too Well, does any SMP board map anything into the local APIC space? After saying there a real APIC there??? Now *THAT* is completely unsafe. How is that supposed to work when there actually is an APIC-equipped CPU put in? Poking unoccupied space leads to bus error exceptions for certain archs but I can't actually recall existence of such events for i386... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: > > > o Dont crash on boot with a dual cpu board holding a non intel cpu > > > > Is this the patch to check for the Local APIC? > > Yep Hmm, that's weird -- the check is already there for some time -- see verify_local_APIC(). It works and it's reliable even for the 82489DX. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> > > > o Dont crash on boot with a dual cpu board holding a non intel cpu > > > Is this the patch to check for the Local APIC? > > Yep > > Hmm, that's weird -- the check is already there for some time -- see > verify_local_APIC(). It works and it's reliable even for the 82489DX. Its completely unsafe. The CPU in question is NOT intel. It has no APIC instead you poke around randomly in MMIO space and the box dies. You have to check the cpu capabilities too Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
> On Tue, Nov 21, 2000, Alan Cox <[EMAIL PROTECTED]> wrote: > > o Dont crash on boot with a dual cpu board holding a non intel cpu > > Is this the patch to check for the Local APIC? Yep - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, Nov 21, 2000, Alan Cox <[EMAIL PROTECTED]> wrote: > o Dont crash on boot with a dual cpu board holding a non intel cpu Is this the patch to check for the Local APIC? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, Nov 21, 2000, Alan Cox [EMAIL PROTECTED] wrote: o Dont crash on boot with a dual cpu board holding a non intel cpu Is this the patch to check for the Local APIC? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, Nov 21, 2000, Alan Cox [EMAIL PROTECTED] wrote: o Dont crash on boot with a dual cpu board holding a non intel cpu Is this the patch to check for the Local APIC? Yep - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
o Dont crash on boot with a dual cpu board holding a non intel cpu Is this the patch to check for the Local APIC? Yep Hmm, that's weird -- the check is already there for some time -- see verify_local_APIC(). It works and it's reliable even for the 82489DX. Its completely unsafe. The CPU in question is NOT intel. It has no APIC instead you poke around randomly in MMIO space and the box dies. You have to check the cpu capabilities too Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: o Dont crash on boot with a dual cpu board holding a non intel cpu Is this the patch to check for the Local APIC? Yep Hmm, that's weird -- the check is already there for some time -- see verify_local_APIC(). It works and it's reliable even for the 82489DX. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: Its completely unsafe. The CPU in question is NOT intel. It has no APIC instead you poke around randomly in MMIO space and the box dies. You have to check the cpu capabilities too Well, does any SMP board map anything into the local APIC space? After saying there a real APIC there??? Now *THAT* is completely unsafe. How is that supposed to work when there actually is an APIC-equipped CPU put in? Poking unoccupied space leads to bus error exceptions for certain archs but I can't actually recall existence of such events for i386... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote: Change Log o Cleanup console_verbose() dunplication include/linux/kernel.h: if we are adding new inlines to kernel headers, they should be 'static inline'.. o 3c503 error return cleanup o 8390 seperate tx timeout path o Acenic update o Network driver check/request region fixes o Epic100 update dhinds seemed to question the epic100 fix which is enclosed in CONFIG_CARDBUS... also I have a big endian fix for epic100 in my local tree. The change to hp-plus is totally unnecessary and backwards... [un]load_8390_module is null, has been for a while. A bombing run was made recently through most drivers to -remove- the now-null calls to *_8390_module. o Tulip crash fix on weird eeproms Hopefully an update with this and more will be out this week. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Well, does any SMP board map anything into the local APIC space? After saying there a real APIC there??? Now *THAT* is completely unsafe. How is that supposed to work when there actually is an APIC-equipped CPU put in? Quite a few dual pentium socket 7 boards report dual cpu and apic in the MP table regardless of the capabilities of the CPU installed. Its apparently legal to do so. There is an apic capability flag that should be tested before making any assumptions about APIC availability on a processor. And yes some boards crash otherwise. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out: /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o sched.o sched.c irq.c:182: conflicting types for `global_irq_lock' /usr/src/linux/include/asm/hardirq.h:45: previous declaration of `global_irq_lock' make[1]: *** [irq.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-ac1/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 Some additional information: [root@spc linux]# which kgcc /usr/bin/kgcc [root@spc linux]# kgcc --version egcs-2.91.66 [root@spc linux]# which make /usr/bin/make [root@spc linux]# make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i586-mandrake-linux-gnu I also had the reiserfs-3.6.19 patch applied, but the compile made it through the reiserfs part successfully. This all works just fine with 2.4.0-test11, where I used gcc 2.95.3 as supplied by Linux-Mandrake 7.2. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
On Tue, 21 Nov 2000, Alan Cox wrote: Quite a few dual pentium socket 7 boards report dual cpu and apic in the MP table regardless of the capabilities of the CPU installed. Its apparently legal to do so. There is an apic capability flag that should be tested before It's not legal -- the MPS is very explicit the MP-table must reflect a real configuration. making any assumptions about APIC availability on a processor. OK, but how does it handle the 82489DX? There are valid configurations using this kind of APIC, including Pentium P54C ones... And yes some boards crash otherwise. Hmm, the only solution I can see is to check the APIC version in the MP-table and only if an integrated version is reported then check capabilities. But can we trust the version reported given that amount of brokenness out there? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
"Maciej W. Rozycki" wrote: On Tue, 21 Nov 2000, Alan Cox wrote: Quite a few dual pentium socket 7 boards report dual cpu and apic in the MP table regardless of the capabilities of the CPU installed. Its apparently legal to do so. There is an apic capability flag that should be tested before It's not legal -- the MPS is very explicit the MP-table must reflect a real configuration. Legal or not, there are broken BIOSes out there. I had a Tyan Tomcat 4S that exhibited this behavior. Even though it was a single socket board, it had the same BIOS as the 4D (dual socket version) and would crash on an SMP kernel with a K6. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
o Cleanup console_verbose() dunplication include/linux/kernel.h: if we are adding new inlines to kernel headers, they should be 'static inline'.. Agreed o Epic100 update dhinds seemed to question the epic100 fix which is enclosed in CONFIG_CARDBUS... also I have a big endian fix for epic100 in my local tree. I dont think its CONFIG_CARDBUS, we need to test the chip version. But as it stands without that newer cards dont work. Its a WiP The change to hp-plus is totally unnecessary and backwards... [un]load_8390_module is null, has been for a while. A bombing run was made recently through most drivers to -remove- the now-null calls to *_8390_module. Thats just cruft, already done o Tulip crash fix on weird eeproms Hopefully an update with this and more will be out this week. Ok - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out: /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o sched.o sched.c irq.c:182: conflicting types for `global_irq_lock' /usr/src/linux/include/asm/hardirq.h:45: previous declaration of `global_irq_lock' I'll check this. I take it you tried an SMP build ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
MP table regardless of the capabilities of the CPU installed. Its apparently legal to do so. There is an apic capability flag that should be tested before It's not legal -- the MPS is very explicit the MP-table must reflect a real configuration. Intel tell me otherwise. The real world also disagrees which makes the discussion a little pointless. We have to handle the real situation where this occurs making any assumptions about APIC availability on a processor. OK, but how does it handle the 82489DX? There are valid configurations using this kind of APIC, including Pentium P54C ones... These processors don't report the APIC on the cpuid ? If so then I guess the fix is something like this if( cpuid says there is no local apic vendor != intel) Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Followup to: [EMAIL PROTECTED] By author:Alan Cox [EMAIL PROTECTED] In newsgroup: linux.dev.kernel making any assumptions about APIC availability on a processor. OK, but how does it handle the 82489DX? There are valid configurations using this kind of APIC, including Pentium P54C ones... These processors don't report the APIC on the cpuid ? If so then I guess the fix is something like this if( cpuid says there is no local apic vendor != intel) Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. Nononono... the 82489DX is an *external* APIC, which should be usable on any Socket 5/7 CPU... -hpa -- [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. Nononono... the 82489DX is an *external* APIC, which should be usable on any Socket 5/7 CPU... I know of no socket 7 board with an 82489DX, and no board on the planet which has 82489DX and works SMP with a non intel processor. I accept its a heuristic but so is the current behaviour, and the current heuristic isnt working for as many cases. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Followup to: [EMAIL PROTECTED] By author:Alan Cox [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Nononono... the 82489DX is an *external* APIC, which should be usable on any Socket 5/7 CPU... I know of no socket 7 board with an 82489DX, and no board on the planet which has 82489DX and works SMP with a non intel processor. I accept its a heuristic but so is the current behaviour, and the current heuristic isnt working for as many cases. Fair enough. -hpa -- [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test11-ac1
Alan Cox wrote:
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting types for `global_irq_lock'
/usr/src/linux/include/asm/hardirq.h:45: previous declaration of
`global_irq_lock'
I'll check this. I take it you tried an SMP build ?
Yes, this above build attempt was for an SMP kernel. When I got home,
I tried to build an UP kernel with test11-ac1, and as I'm sure you know
already, it worked perfectly. I then tried to build another SMP kernel, with
the same results as above.
I submitted a tiny patchlet earlier for this. It seems to fix the symptoms.
I compiled and ran a kernel with this patch on the SMP box at work.
I replicated the associated comment for people searching on this pattern.
I'm at home now, please cc any questions or comments to [EMAIL PROTECTED]
Steven
Here is the patchlet again:
diff -u linux/include/asm/hardirq.h.orig linux/include/asm/hardirq.h
--- linux/include/asm/hardirq.h.origTue Nov 21 13:38:07 2000
+++ linux/include/asm/hardirq.h Tue Nov 21 13:40:13 2000
@@ -42,7 +42,7 @@
#include asm/smp.h
extern unsigned char global_irq_holder;
-extern unsigned volatile int global_irq_lock;
+extern unsigned volatile long global_irq_lock; /* long for set_bit --RR */
static inline int irqs_running (void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
