  Linux SMP HOWTO
  David Mentr, David.Mentre@irisa.fr
  v1.9, 13 January 2000

  This HOWTO reviews main issues (and I hope solutions) related to SMP
  configuration under Linux.
  ______________________________________________________________________

  Table of Contents

























































  1. Introduction

  2. Questions related to any architectures

     2.1 Kernel Side
     2.2 User Side
     2.3 SMP Programming
        2.3.1 Parallelization methods
        2.3.2 The C Library
        2.3.3 Languages, Compilers and debuggers
        2.3.4 Other libraries
        2.3.5 Other points about SMP Programming

  3. x86 architecture specific questions

     3.1 Why it doesn't work on my machine?
     3.2 Possible causes of crash
     3.3 Motherboard specific information
        3.3.1 Motherboards with known problems
     3.4 Low cost SMP Linux box (dual Celeron box)
        3.4.1 Is it possible to run a dual Intel Celeron box ?
        3.4.2 How does Linux behave on a dual Celeron system ?
        3.4.3 Celeron processors are known to be easily overclockable. And dual Celeron system ?
        3.4.4 And making a quad Celeron system ?
        3.4.5 What about mixing Celeron and Pentium II processor ?

  4. Sparc architecture specific questions

     4.1 Which Sparc machines are supported ?
     4.2 Specific problem related to Sparc SMP support
     4.3 SMP specific limit with current kernel (2.2)

  5. PowerPC architecture specific questions

     5.1 Which PPC machines are supported ?
     5.2 Specific problem related to PPC SMP support

  6. Alpha architecture specific questions

     6.1 Which Alpha machines are supported ?
     6.2 Specific problem related to Alpha SMP support

  7. Useful pointers

     7.1 Various
     7.2 Multithreaded programs and library
     7.3 SMP specific patches
     7.4 Parallelizing/Optimizing Compilers for 586/686 machines (

  8. Glossary

  9. What's new ?

  10. List of contributors



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  Linux works on SMP (Symmetric Multi-Processors) machines. SMP support
  was introduced with kernel version 2.0, and has improved steadily ever
  since.  The kernel locking granularity is much finer in 2.2.x than in
  2.0.x, which enables better performance when processes are accessing
  the kernel!
  HOWTO maintained by David Mentr (David.Mentre@irisa.fr). The latest
  edition of this HOWTO can be found at

  +o  http://www.irisa.fr/prive/mentre/smp-howto/ (France)

  +o  http://www.phy.duke.edu/brahma/smp-faq/ (USA)


  If you want to contribute to this HOWTO, I would prefer a diff against
  the SGML version <http://www.irisa.fr/prive/mentre/smp-howto/smp-
  howto.sgml> of this document, but any remarks (in plain text) will be
  greatly appreciated. If you send me an email about this HOWTO, please
  include a tag like [Linux SMP HOWTO] in the Subject: field of your e-
  mail. It helps me to automatically sort mails (and you will have a
  faster reply ;)).


  This HOWTO is an improvement of a first draft
  <http://www.ihoc.net/linux-smp-faq-draft.html> made by CChhrriiss PPiirriihh.


  All information contained in this HOWTO is provided "as is." All
  warranties, expressed, implied or statutory, concerning the accuracy
  of the information of the suitability for any particular use are
  hereby specifically disclaimed. While every effort has been taken to
  ensure the accuracy of the information contained in this HOWTO, the
  authors assume no responsibility for errors or omissions, or for
  damages resulting from the use of the information contained herein.


  22..  QQuueessttiioonnss rreellaatteedd ttoo aannyy aarrcchhiitteeccttuurreess


  22..11..  KKeerrnneell SSiiddee




  1. DDooeess LLiinnuuxx ssuuppppoorrtt mmuullttii--tthhrreeaaddiinngg??  IIff II ssttaarrtt ttwwoo oorr mmoorree
     pprroocceesssseess,, wwiillll tthheeyy bbee ddiissttrriibbuutteedd aammoonngg tthhee aavvaaiillaabbllee CCPPUUss??

     Yes. Processes and kernel-threads are distributed among processors.
     User-space threads are not.


  2. WWhhaatt kkiinndd ooff aarrcchhiitteeccttuurreess aarree ssuuppppoorrtteedd iinn SSMMPP??


     FFrroomm AAllaann CCooxx:
        SMP is supported in 2.0 on the hypersparc (SS20, etc.) systems
        and Intel 486, Pentium or higher machines which are Intel
        MP1.1/1.4 compliant. RRiicchhaarrdd JJeelliinneekk adds: right now, systems
        have been tested up to 4 CPUs and the MP standard (and so Linux)
        theoretically allows up to 16 CPUs.

        SMP support for UltraSparc, SparcServer, Alpha and PowerPC
        machines is in available in 2.2.x.


     FFrroomm RRaallff BBcchhllee:
        MIPS, m68k and ARM does not support SMP; the latter two probly
        won't ever.

        That is, I'm going to hack on MIPS-SMP as soon as I get a SMP
        box ...

  3. HHooww ddoo II mmaakkee aa LLiinnuuxx SSMMPP kkeerrnneell??

     Most Linux distributions don't provide a ready-made SMP-aware
     kernel, which means that you'll have to make one yourself. If you
     haven't made your own kernel yet, this is a great reason to learn
     how.  Explaining how to make a new kernel is beyond the scope of
     this document; refer to the Linux Kernel Howto for more
     information. (CC.. PPoolliisshheerr)

     In kernel series 2.0 up to but not including 2.1.132, uncomment the
     SMP=1 line in the main Makefile (/usr/src/linux/Makefile).

     In the 2.2 version, configure the kernel and answer "yes" to the
     question "Symmetric multi-processing support" (MMiicchhaaeell EElliizzaabbeetthh
     CChhaassttaaiinn).

     AND

     enable real time clock support by configuring the "RTC support"
     item (from RRoobbeerrtt GG..  BBrroowwnn). Note that inserting RTC support
     actually doesn't afaik prevent the known problem with SMP clock
     drift, but enabling this feature prevents lockup when the clock is
     read at boot time. A note from RRiicchhaarrdd JJeelliinneekk says also that
     activating the Enhanced RTC is necessary to get the second CPU
     working (identified) on some original Intel Mainboards.

     AND

     (x86 kernel) do NOT enable APM (advanced power management)! APM and
     SMP are not compatible, and your system will almost certainly (or
     at least probably ;)) crash while booting if APM is enabled (JJaakkoobb
     OOeesstteerrggaaaarrdd). AAllaann CCooxx confirms this : 2.1.x turns APM off for SMP
     boxes.  Basically APM is undefined in the presence of SMP systems,
     and anything could occur.

     AND

     (x86 kernel) enable "MTRR (Memory Type Range Register) support".
     Some BIOS are buggy as they do not activate cache memory for the
     second processor. The MTRR support contains code that solves such
     processor misconfiguration.



     You must rebuild all your kernel and kernel modules when changing
     to and from SMP mode. Remember to make modules and make
     modules_install (from AAllaann CCooxx).


     If you get module load errors, you probably did not rebuild and/or
     re-install your modules.  Also with some 2.2.x kernels people have
     reported problems when changing the compile from SMP back to UP
     (uni-processor).  To fix this, save your .config file, do _m_a_k_e
     _m_r_p_r_o_p_e_r, restore your _._c_o_n_f_i_g file, then remake your kernel (_m_a_k_e
     _d_e_p, etc.)  (WWaaddee HHaammppttoonn). Do not forget to run lilo after copying
     your new kernel.

     Recap:








     ___________________________________________________________________
     make config # or menuconfig or xconfig
     make dep
     make clean
     make bzImage # or whatever you want
     # copy the kernel image manually then RUN LILO
     # or make lilo
     make modules
     make modules_install
     ___________________________________________________________________





  4. HHooww ddoo II mmaakkee aa LLiinnuuxx nnoonn-SMP kernel?

     In the 2.0 series, ccoommmmeenntt the SMP=1 line in the main Makefile
     (/usr/src/linux/Makefile).

     In the 2.2 series, configure the kernel and answer "no" to the
     question "Symmetric multi-processing support" (MMiicchhaaeell EElliizzaabbeetthh
     CChhaassttaaiinn).




     You must rebuild all your kernel and kernel modules when changing
     to and from SMP mode. Remember to make modules and make
     modules_install and remember to run lilo.  See notes above about
     possible configuration problems.



  5. HHooww ccaann II tteellll iiff iitt wwoorrkkeedd??


      cat /proc/cpuinfo




  Typical output (dual PentiumII):

  ______________________________________________________________________
  processor       : 0
  cpu             : 686
  model           : 3
  vendor_id       : GenuineIntel
  [...]
  bogomips        : 267.06

  processor       : 1
  cpu             : 686
  model           : 3
  vendor_id       : GenuineIntel
  [...]
  bogomips        : 267.06
  ______________________________________________________________________




  6. WWhhaatt iiss tthhee ssttaattuuss ooff ccoonnvveerrttiinngg tthhee kkeerrnneell ttoowwaarrdd ffiinneerr ggrraaiinneedd
     lloocckkiinngg aanndd mmuullttiitthhrreeaaddiinngg??

     Linux kernel version 2.2 has signal handling, interrupts and some
     I/O stuff fine grain locked.  The rest is gradually migrating. All
     the scheduling is SMP safe.


     Kernel version 2.3 (next 2.4) has really fine grained locking. In
     the 2.3 kernels the usage of the big kernel lock has basically
     disappeared, all major Linux kernel subsystems are fully threaded:
     networking, VFS, VM, IO, block/page caches, scheduling, interrupts,
     signals, etc. (IInnggoo MMoollnnaarr)


  7. DDooeess LLiinnuuxx SSMMPP ssuuppppoorrtt pprroocceessssoorr aaffffiinniittyy??



     SSttaannddaarrdd kkeerrnneell
        No and Yes.  There is no way to force a process onto specific
        CPU's but the linux scheduler has a processor bias for each
        process, which tends to keep processes tied to a specific CPU.


     PPaattcchh
        Yes. Look at PSET - Processor Sets for the Linux kernel
        <http://isunix.it.ilstu.edu/~thockin/pset/>:

          The goal of this project is to make a source compatible
          and functionally equivalent version of pset (as defined
          by SGI - partially removed from their IRIX 6.4 kernel)
          for Linux.  This enables users to determine which proces-
          sor or set of processors a process may run on.  Possible
          uses include forcing threads to separate processors, tim-
          ings, security (a `root' only CPU?) and probably more.


     It is focused around the syscall sysmp().  This function takes a
     number of parameters that determine which function is requested.
     Functions include:

     +o  binding a process/thread to a specific CPU

     +o  restricting a CPU's ability to execute some processes

     +o  restricting a CPU from running at all

     +o  forcing a cpu to run _only_ one process (and its children)

     +o  getting information about a CPU's state

     +o  creating/destroying sets of processors, to which processes may
        be bound



  8. WWhheerree sshhoouulldd oonnee rreeppoorrtt SSMMPP bbuuggss ttoo??

     Please report bugs to linux-smp@vger.rutgers.edu.


  9. WWhhaatt aabboouutt SSMMPP ppeerrffoorrmmaannccee??

     If you want to gauge the performance of your SMP system, you can
     run some tests made by Cameron MacKinnon and available at
     http://www.phy.duke.edu/brahma/benchmarks.smp.


  22..22..  UUsseerr SSiiddee


  1. DDoo II rreeaallllyy nneeeedd SSMMPP??

     If you have to ask, you probably don't. :) Generally, multi-
     processor systems can provide better performance than uni-processor
     systems, but to realize any gains you need to consider many other
     factors besides the number of CPU's.  For instance, on a given
     system, if the processor is generally idle much of the time due to
     a slow disk drive, then this system is "input/output bound", and
     probably won't benefit from additional processing power. If, on the
     other hand, a system has many simultaneously executing processes,
     and CPU utilization is very high, then you are likely to realize
     increased system performance.  SCSI disk drives can be very
     effective when used with multiple processors, due to the way they
     can process multiple commands without tying up the CPU. (CC..
     PPoolliisshheerr)


  2. DDoo II ggeett tthhee ssaammee ppeerrffoorrmmaannccee ffrroomm 22--330000 MMHHzz pprroocceessssoorrss aass ffrroomm oonnee
     660000 MMHHzz pprroocceessssoorr??

     This depends on the application, but most likely not.  SMP adds
     some overhead that a faster uniprocessor box would not incur (WWaaddee
     HHaammppttoonn).  :)


  3. HHooww ddooeess oonnee ddiissppllaayy mmuuttiippllee ccppuu ppeerrffoorrmmaannccee??

     Thanks to SSaammuueell SS.. CChheessssmmaann, here are some useful utilities:

     CChhaarraacctteerr bbaasseedd::
        http://www.cs.inf.ethz.ch/~rauch/procps.html

        Basically, it's procps v1.12.2 (top, ps, et. al.)  and some
        patches to support SMP.

        For 2.2.x, GGrreeggoorryy RR.. WWaarrnneess as made a patch available at
        http://queenbee.fhcrc.org/~warnes/procps


     GGrraapphhiicc::
        xosview-1.5.1 supports SMP. And kernels above 2.1.85 (included)
        the cpuX entry in /proc/stat file.

        The official homepage for xosview is:
        http://lore.ece.utexas.edu/~bgrayson/xosview.html

        You'll find a version patched for 2.2.x kernels by KKuummssuupp LLeeee :
        http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz

        The various Forissier's kernel patches are at: http://www-
        isia.cma.fr/~forissie/smp_kernel_patch/

     By the way, you can't monitor processor scheduling precisely with
     xosview, as xosview itself causes a scheduling perturbation. (HH..
     PPeetteerr AAnnvviinn)


  4. HHooww ccaann II eennaabbllee mmoorree tthhaann 11 pprroocceessss ffoorr mmyy kkeerrnneell ccoommppiillee??

     use:



     ___________________________________________________________________
             # make [modules|zImage|bzImages] MAKE="make -jX"
             where X=max number of processes.
             WARNING: This won't work for "make dep".
     ___________________________________________________________________



  With a 2.2 like kernel, see also the file
  /usr/src/linux/Documentation/smp.txt for specific instruction.

  BTW, since running multiple compilers allows a machine with sufficient
  memory to use use the otherwise wasted CPU time during I/O caused
  delays, make MAKE="make -j 2" -j 2 actually helps even on uniprocessor
  boxes (from RRaallff BBcchhllee).


  5. WWhhyy iiss tthhee ttiimmee ggiivveenn bbyy tthhee time command inaccurate?  (from JJooeell
     MMaarrcchhaanndd)

     In the 2.0 series, the result given by the time command is false.
     The sum user+system is right *but* the spreading between user and
     system time is false.

     More precisely: "The explanation is, that all time spent in
     processors other than the boot cpu is accounted as system time.  If
     you time a program, add the user time and the system time, then you
     timing will be almost right, except for also including the system
     time that is correctly accounted for" (JJaakkoobb sstteerrggaaaarrdd).

     This bug is corrected in 2.2 kernels.






  22..33..  SSMMPP PPrrooggrraammmmiinngg

  Section by JJaakkoobb sstteerrggaaaarrdd.

  This section is intended to outline what works, and what doesn't when
  it comes to programming multi-threaded software for SMP Linux.


  22..33..11..  PPaarraalllleelliizzaattiioonn mmeetthhooddss


  1. POSIX Threads

  2. PVM / MPI Message Passing Libraries

  3. fork() -- Multiple processes

  Since both fork() and PVM/MPI processes usually do not share memory,
  but either communicate by means of IPC or a messaging API, they will
  not be described further in this section. They are not very specific
  to SMP, since they are used just as much - or more - on uniprocessor
  computers, and clusters thereof.


  Only POSIX Threads provide us with multiple threads sharing ressources
  like - especially - memory. This is the thing that makes a SMP machine
  special, allowing many processors to share their memory. To use both
  (or more ;) processors of an SMP, use a kernel-thread library. A good
  library is the LinuxThreads, a pthread library made by Xavier Leroy
  <http://pauillac.inria.fr/~xleroy/linuxthreads/> which is now
  integrated with glibc2 (aka libc6).  Newer Linux distributions include
  this library by default, hence you do not have to obtain a separate
  package to use kernel threads.

  There are implementations of threads (and POSIX threads) that are
  application-level, and do not take advantage of the kernel-threading.
  These thread packages keep the threading in a single process, hence do
  not take advantage of SMP.  However, they are good for many
  applications and tend to actually run faster than kernel-threads on
  single processor systems.

  Multi-threading has never been really popular in the UN*X world
  though. For some reason, applications requiring multiple processes or
  threads, have mostly been written using fork(). Therefore, when using
  the thread approach, one runs into problems of incompatible (not
  thread-ready) libraries, compilers, and debuggers.  GNU/Linux is no
  exception to this. Hopefully the next few sections will sched a little
  light over what is currently possible, and what is not.



  22..33..22..  TThhee CC LLiibbrraarryy

  Older C libraries are not thread-safe. It is very important that you
  use GNU LibC (gglliibbcc), also known as lliibbcc66. Earlier versions are, of
  course possible to use, but it will cause you much more trouble than
  upgrading your system will, well probably :)

  If you want to use GDB to debug your programs, see below.


  22..33..33..  LLaanngguuaaggeess,, CCoommppiilleerrss aanndd ddeebbuuggggeerrss

  There is a wealth of programming languages available for GNU/Linux,
  and many of them can be made to use threads one way or the other (some
  languages like Ada and Java even have threads as primitives in the
  language).

  This section will, however, currently only describe C and C++. If you
  have experience in SMP Programming with other languages, please
  enlighten us.

  GNU C and C++, as well as the EGCS C and C++ compilers work with the
  thread support from the standard C library (gglliibbcc). There are however
  a few issues:


  1. When compiling C or C++, use the --DD__RREEEENNTTRRAANNTT define in the
     compiler command line. This is necessary to make certain error-
     handling functions work like the errno variable.

  2. When using C++, If two threads throw exceptions concurrently, the
     program will segfault.  The compiler does not generate thread-safe
     exception code.

     The workaround is to put a
     pthread_mutex_lock(&global_exception_lock) in the constructor(s) of
     every class you throw(), and to put the corresponding
     pthread_mutex_unlock(...) in the destructor.  It's ugly, but it
     works.  This solution was given by MMaarrkkuuss FFeerrcchh.

  The GNU Debugger GGDDBB as of version 4.18, should handle threads
  correctly. Most Linux distribution offer a patched, thread-aware gdb.


  It is not necessary to patch gglliibbcc in any way just to make it work
  with threads. If you do not need to debug the software (this could be
  true for all machines that are not development workstations), there is
  no need to patch gglliibbcc.

  Note that core-dumps are of no use when using multiple threads.
  Somehow, the core dump is attached to one of the currently running
  threads, and not to the program as a whole. Therefore, whenever you
  are debugging anything, run it from the debugger.

  HHiinntt:: If you have a thread running haywire, like eating 100% CPU time,
  and you cannot seem to figure out why, here is a nice way to find out
  what's going on: Run the program straight from the shell, no GDB. Make
  the thread go haywire. Use ttoopp to get the PID of the process.  Run GDB
  like ggddbb pprrooggrraamm ppiidd. This will make GDB attach itself to the process
  with the PID you specified, and stop the thead. Now you have a GDB
  session with the offending thread, and can use bbtt and the like to see
  what is happening.


  22..33..44..  OOtthheerr lliibbrraarriieess

  EElleeccttrriiccFFeennccee:: This library is not thread safe. It should be possible,
  however, to make it work in SMP environments by inserting mutex locks
  in the ElectricFence code.



  22..33..55..  OOtthheerr ppooiinnttss aabboouutt SSMMPP PPrrooggrraammmmiinngg


  1. WWhheerree ccaann II ffoouunndd mmoorree iinnffoorrmmaattiioonn aabboouutt ppaarraalllleell pprrooggrraammmmiinngg??

     Look at the Linux Parallel Processing HOWTO
     <http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html>

     Lots of useful information can be found at Parallel Processing
     using Linux <http://yara.ecn.purdue.edu/~pplinux/>

     Look also at the Linux Threads FAQ <http://linas.org/linux/threads-
     faq.html>


  2. AArree tthheerree aannyy tthhrreeaaddeedd pprrooggrraammss oorr lliibbrraarriieess??

     Yes. For programs, you should look at: Multithreaded programs on
     linux <http://www.informatik.uni-bremen.de/~hollow/mthread.html> (I
     love hyperlinks, did you know that ? ;))

     As far as library are concerned, there are:


     OOppeennGGLL MMeessaa lliibbrraarryy
        Thanks to DDaavviidd BBuuccccaarreellllii, AAnnddrreeaass SScchhiifffflleerr and EEmmiill BBrriiggggss,
        it exists in a multithreaded version (right now [1998-05-11],
        there is a working version that provides speedups of 5-30% on
        some OpenGL benchmarks). The multithreaded stuff is now included
        in the regular Mesa distribution as an experimental option.  For
        more information, look at the Mesa library
        <http://www.ssec.wisc.edu/~brianp/Mesa.html>


     BBLLAASS
        Pentium Pro Optimized BLAS and FFTs for Intel Linux
        <http://www.cs.utk.edu/~ghenry/distrib/>

        Multithreaded BLAS routines are not available right now, but a
        dual proc library is planned for 1998-05-27, see Blas News
        <http://www.cs.utk.edu/~ghenry/distrib/blasnews> for details.


     TThhee GGIIMMPP
        EEmmiill BBrriiggggss, the same guy who is involved in multithreaded Mesa,
        is also working on multithreaded The GIMP plugins. Look at
        http://nemo.physics.ncsu.edu/~briggs/gimp/index.html for more
        info.






  33..  xx8866 aarrcchhiitteeccttuurree ssppeecciiffiicc qquueessttiioonnss


  33..11..  WWhhyy iitt ddooeessnn''tt wwoorrkk oonn mmyy mmaacchhiinnee??


  1. CCaann II uussee mmyy CCyyrriixx//AAMMDD//nnoonn--IInntteell CCPPUU iinn SSMMPP??

     SShhoorrtt aannsswweerr:: no.

     LLoonngg aannsswweerr:: 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.


  2. WWhhyy ddooeessnn''tt mmyy oolldd CCoommppaaqq wwoorrkk??

     Put it into MP1.1/1.4 compliant mode.

     check "Configure Hardware" -> "View / Edit details" -> "Advanced
     mode" (F7 I think) for a configuration option "APIC mode" and set
     this to "full Table mode". This is an official Compaq
     recommandation. (DDaanniieell RRooeesseenn)

     (AAddrriiaann PPoorrtteellllii)To do this:

     a. Press F10 when the server boots to enter the System
        Configuration Utility

     b. Press Enter to dismiss the splash screen

     c. Immediately press CTRL+A

     d. A message will appear informing you that you are now in
        "Advanced Mode"

     e. Then select "Configure Hardware" -> "View / Edit details"

     f. You will then see the advanced settings (intermixed with the
        ordinary ones)

     g. Stroll down to "APIC Mode" and then select "Fully Mapped"

     h. Save changes and reboot



  3. WWhhyy ddooeessnntt mmyy AALLRR wwoorrkk??

     From RRoobbeerrtt HHyyaatttt : ALR Revolution quad-6 seems quite safe, while
     some older revolution quad machines without P6 processors seem
     "iffy"...


  4. WWhhyy ddooeess SSMMPP ggoo ssoo sslloowwllyy?? or WWhhyy ddooeess oonnee CCPPUU sshhooww aa vveerryy llooww
     bbooggoommiippss vvaalluuee wwhhiillee tthhee ffiirrsstt oonnee iiss nnoorrmmaall??

     From AAllaann CCooxx: 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.

     A 2.0 kernel (> 2.0.36) contains the MTRR patch which should solve
     this problem (select option "Handle buggy SMP BIOSes with bad MTRR
     setup" in the "General setup" menu).

     I think buggy SMP BIOS handling is automatic in latest 2.2 kernels.


  5. II''vvee hheeaarrdd IIBBMM mmaacchhiinneess hhaavvee pprroobblleemmss


     Some IBM machines have the MP1.4 bios block in the EBDA, allowed
     but not supported below 2.2 kernels.

     There is an old 486SLC based IBM SMP box. Linux/SMP requires
     hardware FPU support.


  6. IIss tthheerree aannyy aaddvvaannttaaggee ooff IInntteell MMPP 11..44 oovveerr 11..11 ssppeecciiffiiccaattiioonn??

     Nope (according to Alan :) ), 1.4 is just a stricker specs of 1.1.


  7. WWhhyy ddooeess tthhee cclloocckk ddrriifftt ssoo rraappiiddllyy wwhheenn II rruunn lliinnuuxx SSMMPP??


     This is known problem with IRQ handling and long kernel locks in
     the 2.0 series kernels.  Consider upgrading to a later 2.2 kernel.

     From JJaakkoobb OOeesstteerrggaaaarrdd: 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)


     There are some kernel fixes in the later 2.2.x series that may fix
     this.



  8. WWhhyy aarree mmyy CCPPUU''ss nnuummbbeerreedd 00 aanndd 22 iinnsstteeaadd ooff 00 aanndd 11 ((oorr ssoommee ootthheerr
     oodddd nnuummbbeerriinngg))??

     The CPU number is assigned by the MB manufacturer and doesn't mean
     anything.  Ignore it.



  9. MMyy qquuaadd--XXeeoonn ssyysstteemm hhaannggss aass ssoooonn aass iitt hhaass ddeeccoommpprreesssseedd tthhee kkeerrnneell

     (DDoouugg LLeeddffoorrdd) Try recompiling LILO with LARGE_EBDA support and
     then making sure to always use make bzImage when compiling the
     kernel.  That appears to have fixed the SMP boot hangs here on
     Intel multi-Xeon boards.  However, please note that this also
     appears to break LILO in that the root= option no longer works, so
     make sure you rdev your kernel image at the same time you run lilo
     to make sure that the kernel loads the correct root filesystem at
     boot.

     (RRoobbeerrtt MM.. HHyyaatttt) With 3 cpus, do you have a terminator in the 4th
     slot?


  10.
     DDuurriinngg bboooott mmaacchhiinnee hhaanngg ssiiggnnaalliinngg aann IIOOAAPPIICC pprroobblleemm

     Try boot options "noapic" (JJoohhnn AAllddrriicchh) and/or "reboot=bios"
     (TTeerrrryy SShhuullll).


  11.
     MMyy ssyysstteemm lloocckkss uupp dduurriinngg hheeaavvyy NNFFSS ttrraaffffiicc

     Try the later 2.2.x kernels and the knfsd patches.  This is
     currently under investigation. (WWaaddee HHaammppttoonn)



  12.
     MMyy ssyysstteemm lloocckkss uupp wwiitthh nnoo ooooppss mmeessssaaggeess

     If you are using kernels 2.2.11 or 2.2.12, get the latest kernel.
     For example 2.2.13 has a number of SMP fixes.  Several people have
     reported these kernels to be unstable for SMP.  These same kernels
     may have NFS problems that can cause lockups.  Also, use a serial
     console to capture your oops messages. (WWaaddee HHaammppttoonn)

     If the problem remains (and the other suggestions on this list
     didn't help either), then you could try the latest 2.3 kernels.
     They have more verbose (and more robust) SMP/APIC code, and
     automatic hard-lockup-prevention code which will produce meaningful
     oopses instead of a silent hang. (IInnggoo MMoollnnaarr)

     (OOssaammuu AAookkii) You MUST also _d_i_s_a_b_l_e all BIOS related power save
     features.  Example of good configuration (Dual Celeron 466 Abit
     BP6):

     ___________________________________________________________________
      POWER MANAGEMENT SETUP.
        ACPI:              Disabled
        POWER MANAGEMENT:  Disabled
        PM CONTROL by APM: No
     ___________________________________________________________________


  If power management features are activated, some random freeze can
  occur.


  13.
     DDeebbuuggggiinngg lloocckkuuppss

     (item by WWaaddee HHaammppttoonn)

     A good means of debugging lockups is to get the ikd patch from
     Andrea Arcangeli: ftp://ftp.suse.com/pub/people/andrea/kernel-
     patches
     There are several of debug options, but do NOT use the soft lockup
     option!  For newer SMP boxes, turn kernel debugging then turn on
     the NMI oopser.  To verify that the NMI oopser is working, after
     booting the new kernel, /cat /proc/interrupts and verify that you
     are getting NMIs.  When the box locks up, you should get an OOPS.

     You may also try the %eip option.  This allows the kernel to print
     on the console the %eip address every time a kernel function is
     called.  When the box locks up, write down the first column ordered
     by the second column then lookup the addresses in the System.map
     file.  This works only in console mode.

     Also note that the use of a serial console can greatly facilitate
     debugging kernel lockups, not just SMP kernel lockups!


  14.
     ""AAPPIICC eerrrroorr iinntteerrrruupptt oonn CCPPUU##nn,, sshhoouulldd nneevveerr hhaappppeenn"" mmeessssaaggeess iinn
     llooggss

     A message like:

     ___________________________________________________________________
     APIC error interrupt on CPU#0, should never happen.
     ... APIC ESR0: 00000002
     ... APIC ESR1: 00000000
     ___________________________________________________________________


  indicates a 'receive checksum error'. This cannot be caused by Linux
  as the APIC message checksumming part is completely in hardware. It
  might be marginal hardware. As long as you dont see any instability,
  they are not a problem - APIC messages are retried until delivered.
  (IInnggoo MMoollnnaarr)




  33..22..  PPoossssiibbllee ccaauusseess ooff ccrraasshh

  In this section you'll find some ppoossssiibbllee reasons for a crash of an
  SMP machine (credits are due to JJaakkoobb sstteerrggaaaarrdd for this part). As far
  as I (David) know, theses problems are Intel specific.



  +o  CCoooolliinngg pprroobblleemmss

     From RRaallff BBcchhllee: [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.

     Of course you can always go to Radio Shack (or similar) and get
     another fan.  You can use the lm_sensors to monitor the CPU
     temperature of newer PII and PIII processors.  This might help you
     to determine if heat is a problem. (WWaaddee HHaammppttoonn)



  +o  BBaadd mmeemmoorryy

     Don't buy 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
     (see the Tyan paragraph below for a possible solution).


     There have been some report of 10ns PC100 RAM being sold with
     motherboards where the CPU really needs 8ns RAM. (WWaaddee HHaammppttoonn)



  +o  BBaadd ccoommbbiinnaattiioonn ooff ddiiffffeerreenntt sstteeppppiinngg CCPPUUss

     Check /proc/cpuinfo to see that your CPUs are same stepping.


  +o  IIff yyoouurr ssyysstteemm iiss uunnssttaabbllee,, tthheenn DDOONN''TT oovveerrcclloocckk iitt!!

     ...and even if it is stable, DON'T overclock.

     From RRaallff BBcchhllee: Overclocking causes very subtle 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 _n_e_v_e_r_,
     _n_u_n_c_a_s_, _j_a_m_a_i_s_, _n_i_e_m_a_l_s overclock.



  +o  22..00..xx kkeerrnneell aanndd ffaasstt eetthheerrnneett (from RRoobbeerrtt GG.. BBrroowwnn)

     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 Linux Ethernet device drivers site
     <http://cesdis.gsfc.nasa.gov/linux/drivers/> (ones that define
     SMPCHECK).


  +o  AA bbuugg iinn tthhee 444400FFXX cchhiippsseett (from EEmmiill BBrriiggggss)

     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

     http://www.intel.com/design/pcisets/specupdt/297654.htm

     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:

     http://nemo.physics.ncsu.edu/~briggs/vfix.html


  +o  DDOONNTT rruunn eemmmm338866..eexxee bbeeffoorree bboooottiinngg lliinnuuxx SSMMPP

     From MMaarrkk DDuugguuiidd, dumb rule #1 with W6LI motherboards. ;)


  +o  IIff tthhee mmaacchhiinnee rreebboooottss//ffrreeeezzeess aafftteerr aa wwhhiillee,, tthheerree ccaann bbee ttwwoo ggoooodd
     BBIIOOSS ++ mmeemmoorryy rreellaatteedd rreeaassoonnss (from JJaakkoobb sstteerrggaaaarrdd)

  +o  If the BIOS has settings like "memory hole at 16M" and/or "OS/2
     memory > 64MB", try disabling them both. Linux does not always
     react well with theese options.

  +o  If you have more than 64 MB of memory in the machine, and you
     specified the exact number manually in the LILO configuration, you
     should specify one MB less than you actually have in the machine.
     If you have 128 MB, you lilo.conf line looks like:
     append="mem=127M"



  +o  BBee aawwaarree ooff IIRRQQ rreellaatteedd pprroobblleemmss

     Sometime, some cards are not recognized or can trigger IRQ
     conflicts. Try shuffling cards on slots in different ways and
     possibly moving them to different IRQs.

     Contributed by hhAASSCCIIII : removing an " append="hisax=9,2,3"" line in
     lilo.conf allowed using a kernel from the 2.1.xx series with
     activated ISDN + Hisax support. Kernels from the 2.0.xx series
     doesn't make problems like this.

     Try also to set BIOS setup option like "MP 1.4 mode" or "route PCI
     interrupts through IOAPIC", or "OS Type" not set to DOS neither
     Novell (IInnggoo MMoollnnaarr).



  +o  FFllooppppyy aacccceessss wwhhiillee ssoouunndd iiss aaccttiivvee

     If you lockup when trying to access the floppy (for example while
     sound is playing) you may have to edit drivers/pci/quirks.c and set
     /int isa_dma_bridge_buggy = 1; This is a problem with my Dell WS400
     dual PII/300, 2.2.x, SMP (WWaaddee HHaammppttoonn).




  33..33..  MMootthheerrbbooaarrdd ssppeecciiffiicc iinnffoorrmmaattiioonn

  _P_l_e_a_s_e _n_o_t_e: Some more specific information can be found with the list
  of Motherboards rumored to run Linux SMP <http://www.nlug.org/smp/>


  33..33..11..  MMootthheerrbbooaarrddss wwiitthh kknnoowwnn pprroobblleemmss


  +o  none right now



  33..44..  LLooww ccoosstt SSMMPP LLiinnuuxx bbooxx ((dduuaall CCeelleerroonn bbooxx))

  (SSttpphhaannee ccoolliivveett)


  The lowest cost SMP Linux boxes with nowadays buyable processors are
  dual Celeron systems. Such a system is not officially possible
  according to Intel.  Better think about the second generation of
  Celeron, those with 128 Kb L2 cache.





  33..44..11..  IIss iitt ppoossssiibbllee ttoo rruunn aa dduuaall IInntteell CCeelleerroonn bbooxx ??

  OOffffiicciiaall aannsswweerr ffrroomm IInntteell:: no, Celeron cannot work in SMP mode.

  PPrraaccttiiccaall aannsswweerr:: it is possible, but requires hardware alteration for
  Slot 1 processors.  Alteration is described by Tomohiro Kawada on his
  Dual Celeron System <http://kikumaru.w-
  w.ne.jp/pc/celeron/index_e.html> page.  Of course, this kind of
  modification removes warranties...  Some versions of Celeron processor
  are also available in Socket 370 format.  In that case, alteration may
  just be done on the Socket 370 to Slot 1 adapter or may even be sold
  pre-wired for SMP use. (AAnnddyy PPoolliinngg, HHaannss -- EErriikk SSkkyyttttbbeerrgg, JJaammeess
  BBeeaarrdd)

  There is also a motherboard (ABIT BP6) allowing two Celerons in Socket
  370 format to be inserted (MMaarrttiijjnn KKrruuiitthhooff, RRyyaann MMccCCuuee). ABIT
  Computer BP6 verified tested and native to linux with dual ppga socket
  370 (AAnnddrree HHeeddrriicckk).


  33..44..22..  HHooww ddooeess LLiinnuuxx bbeehhaavvee oonn aa dduuaall CCeelleerroonn ssyysstteemm ??

  Fine, thank you.


  33..44..33..  CCeelleerroonn ssyysstteemm ??  CCeelleerroonn pprroocceessssoorrss aarree kknnoowwnn ttoo bbee eeaassiillyy
  oovveerrcclloocckkaabbllee.. AAnndd dduuaall

  It mmaayy work. However, overclocking this kind of system is not as easy
  as overclocking a mono-processor one. It is definitly not a good idea
  for a production system. For personal use, dual Celeron 300A systems
  running rock-solid at 450 MHz have been reported. (nnuummeerroouuss ppeeooppllee)


  33..44..44..  AAnndd mmaakkiinngg aa qquuaadd CCeelleerroonn ssyysstteemm ??

  It is impossible. Celeron processors have nearly the same features as
  basic Pentium II chips.  If you want more than 2 processors in your
  system, you'll have to look at Pentium Pro, Pentium II Xeon or Pentium
  III (?) boxes.



  33..44..55..  WWhhaatt aabboouutt mmiixxiinngg CCeelleerroonn aanndd PPeennttiiuumm IIII pprroocceessssoorr ??

  A system using a "re-enable" Celeron processor and a Pentium II
  processor with the same steppings mmaayy tthheeoorriiccaallllyy work.

  AAlleexxaannddrree CChhaarrbbeeyy as made such a system:

  +o  Asus P2B-D motherboard, proc 1: Celeron 366, proc 2: Pentium II
     400@266

  +o  66Mhz and 75Mhz bus frenquencies where functionnal

  +o  the fastest processor (in this case the Celeron) should be put on
     the second slot. Swapping processors (fatest first) leads to quick
     failure.


  44..  SSppaarrcc aarrcchhiitteeccttuurree ssppeecciiffiicc qquueessttiioonnss





  44..11..  WWhhiicchh SSppaarrcc mmaacchhiinneess aarree ssuuppppoorrtteedd ??

  Quoting the UltraLinux <http://ultra.linux.cz/> web page (only SMP
  systems):

  +o  UltraSPARC PCI based workstations: Ultra60, Ultra450

  +o  UltraSPARC SBUS based servers: Enterprise 1, 2, 150

  +o  UltraSPARC SBUS based large servers: Enterprise 3000, 4000, 5000,
     6000, 10000

  +o  UltraSPARC PCI based servers: Enterprise 250, 450

  +o  SPARC sun4m SMP machines (AAnnttoonn BBllaanncchhaarrdd)

  UltraLinux has ran on a 14 CPUs machine (see the dmesg output
  <http://lwn.net/1998/1210/a/dm-sparc.html>).


  44..22..  SSppeecciiffiicc pprroobblleemm rreellaatteedd ttoo SSppaarrcc SSMMPP ssuuppppoorrtt

  (DDaavviidd MMiilllleerr) There should not be any worries.

  The only known problem, and one we don't intend to fix, is that if you
  build an SMP kernel for 32-bit (ie. non-ultrasparc) systems, this
  kernel will not work on sun4c systems.


  44..33..  SSMMPP ssppeecciiffiicc lliimmiitt wwiitthh ccuurrrreenntt kkeerrnneell ((22..22))

  (DDaavviidd MMiilllleerr) There is a bug in the include/linux/tasks.h header
  file, it needs to define NR_CPUS to 64 on UltraSparc as this is the
  upper limit for the hardware we support :-)


  55..  PPoowweerrPPCC aarrcchhiitteeccttuurree ssppeecciiffiicc qquueessttiioonnss



  55..11..  WWhhiicchh PPPPCC mmaacchhiinneess aarree ssuuppppoorrtteedd ??


  +o  PowerSurge boards (including UMAX s900)

  +o  PowerMac

  +o  Motorola MTX: support under developement. Patches not yet
     integrated into the main kernel (TTrrooyy BBeennjjeeggeerrddeess)

  (CCoorrtt DDoouuggaann) Not supported: PPC RS/6000 systems



  55..22..  SSppeecciiffiicc pprroobblleemm rreellaatteedd ttoo PPPPCC SSMMPP ssuuppppoorrtt

  Nothing. Usual SMP compiling (see above). As usual, be aware, modules
  are specific either for UP or SMP. Recompile them. (PPaauull MMaacckkeerrrraass)


  66..  AAllpphhaa aarrcchhiitteeccttuurree ssppeecciiffiicc qquueessttiioonnss





  66..11..  WWhhiicchh AAllpphhaa mmaacchhiinneess aarree ssuuppppoorrtteedd ??

  (GGeeeerrtteenn KKuuiippeerr) SMP works for most, if not all, AXP servers.

  (JJaayy AA EEssttaabbrrooookk) SMP does seem to work on most of our [Compaq] boxes
  with 2 or more CPUs. That includes :

  +o  AS2000/2100 (SABLE)

  +o  AS4000/4100 (RAWHIDE)

  +o  DS20 (DP264)

  It does not include :

  +o  AS2100A (LYNX)

  +o  TurboLaser bigboys (8200/8400)


  66..22..  SSppeecciiffiicc pprroobblleemm rreellaatteedd ttoo AAllpphhaa SSMMPP ssuuppppoorrtt

  None (really ? :-)


  77..  UUsseeffuull ppooiinntteerrss


  77..11..  VVaarriioouuss


  +o  Parallel Processing using Linux
     <http://yara.ecn.purdue.edu/~pplinux/>

  +o  Linux Parallel Processing HOWTO
     <http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html>

  +o  ((oouuttddaatteedd)) Linux SMP home page
     <http://www.uk.linux.org/SMP/title.html>

  +o  linux-smp mailing list

     To ssuubbssccrriibbee, send subscribe linux-smp in the message body at
     majordomo@vger.rutgers.edu

     To uunnssuubbssccrriibbee, send unsubscribe linux-smp in the message body at
     majordomo@vger.rutgers.edu

     Linux SMP archives <http://www.linuxhq.com/lnxlists/linux-smp/>

     Linux SMP archives at progressive-comp.com <http://www.progressive-
     comp.com/Lists/?l=linux-smp&r=1&w=2#linux-smp>



  +o  pthread library made by Xavier Leroy
     <http://pauillac.inria.fr/~xleroy/linuxthreads/>

  +o  Motherboards rumored to run Linux SMP <http://www.nlug.org/smp/>

  +o  procps <http://www.cs.inf.ethz.ch/~rauch/procps.html>

  +o  procps patch for 2.2.x <http://queenbee.fhcrc.org/~warnes/procps>

  +o  xosview <http://lore.ece.utexas.edu/~bgrayson/xosview.html>

  +o  xosview for 2.2.x
     <http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz>

  +o  SMP Performance of Linux
     <http://www.phy.duke.edu/brahma/benchmarks.smp>

  +o  CESDIS Linux Ethernet device drivers site
     <http://cesdis.gsfc.nasa.gov/linux/drivers/>

  +o  Dual Celeron System <http://kikumaru.w-
     w.ne.jp/pc/celeron/index_e.html>



  77..22..  MMuullttiitthhrreeaaddeedd pprrooggrraammss aanndd lliibbrraarryy


  +o  Linux Threads FAQ <http://linas.org/linux/threads-faq.html>

  +o  Multithreaded programs on linux <http://www.informatik.uni-
     bremen.de/~hollow/mthread.html>

  +o  Pentium Pro Optimized BLAS and FFTs for Intel Linux
     <http://www.cs.utk.edu/~ghenry/distrib/> (not available right now,
     but a dual proc library is planned for 5/27/98, see Blas News
     <http://www.cs.utk.edu/~ghenry/distrib/blasnews> for details)

  +o  Mesa library <http://www.ssec.wisc.edu/~brianp/Mesa.html> (with
     experimental multi-threading)

  +o  Parallel plugins for The GIMP
     <http://nemo.physics.ncsu.edu/~briggs/gimp/index.html>




  77..33..  SSMMPP ssppeecciiffiicc ppaattcchheess


  +o  Forissier kernel patches <http://www-
     isia.cma.fr/~forissie/smp_kernel_patch/>

  +o  Patch for a bug in the 440FX chipset
     <http://nemo.physics.ncsu.edu/~briggs/vfix.html>

  +o  MTRR patch (latest version: 1.9)
     <http://www.atnf.csiro.au/~rgooch/kernel-patches.html>

  +o  PSET - Processor Sets for the Linux kernel
     <http://isunix.it.ilstu.edu/~thockin/pset/>

  +o  Ingo Molnar SMP patches <http://www.redhat.com/~mingo/> (for
     experts only, please read linux-smp@vger.rutgers.edu)




  77..44..  (( SSuummiitt RRooyy )) PPaarraalllleelliizziinngg//OOppttiimmiizziinngg CCoommppiilleerrss ffoorr 558866//668866
  mmaacchhiinneess


  +o  Pentium Compiler Group <http://www.goof.com/pcg/> creators of pgcc

  +o  Absoft <http://www.absoft.com/> , Fortran 90 and Fortran 77
     compilers

  +o  The Portland Group, Inc. <http://www.pgroup.com/>, supports the
     OpenMP <http://www.openmp.org> standard for Fortran parallelization
     on Linux

  +o  Pacific-Sierra Research Corporation <http://www.psrv.com/>, has a
     free F90 compiler for Linux, as well as parallelizing compilers for
     SMP Linux

  +o  Applied Parallel Research <http://s006.infomall.org/index.html>,
     currently have parallelizing compilers for WinNT

  +o  KAI <http://www.kai.com> has a C++-Compiler for Linux, that
     understands OpenMPI. It is called Guide_OpenMP. Info under
     http://www.kai.com/parallel/kappro/guide. (GGeerroo WWeeddeemmaannnn)



  88..  GGlloossssaarryy


  +o  SSMMPP Symmetric Multi-Processors

  +o  AAPPIICC Advanced Programmable Interrupt Controler

  +o  tthhrreeaadd A thread is a processor activity in a process. The same
     process can have multiple threads. Those threads share the process
     address space and can therefore share data.

  +o  pptthhrreeaadd Posix thread, threads defined by the Posix standard.

  +o  AAPPMM Advanced Power Managment



  99..  WWhhaatt''ss nneeww ??



     vv11..99,, 1133 jjaannuuaarryy 22000000

     +o  Remember to disable all BIOS power-save features (OOssaammuu AAookkii)

     +o  Explain how to access to Compaq server into advanced
        configuration mode (AAddrriiaann PPoorrtteellllii)


     vv11..88,, 88 nnoovveemmbbeerr 11999999

     +o  quad-celeron motherboard was a hoax, restored old paragraph
        (SSiimmeenn TTiimmiiaann TThhoorreesseenn)


     vv11..77,, 66 nnoovveemmbbeerr 11999999

     +o  new introduction (CC.. PPoolliisshheerr aka cp)

     +o  numerous typo and grammatical fixes (cp)

     +o  introductory paragraph on kernel compilation (cp)

     +o  introductory paragraph on SMP need (cp)

     +o  reference on KAI optimizing compiler (GGeerroo WWeeddeemmaannnn)

     +o  quad-celeron motherboard exists (JJeeffffrreeyy HH.. IInnggbbeerr)

     vv11..66,, 2211 ooccttoobbeerr 11999999

     +o  added information on xosview scheduling perturbation

     +o  added "APIC error interrupt on CPU#n" message information

     +o  added information on hard lockup

     +o  deleted section "How to optain maximum performance" (was
        obsolete)

     +o  added info on dual systems with different x86 procs (a Celeron
        and a P-II)


     vv11..55,, 44 ooccttoobbeerr 11999999

     +o  more precision in PSET description


     vv11..44,, 3300 sseepptteemmbbeerr 11999999

     +o  precize to enable MTRR support for an x86 SMP kernel (me)


     vv11..33,, 2299 sseepptteemmbbeerr 11999999

     +o  many many grammar and typographical fixes (WWaaddee HHaammppttoonn aka hww)

     +o  added info in short introduction related to 2.2/2.4/2.0 diffs
        (hww)

     +o  added step by step things to do to recompile a kernel (hww and
        me)

     +o  added info related to SMP/UP modules problems  (hww)

     +o  added precision in Posix Threads section related to user  (hww)
        vs. kernel threads (hww)

     +o  new item about NFS and kernel lock  (hww)

     +o  new item about kernel lock without message  (hww)

     +o  new item about debugging lockup problems  (hww)

     +o  added info about heating problems  (hww)

     +o  miscellaneous updates I've forget about  (hww)

     +o  new item about floppy access and sound  (hww)


     vv11..22,, 2277 sseepptteemmbbrree 11999999

     +o  name change: this document is now a HOWTO. TWD, and fast!
        (GGuuyyllhheemm AAzznnaarr)


     vv11..11,, 2266 sseepptteemmbbrree 11999999

     +o  added a link to first Chris Pirih FAQ draft

     +o  expanted an IRQ related problems


     vv11..0000,, 2255 sseepptteemmbbrree 11999999

     +o  first upgrade in a long long time!

     +o  reprocessed the whole FAQ: 2.2 is here and 2.4 soon

     +o  added kernel locking information from Ingo Molnar

     +o  deleted item "How will my application perform under SMP?":
        outdated

     +o  deleted item "My SMP system is locking up all the time.":
        outdated

     +o  deleted item "You are running 2.0.35 aren't you ?": outdated

     +o  deleted item "Some hardware is also known to cause problems.":
        outdated

     +o  blanked section "Motherboards with known problems". We should
        restart from scratch

     +o  deleted section "Motherboards with NO known problems": outdated

     +o  updated dual celeron section (numerous people)

     +o  added "SPARC sun4m SMP machines" to supported SMP sparc machines
        (AAnnttoonn BBllaanncchhaarrdd)

     +o  added a "During boot machine hang signaling an IOAPIC problem"
        item in "Why it doesn't work on my machine?" section

     +o  added a "What about SMP performances?" item

     +o  updated "Why doesn't my old Compaq work?" item

     +o  fixed an outdated pointer

     +o  added a pointer to Ingo test SMP patches


     vv00..5544,, 1133 mmaarrcchh 11999999

     +o  Added a section about SMP Alpha systems


     vv00..5533,, 0088 mmaarrcchh 11999999

     +o  Added a section about SMP PowerPC systems


     vv00..5522,, 0077 mmaarrcchh 11999999

     +o  Added a section about SMP Sparc systems


     vv00..5511,, 0066 mmaarrcchh 11999999

     +o  Added a dual-celeron section

     +o  Deleted Adaptec section

     +o  Updated procps link

     +o  Updated xosview link

     +o  Added an answer for quad Xeon boot hang

     +o  Updated item about glibc patch for gd: should be included in RH
        5.2


     vv00..5500,, 0033 ffeebbrruuaarryy 11999999

     +o  Updated "Multithreaded programs on linux" link


     vv00..4499,, 1133 jjaannuuaarryy 11999999

     +o  Update about CONFIG_SMP. Added .txt to Documentation/smp.
        (MMiicchhaaeell EElliizzaabbeetthh CChhaassttaaiinn)


     vv00..4488,, 1100 ddeecceemmbbeerr 11999988

     +o  Mispelled corrected. Email address corrected.


     vv00..4477,, 2200 nnoovveemmbbeerr 11999988

     +o  Added that 2.0.36 as the MTRR patch (related to the BogoMips
        problem)


     vv00..4466,, 1100 nnoovveemmbbeerr 11999988

     +o  Update about Epox KP6-LS motherboards


     vv00..4455,, 2255 ooccttoobbeerr 11999988

     +o  Corrected an error regarding /proc/stat file

     +o  Added a pointer to CESDIS Ethernet Linux Drivers site


     vv00..4444,, 1144 ooccttoobbeerr 11999988

     +o  Updated the link to the web page: _M_o_t_h_e_r_b_o_a_r_d_s _r_u_m_o_r_e_d _t_o _r_u_n
        _L_i_n_u_x _S_M_P

     +o  Added Jakob explanation how to time SMP systems with 2.0 kernels


     vv00..4433,, 99 sseepptteemmbbeerr 11999988

     +o  Updated first question in section 3.1

     +o  Updated mt-Mesa link: multi-threaded is now included as
        experimental in the Mesa distribution


     vv00..4422,, 22 sseepptteemmbbeerr 11999988

     +o  Minor cosmetic update in sect 3.3

     +o  Two links (multithreaded Mesa and SMP performance) marked
        outdated

     +o  Updated the item about threads and exceptions in C++ (sect 3.3)


     vv00..4411,, 11 sseepptteemmbbeerr 11999988

     +o  Added a major section: "3.3 SMP Programming" written by Jakob
        stergaard

     +o  moved some item of section "3.2 User side" in sect 3.3


     vv00..4400,, 2277 aauugguusstt 11999988

     +o  Updated section 3.1, item 7: processor affinity


     vv00..3399,, 2277 aauugguusstt 11999988

     +o  Updated needed Award BIOS version for Tyan motherboards (hhAASSCCIIII)

     +o  Added an item on IRQ in the crash section (me and hhAASSCCIIII)

     +o  Added good support of Asus P2B-DS (UUllff RRoommppee)

     +o  Added another smp-list archive in pointer section (HHaannkk
        LLeeiinniinnggeerr)


     vv00..3388,, 88 aauugguusstt 11999988

     +o  Added a pointer to the Linux Threads FAQ


     vv00..3377,, 3300 JJuullyy 11999988

     +o  EEmmiill BBrriiggggss is working on parallel plugins for Gimp (see "Is
        there any threaded programs or library?", sect. "User side")


     vv00..3366,, 2266 JJuullyy 11999988

     +o  Thanks to JJaakkoobb sstteerrggaaaarrdd, two changes in "Possible causes of
        Crash"

     +o  Changed 2.0.33 to 2.0.35 (latest stable)

     +o  Added a "BIOS related causes of failure"


     vv00..3355,, 1144 JJuullyy 11999988

     +o  Added N440BX Server Board in Motherboards with NO problems

     +o  Added a succes story for GigaByte motherboard with BIOS upgrade

     +o  Added a "How to obtain maximum performance ?" section (waiting
        for your contributions ;)


     vv00..3344,, 1100 jjuunnee 11999988

     +o  Added a "Parallelizing/Optimizing Compilers for 586/686
        machines" section in section "Useful Pointers", thanks to SSuummiitt
        RRooyy

     +o  Corrected a mispelling, "Asus P/I-UP5" is in fact "Asus P/I-
        P65UP5"


     vv00..3333,, 33 jjuunnee 11999988

     +o  Yet another success story for a GigaByte DLX Motherboard.

     +o  A tip for Tyan motherboards, disable the "DRAM Fast Leadoff"
        BIOS option


     vv00..3322,, 2277 mmaayy 11999988

     +o  Asus P/I-UP5 added in the motherboard-with-NO-problem section


     vv00..3311,, 1188 mmaayy 11999988

     +o  Elitegroup P6LX2-A works with 2.1.100 and 101

     +o  Bugs should be reported to linux-smp@vger.rutgers.edu


     vv00..3300,, 1122 mmaayy 11999988

     +o  SuperMicro is now in the motherboard-with-NO-problem section


     vv00..2299,, 1111 mmaayy 11999988

     +o  A success story for a GigaByte 686 motherboard with 2.1.101

     +o  Added a new item in the "User Side" section: "Is there any
        threaded programs or library?"

     +o  OpenGL Mesa library is beeing multithreaded. Cool! See the new
        section for details.


     vv00..2288,, 0099 mmaayy 11999988

     +o  A US mirror of this FAQ is now available (see Introduction)

     +o  Merge of the two confusing Gigabyte 686 entries


     vv00..2277,, 0055 mmaayy 11999988

     +o  New info for the Adaptec and TekRam drivers

     +o  Micronics W6-LI motherboard works under SMP




  1100..  LLiisstt ooff ccoonnttrriibbuuttoorrss

  Many thanks to those who help me to maintain this HOWTO:


  1. Tigran A. Aivazian

  2. John Aldrich

  3. Niels Ammerlaan

  4. H. Peter Anvin


  5. Osamu Aoki

  6. Guylhem Aznar

  7. Ralf Bchle

  8. James Beard

  9. Troy Benjegerdes

  10.
     Anton Blanchard

  11.
     Emil Briggs

  12.
     Robert G. Brown

  13.
     Alexandre Charbey

  14.
     Michael Elizabeth Chastain

  15.
     Samuel S. Chessman

  16.
     Alan Cox

  17.
     Andrew Crane

  18.
     Cort Dougan

  19.
     Mark Duguid

  20.
     Stphane colivet

  21.
     Jocelyne Erhel

  22.
     Jay A Estabrook

  23.
     Byron Faber

  24.
     Mark Garlanger

  25.
     hASCII

  26.
     Wade Hampton

  27.
     Andre Hedrick

  28.
     Claus-Justus Heine
  29.
     Benedikt Heinen

  30.
     Florian Hinzmann

  31.
     Moni Hollmann

  32.
     Robert M. Hyatt

  33.
     Jeffrey H. Ingber

  34.
     Richard Jelinek

  35.
     Tony Kocurko

  36.
     Geerten Kuiper

  37.
     Martijn Kruithof

  38.
     Doug Ledford

  39.
     Kumsup Lee

  40.
     Hank Leininger

  41.
     Ryan McCue

  42.
     Paul Mackerras

  43.
     Cameron MacKinnon

  44.
     Joel Marchand

  45.
     David Maslen

  46.
     Chris Mauritz

  47.
     Jean-Francois Micouleau

  48.
     David Miller

  49.
     Ingo Molnar

  50.
     Ulf Nielsen

  51.
     Jakob Oestergaard

  52.
     C Polisher

  53.
     Adrian Portelli

  54.
     Matt Ranney

  55.
     Daniel Roesen

  56.
     Ulf Rompe

  57.
     Jean-Michel Rouet

  58.
     Volker Reichelt

  59.
     Sean Reifschneider

  60.
     Sumit Roy

  61.
     Thomas Schenk

  62.
     Terry Shull

  63.
     Chris K. Skinner

  64.
     Hans - Erik Skyttberg

  65.
     Szakacsits Szabolcs

  66.
     Jukka Tainio

  67.
     Simen Timian Thoresen

  68.
     El Warren

  69.
     Gregory R. Warnes

  70.
     Gero Wedemann

  71.
     Christopher Allen Wing

  72.
     Leonard N. Zubkoff



































































