doscall1

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 "intn" or "lintn".

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" 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
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 "intn" or "lintn".

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
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 "intn" or "lintn".

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