On Wednesday, September 12, 2007 11:16 PM, Dana.Myers at Sun.COM 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.
Errr, yes, the result of an Alias is another Processor() object in the
namespace.
What I mean is, this object is useless. Can we ignore all kinds of these
objects,
So that we have an unique object for each actual device?
>
> 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.
>
Thanks,
-Aubrey
