Li, Aubrey wrote:
> Mark.Haywood wrote:
>
>
>> Li, Aubrey wrote:
>>
>>> pm-discuss-bounces at opensolaris.org wrote:
>>>
>>>
>>>
>>>> Jason Rhodes wrote:
>>>>
>>>>
>>>>> I have an Intel E7400 CPU on an Intel DG43NB motherboard,
>>>>>
>>>>>
>>>> and /cpu throttling does not appear to work under OpenSolaris.
>>>> EIST is enabled in the BIOS, and I upgraded to the latest
>>>> version 75 BIOS. I'm running snv_105. I've attached the .DSL
>>>> file output by iasl -g, and included log messages an cpu_info
>>>> below. I can provide additional info as necessary.
>>>>
>>>>
>>>> Unless I'm mistaken, the problem is in the _PDC definition:
>>>>
>>>> Method (_PDC, 1, NotSerialized)
>>>> {
>>>> CreateDWordField (Arg0, 0x08, DAT0)
>>>> Store (DAT0, TYPE)
>>>> If (LEqual (CINT, Zero))
>>>> {
>>>> Store (One, CINT)
>>>> If (LOr (LEqual (And (TYPE, 0x1B), 0x1B), LEqual (DCOR,
>>>> Zero))) { If (LNotEqual (NPSS, Zero))
>>>> {
>>>> Load (SSDT, HNDL)
>>>> }
>>>> }
>>>> Else
>>>> {
>>>> Store (One, NCST)
>>>> }
>>>> }
>>>> }
>>>>
>>>> And in case this is all Greek to you, I believe that the _PSS
>>>> is getting
>>>> loaded dynamically and one of the requirements for it getting
>>>> loaded is that the _PDC has bit 0x10 enabled (TYPE equaling 0x1B
>>>> check above). That bit has *nothing* to do with SpeedStep. It is
>>>> supposed to
>>>> mean that
>>>> the OS can support deep C-states on MP systems. I wish either,
>>>>
>>>> a) Intel had never introduced these _PDC bits or
>>>> b) BIOS developers would get a clue as to what the bits mean.
>>>>
>>>> I'm not sure what to do about this. I'd hate to see us enable that
>>>> bit in Solaris as a work around. If we do, then I'm pretty close to
>>>> saying screw it and enabling all the _PDC bits all the time. The
>>>> BIOS developers have blown their use all to hell.
>>>>
>>>> Again, I started this with "Unless I'm mistaken ...". ;-)
>>>>
>>>> Mark
>>>>
>>>>
>>> sigh, buggy BIOS. "0x1B" checking will load "SSDT" table. Maybe there
>>> is something else in the table need to be loaded to support deep
>>> c-state, although I saw _CST(C1ST, C2ST, C3ST, C4ST) are already
>>> there.
>>>
>>> This issue should be fixed in 110 and later build due to the deep
>>> c-states support, by accident, :D. So no more work need to be done.
>>>
>>>
>> Not necessarily. Only if cpu_deep_cstates_supported() returns B_TRUE.
>>
>>
>
> No, PDC setting doesn't need to do that check.
>
Probably doesn't matter much, but besides the comment being wrong:
/*
* If we support deep cstates on this processor, then set
the
* correct cstate_ops for the processor and enable
appropriate
* _PDC
bits.
*/
mach_state->ms_cstate.cma_ops = &cpu_idle_ops;
cpupm_intel_pdccap |= CPUPM_INTEL_PDC_C1_HALT |
CPUPM_INTEL_PDC_C2C3_MP | CPUPM_INTEL_PDC_C1_FFH;
I do wonder why we are setting the bits if we don't support it? And
unless I'm misreading the code, we even try to read the C-state data
even in the case where we don't support the processor?
Mark
> Thanks,
> -Aubrey
>
>
>> Mark
>>
>>
>>> Thanks,
>>> -Aubrey
>>>
>>>
>>>
>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> root at cambot:~/ttt# grep cpudrv /var/adm/messages
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 569748 kern.info] NOTICE:
>>>>>
>>>>>
>>>> cpu_acpi: _PSS package not found.
>>>>
>>>>
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 978953 kern.warning]
>>>>>
>>>>>
>>>> WARNING: cpu_acpi: error parsing _PSS for CPU instance 0
>>>>
>>>>
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 647322 kern.warning]
>>>>>
>>>>>
>>>> WARNING: cpudrv_mach_pm_init: instance 0: unable to initialize
>>>> P-state support
>>>>
>>>>
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 569748 kern.info] NOTICE:
>>>>>
>>>>>
>>>> cpu_acpi: _TSS package not found.
>>>>
>>>>
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 227567 kern.warning]
>>>>>
>>>>>
>>>> WARNING: cpu_acpi: error parsing _TSS for CPU instance 0
>>>>
>>>>
>>>>> Mar 23 17:07:53 cambot cpudrv: [ID 888440 kern.warning]
>>>>>
>>>>>
>>>> WARNING: cpudrv_mach_pm_init: instance 0: unable to initialize
>>>> T-state support
>>>>
>>>>
>>>>> root at cambot:~/ttt# kstat -m cpu_info
>>>>> module: cpu_info instance: 0
>>>>> name: cpu_info0 class: misc
>>>>> brand Intel(r) Core(tm)2 Duo CPU
>>>>> E7400 @ 2.80GHz chip_id 0
>>>>> clock_MHz 2793
>>>>> clog_id 0
>>>>> core_id 0
>>>>> cpu_type i386
>>>>> crtime 34.705146564
>>>>> current_clock_Hz 2792966885
>>>>> family 6
>>>>> fpu_type i387 compatible
>>>>> implementation x86 (chipid 0x0
>>>>>
>>>>>
>>>> GenuineIntel 1067A family 6 model 23 step 10 clock 2793 MHz)
>>>>
>>>>
>>>>> model 23
>>>>> ncore_per_chip 2
>>>>> ncpu_per_chip 2
>>>>> pkg_core_id 0
>>>>> snaptime 174798.61890531
>>>>> state on-line
>>>>> state_begin 1237842473
>>>>> stepping 10
>>>>> supported_frequencies_Hz 2792966885
>>>>> vendor_id GenuineIntel
>>>>>
>>>>> module: cpu_info instance: 1
>>>>> name: cpu_info1 class: misc
>>>>> brand Intel(r) Core(tm)2 Duo CPU
>>>>> E7400 @ 2.80GHz chip_id 0
>>>>> clock_MHz 2793
>>>>> clog_id 1
>>>>> core_id 1
>>>>> cpu_type i386
>>>>> crtime 39.623228409
>>>>> current_clock_Hz 2792966885
>>>>> family 6
>>>>> fpu_type i387 compatible
>>>>> implementation x86 (chipid 0x0
>>>>>
>>>>>
>>>> GenuineIntel 1067A family 6 model 23 step 10 clock 2793 MHz)
>>>>
>>>>
>>>>> model 23
>>>>> ncore_per_chip 2
>>>>> ncpu_per_chip 2
>>>>> pkg_core_id 1
>>>>> snaptime 174798.619555623
>>>>> state on-line
>>>>> state_begin 1237842478
>>>>> stepping 10
>>>>> supported_frequencies_Hz 2792966885
>>>>> vendor_id GenuineIntel
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------
>>>> ---------
>>>>
>>>>
>>>>> _______________________________________________
>>>>> pm-discuss mailing list
>>>>> pm-discuss at opensolaris.org
>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss
>>>>>
>>>>>
>>>> _______________________________________________
>>>> pm-discuss mailing list
>>>> pm-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss
>>>>
>
>
