.os.os2.apps,comp.os.os2.setup.misc   
   309e9daef7c59bc29a00.newsdawg.com   
   comp.os.os2.misc:3588 comp.os.os2.apps:1930 comp.os.os2.setup.misc:617   
   ooglegroups.com> 2ab70efa   
   From: "Dariusz Piatkowski"    
      
   Hi Pete!   
      
   On Thu, 18 Aug 2011 00:10:24 UTC, Peter Brown    
   wrote:   
      
   > Hi Dariusz   
   >    
   > Dariusz Piatkowski wrote:   
   > > 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.   
   >    
   > Maybe it could be incorporated into the acpi driver to help that driver    
   > get things right (finally :-) - especially if it could also be used for    
   > non Intel chipsets.   
   >    
   > Regards   
   >    
   > Pete   
      
   Well, the Linux C code I looked at so far didn't look all that bad...I'm not   
   up    
   to attempting to compile it yet though...lol...so far most of my time is being    
   spent trying to remember how I set things up...etc...but I will update the   
   group   
   once I have something...   
      
   --- Internet Rex 2.31   
    * Origin: NewsGuy - Unlimited Usenet $19.95 (1:261/20.999)