[9fans] missing machs unearthed

[9fans] missing machs unearthed

[erik quanstrom]

i've had a core i7 machine for some time with 4c/8t.
unfortunately, the mp table has only 4 processor entries.
evidently this is also the case on core i5/xeon 3xxxx machines
with >= 4t as well.

in my case, i was given a lucky break by bios which gave
the processors apic ids 0, 2, 4, 6 and the ioapic got apic
id 8.  since apic ids are unique within a system, it wasn't
too hard to guess that i might be missing 1, 3, 5, 7.
clearly guessing wrong will result in no boot for you.

(unluckily, the xeon 3xxxx that's come for a visit gives
its ioapic id 1.  :-(.)

a quick (but gruesome) hack later, and i was able to
generate fake mp entries for the missing processors.
and:

chula# cat /dev/sysstat
          0        1659       77046         458         444           0           0         391          94           0
          1        2773       70167         686         698           0           0           0          87           0
          2        2116       69208         616         433           0           0           0          86           0
          3        2129       70004         804         431           0           0           0          85           0
          4        2357       72195         567         462           0           0           0          90           0
          5        1291      125929         602         429           0           0           0          85           0
          6        2223       70054         526         478           0           0           0          85           0
          7        2153       70028         568         405           0           0           0          84           0

i can then use cpuid to validate this.  cpuid -t wires itself
to each processor to get the apic id for that processor.

chula# aux/cpuid -t
thread	00000001 00000002 00000100 00000000
core	00000004 00000008 00000201 00000000
mach0	apic 00000000
mach1	apic 00000001
mach2	apic 00000002
mach3	apic 00000003
mach4	apic 00000004
mach5	apic 00000005
mach6	apic 00000006
mach7	apic 00000007

it's quite unfortunate that this info isn't available outside
the processor.

this is what the system thinks;
the fields are type/apicno/flags/lintr0/lintr1/machno

chula# cat /dev/mpapic
proc                0 be        65536        65536           0
proc                1  e        65536        65536           1
proc                2  e        65536        65536           2
proc                3  e        65536        65536           3
proc                4  e        65536        65536           4
proc                5  e        65536        65536           5
proc                6  e        65536        65536           6
proc                7  e        65536        65536           7
ioapic              8  e            0            0           0

- erik

Re: [9fans] missing machs unearthed

[Richard Miller]

> i've had a core i7 machine for some time with 4c/8t.
> unfortunately, the mp table has only 4 processor entries.

My impression is that mp tables are getting worse and worse on new
hardware because vendors assume everyone is running an acpi-aware OS.

Does anybody have an (informed) opinion as to the feasibility of
parsing the acpi tables just enough to get what we need for boot-time
multiprocessor configuration, without having to implement all of acpi?

Re: [9fans] missing machs unearthed

[Francisco J Ballesteros]

There's an initial implementation of acpi, but it's not yet ready.
Getting boot-time MP info is not enough, the information regarding
bus/interrupt entries is provided in many cases by AML methods.

So, in short, you need all of acpi to get that information.
The good news is that it's implemented.
The bad news is that is does not work yet.
What remains to be done is to supply bus information to the kernel
correctly, and that's not happening as of today.


On Mon, Apr 5, 2010 at 11:20 AM, Richard Miller <9fans@hamnavoe.com> wrote:
>> i've had a core i7 machine for some time with 4c/8t.
>> unfortunately, the mp table has only 4 processor entries.
>
> My impression is that mp tables are getting worse and worse on new
> hardware because vendors assume everyone is running an acpi-aware OS.
>
> Does anybody have an (informed) opinion as to the feasibility of
> parsing the acpi tables just enough to get what we need for boot-time
> multiprocessor configuration, without having to implement all of acpi?
>
>
>

Re: [9fans] missing machs unearthed

[erik quanstrom]

On Mon Apr  5 05:21:57 EDT 2010, 9fans@hamnavoe.com wrote:
> > i've had a core i7 machine for some time with 4c/8t.
> > unfortunately, the mp table has only 4 processor entries.
>
> My impression is that mp tables are getting worse and worse on new
> hardware because vendors assume everyone is running an acpi-aware OS.

it's not clear to me that's it's not just general low
quality, especially with board-specific bits like mp
tables.  z.B. if you look at the smb on the typicall mb,
it's amazing how much of it is broken.  i've had
good luck though with some vendors, though.

also, i wonder if not all the threads are in the mp
table due to format limitations.  the traditional i/o
apic format is 32 bits and uses (1<<apicno)<<24
as the vector for the cpu apics so my i7 board has
the vectors arranged the only way they could be to
give use of all 8 cpus.  i suppose i'm out of luck for
a xeon-ex with 16t unless i do something about x2apic.

- erik

Re: [9fans] missing machs unearthed

[Richard Miller]

>> My impression is that mp tables are getting worse and worse on new
>> hardware because vendors assume everyone is running an acpi-aware OS.
>
> it's not clear to me that's it's not just general low
> quality,

Does that imply that we can expect the acpi tables to be often
incorrect too?  That would be disappointing.

Re: [9fans] missing machs unearthed

[erik quanstrom]

> >> My impression is that mp tables are getting worse and worse on new
> >> hardware because vendors assume everyone is running an acpi-aware OS.
> >
> > it's not clear to me that's it's not just general low
> > quality,
>
> Does that imply that we can expect the acpi tables to be often
> incorrect too?  That would be disappointing.

having not done much with acpi, i don't know.  i do
know that things like smb tend not to work right,
often because bios and hw are not quite right.

- erik

Re: [9fans] missing machs unearthed

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

Not that this is a great answer, but the way I've done SMP boot without
parsing either the ACPI or MPS tables was to issue broadcast init and
startup IPIs, rather than targeted ones. All the CPUs in an i7-based machine
came up, fwiw...

-- vs

[-- Attachment #2: Type: text/html, Size: 276 bytes --]

Re: [9fans] missing machs unearthed

[erik quanstrom]

On Mon Apr  5 14:44:44 EDT 2010, me@acm.jhu.edu wrote:

> Not that this is a great answer, but the way I've done SMP boot without
> parsing either the ACPI or MPS tables was to issue broadcast init and
> startup IPIs, rather than targeted ones. All the CPUs in an i7-based machine
> came up, fwiw...

how did you get around the fact that you had now PCMPprocessor structure?
the current code requires that you have a PCMP structure to get things going,
and you're going to have to manufacture interrupt routing information from
somewhere.  where'd you get that info, with no tables?

- erik

Re: [9fans] missing machs unearthed

[Brian L. Stuart]

> >> My impression is that mp
> tables are getting worse and worse on new
> >> hardware because vendors assume everyone is
> running an acpi-aware OS.
> > 
> > it's not clear to me that's it's not just general low
> > quality,
> 
> Does that imply that we can expect the acpi tables to be
> often
> incorrect too?  That would be disappointing.

Well, they are bad enough that FreeBSD (and I assume
others) gives you a way of overriding the one provided
by the vendor.  There are collections of fixed ACPI
tables for various machines out there.

Just to make life more "interesting," there's something
flakey about FreeBSD's access of the table in my HP
laptop.  About half the time it boots up and reads the
table happily.  The other half, it will continually
complain that there's something wrong with the table.

BLS

Re: [9fans] missing machs unearthed

[ron minnich]

On Mon, Apr 5, 2010 at 2:20 AM, Richard Miller <9fans@hamnavoe.com> wrote:
>> i've had a core i7 machine for some time with 4c/8t.
>> unfortunately, the mp table has only 4 processor entries.
>
> My impression is that mp tables are getting worse and worse on new
> hardware because vendors assume everyone is running an acpi-aware OS.
>

that's precisely the problem. We've seen cases where vendors too
bioses from an old machine to a new machine. If you are not acpi aware
you are pretty much 5 years out of date.

> Does anybody have an (informed) opinion as to the feasibility of
> parsing the acpi tables just enough to get what we need for boot-time
> multiprocessor configuration, without having to implement all of acpi?


Extremely doable.

ron

Re: [9fans] missing machs unearthed

[Francisco J Ballesteros]

>
> Extremely doable.
>


If you forget about bus information.

Re: [9fans] missing machs unearthed

[Devon H. O'Dell]

2010/4/5 ron minnich <rminnich@gmail.com>:
> On Mon, Apr 5, 2010 at 2:20 AM, Richard Miller <9fans@hamnavoe.com> wrote:
>>> i've had a core i7 machine for some time with 4c/8t.
>>> unfortunately, the mp table has only 4 processor entries.
>>
>> My impression is that mp tables are getting worse and worse on new
>> hardware because vendors assume everyone is running an acpi-aware OS.
>>
>
> that's precisely the problem. We've seen cases where vendors too
> bioses from an old machine to a new machine. If you are not acpi aware
> you are pretty much 5 years out of date.

It's not just that. The other part is that you can put OS-specific
information into the AML, which is nice in theory, until you consider
that most vendors consider Windows to be the only operating system in
existence. (This is why FreeBSD allows you to override the tables --
you can rewrite those sections to apply to FreeBSD, and most of the
time, that works just fine).

That said, things have settled down a good bit in ACPI land and
Intel's ACPICA reference implementation is fairly complete (but
unfortunately not something we can use).

Nemo, I wonder if you have any way to allow others to collaborate on
that code? Seems like there's certainly interest, and the ACPI spec
*is* open...

--dho

Re: [9fans] missing machs unearthed

[Francisco J Ballesteros]

> Nemo, I wonder if you have any way to allow others to collaborate on
> that code? Seems like there's certainly interest, and the ACPI spec
> *is* open...
>

Well, the code is done. The interpreter seems to be working, and the
tables seem to be parsed.

The problem is that we have to supply bus info
correctly to the kernel. Once that is done, there'll be plenty of bugs to
fix, and there's the joy of "acpi aware drivers".

Sadly, the last month we could put almost no time on this, but that's changing
now. I don't know when will it be ready for use. We are still almost
there, but not there yet.

Re: [9fans] missing machs unearthed

[erik quanstrom]

> fix, and there's the joy of "acpi aware drivers".

what does this mean?

- erik

Re: [9fans] missing machs unearthed

[Francisco J Ballesteros]

An example, enumerating and configuring PCI using acpi methods,
enumerate and configure X using acpi methods.


On Mon, Apr 5, 2010 at 5:56 PM, erik quanstrom <quanstro@labs.coraid.com> wrote:
>> fix, and there's the joy of "acpi aware drivers".
>
> what does this mean?
>
> - erik
>
>

Re: [9fans] missing machs unearthed

[erik quanstrom]

On Mon Apr  5 12:06:39 EDT 2010, nemo@lsub.org wrote:
> An example, enumerating and configuring PCI using acpi methods,
> enumerate and configure X using acpi methods.

i hope i'm not being ignorant here, but i just went through
the linux code for enumerating pci.  they try every trick in
the book, but they don't bother with acpi (that i saw.)
may be i'm suffering from all the world's a pc syndrome?

- erik

Re: [9fans] missing machs unearthed

[Francisco J Ballesteros]

I may be mistaken, but I think they have all sorts of ways to
enumerate devices, both with and without acpi.


On Mon, Apr 5, 2010 at 6:12 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Mon Apr  5 12:06:39 EDT 2010, nemo@lsub.org wrote:
>> An example, enumerating and configuring PCI using acpi methods,
>> enumerate and configure X using acpi methods.
>
> i hope i'm not being ignorant here, but i just went through
> the linux code for enumerating pci.  they try every trick in
> the book, but they don't bother with acpi (that i saw.)
> may be i'm suffering from all the world's a pc syndrome?
>
> - erik
>
>

Re: [9fans] missing machs unearthed

[Artem Pylypchuk]

On Monday 05 April 2010 15:00:01 9fans-request@9fans.net wrote:
> The good news is that it's implemented.
> The bad news is that is does not work yet.
> What remains to be done is to supply bus information to the kernel
> correctly, and that's not happening as of today.

where can I find the implementation?