Dana H. Myers wrote:
> 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.
Actually, I think that this was Aubrey's original suggested fix
(ignoring Processor objects that have already been mapped). I'm hesitant
to implement a fix though until we have a better understanding of the
problem.
I guess what doesn't make sense to me is why mapping to the alias
instead of the original Processor object should be a problem. What good
is an alias, if you can't distinguish it from the original object and
you can't use it as you would the original object?
According to the ACPI specification:
17.5.3 Alias (Declare Name Alias)
Syntax
Alias (SourceObject, AliasObject)
Arguments
SourceObject is any named object. AliasObject is a NameString.
Description
Creates a new object named AliasObject that refers to and acts
exactly the same as SourceObject.
AliasObject is created as an alias of SourceObject in the namespace.
The SourceObject name must already
exist in the namespace. If the alias is to a name within the same
definition block, the SourceObject name
must be logically ahead of this definition in the block.
So, why should mapping to the alias object be a problem?
Mark
>
> 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
>
