Text 2219, 91 rader
Skriven 2011-08-18 01:04:36 av Dariusz Piatkowski
Ärende: Re: OS2APIC.PSD
=======================
comp.sys.ibm.pc.hardware.chips,comp.os.os2.misc,comp.os.os2.apps,comp.os.os2.setup.misc

p5a72643d201c6c25758e4c8f09f250fb997465993512309e9daef7c59bc29a00.newsdawg.com
comp.os.os2.misc:3588 comp.os.os2.apps:1930 comp.os.os2.setup.misc:617
<3060ae5e-ef8c-4ce7-bf15-a5263ffd9273@glegroupsg2000goo.googlegroups.com>
2ab70efa
From: "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net>

Hi Pete!

On Thu, 18 Aug 2011 00:10:24 UTC, Peter Brown
<losepeteSPAM-ME-NOT@ntlworld.com>
wrote:

> Hi Dariusz
> 
> Dariusz Piatkowski wrote:
> > On Fri, 12 Aug 2011 13:02:51 UTC, Jonathan de Boyne Pollard
> > <J.deBoynePollard-newsgroups@NTLWorld.COM>  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<n>" or "lint<n>".
> >>
> >> 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)