On Thursday, September 13, 2007 1:56 AM, Dana.Myers at Sun.COM wrote:
> Mark Haywood 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?
> So I took a look at the code (it's been a long time since I wrote it,
> and I've forgotten how I implemented it). I originally feared that
> I'd implemented the CPU mapping in a way that the 'duplicate'
> Processor objects would confuse the mapping code. As you point out,
> Mark, this is not
> the case.
> You're completely correct, as far as I can tell - there's no reason to
> ignore the Alias()ed Processor objects - they're just references to
> the same object anyway. I admit I wasn't thinking of the case of
> Alias() when I implemented the mapping code, but it doesn't make a
> difference at
> all.
> No memory is leaked, nothing is broken.
>
> Thanks -
> Dana
That's not true, actually processor handler mapping is broken when an
AliasObject exists.
Although it is reference to the same object, it's another new object in
the namespace.
And it's not the parent of _PDC object. So when you passed it as the
handler parameter to evaluate _PDC,
We will run into the failure.
-Aubrey
