On 07/02/12 19:57, Sean Bruno wrote:
Author: sbruno Date: Mon Jul 2 16:57:13 2012 New Revision: 238004 URL: http://svn.freebsd.org/changeset/base/238004Log: Cosmetic display change of Cx states via cx_supported sysctl entries. Adjust power_profile script to handle the new world order as well. Some vendors are opting out of a C2 state and only defining C1 & C3. This leads the acpi_cpu display to indicate that the machine supports C1 & C2 which is caused by the (mis)use of the index of the cx_state array as the ACPI_STATE_CX value. e.g. the code was pretending that cx_state[i] would always convert to i by subtracting 1. cx_state[2] == ACPI_STATE_C3 cx_state[1] == ACPI_STATE_C2 cx_state[0] == ACPI_STATE_C1 however, on certain machines this would lead to cx_state[1] == ACPI_STATE_C3 cx_state[0] == ACPI_STATE_C1 This didn't break anything but led to a display of: * dev.cpu.0.cx_supported: C1/1 C2/96 Instead of * dev.cpu.0.cx_supported: C1/1 C3/96 MFC after: 2 weeks
If I remember correctly, ACPI spec directly specifies that there can be several C-states with the same type but with different enter method and exit latency. I have never seen any system with more then 3 C-states yet, but technically I think that is possible. Type field defines enter/exit semantics, respecting cache coherency and other things, so I think there can be more then one state with, for example, C3 semantics. Latest CPUs support states C1, C3 and C5, while ACPI AFAIK defines only three types and it may happen that both C3 and C5 have type-3 semantics.
-- Alexander Motin _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
