Short answer: no.
Long answer: Intel claims ownership to the APIC SMP scheme, and unless a company licenses it from Intel they may not use it. There are currently no companies that have done so. (This of course can change in the future) FYI - Both Cyrix and AMD support the non-proprietary OpenPIC SMP standard but currently there are no motherboards that use it.
Put it into MP1.1/1.4 compliant mode.
From Robert Hyatt : ALR Revolution quad-6 seems quite safe, while some older revolution quad machines without P6 processors seem "iffy"...
From Alan Cox: If one of your CPU's is reporting a very low bogomips value the cache is not enabled on it. Your vendor probably provides a buggy BIOS. Get the patch to work around this or better yet send it back and buy a board from a competent supplier.
Some IBM machines have the MP1.4 bios block in the EBDA, allowed but not supported by <2.1.80. Please update to the right kernel.
There is an old 486SLC based IBM SMP box. Linux/SMP requires hardware FPU support.
Nope (according to Alan
:) ), 1.4 is just a stricker specs of 1.1.
This is known problem with IRQ handling and long kernel locks in the 2.0 series kernels. Consider upgrading to a later 2.1 kernel (not garenteed to work).
From Jakob Oestergaard: Or, consider running xntpd. That should keep your clock right on time. (I think that I've heard that enabling RTC in the kernel also fixes the clock drift. It works for me! but I'm not sure whether that's general or I'm just being lucky)
The CPU number is assigned by the MB manufacturer and doesn't mean anything. Ignore it.
If you're running a 2.0 kernel, consider upgrading to later 2.0.32+ kernels or apply Leonard Zubkoff's deadlock patch. If you still have deadlocks, apply Ingo Molnar's deadlock detection patch and post the results (against your System.map) to linux-smp or linux-kernel. You might also consider running a 2.1 kernel.
You'll find in this section some possible reasons for a crash of an SMP machine (credits are due to Jakob Oestergaard for this part). As far as I (david) know, theses problems are Intel specific.
From Ralf Bächle: [Related to case size and fans] It's important that the air is flowing. It of course can't where cables etc. are preventing this like in too small cases. On the other side I've seen oversized cases causing big problems. There are some tower cases on the market that actually are worse for cooling than desktops. In short, the right thing is thinking about aerodynamics in the case. Extra cases for hot peripherals are usefull as well.
Don't buy too cheap RAM and don't use mixed RAM modules on a motherboard that is picky about it.
Especially Tyan motherboards are known to be picky about RAM speed.
/proc/cpuinfo to see that your CPUs are same stepping.
If you run 2.0.31 or 2.1.xx you can't be sure that SMP is stable. 2.0.33 is the right kernel for a production system. 2.1.xx kernels perform better, but they are development releases and should NOT be considered stable!
...and even if it is stable, DON'T overclock.
From Ralf Bächle: Overclocking causes very subtile problems. I have a nice example, one of my overclocked old machines misscomputes a couple of pixels of a 640 x 400 fractal. The problem is only visible when comparing them using tools. So better say never, nuncas, jamais, niemals overclock.
2.0.X kernels on high performance fast ethernet systems have significant (and known) problems with a race/deadlock condition in the networking interrupt handler.
The solution is to get the latest 100BT development drivers from CESDIS (ones that define SMPCHECK).
If you had a system using the 440FX chipset then your problem with the lockups was possibly due to a documented errata in the chipset. Here is a reference
References: Intel 440FX PCIset 82441FX (PMC) and 82442FX (DBX) Specification Update. pg. 13
The problem can be fixed with a BIOS workaround (Or a kernel patch) and in fact David Wragg wrote a patch that's included with Richard Gooch's MTTR patch. For more information and a fix look here:
From Mark Duguid, dumb rule #1 with W6LI
Some hardware is also known to cause problems. This includes:
Latest news (05 may 1998):
The latest version of this driver (5.0.13 at this writting) should be SMP safe (both in 2.0 and 2.1 kernels). Doug had verified it through code review and intensive tests (on a dual PII system).
This said, some machines still have problems. Doug has kindly given some explanations:
Some work, some don't. Try disabling busmastering if your system is unstable.
Some more specific information can be found with the survey of SMP motherboards
Solution: BIOS upgrade
Solution: BIOS upgrade
It appears to have the same BIOS related BogoMIPS problem as other motherboards. (one CPU only gives about 3 BogoMIPS, the other gives the full amount) All 2.0.x kernels lock up soon after booting, late 2.1.x kernels run slowly but don't seem to lock up. There is no BIOS upgrade available (yet). I wrote the manufacturer but have not received a reply.
Tyan motherboards are known to be picky about RAM speed (Jakob Oestergaard).
From Doug Ledford about the onboard aic-7895 SCSI controller (for which he wrote the driver): "BTW, make sure you have at least BIOS version 1.16 on that Tyan motherboard. The 1.15 and below BIOS versions have a bug relating to IRQ allocation for the 7895 SCSI controller" (submitted by Szakacsits Szabolcs).
But, as motherboard problems are more close to grayshade than black and
;), Richard Jelinek (from S.u.S.E.) tells that
they sell/sold several Tyan Titan Pro (Dual-PPro) Motherboards. They
work perfectly with SMP.
Same BIOS related BogoMIPS problem as other motherboards.
Solution from Alan Cox: Congratulations, send the bill for your hair damage to the supplier. You have yet another SMP box with faulty bios. There is a patch for 2.0.x on www.uk.linux.org and there are people working on generic MTRR handling for 2.1.x
From Claus-Justus Heine: I'm able to boot above MB with 2.1.90 + Ingo's apic + Richard's mtrr patches.
More details for this motherboard at http://www.msi.com.tw/product/6114/6114.htm
Solution: BIOS upgrade
Somebody experienced solid hangs (nothing in the log files) under constant load of about 5 running processes within less than 12 hours with AMI BIOS v1.1. v1.4b3 runs without problems.
My primary production machine is based on an AIR P6NDP and one of my test machines uses a P6NDI. Both seem to be fine motherboards in my experience. The P6NDI BIOS is a little conservative in its programming of the Natoma chipset for 50ns EDO, but a minor tweek to one register in rc.local took care of that.
You can also list the following motherboard as working with no problems:
AIR 54CDP motherboard / EISA/PCI / onboard aic7870 / dual P120 / Redhat 5.0 (2.0.32 and 2.0.33 kernels)
However, Jon Lewis adds the following comments: Has Chris tried putting multiple PCI cards in these motherboards...say a SCSI card and a network card? Due to BIOS brain damage, the 54CDP insists on having all PCI devices share a single IRQ. AIR lead me on for 2 weeks and then said "there have been / will be no updates for your board". This means I can't have Tulip network cards and PCI SCSI without hacking the drives (which seems to work, though I was cautioned not to do it).
Works with 2.0 and 2.1 kernels. Some problems under high network load with 2.0.x kernel. Works under 2.1.78 with Ingo Molnar IO-APIC patch.
Had this mainboard running with ONE PPro on it for several months, and
since about a year, it's running without problems with TWO PPro
200MHz. The only crashes this machine ever experienced were before
Leonard Zubkoff's deadlock-patches for Linux 2.0.30...
Elitegroup P6FX2-A / ISA/PCI / Dual PPro200 / Debian "hamm"
The QDI P6I440LX/DP "Legend IV" dual Pentium II motherboard now boots
properly with Linux-SMP. As of 0326 hours on 15 April, there is a
necessary BIOS upgrade to version 1.6 at the Canadian site (
http://www.qdi.ca). Previously, the
Legend IV would bring up the first processor normally, but the
/proc/cpuinfo file would show the second processor barely
alive. The BIOS update seems to have corrected the problem.
ASUS P2L97-DS works great under Linux-SMP (from Richard Jelinek).
From Mark Garlanger: 2.0.33 is very stable on the board, and the 2.1.xx kernels are improving. People have also been able to run other OSes including Windows NT(yuck...), FreeBSD-SMP, Rhapsody.