On Fri, 12 Aug 2011 13:02:51 UTC, Jonathan de Boyne Pollard
<J.deBoynePollard-(E-Mail Removed)> 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.

Lars,

On Thu, 11 Aug 2011 06:47:53 UTC, "Lars Erdmann" <(E-Mail Removed)> wrote:

> 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.

....snip...snip...

> 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).

I started reading through the Intel MPS specs...and started looking at porting
the Unix 'mptable' utility...wish me luck...it's been a LOOONG time since I last
compiled anything on my machine...but to be honest...in my work I moved away
from coding a few years back and miss it badly...LOL...time to put some of that
gray metter back to work!!!

Hi Dariusz

Dariusz Piatkowski wrote:
> On Fri, 12 Aug 2011 13:02:51 UTC, Jonathan de Boyne Pollard
> <J.deBoynePollard-(E-Mail Removed)> 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

Hi Pete!

On Thu, 18 Aug 2011 00:10:24 UTC, Peter Brown <losepeteSPAM-ME-(E-Mail Removed)>
wrote:

> Hi Dariusz
>
> Dariusz Piatkowski wrote:
> > On Fri, 12 Aug 2011 13:02:51 UTC, Jonathan de Boyne Pollard
> > <J.deBoynePollard-(E-Mail Removed)> 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...

> 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.

You've made me think. One obviously missing utility is an EFI utility
to do this, so people can bootstrap into the EFI Shell and dump out
their MPS tables from there.

It should be even easier than another form of MPS table dumper. For
starters, whilst a program to run on bare PC98 firmware, or on top of
OS/2, has to locate the table by scanning physical memory (which as
pointed out requires some shenanighans from application-mode code, and
which is somewhat tricky even if running in real mode on bare PC98
firmware) an EFI application has no such worries. The locations of the
various tables (ACPI, MPS, SMBIOS, and so forth) are supplied to EFI
utililty programs directly as startup parameters.

Hi Jonathan,

On Fri, 19 Aug 2011 11:24:00 UTC, Jonathan de Boyne Pollard
<J.deBoynePollard-(E-Mail Removed)> wrote:

> > 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.
>
> You've made me think. One obviously missing utility is an EFI utility
> to do this, so people can bootstrap into the EFI Shell and dump out
> their MPS tables from there.
>
> It should be even easier than another form of MPS table dumper. For
> starters, whilst a program to run on bare PC98 firmware, or on top of
> OS/2, has to locate the table by scanning physical memory (which as
> pointed out requires some shenanighans from application-mode code, and
> which is somewhat tricky even if running in real mode on bare PC98
> firmware) an EFI application has no such worries. The locations of the
> various tables (ACPI, MPS, SMBIOS, and so forth) are supplied to EFI
> utililty programs directly as startup parameters.

Well...some references to EFI for those who are not familiar with this (that
includes me..lol) => http://wiki.osx86project.org/wiki/index.php/EFI

....also what appears (various claims) to be a replacement interface, the UEFI =>
http://en.wikipedia.org/wiki/Unified...ware_Interface

Jonathan you may have been referencing UEFI when saying EFI...maybe?

But boy...that seems like a bit complex proposition no? If I understood
correctly, the BIOS itself has to be able to support EFI...maybe a bit more of a
question then statement actually...

The Linux mptable code seems fairly straightforward...I'm guessing I will have
easier time understanding the OS2 specific API calls to use as opposed to
getting a EFI solution in place.

Dariusz Piatkowski wrote:
> The Linux mptable code seems fairly straightforward...I'm guessing I will have
> easier time understanding the OS2 specific API calls to use as opposed to
> getting a EFI solution in place.

There is also a FreeBSD implementation,
http://www.freebsd.org/cgi/cvsweb.cg....sbin/mptable/ which looks
like it would be easy to port
Dave

Dave!

On Sat, 20 Aug 2011 01:09:02 UTC, Dave Yeo <(E-Mail Removed)> wrote:

> Dariusz Piatkowski wrote:
> > The Linux mptable code seems fairly straightforward...I'm guessing I will have
> > easier time understanding the OS2 specific API calls to use as opposed to
> > getting a EFI solution in place.
>
> There is also a FreeBSD implementation,
> http://www.freebsd.org/cgi/cvsweb.cg....sbin/mptable/ which looks
> like it would be easy to port
> Dave

....thank you...nice to have several options...for sure...

> But boy...that seems like a bit complex proposition no?
>
Not for me. It's a logical next stage, in fact. I have to deal with
MPS tables anyway.

> If I understood correctly, the BIOS itself has to be able to support EFI.
>
Not necessarily. On one of my PC98 test machines, for example, I have
DUET installed in the EFI System Partition on disc #81. The EFI System
Partition is marked "startable"/"HasVBR"/"active". So I can bootstrap
into an EFI environment from purely PC98 firmware.

> You've made me think. One obviously missing utility is an EFI utility to
> do this, so people can bootstrap into the EFI Shell and dump out their MPS
> tables from there.
>
> It should be even easier than another form of MPS table dumper. For
> starters, whilst a program to run on bare PC98 firmware, or on top of
> OS/2, has to locate the table by scanning physical memory (which as
> pointed out requires some shenanighans from application-mode code, and
> which is somewhat tricky even if running in real mode on bare PC98
> firmware) an EFI application has no such worries. The locations of the
> various tables (ACPI, MPS, SMBIOS, and so forth) are supplied to EFI
> utililty programs directly as startup parameters.

What is so difficult to dump the MPS tables ? It's just located at some
physical memory location.
It is easy to scan for the table.
SCREEN01.SYS offers an IOCTL to map a physical address range into
application memory range.
It's straightforward to use. In fact I had started such a utility for
searching some of the ACPI tables, same game.

I don't know why you are so hung up on EFI.


Lars