Text 2199, 151 rader
Skriven 2011-08-11 08:47:53 av Lars Erdmann
Ärende: Re: doscall1
====================
comp.os.os2.apps,comp.os.os2.setup.misc,comp.sys.ibm.pc.hardware.chips,comp.os.os2.misc

DXC=HO4[YJa`65QYI9]OHn9o5^A9EHlD;3YcR4Fo<]lROoRQ8kF<OcfhCO[mUW1@dmaO0T^CT1A^BL@[^6iTbKebAoFY9dLcLa8jW[\fdNXQV;<T7T

comp.os.os2.setup.misc:584 comp.sys.ibm.pc.hardware.chips:1323
comp.os.os2.misc:3568
<3060ae5e-ef8c-4ce7-bf15-a5263ffd9273@glegroupsg2000goo.googlegroups.com>
2ab70efa
From: "Lars Erdmann" <lars.erdmann@arcor.de>

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.

Then, switches for OS2APIC.PSD:

/apic: set up the system as described in chapter 3.6.2.3 in said spec
          Please note that SMP for Warp Server (this is what we use today if 
we have a
          multiprocessor system) only routes interrupts to CPU1. OS/2 SMP 
version 2.1
          used to route interrupts to all CPUs. There were reasons to change 
this
          with SMP for Warp Server (avoid "parallel" paths in device 
drivers).

/pic:  set up the system as described in chapter 3.6.2.2 of said spec
         Note: yes, the system runs in "virtual wire" mode as a "minimum".
         It will never run as defined in chapter 3.6.2.1. That also means
         OS2APIC.PSD will only work if you have a CPU with a local APIC.
         Of course that is not a problem since the first generation Pentiums 
came out.
         You will need to run in this mode if your system DOES NOT contain 
an IO-APIC.

/nmi: basically defines on what local APIC input pin the NMI signal line is 
routed across.
         You will only need this if the MP tables on your system are broken 
or incomplete
         If you look at what the MP tables contain, you will see that the 
NMI signal line is
         routed via the local APIC just as the interrupt lines are.
         See chapter 4.3.5 of said spec. See table 4-11 for the types of 
"interrupts" that are
         routed across a local APIC.

/prec: as far as I understand if the NMI signal line is routed over more 
than one local APIC
           input, you can choose with this switch what the preferrable route 
is. Again you
           will only need this if the MP tables on your system are broken

Don't ask me about MSIs (message signalled interrupts).
Maybe it's the "messages" sent via the ICC-bus that the MP spec talks about 
but I am not sure.


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

But be aware that the MP tables will become obsolete with the multiprocessor 
ACPI table that replaces them.
In other words: if your system no longer contains MP tables, then 
OS2APIC.PSD will cease to work as it will
be looking for them.


Lars


"Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net> schrieb im Newsbeitrag 
news:Qg5I6Bo2seGy-pn2-dR4CcEgq6dDB@neurobox...
> On Wed, 10 Aug 2011 14:51:07 UTC, Jonathan de Boyne Pollard
> <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote:
>
>> > maybe he can successfully shed some more light on this subject.
>>
>> Here are some more basics, just so that we're all on the same page:
>
>
> ...snip...snip...a ton of absolutely WEALTHY WONDERFUL info...thank you!!!
>
>
>> * An OS/2 Platform-Specific Driver (PSD) is not a Windows NT Hardware
>> Abstraction Layer (HAL).  A HAL abstracts away quite a lot of the
>> details of interrupt processing and low-level inter-processor
>> synchronization and communication.  A PSD does not.  There are two
>> particulars of note.  First: The OS/2 kernel has fallback code that
>> knows how to talk to dual 8259s, should a PSD not implement certain
>> optional capabilities, and operate what is essentially an *asymmetric*
>> multiprocessor system.  Second: An OS/2 PSD has no responsibility for
>> implementing spinlocks.  So a system where the PSD omits the optional
>> features does not devolve to being identical to a uniprocessor OS/2 
>> system.
>>
>> * The idea that I/O APICs increase the number of available interrupts is
>> a bit of a swizz.  The number of PIRQ signal lines on the PCI bus
>> doesn't magically change.  Some internal devices, built in to the
>
>
> OK...so are there any tools currently in existence on our platform that we 
> could
> use to really understand the 'setup' that our BIOS has attempted to 
> implement?
>
> I found this interesting IOAPIC note
> (http://www.o3one.org/tutorials/apicarticle.txt), it explains the 
> functionality
> in accessible terms.
>
> Now, a question on my part as I've been trying to understand the options 
> for the
> OS2APIC.PSD driver...what exactly do the following mean (as best as you 
> can
> estimate):
>
> /apic
> /pic
> /nmi
> /prec
> ...and directly from a reference post:
>
> There are three (3) possible entries that can describe a route:
> route to the I/O APIC
> route to the Local APIC
> route described by argument(s) to the PSD
>
> For a typical single user, multi core system, what are the possible
> 'combinations' of these options to use/try? I understand that this depends
> heavily on the hardware itself, but is there an overall direction one 
> should be
> trying to pursue while setting up the system?
>
> Thanks again! 


--- Internet Rex 2.31
 * Origin: Arcor (1:261/20.999)