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.
Dana
