Subject : max_cstate VMware regression
Submitter : Mark Lord <email@example.com>
References : http://lkml.org/lkml/2008/1/2/328
Handled-By : "Pallipadi, Venkatesh" <firstname.lastname@example.org>
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