Bug 221070 - speedstep on IBM T22 doesn't work
speedstep on IBM T22 doesn't work
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: cpuspeed (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-31 19:21 EST by Joachim Kunze
Modified: 2008-05-06 13:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 13:16:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output of my T22 (17.49 KB, text/plain)
2007-02-04 06:07 EST, Joachim Kunze
no flags Details

  None (edit)
Description Joachim Kunze 2006-12-31 19:21:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de-DE; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-1.fc6 Firefox/1.5.0.9 pango-text

Description of problem:
After migrating a T22 Laptop to fc6 (from windows actually), speedstep doesn't work at all - the cpu speed is fixed accordingly to what has been choosen in the BIOS.
On the bootscreen when the cpuspeed-initscript is started you'll just receive the message "device not found"
I've tested this on a second T22 - the same issue. I've tested this also on a T23 (also PIII coppermine-based) and there it works perfectly fine.  Tested on an X20 and T30 - it works perfectly fine. Just the T22 seems to be affected.

Version-Release number of selected component (if applicable):
kernel-2.6.18-1.2868

How reproducible:
Always


Steps to Reproduce:
Install fc6 on an IBM T22 and perform a
#cat /proc/cpuinfo
With BIOS-setting "automatic" the cpu speed stays at ~700 MHz and with the "fixed max" setting at 900 MHz (max is for these two laptops 900 MHz)

Actual Results:


Expected Results:


Additional info:
Comment 1 Joachim Kunze 2007-01-01 03:20:33 EST
And here're some additional bootup messages concerning ACPI:
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Core revision 20060707
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: setting ELCR to 0200 (from 0800)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: bus type pci registered
Jan  1 08:28:03 saintpoldeleon kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd
94f, last bus=7
Jan  1 08:28:03 saintpoldeleon kernel: PCI: Using configuration type 1
Jan  1 08:28:03 saintpoldeleon kernel: Setting up standard PCI resources
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Interpreter enabled
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Using PIC for interrupt routing
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4
 5 6 7 9 10 *11)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4
 5 6 7 9 10 *11)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4
 5 6 7 9 10 *11)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4
 5 6 7 9 10 *11)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Assume root bridge [\_SB_.PCI0] bus
 is 0
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Power Resource [PSER] (on)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Power Resource [PSIO] (on)
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: Embedded Controller [EC] (gpe 9) in
terrupt mode.
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKA] enabled a
t IRQ 11
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Li
nk [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKB] enabled a
t IRQ 11
Jan  1 08:28:03 saintpoldeleon kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Li
nk [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan  1 08:28:03 saintpoldeleon kernel: IBM machine detected. Enabling interrupts
 during APM calls.
Jan  1 08:28:03 saintpoldeleon kernel: apm: BIOS version 1.2 Flags 0x03 (Driver 
version 1.16ac)
Jan  1 08:28:03 saintpoldeleon kernel: apm: overridden by ACPI.
Jan  1 08:28:04 saintpoldeleon kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C
3[C3])
Jan  1 08:28:04 saintpoldeleon kernel: ACPI: Processor [CPU] (supports 8 throttl
ing states)
Jan  1 08:28:04 saintpoldeleon kernel: ACPI: Thermal Zone [THM0] (33 C)
Jan  1 08:28:04 saintpoldeleon kernel: ACPI: PCI Interrupt Link [LNKC] enabled a
t IRQ 11
Jan  1 08:28:04 saintpoldeleon kernel: ACPI: PCI Interrupt 0000:00:03.1[A] -> Li
nk [LNKC] -> GSI 11 (level, low) -> IRQ 11

... and the detailed message:

FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.18-1.2868.fc6/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
No such device
Comment 2 Jarod Wilson 2007-01-02 16:05:49 EST
Please double-check that you've got an i686 kernel and not an i586 one, per
http://fedoraproject.org/wiki/Bugs/FC6Common and update to the latest cpuspeed.

*** This bug has been marked as a duplicate of 212802 ***
Comment 3 Jarod Wilson 2007-01-15 10:43:22 EST
Reopening, this appears to be a kernel-level issue, not one with cpuspeed, which
is what bug 212802 covers.
Comment 4 Joachim Kunze 2007-01-16 08:03:05 EST
I'm not sure it it still applies, but I've read some threads about missing
modules like here:
http://www.thinkwiki.org/wiki/Talk:How_to_get_SpeedStep_working_on_Coppermine-piix4-smi_based_ThinkPads

or here:
http://bugzilla.kernel.org/show_bug.cgi?id=5553

Anyway - speedstep-smi is no longer part of the fedora kernel - right ?

Thanks,

Jo
Comment 5 Jarod Wilson 2007-01-16 13:25:45 EST
> Anyway - speedstep-smi is no longer part of the fedora kernel - right ?

It is indeed part of the fedora kernel, though we build it in, rather than
making it a module.

I took a look at the kernel.org bugzilla, as well as that wiki page... We picked
up the speedstep-smi fix long ago by simply tracking upstream, and we've also
got CONFIG_CPU_FREQ_DEBUG enabled. The only thing we don't have that might
possibly be relevant in your situation is CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
enabled (though the wiki suggests this is more for the t20, not the t22). I see
there's an entry in the wiki page for a t22 owner that can only get 700 or 900
-- is that you, or someone else?

You might try building a kernel w/CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK on, and
see what you can see booting that kernel with it enabled.

Also, you mentioned your cpu never scales up w/the ondemand governor... What
about with the userspace governor and the cpuspeed daemon running?

----8<----
$ grep -E '(SPEEDSTEP|CPU_FREQ_DEBUG)' config-x86-generic 
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_SPEEDSTEP_LIB=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
Comment 6 Jarod Wilson 2007-01-16 13:29:44 EST
Forgot to mention... Please attach dmesg output following a boot with
'cpufreq.debug=7' added to your kernel params.
Comment 7 Joachim Kunze 2007-02-04 05:53:54 EST
(In reply to comment #5)
> there's an entry in the wiki page for a t22 owner that can only get 700 or 900
> -- is that you, or someone else?
That's somebody else - I've just picked the info from there.


> You might try building a kernel w/CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK on, and
> see what you can see booting that kernel with it enabled.
Still the same issues - using the rebuild kernel doesn't change the behaviour -
unfortunately ...

> Also, you mentioned your cpu never scales up w/the ondemand governor... What
> about with the userspace governor and the cpuspeed daemon running?
Which userspace governor you're refering to ?

> ----8<----
> $ grep -E '(SPEEDSTEP|CPU_FREQ_DEBUG)' config-x86-generic 
> CONFIG_CPU_FREQ_DEBUG=y
> CONFIG_X86_SPEEDSTEP_CENTRINO=y
> CONFIG_X86_SPEEDSTEP_ICH=y
> CONFIG_X86_SPEEDSTEP_SMI=y
> CONFIG_X86_SPEEDSTEP_LIB=y
> CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
> CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
> # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
These are the parameters I've used.
Comment 8 Joachim Kunze 2007-02-04 06:07:48 EST
Created attachment 147297 [details]
dmesg output of my T22
Comment 9 Jarod Wilson 2007-02-04 15:34:01 EST
This bit from your dmesg output...

speedstep-lib: x86: 6, model: 8
speedstep-lib: Coppermine: MSR_IA32_EBL_CR_POWERON is 0x4c080020, 0x0
speedstep-lib: Coppermine: MSR_IA32_PLATFORM ID is 0x0, 0x570000
speedstep-smi: No supported Intel CPU detected.

...is not so good. You're positive that you've got the latest and greatest BIOS for this system? Based on 
other reports, speedstep-smi should be finding a supported cpu w/2.6.16.1 and later kernels, unless 
there was some sort of regression...

As for "userspace governor", set GOVERNOR=userspace in the config file, and cpuspeed will attempt to 
use the userspace governor and launch the cpuspeed daemon, but given that we're not finding a 
speedstep supported CPU of any kind, I don't think its gonna work either.
Comment 10 Chuck Ebbert 2007-02-05 12:05:51 EST
Please upgrade to the latest FC6 kernel and try again.

There were some problems with speedstep in certain kernels...

Comment 11 Joachim Kunze 2007-02-05 15:31:43 EST
Both laptops are on the same BIOS-Level (1.12/1.06-combination , the latest,
greatest ...)
Even with GOVERNOR=userspace the scaling isn't working. But funny enough it
starts with 900 MHz now instead of 700MHz like before without the entry

The kernel is still the 2.6.19-1.2895
Comment 12 Bug Zapper 2008-04-04 01:25:38 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

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

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 13 Bug Zapper 2008-05-06 13:16:26 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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