Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9

on 12/09/2010 12:26 Norikatsu Shigemura said the following:
> Hi avg and mav.
> 
> On Sun, 12 Sep 2010 11:12:20 +0300
> Alexander Motin <mav_at_freebsd.org> wrote:
>>>>> PROCESSOR-0696 [257314] cpu_cx_cst            : acpi_cpu3: C2[1] not available.
>>>>> PROCESSOR-0730 [257314] cpu_cx_cst            : acpi_cpu3: Got C3 - 245 latency
>>>> I think the issue is that C2 is not available for some reason and thus
>>>> C3 can't be used either. The way to tell is to use acpidump and look for
>>>> the CPU objects' _CST fields.
>>> The "not available" message means that transition latency is defined too high.
>>> That is, in this case latency is greater than 100 for C2.
>> Just an idea. Limits of 100 and 1000 are defined for detection of
>> C-states using P_LVLx_LAT registers. Because _CST explicitly specifies
> 
> 	Oops! I forgot. Thank you, I tried.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> --- sys/dev/acpica/acpi_cpu.c.orig	2010-09-12 01:31:38.144243000 +0900
> +++ sys/dev/acpica/acpi_cpu.c	2010-09-12 18:06:14.651938193 +0900
> _at__at_ -597,7 +597,7 _at__at_
>      /* Validate and allocate resources for C2 (P_LVL2). */
>      gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
>      gas.BitWidth = 8;
> -    if (AcpiGbl_FADT.C2Latency <= 100) {
> +    if (AcpiGbl_FADT.C2Latency <= 1000) {
>  	gas.Address = sc->cpu_p_blk + 4;
>  	acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid,
>  	    &gas, &cx_ptr->p_lvlx, RF_SHAREABLE);
> _at__at_ -613,7 +613,7 _at__at_
>  	return;
>  
>      /* Validate and allocate resources for C3 (P_LVL3). */
> -    if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) {
> +    if (AcpiGbl_FADT.C3Latency <= 10000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) {
>  	gas.Address = sc->cpu_p_blk + 5;
>  	acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas,
>  	    &cx_ptr->p_lvlx, RF_SHAREABLE);

The above changes are incorrect.

> _at__at_ -690,7 +690,7 _at__at_
>  	    sc->cpu_cx_count++;
>  	    continue;
>  	case ACPI_STATE_C2:
> -	    if (cx_ptr->trans_lat > 100) {
> +	    if (cx_ptr->trans_lat > 1000) {
>  		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>  				 "acpi_cpu%d: C2[%d] not available.\n",
>  				 device_get_unit(sc->cpu_dev), i));
> _at__at_ -700,7 +700,7 _at__at_
>  	    break;
>  	case ACPI_STATE_C3:
>  	default:
> -	    if (cx_ptr->trans_lat > 1000 ||
> +	    if (cx_ptr->trans_lat > 10000 ||
>  		(cpu_quirks & CPU_QUIRK_NO_C3) != 0) {
>  
>  		ACPI_DEBUG_PRINT((ACPI_DB_INFO,

You should simply remove the check instead of bumping the threshold.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> 	But cx_lowest is not changed:

Why do you expect it to be changed?

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> $ sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/3 C2/245

cx_supported has C2 now though.

> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us
> dev.cpu.1.cx_supported: C1/3 C2/245
> dev.cpu.1.cx_lowest: C1
> dev.cpu.1.cx_usage: 100.00% 0.00% last 798us
> dev.cpu.2.cx_supported: C1/3 C2/245
> dev.cpu.2.cx_lowest: C1
> dev.cpu.2.cx_usage: 100.00% 0.00% last 158us
> dev.cpu.3.cx_supported: C1/3 C2/245
> dev.cpu.3.cx_lowest: C1
> dev.cpu.3.cx_usage: 100.00% 0.00% last 227us


-- 
Andriy Gapon