Mark Haywood wrote: > It was recently pointed out to me that the CPU driver is printing (a > very poorly worded) message to the system error log every time it > receives a _PPC change notification. For those who don't know what a > _PPC is, it's an ACPI object that informs the OS which of the defined > P-states are accessible. That is, it's like a governor on which P-states > the OS should use. It's frequently used by the platform to force the > processors down to a lower frequency as a thermal control mechanism. > > The _PPC can change dynamically and when it does it is possible for the > OS to find out about the change by registering a change notification > handler. The CPU driver does register a handler and as I mentioned above > is printing an error message to the system error log it is invoked. > Printing the message to the system error log was apparently a mistake. > Some platforms are changing the _PPC values much more often that I expected. > > I've already filed: > > 6636222 "NOTICE: cpudrv_pm_set_topspeed: instance 0: has new max power > of 2000 MHz" needs to go > > to remove the message. But was thinking that we might want to add > another cpu_info kstat to track the current maximum permissible > frequency for the processor. It would have to be an x86 only kstat > probably tracked in the cpu_t structure in a similar fashion as > cpu_curr_clock. I was wondering if anyone had an opinion on the > usefulness of this data as a cpu_info kstat addition? > > Mark > > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev We will have to deal with _CST object change notifications for c-states too.
Bill
