On Friday, August 10, 2007 11:37 AM, Mark.Haywood at Sun.COM wrote: > Li, Aubrey wrote: >> On Friday, August 10, 2007 10:55 AM, Dana.Myers at Sun.COM wrote: >> >>> Li, Aubrey wrote: >>>> On Friday, August 10, 2007 4:42 AM, Dana.Myers at Sun.COM wrote: >>>> >>>>> Aubrey wrote: >>>>> >>>>>> For P-state driver, I have one suggestion. There are still some >>>>>> old machines which support early ACPI specs but not support >>>>>> P-state. We should not ignore this kind of machine. So IMHO >>>>>> P-state driver should check the version of ACPI and doesn't make >>>>>> unnecessary warning. >>>>> It's a bit difficult to tell what version of ACPI a BIOS has been >>>>> "written for"; there's no version stamp on a BIOS saying >>>>> "compliant with ACPI version x.xx". Certainly we shouldn't >>>>> generate warnings when a feature simply isn't supported, though. >>>> Well, there is a structure member "Revision" in the RSDP structure. >>>> The ACPI version 1.0 revision number of this table is zero. Later >>>> the value for this field is 2. That's enough for PSS object >>>> checking. I'll come up with a patch against it if it's acceptable. >>> That field is the revision of the RSDP structure itself, not >>> of the ACPI >>> tables. >>> It's been '2' in both the ACPI 2.x and 3.x specs and '0' in >>> the 1.x spec, >>> so I suppose we could infer from it that a BIOS written in the >>> pre-2.0 era is present, but I'm afraid I don't understand the >>> exact error case we're >>> discussing in the first place. What is the problem we're >>> trying to solve? >>> I'd prefer to solve the root-cause of the problem rather use the >>> RSDP structure version in a way not intended by the spec. >>> >> >> I think it's PSS object not found. I checked ACPI spec and found PSS >> object is introduced since ACPI2.0. > > Right. In cpu_acpi.c we try to evaluate the _PSS object and > AcpiEvaluateObjectTyped() fails to evaluate it because the _PSS is not > there. This results in a call to cmn_err(). As I said previously, this > messages is being displayed on the console. A bug was filed > against this > a couple of days ago: > > 6589662 Error messages from cpu_acpi on install boot w/snv_70 > > I'm changing the behavior so that the message only gets logged to the > system log. I'm not sure that I see a reason for checking the version > and I'm not if there is a reliable way to do this. I didn't > believe that > it was the case that a BIOS implemented a specific ACPI version. > > Regardless, we're going to want to log a message saying that we can't > manage the P-states because we don't have a _PSS object (for whatever > reason).
OK, that makes sense to me. Thanks, -Aubrey > >> So the machine wih ACPI1.0 don't have this object. >> IMHO, that means speedstep driver would only work on the machines >> with ACPI2.0 and later. So, for those ACPI1.0 machine, PSS warning >> message is not necessary. But I need some time to verify the root >> cause. >> >>>>> What version did you find on the Intel website? We're >>>>> currently at 20060721 in Solaris Nevada. >>>>> >>>>> Dana >>>> The current version is 20061109, here is the changelog. >>>> http://www.intel.com/technology/iapc/acpi/downloads/changes.txt >>>> I'm new to solaris, just want to know when and how this package is >>>> updated into solaris. >>> Thanks; we currently have a later source drop in-house, but there's >>> an issue in 20070508 and later which results in a dead-lock when >>> delivering GPE events. Do you know when Bob Moore will be back from >>> sabbatical? >> >> Sorry, I have no idea, ;-) >> >> Best Regards, >> -Aubrey >> Intel OpenSolaris Team >> _______________________________________________ >> tesla-dev mailing list >> tesla-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
