Differences between 2.4.0test11ac1 and 2.4.0test11, pretty much all merged
from stuff off the maintainers and kernel list.
For newcomers to these patches:
- You can find them on ftp.*.kernel.org/pub/linux/kernel/people/alan
- They are diffed against the base revision not cumulative diffs
- Please report -ac bugs to me. I'm sure Linus doesn't want to know
unless you can duplicate the problem on unadulterated 2.4test
Change Log
o Documentation for CONFIG_TOSHIBA
o Updated version of Rusty's kernel-hacking doc
o Updated SubmittingDrivers
o Added SubmittingPatches
o Updated procfs docs
o Updated initrd docs
o Support kgcc autodetect
o Link correctly with ACPI on ACPI_INTERPRETER off
o Rusty's fixes/review of unsafe set_bit usage
o Cleanup console_verbose() dunplication
o MTRR updates (36bit etc)
o Dont crash on boot with a dual cpu board holding a non intel cpu
o Ramdisk missing blkdev_put
o Radio driver cleanups
o BTTV radio config option
o Fix qcam VIDIOCGWIN bugs
o 3c503 error return cleanup
o 8390 seperate tx timeout path
o Acenic update
o Network driver check/request region fixes
o Epic100 update
o Tulip crash fix on weird eeproms
o ISAPnP hang on boot port fix
o CS46xx update
o Maestro pci_enable fix
o Support mixed pnp and legacy sb cards
o Fix function prototype in wacom drivr
o Hopefully fix the bugs in the FAT and HPFS file systems that
caused fs corruption
o Fix cramfs vanishing data bug
o Fix NLS config.in bug for SMB
o Fix generic bitops bugs
o Power management locking fixes
o filemap posix compliance fix
o Fix pte handling race
Also the ramfs changes are in my tree. I don't plan to submit the ramfs bits
to Linus in their current state, thats just an Alan Convenience
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
> 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
> > > > 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
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 +
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 +
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
> 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
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
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 +
"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
> > 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
> 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 ?
> > 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
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
> > 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
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
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.orig Tue 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)
{
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 +
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 +
> 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 */
On Wed, 22 Nov 2000, Alan Cox wrote:
> I think it reports 1.1 apics from memory. Its simply hardcoded in the bios
> rather than the configurable flash area.
So we might check for it. Good!
> The following change should make all of this work
>
> if(vendor!=INTEL && !has_apic)
> /* No SMP */
And suddenly certain i486 systems do not work anymore? Well, I haven't
actually heard of an i486 SMP system running Linux so far (maybe they just
work fine, so no reports). But we could try the following, instead:
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.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
> > 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
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
> > > 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
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
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!
On Wed, Nov 22, 2000 at 05:58:14PM +0000, 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