On Thursday, September 13, 2007 9:47 AM, Dana.Myers at Sun.COM wrote: > Mark Haywood wrote: >> Li, Aubrey wrote: >>> On Thursday, September 13, 2007 1:56 AM, Dana.Myers at Sun.COM wrote: >>> >>> >>>> 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. >>> >> If this is true, then it seems to me that something must be wrong >> with the acpica interpreter. According to the spec (as I read it >> anyway), you should be able to treat the alias just as you would the >> target. So, it we cannot evaluate the _PDC using the alias object, >> then again, I think something is wrong at a higher level than where >> we are doing the mapping in osl.c > That's my concern, as well - that ACPI CA may not be properly > handling the Alias() statement. We need to bounce this off of Bob > Moore at Intel (who is the lead engineer for ACPI CA), but first I'd > like some information on the purpose of the Alias statements in this > case. > I have another meeting with him a few hours ago. I can forward the issue to him. Let's see what feedback.
-Aubrey
