Hi Anup,

As far as I know the motherboard supports deep C-states. There could be a
BIOS bug however, so I will contact the vendor to see what they say about
the issue.

I did see a bug 6068 (http://defect.opensolaris.org/bz/show_bug.cgi?id=6068)
that messed up C-State detection due to a bad bitmask operation. As I
mentioned before, being new to the way things work for OpenSolaris, I am
having a hard time figuring out when such fixes actually make it into the
package repository. I was hoping it could be just a simple, existing, patch
in dev package to resolve my issue :)

Thanks for the information regarding powertop. I was following the blog
entry at
http://blogs.sun.com/mhaywood/entry/introducing_speedstep_on_solaris and did
not realize that current_clock_Hz is highly variable.

Regards,
John


On Mon, Jun 29, 2009 at 1:30 PM, Anup Pemmaiah <Napanda.Pemmaiah at 
sun.com>wrote:

> Hi John,
>
> From the initial look at the log messages, it looks like even though your
> processor might supportsp,
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20090629/8ce968aa/attachment.html>

Reply via email to