Description of problem:
$subject. It should be =y (as it is for x86).
Version-Release number of selected component (if applicable):
I'm closing this bug as we've agreed for GA to disable the speedstep
centrino driver. We'll use 138952, to track the progress of this
feature in U1, since it has all of the history already.
Duh, right, I agree it should be disabled, not =y, my mistake.
Can we leave this open, mark MODIFIED when the change is committed to CVS?
right, two changes needed to be made from rc1:
1) disable CENTRINO on x86_64, captured now in this bug
2) enable ACPI_CPUFREQ=y on x86_64, per bz #142152
This should now be committed, but i'll let Dave move it to modified.
been thinking about this situation. I think building ACPI in is going
to break every other cpufreq driver, as cpufreq only supports 1 driver
right now, and acpi is going to claim success on a majority of
hardware, including hardware that for eg, may be better suited with
powernow drivers or such.
This might be fixable just by adjusting the link order.
The acpi driver will load after everything except p4_clockmod as it is
currently built based on load order, assuming all the other drivers
are built-in, and it looks like it's "first one that works wins".
yes, that'll teach me to check the code before making comments. :-)
p4-clockmod isn't too useful anyway, so the current status seems fine.
2.6.9-1.871_EL has the following:
kernel-2.6.9-i686.config:# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
kernel-2.6.9-i686-hugemem.config:# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
kernel-2.6.9-i686-smp.config:# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
kernel-2.6.9-x86_64.config:# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
kernel-2.6.9-x86_64-smp.config:# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
So, that's what's mentioned in comment 5 and since this kernel is included in
our latest trees, closing out.