Subject : max_cstate VMware regression Submitter : Mark Lord <lkml@rtr.ca> References : http://lkml.org/lkml/2008/1/2/328 Handled-By : "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Where is the actual bug that requires max_cstate located? - in the kernel? - in the userspace application? - in some non-GPL blob loaded into the kernel? Is there any way to reproduce the issue with a non-tainted kernel?
The real bug is that VMware loads slowly without "max_cstate=1". Nobody knows why this workaround is needed, or why it works. Worse, it doesn't always work, as Mark reports that it doesn't make the real bug go away on single core systems. But this but report isn't about the real bug. This bug report is the "regression" that this modparam can no longer be changed at run-time by echoing into sysfs in 2.6.24-rc. (note that you can still invoke this workaround at boot time and module load time)
Created attachment 14330 [details] patch vs 2.6.24-rc6 to restore sysfs access to max_cstate This patch from Mark/Venki addresses sysfs issue at hand. I'd like to see a new bug report that is filed against the real problem that this episode has exposed -- that C-states sometimes have a dramatic effect on how fast VMware loads.
patch in comment #3 shipped in linux 2.6.24-rc7-git5 closed.