On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote: > on 19/06/2012 19:02 Sean Bruno said the following: > > The first impact of this behavior is to list C3 as C2 in the list of > > Cstates when you retrieve the cx_supported sysctls for the cpus. > > I do not think that this is a real problem. A cosmetic one - most likely. > Yes, most likely. Except that the code seems to think that the index of the Cstates is good enough for a comparison to value. More over, the sysctl's accept a value like "C3" and manipulate that into an index into the Cstate array without checking for the Cstate value.
The impact of this patch corrects this cosmetic display issue. > > The > > second impact is that the power_profile script never drops to a valid > > Cstate when you set the economy_lowest variable in rc.conf. > > Could you please explain if this somehow follows from your first observation > and > how? > If not, could you please share your finding on what exactly causes this to > happen? > > Also, are we talking about a laptop here? Namely, judging from the reference > to > 'economy_lowest', are AC state changes in play? > No, what I was attempting to do was configure a server such that it would attempt to use the C3 state at idle. Since the server gets configured by the power_state scripts via devd, the server is never configured with its global cx_lowest as anything other than C1. e.g: -bash-4.2$ sysctl -a|grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 -bash-4.2$ sysctl -a|grep cx_supported dev.cpu.0.cx_supported: C1/1 C2/96 dev.cpu.1.cx_supported: C1/1 C2/96 It seems that the rc.conf value of performance_cx_lowest="LOW" is what I really want, not economy_cx_lowest. Sean _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
