Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 231783 - cpuspeed startup script should try acpi-cpufreq even if est flag not present
Summary: cpuspeed startup script should try acpi-cpufreq even if est flag not present
Alias: None
Product: Fedora
Classification: Fedora
Component: cpuspeed
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-11 19:16 UTC by David Baron
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-04 00:29:59 UTC
Type: ---

Attachments (Terms of Use)

Description David Baron 2007-03-11 19:16:57 UTC
Description of problem:  I have a Mobile Intel Pentium 4, 3.06 GHz laptop, which
has the interesting characteristic that its default CPU speed is half-speed. 
Therefore it's essential to have CPU scaling working to get the full power out
of the CPU -- otherwise it just stays at half speed all the time.

The CPU does not report the est status register, so /etc/init.d/cpuspeed does
not try loading the acpi-cpufreq driver in the default case.  Putting
DRIVER='acpi-cpufreq' in /etc/sysconfig/cpuspeed makes scaling work, but it
really ought to work out of the box so people with this configuration don't end
up wasting half the speed of their CPU unless they know how to tweak their

I'd note that acpi_cpufreq_cpu_init does check for the est flag in one of two
cases, but it functions without the est flag in the other case, which is
presumably what's happening on my machine.

Version-Release number of selected component (if applicable):
$ rpm -q --queryformat="%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" cpuspeed kernel

How reproducible: always

Steps to Reproduce:
1. cat /proc/cpuinfo
2. md5sum /dev/zero &
3. cat /proc/cpuinfo
4. kill %1
Actual results: CPU running at 1596 MHz in both cases

Expected results: CPU running at 3059 MHz in the second case

Additional info:

$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Genuine Intel(R) CPU 3.06GHz
stepping        : 9
cpu MHz         : 1596.000
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up cid xtpr
bogomips        : 3192.41
clflush size    : 64

Comment 1 David Baron 2007-03-11 19:21:29 UTC
Er, two more things I forgot to mention:

This is somewhat similar to bug 219921.

The source code I was referring to is

Comment 2 Jarod Wilson 2007-03-12 14:12:19 UTC
You're correct, we should try loading acpi-cpufreq even if the system doesn't
report est. The functionality provided by umpteen different speedstep-* drivers,
some of which run on non-est machines iirc, has all recently been merged into
acpi-cpufreq, and I see the case you're referring to in the code. (not to
mention that ia64 doesn't report est and new ia64 systems coming down the road
can do freq scaling via acpi-cpufreq)...

I'll drop the est flag check in the next cpuspeed.

Comment 3 Jarod Wilson 2007-03-12 17:31:20 UTC
Just pushed a new rawhide build that drops the est flag check. I want to let the
change soak there for a while before pushing it for FC6 as well, just in case
there are any negative side-effects trying to load acpi-cpufreq on unsupported
machines (shouldn't be, but...).

Comment 4 Bug Zapper 2008-04-03 23:39:34 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 5 Jarod Wilson 2008-04-04 00:29:59 UTC
Long since fixed...

Note You need to log in before you can comment on or make changes to this bug.