Bug 9683

Summary: max_cstate VMware regression
Product: ACPI Reporter: Rafael J. Wysocki (rjw)
Component: Power-ProcessorAssignee: Venkatesh Pallipadi (venki)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, bunk, venki
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.24-rc Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 9243    
Attachments: patch vs 2.6.24-rc6 to restore sysfs access to max_cstate

Description Rafael J. Wysocki 2008-01-03 14:54:33 UTC 
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>
Comment 1 Adrian Bunk 2008-01-03 16:08:20 UTC 
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?
Comment 2 Len Brown 2008-01-07 11:25:42 UTC 
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)
Comment 3 Len Brown 2008-01-07 11:29:10 UTC 
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.
Comment 4 Len Brown 2008-01-13 23:08:19 UTC 
patch in comment #3
shipped in linux 2.6.24-rc7-git5

closed.