Date: Sun, 12 Sep 2010 11:12:20 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua>, Norikatsu Shigemura <nork@FreeBSD.org>, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 Message-ID: <4C8C8B64.8020907@FreeBSD.org> In-Reply-To: <mailpost.1284277196.1767764.83548.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> References: <4C8BCAC5.5050008@root.org> <mailpost.1284277196.1767764.83548.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > on 11/09/2010 21:30 Nate Lawson said the following: >>> PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 >>> 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 which states are available, these limitations may not apply there. I would try to comment these checks in acpi_cpu_cx_cst() and look what happen. At least I haven't found in ACPI 3.0 specification any latency limits applied to _CST. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8C8B64.8020907>