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
