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.
--
Unable to set max_cstate on hardy kernel
https://bugs.launchpad.net/bugs/206864
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
