Li, Aubrey wrote:
> On Wednesday, September 12, 2007 5:48 PM, Mark.Haywood at Sun.COM wrote:
>
>>> Your change of that table is so good that we don't have to change
>>> the current code behavior. But that's the table the BIOS give out.
>>> And the driver have to be based on it. I didn't found the
>>> specification for it so far.
>>> At least, the current method of building cpu acpi map doesn't cover
>>> all kinds of machine, which need to be fixed.
>>> I'll continue to investigate and let you know when I get something.
>> I ran into a system today with the following iasl dump:
>>
>> Scope (_PR)
>> {
>> Processor (P001, 0x01, 0x00000810, 0x06) {} Alias
>> (P001, CPU1) Processor (P002, 0x02, 0x00000000, 0x00) {}
>> Alias (P002, CPU2) Processor (P003, 0x03, 0x00000000, 0x00)
>> {} Alias (P003, CPU3) Processor (P004, 0x04,
>> 0x00000000, 0x00) {} Alias (P004, CPU4) }
>>
>> I've never see an "Alias" defined before. I'm wondering if
>> that is what
>> you are running into. If so, then I think the fix might be to ignore
>> aliases when doing the mapping. Can you check to see if that's what
>> you're running into? If so, then we'll have to figure out how to
>> identify an "Alias".
> Yes, I saw an "Alias" on my system. From the objects "P001" and "CPU1",
> they have the same type and flags.
> We have to find another way to identify this "Alias".
> Can we simply not add these "Alias" object into the namespace when we
> load the whole table?
I'm not sure what you mean by 'add these "Alias" object into the
namespace'. The result of an Alias() is another Processor() object
in the namespace; unfortunately, I believe we currently treat them
as unique Processor() objects because that's what they look like
by the time we see them. Perhaps the right thing to to do is to
ignore a duplicate Processor() based on the ProcessorID, which
is required to be unique for each actual processor.
Arguably, creating alias objects for Processor()s is a bad idea;
any idea why a BIOS author would do that?
>
>> BTW, On this particular system, there really wasn't a _PSS.
>>
>
> _PSS may be in another table which needs to be loaded by evaluating
> _PDC.
> Can you give me the ssdt table on your system to check?
We've seen some real magic with _PSS, particularly Toshiba BIOSes which
do not declare a _PSS anywhere in the ACPI tables, but instead load
one dynamically from a SystemMemory region at _PDC time. Mark's seen
that before, though.
Dana
