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

Andriy Gapon wrote:
> on 12/09/2010 18:22 Andriy Gapon said the following:
>> Observations are correct, but incomplete; the conclusions are wrong.
>> At the end of the boot there are message like this one:
>> PROCESSOR-0722 [402244] cpu_cx_cst            : acpi_cpu0: Got C2 - 245 latency
>> This is a result of re-evaluation of _CST because of a notification from ACPI.
> 
> But still, as you suggest, a patch like the following should be tested and
> committed:
> 
> --- a/sys/dev/acpica/acpi_cpu.c
> +++ b/sys/dev/acpica/acpi_cpu.c
> _at__at_ -828,7 +828,8 _at__at_ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
>      sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported),
>  	SBUF_FIXEDLEN);
>      for (i = 0; i < sc->cpu_cx_count; i++) {
> -	sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat);
> +	sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
> +	    sc->cpu_cx_states[i].trans_lat);
>  	if (sc->cpu_cx_states[i].type < ACPI_STATE_C3)
>  	    sc->cpu_non_c3 = i;
>      }

I am not sure this patch is complete:
1) AFAIR I have seen somewhere example where system had several C-states
with different latency, but the same type - C3. Type only means
enter/exit semantics, and there could be several states with the same
semantics. Not sire how to properly them in this case. May be existing
approach was not so bad. It is ACPI C-states, not CPU C-states, they are
not same. May be we should just mention type somewhere in addition.
2) This change makes heavily understandable values of cx_lowest.
3) If touch cx_lowest, I would prefer to see there possibility to set it
to some abstract C6 or whatever, allowing system automatically choose
state it has available at the moment.

-- 
Alexander Motin