Comment 18 for bug 206864

Revision history for this message
tvrusso (russo-bogodyn) wrote : Re: Unable to set max_cstate on hardy kernel

Since Marcel states the /sys/module/processor/parameters/max_cstate doesn't exist in the alpha5 version of the kernel in Intrepid, the issue is apparently not resolved,and the only way to get max_cstate set is to set it at boot time with modprobe.d options, just as it was before.

Setting probe options at boot time is not an adequate substitute for the on-the-fly manipulation provided by the max_cstate mechanism. My understanding is that there is a kernel parameter that can be enabled to allow max_cstate to work again, but that it is off by default.

Building the generic kernel with this option enabled would fix the problem, unless of course they've completely removed that option.

For me, I only need max_cstate changed when running vmware on a Pentium-M laptop, because vmware and the higher cstates don't play well together. Rebooting with new options just to run vmware isn't a reasonable "solution." At the moment, the only thing I can do to get vmware to work in a reasonable manner is to run an infinite loop junk process in another shell to keep the system from thinking it can go into higher cstates ("while [ true ] ; do echo foo > /dev/null ; done" does the trick, but at some expense).

The old way of putting "1" into /sys/module/preprocessor/parameters/max_cstate while vmware is running is an annoyance that is clearly a fault of vmware, but it worked better than the infinite loop does.