Re: Enabling SMP
Jonathan de Boyne Pollard
On general principles, given what that DLL is, the answer to that should
always be taken to be "Yes." unless one has positive information to the
contrary.
Jonathan de Boyne Pollard
>> BIOS to ACPI enabled and using MPS map 1.4 seems to produce an
>> otherwise pretty darn stable system. [...]
>
> So you have ACPI disabled even though having it enabled is more stable?
The last time around, M. Piatkowski said APIC, not ACPI. I pointed out
then that xe shouldn't be mixing up xyr initialisms. Disabling the
Advanced Configuration and Power Interface is a very different kettle of
fish to disabling any use of Advanced Programmable Interrupt
Controllers. It's actually the latter that M. Piatkowski is doing.
In an AMIBIOS machine, the setting that M. Piatkowski was talking about
earlier is named "ACPI APIC Support" and it deals with APICs. In
AWARD-Phoenix firmwares, the equivalent setting is named "APIC Mode".
It almost goes without saying that if one disables the use of APICs
entirely, by setting APIC mode to "disabled", then I/O APICs are as a
consequence unavailable. If all local APICs are switched off during
POST (as essentially all that this setting has to do), then whatever I/O
APICs may do is entirely irrelevant: there is no-one listening to them.
Peter Flass
It's unfortunate that these two acronyms are so easily confused.
Dariusz Piatkowski
Well...you did bring up an excellent point. I had read your original response to
my other post and had intended to respond...however I did encounter a
soft-freeze and wasn't able to find the posting anymore in my news reader...???
So here is the response, hopefully if I used the wrong terminology last time I
am getting it correct this time...I am in fact using the correct terms as
applicable to my hardware and in my descriptions I am addressing 2 separate
issues:
1) ACPI - replacing APM for example
2) APIC - dealing with SMP support and things like advanced programmable IO
controllers
In the BIOS of my motherboard, which is the MSI 790X-G45 piece, I do in fact
have 2 such separate settings.
1) Enabling ACPI also appears to enable the IOAPIC (that's correct), disabling
ACPI shuts OFF IOAPIC
2) SMP related stuff, I believe is really just the MPS table selection of 1.1 or
1.4
What I do not know is how enabling ACPI turns on the IOAPIC and how that in turn
relates to supporting SMP in OS2.
Here is a link to a mb review, and while it's not the matching model, it is very
close: MSI 790FX-GD70, the BIOS screenshots are very close (not the same
ofcourse for all settings) to what I see for my 790X-G45,
http://www.hardocp.com/article/2009/08/04/msi_790fxgd70_amd_motherboard/
Specifically, this is AMI BIOS and shows the following:
1)
http://www.hardocp.com/image.html?image=MTI0NTM3OTE2NFhVdWJNdTV0MzNfMl80X2wuZ2lm
...shows the IOAPIC function, it is ONLY present when ACPI has been turned ON
2)
http://www.hardocp.com/image.html?image=MTI0NTM3OTE2NFhVdWJNdTV0MzNfMl84X2wuZ2lm
...shows the ACPI controls
OK...so now given that information, I stand by my earlier conclusion...how does
ACPI control the IOAPIC??? Unless, the IOAPIC is only used to support the ACPI
functionality and has absolutely nothing to do with SMP.
Dariusz Piatkowski
...something else which I looked up in the BIOS this time, the description for
hte IOAPIC says the following:
'Include ACPI APIC table pointer to RSDT pointer list'
Now...does that make sense, and can you shed some light on this? Google is my
next stop...LOL...
Thanks!
Dave Yeo
What I've found on this system is that only the 105 SMP kernel will get
past the boot logo, even with the PSD statement remmed out.
Others have reported mixing close versions together successfully and
IIRC when the testcase kernels were being regularly released for
testing, not once was a doscall.dll released.
Dave
Jonathan de Boyne Pollard
> description for hte IOAPIC says the following:
>
> 'Include ACPI APIC table pointer to RSDT pointer list'
>
> Now...does that make sense, and can you shed some light on this?
>
No, it doesn't make sense. It tells me that your SETUP utility was put
together in a fairly slapdash manner, with the wrong text attached to
the setting. Here is a correctly selected, albeit not quite English,
description, from an MSI manual:
> IOAPIC Function
>
> This field is used to enable or disable the APIC (Advanced
> Programmable Interrupt Controller). Due to compliance with PC2001
> design guide, the system is able to run in APIC mode. Enabling APIC
> mode will expand available IRQ resources for the system.
>
> Settings: [Enabled], [Disabled].
It expands it by two (three for some chipsets), and even then only if
the local APICs are enabled.
Jonathan de Boyne Pollard
Especially when, as it seems here, conversation is about to turn to the
way that Advanced Programmable Interrupt Controllers are dealt with in
the Advanced Configuration and Power Interface. (-:
Jonathan de Boyne Pollard
>>
>> On general principles, given what that DLL is, the answer to that should
>> always be taken to be "Yes." unless one has positive information to the
>> contrary.
>
> IIRC when the testcase kernels were being regularly released for
> testing, not once was a doscall.dll released.
Nonetheless the general principle stands. Yes, it *might* be the case
that things *happen to be* compatible. And yes, there's the implied
compatibility of a patched or updated kernel with the thing that it is
replacing. But on any system the lowest-level system call library and
the kernel providing that system call interface are best considered
tightly coupled to each other without positive information to the contrary.
But this is an aside from your situation, since the SciTech statement is
fairly definite and unequivocal. It translates, upon my reading it, to
"We haven't put the interlocks in." or "We have put the interlocks in
but we've found in testing that they aren't quite right.".
> What I've found on this system is that only the 105 SMP kernel
> will get past the boot logo, even with the PSD statement remmed out.
Do you have the option of simply not using the SNAP drivers?
Dariusz Piatkowski
Alright now...LOL, my MSI BIOS does what it does...you may have whatever ideas
you have on how things should work...and I don't even necessairly disagree with
you, however, it is what it is.
In my MSI mb BIOS, as I previously described, the IOAPIC option ONLY shows up in
the menu when the ACPI mode is enabled. End of story.
C'mon man...accept that a vendor has chosen to implement something in a
particular way and deal with it...don't make that fact an overarching difficulty
for our conversation here. For the most part anyways you are merely pointing out
how you think BIOS settings should be, but I do not see any real examples you
are using to illustrate to us why and how it impacts OS2...
Steve Wendt
> > What I've found on this system is that only the 105 SMP kernel
> > will get past the boot logo, even with the PSD statement remmed out.
>
> Do you have the option of simply not using the SNAP drivers?
What does that have to do with not getting past the boot logo?
Jonathan de Boyne Pollard
>>> will get past the boot logo, even with the PSD statement remmed out.
>>>
>> Do you have the option of simply not using the SNAP drivers?
>>
> What does that have to do with not getting past the boot logo?
>
Dave Yeo
Attempting to enable SMP on my maintainance partition, which is very
minimal including only VGA, the desktop comes up but as soon as I type
anything I get a trap E, often in PMSHELL. Pressing ctrl-alt-del causes
more trap E
Dave
Jonathan de Boyne Pollard
>
> Attempting to enable SMP on my maintainance partition, which is very
> minimal including only VGA, the desktop comes up but as soon as I type
> anything I get a trap E, often in PMSHELL. Pressing ctrl-alt-del causes
Ouch! That says that there's more than just the SNAP drivers at work
here. What does moving the mouse do? Is this with a USB keyboard? If
it's not with a USB keyboard, what happens if you use a USB keyboard and
USB drivers?
Dave Yeo
Currently no USB drivers, even though the BIOS is set to use the USB
mouse in compatible mode, which should emulate a PS/2 mouse, I don't
even get a mouse cursor.
It's a PS/2 keyboard. I'll test by adding the USB drivers and try the
USB keyboard. I'd like to know how it works under my regular system anyways.
Dave
Jonathan de Boyne Pollard
That's a load of old twaddle, ascribing to me things that I never wrote.
Jonathan de Boyne Pollard
Let's eliminate some possibilities. Try /P=1 on the OS2APIC.PSD command
line.
Dariusz Piatkowski
Look...I have no quarrel with you...honestly, and I already said this, I
seriously appreciate the input folks like yourself can provide to the community.
My response was simply to address something you DID write in one of your posts
stating how things simply didn't work the way I was posting about
them...meanwhile, all I did was to try to re-create as closely as I could the
screens my BIOS showed...heck, I even found the best matching posts of such
screens from another MSI motherboard to illustrate what I was talking about and
included the URLs in my post for reference. Meanwhile your response was to say
how MSI got it wrong and we were therefore all confused...LOL!
YES...I accept the fact that if MSI had the wrong description of a BIOS function
then it certainly made me misunderstand the functionality...to correct this I
ask the OS community...I welcome all such feedback.
Dave Yeo
Works fine with the 105 kernel.
Dave
Jonathan de Boyne Pollard
>>
>> Let's eliminate some possibilities. Try /P=1 on the OS2APIC.PSD command
>> line.
>
> Works fine with the 105 kernel.
I presume that that means that you get a mouse pointer, you don't get
any TRAPs, and the system works pretty much as it did when you used the
uniprocessor kernel. That's what I suspected. Blast!
My educated guess is that either spinlocks or IPIs are not working
properly on your system, because of some chip variation that IBM didn't
account for. The hypothesis still fits all of the observed behaviour.
But I cannot come up with a mechanism for _how_. I'm going to have a
look at the specifications for the Pentium D.
Jonathan de Boyne Pollard
ASUS lists a P5PE-VM on its WWW site. Was that a transcription error?
The ASUS product specifications for the P5PE-VM tell us that it has an
Intel 82865G Graphics and Memory Controller Hub (GMCH). Looking up the
82865G in Wikipedia's "List of Intel chipsets" article, I find that
there's an "SMP" column and the 82865G has "No" in that column.
Unfortunately, the Wikipedia article, like so many, is badly written and
it's not evident what the Wikipedia writers' idea of a GMCH "supporting
SMP" actually is in concrete terms.
The bad news is that there are word-of-mouth reports that the P5PE-VM
was a bit of a bodge job: ASUS using a chipset that wasn't actually
designed for use with the Pentium D. Apparently it didn't work too well
in practice. Certainly there appear to be a fair number of bug reports
involving that combination. It is no wonder that it was cheap. (-:
The good news is that if you go to the "ACPI Compatibility Matrix" page
on the eComstation wiki, you'll find a 2008 report from someone named
Peter R Knapper who gives a magic incantation for ACPI.PSD (not
OS2APIC.PSD, note) that apparently ameliorated the TRAP-on-IPL symptoms
that he was having with a P5PE-VM.
Jonathan de Boyne Pollard
>
> Look...I have no quarrel with you...honestly, and I already said this, I
> seriously appreciate the input folks like yourself can provide to the community.
I know. Nonetheless, you're ascribing to me things that I never wrote.
In fact, you're *still* doing that even now.
> Meanwhile your response was to say how MSI got it wrong and
> we were therefore all confused...LOL!
This is a case in point. I never wrote any such thing. I wrote that
*you* interchanging ACPI and APIC confused people.