s,comp.os.os2.misc,comp.os.os2.apps   
   d158bfda77b185eff9f8.newsdawg.com   
   mp.sys.ibm.pc.hardware.chips:1358 comp.os.os2.misc:3584 comp.os.os2.apps:1926   
   ooglegroups.com> 2ab70efa   
   From: "Dariusz Piatkowski"    
      
   On Fri, 12 Aug 2011 13:02:51 UTC, Jonathan de Boyne Pollard    
    wrote:   
      
   > > I've been trying to understand the options for the OS2APIC.PSD driver...   
   >    
   > Don't go reading the copies of its documentation that exist on the WWW,    
   > such as at the EDM/2 CONFIG.SYS Documentation Project for example.  They    
   > all seem to have a single source, that was mis-transcribed from the    
   > original documentation.  Where the WWW documents say   
   >    
   >  > The argument is "int" or "lint".   
   >    
   > the original document actually said   
   >    
   >  > The argument is "int" or "lint".   
   >    
   > which of course makes more sense when one reads what follows.   
   >    
   > For a better description of OS2APIC.PSD's command-line arguments, see    
   > IBM Technical Document #10322931.  It has the advantage of being more up    
   > to date than OS/2 version 2.11, as well. (-:   
   >    
   > > For a typical single user, multi core system, what are the possible   
   > > 'combinations' of these options to use/try?   
   >    
   > The main use of the /NMI, /PREC, and /PIC options is to compensate for    
   > faulty MPS tables.  You've already seen that your firmware's SETUP    
   > utility has the wrong help text attached to the "IOAPIC function"    
   > option.  This is not the only way that a mainboard manufacturer can    
   > stuff up building a firmware image.  A manufacturer can stuff up the MPS    
   > tables, too.   
   >    
   > It was common enough in years gone by that operating system vendors had    
   > to implement workarounds like this.  DOS+Windows 9x users wouldn't    
   > notice that MPS tables were wrong.  Not even most OS/2 users would.    
   > Only a few people with Windows NT and other SMP operating systems would.    
   >   Now that operating systems that actually care about such things are    
   > pretty much in the majority, the situation is somewhat different    
   > (although the operating systems that care also tend to prefer ACPI    
   > information to MPS).   
   >    
   > Of course, if your MPS tables are *not* faulty, and correctly describe    
   > how your system is wired up, you won't need to fiddle with these options    
   > at all.   
      
   All excellent points...I have read that original IBM tech document...as well,    
   I've now read through the Intel MPS 1.4 spec...and started looking at making a    
   quick port of the Unix style 'mptable' utility. I assume that we OS2 users   
   could   
   use this type of info...not that it may directly fix anything, but rather to    
   give us more info on exactly what the BIOS stuck in place and what our machine    
   is attempting to do with that info.   
      
   --- Internet Rex 2.31   
    * Origin: NewsGuy - Unlimited Usenet $19.95 (1:261/20.999)