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