On Thursday, September 13, 2007 1:46 AM, Mark.Haywood at Sun.COM wrote:
> 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
>
I agree with Mark's idea, we need to distinguish AliasObject from the
SourceObject,
So that we can map the right object as the device handler.
-Aubrey
>>
>> 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
