Re: doscall1

  • Thread starter Thread starter Jonathan de Boyne Pollard
  • Start date Start date
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 original document actually said


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


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.
Click to expand...

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,

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).
Click to expand...

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 said:
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.
Click to expand...



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!

Hi Dariusz



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
Click to expand...

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.
Click to expand...

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,

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.
Click to expand...

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_Extensible_Firmware_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.
 
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.
Click to expand...
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.
Click to expand...

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