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

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);
_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,
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	But cx_lowest is not changed:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_supported: C1/3 C2/245
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Please see also attached dmesg.txt.

	Thank you.

-- 
Norikatsu Shigemura <nork_at_FreeBSD.org>