Thunderbird/5.0   
   misc,comp.sys.ibm.pc.hardware.chips   
   UTC)   
   .os2.apps:1880 comp.os.os2.setup.misc:581 comp.sys.ibm.pc.hardware.chips:1321   
   From: Jonathan de Boyne Pollard    
      
   > 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:   
      
   * In theory one can have multiple I/O APICs in a system.  In practice,    
   on the sorts of systems we're talking about here, there's only going to    
   be one.  It lives in the PCI-to-ISA bridge part of what is variously    
   called an "I/O Controller Hub" (ICH) or a "PCI ISA IDE Xcelerator"    
   (PIIX) by Intel or a "South Bridge" by VIA.   
      
   * The difference between MPS (Intel's "Multi-Processor Specification")    
   version 1.1 tables and version 1.4 tables is that the version 1.4 tables    
   contain various extensions, dealing with things like multiple I/O APICs.    
     Again, this will be largely irrelevant here.   
      
   * For most, perhaps all (certainly all that I have datasheets for),    
   chipsets, there is a control bit of some form in configuration space    
   that enables or disables the I/O APIC.  If there are no local APICs    
   enabled on the other end of the APIC bus, however, it doesn't really    
   matter what state the I/O APICs are in.  Nothing will be listening to    
   their messages.  Indeed, in a more extreme case, the APICCLK signal may    
   be simply tied to ground, and no I/O APIC messages will happen on the    
   APIC bus at all, because its clock is frozen.   
      
   * There are two ways to turn off a local APIC: the hard way and the easy    
   way.  Both involve setting flags in CPU registers.  If a local APIC is    
   turned off the hard way, it cannot be turned back on again without    
   potentially losing interrupts and confusing the entire APIC bus    
   arbitration scheme.  A local APIC turned off the easy way can be re-enabled.   
      
   * There are two ways for firmware to report I/O APIC configuration    
   information to an operating system: the MPS table, and ACPI tables.    
   They aren't quite the same.  The configuration information reported    
   states among other things which ISA devices and which PCI IRQ lines are    
   connected to which I/O APIC inputs.  There's no requirement, after all,    
   that every motherboard manufacturer connect the ISA IRQ #7 signal to I/O    
   APIC INTIN pin #7.   
      
   * In addition to deciding how to program the enable control bits for the    
   I/O APIC and all of the local APICs, firmware also gets to decide what    
   it reports in the MPS and ACPI tables.  It might decide to lie, for    
   example, and deny the existence of I/O APICs or local APICs in the    
   machine.  The idea of this would be to force an operating system, whose    
   primary source of this hardware information is supposed to be the MPS    
   and ACPI tables, to still "see" an ACPI system, but one that doesn't    
   have APICs; thereby forcing it to fall back to whatever dual-8259 mode    
   of operation it has, whilst still retaining other unrelated    
   ACPI-provided information such as (say) system reset and environment    
   control capabilities.   
      
   * 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    
   southbridge, gain the ability to use extra interrupt signals that don't    
   exist on the real PCI bus (On some VIA southbridges, for example, the    
   internal PCI-to-ATA bridge gets to use PCI INT #E.).  But, really,    
   stating that the point of an I/O APIC is to "gain more interrupts" is    
   mis-selling it.  I/O APICs provide better ways to manage and control the    
   *same* set of PCI and ISA interrupt signals, not more of them.   
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)