.pc.hardware.chips,comp.os.os2.misc   
   hCO[mUW1@dmaO0T^CT1A^BL@[^6iTbKebAoFY9dLcLa8jW[\fdNXQV; 2ab70efa   
   From: "Lars Erdmann"    
      
   Hallo,   
      
   since OS2APIC.PSD is pretty old I would think that it exclusively follows   
   Intel's multiprocessor specification Version 1.4 and completely ignores what    
   the ACPI multiprocessor table has to offer   
   (which eventually will replace the MP tables):   
      
   http://www.intel.com/design/pentium/datashts/242016.htm   
      
   Get that document to gain a better understanding. In particular it has some    
   nice diagrams   
   that will tell you more than a thousand words.   
      
   Then, switches for OS2APIC.PSD:   
      
   /apic: set up the system as described in chapter 3.6.2.3 in said spec   
             Please note that SMP for Warp Server (this is what we use today if    
   we have a   
             multiprocessor system) only routes interrupts to CPU1. OS/2 SMP    
   version 2.1   
             used to route interrupts to all CPUs. There were reasons to change    
   this   
             with SMP for Warp Server (avoid "parallel" paths in device    
   drivers).   
      
   /pic:  set up the system as described in chapter 3.6.2.2 of said spec   
            Note: yes, the system runs in "virtual wire" mode as a "minimum".   
            It will never run as defined in chapter 3.6.2.1. That also means   
            OS2APIC.PSD will only work if you have a CPU with a local APIC.   
            Of course that is not a problem since the first generation Pentiums    
   came out.   
            You will need to run in this mode if your system DOES NOT contain    
   an IO-APIC.   
      
   /nmi: basically defines on what local APIC input pin the NMI signal line is    
   routed across.   
            You will only need this if the MP tables on your system are broken    
   or incomplete   
            If you look at what the MP tables contain, you will see that the    
   NMI signal line is   
            routed via the local APIC just as the interrupt lines are.   
            See chapter 4.3.5 of said spec. See table 4-11 for the types of    
   "interrupts" that are   
            routed across a local APIC.   
      
   /prec: as far as I understand if the NMI signal line is routed over more    
   than one local APIC   
              input, you can choose with this switch what the preferrable route    
   is. Again you   
              will only need this if the MP tables on your system are broken   
      
   Don't ask me about MSIs (message signalled interrupts).   
   Maybe it's the "messages" sent via the ICC-bus that the MP spec talks about    
   but I am not sure.   
      
      
   If I ever find the time, I could write a utility that dumps the MP tables    
   content (if you have Linux I would   
   guess that utility already exists). That would also help to find out if your    
   MP tables are broken or incomplete   
   (for example, if the NMI is not routed via any local APIC pin, then NMIs    
   will obviously not work).   
      
   But be aware that the MP tables will become obsolete with the multiprocessor    
   ACPI table that replaces them.   
   In other words: if your system no longer contains MP tables, then    
   OS2APIC.PSD will cease to work as it will   
   be looking for them.   
      
      
   Lars   
      
      
   "Dariusz Piatkowski"  schrieb im Newsbeitrag    
   news:Qg5I6Bo2seGy-pn2-dR4CcEgq6dDB@neurobox...   
   > On Wed, 10 Aug 2011 14:51:07 UTC, Jonathan de Boyne Pollard   
   >  wrote:   
   >   
   >> > maybe he can successfully shed some more light on this subject.   
   >>   
   >> Here are some more basics, just so that we're all on the same page:   
   >   
   >   
   > ...snip...snip...a ton of absolutely WEALTHY WONDERFUL info...thank you!!!   
   >   
   >   
   >> * An OS/2 Platform-Specific Driver (PSD) is not a Windows NT Hardware   
   >> Abstraction Layer (HAL).  A HAL abstracts away quite a lot of the   
   >> details of interrupt processing and low-level inter-processor   
   >> synchronization and communication.  A PSD does not.  There are two   
   >> particulars of note.  First: The OS/2 kernel has fallback code that   
   >> knows how to talk to dual 8259s, should a PSD not implement certain   
   >> optional capabilities, and operate what is essentially an *asymmetric*   
   >> multiprocessor system.  Second: An OS/2 PSD has no responsibility for   
   >> implementing spinlocks.  So a system where the PSD omits the optional   
   >> features does not devolve to being identical to a uniprocessor OS/2    
   >> system.   
   >>   
   >> * The idea that I/O APICs increase the number of available interrupts is   
   >> a bit of a swizz.  The number of PIRQ signal lines on the PCI bus   
   >> doesn't magically change.  Some internal devices, built in to the   
   >   
   >   
   > OK...so are there any tools currently in existence on our platform that we    
   > could   
   > use to really understand the 'setup' that our BIOS has attempted to    
   > implement?   
   >   
   > I found this interesting IOAPIC note   
   > (http://www.o3one.org/tutorials/apicarticle.txt), it explains the    
   > functionality   
   > in accessible terms.   
   >   
   > Now, a question on my part as I've been trying to understand the options    
   > for the   
   > OS2APIC.PSD driver...what exactly do the following mean (as best as you    
   > can   
   > estimate):   
   >   
   > /apic   
   > /pic   
   > /nmi   
   > /prec   
   > ...and directly from a reference post:   
   >   
   > There are three (3) possible entries that can describe a route:   
   > route to the I/O APIC   
   > route to the Local APIC   
   > route described by argument(s) to the PSD   
   >   
   > For a typical single user, multi core system, what are the possible   
   > 'combinations' of these options to use/try? I understand that this depends   
   > heavily on the hardware itself, but is there an overall direction one    
   > should be   
   > trying to pursue while setting up the system?   
   >   
   > Thanks again!    
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)