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:
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
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 ***
Reopening, this appears to be a kernel-level issue, not one with cpuspeed, which is what bug 212802 covers.
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
> 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
Forgot to mention... Please attach dmesg output following a boot with 'cpufreq.debug=7' added to your kernel params.
(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.
Created attachment 147297 [details] dmesg output of my T22
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.
Please upgrade to the latest FC6 kernel and try again. There were some problems with speedstep in certain kernels...
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
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
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.