Hi John, From the initial look at the log messages, it looks like even though your processor might supports deep C-States, the BIOS is not exporting correct ACPI objects to do deep C-State management. Either the deep C-state related information may have to be enabled in the BIOS or BIOS may have to be updated to the version that supports deep C-States.
Regarding freq information, powertop might be the better place to check what the processors are doing and to get the average freq of the processor. current_clock_Hz in kstat gives the processor freq at that moment and it keeps getting changed whenever the processor freq changes and it happens many times a second. So, you cannot compare the current_clock_Hz with that of powertop. HTH Anup bitspace at gmail.com wrote: > Hello, > > My apologies if this is the incorrect list. > > I am having trouble getting deep C-States beyond C1 working on > OpenSolaris nv_111b (2009.06 release). I am running an Intel Core 2 > dual-core E5200 with a Supermicro X7SBL-LN2 motherboard that supports > C1E and deep C-states in the BIOS. > > This shows up in var/adm/messages: > > Jun 29 12:16:05 databank unix: [ID 950921 kern.info > <http://kern.info>] cpu0: x86 (chipid 0x0 GenuineIntel 1067A > family 6 model 23 step 10 clock 2500 MHz) > Jun 29 12:16:05 databank unix: [ID 950921 kern.info > <http://kern.info>] cpu0: Pentium(r) Dual-Core CPU E5200 @ > 2.50GHz > Jun 29 12:16:05 databank unix: [ID 950921 kern.info > <http://kern.info>] cpu1: x86 (chipid 0x0 GenuineIntel 1067A > family 6 model 23 step 10 clock 2500 MHz) > Jun 29 12:16:05 databank unix: [ID 950921 kern.info > <http://kern.info>] cpu1: Pentium(r) Dual-Core CPU E5200 @ > 2.50GHz > Jun 29 12:16:05 databank acpica: [ID 423971 kern.notice] ACPI: > SSDT @ 0xbfe740cb/0x0234 (v 1 PmRef Cpu1Ist 0x00003000 INTL > 0x20050228) > Jun 29 12:16:05 databank acpica: [ID 395089 kern.notice] ACPI: > SSDT @ 0xbfe73a85/0x0085 (v 1 PmRef Cpu1Cst 0x00003000 INTL > 0x20050228) > Jun 29 12:16:05 databank unix: [ID 395387 kern.info > <http://kern.info>] NOTICE: cpu_acpi: _CST invalid count 1 < 2 > Jun 29 12:16:05 databank unix: [ID 518192 kern.warning] WARNING: > cpu_acpi: error parsing _CST for CPU 1 > Jun 29 12:16:05 databank unix: [ID 726263 kern.info > <http://kern.info>] NOTICE: cpu_idle_init: Failed to cache ACPI > C-state data > Jun 29 12:16:05 databank unix: [ID 763091 kern.warning] WARNING: > cpupm_init: processor 1: unable to initialize C-state support > > > > The same occurs for CPU 0 but earlier in the log. > > There also appears to be something strange going on with the p-states > as well: > > $ kstat -m cpu_info -s current_clock_Hz > module: cpu_info instance: 0 > name: cpu_info0 class: misc > current_clock_Hz 2500000000 > > module: cpu_info instance: 1 > name: cpu_info1 class: misc > current_clock_Hz 2500000000 > > > > As you can see, the current_clock_Hz is reported by kstat as 2.5GHz, > but in powertop it is reported differently: > > Cn Avg residency P-states (frequencies) > C0 (cpu running) (3.2%) 1200 Mhz 100.0% > C1 2.4ms (96.8%) 1600 Mhz 0.0% > 2000 Mhz 0.0% > 2400 Mhz 0.0% > 2500 Mhz 0.0% > > > > Powertop says the processor is running at 1.2GHz not 2.5GHz, and of > course no deep c-states. I am unsure as why they are reporting > differently. > > This is my current power.conf: > > autopm enable > autoS3 default > cpu-threshold 1s > # Auto-Shutdown Idle(min) Start/Finish(hh:mm) > Behavior > autoshutdown 30 9:00 9:00 > noshutdown > cpupm enable > cpu_deep_idle enable > > device-thresholds /pci at 0,0/pci15d9,d880 at 1f,2/disk at 0,0 > 45m > device-thresholds /pci at 0,0/pci15d9,d880 at 1f,2/disk at 1,0 > 45m > device-thresholds /pci at 0,0/pci15d9,d880 at 1f,2/disk at 2,0 > 45m > > > > I would appreciate any insights anyone may have. I looked to see if > this has been a reported bug and if there is a fix but have not found > anything. I am new enough to OpenSolaris that I still have not found > out where the changelogs are for the packages in the dev repository > either, so I am unsure if there are patches to the C-state > initialization for other bugs that may fix this. > > Cheers, > John > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
