Bug 7463
Summary: | CPU frequency scaling(cpufreq) does not work. speedstep-centrino.c problem | ||
---|---|---|---|
Product: | Power Management | Reporter: | Oldrich Plchot (olda.plchot) |
Component: | cpufreq | Assignee: | cpufreq (cpufreq) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | akpm, bugzilla.kernel.org, jeremy, lenb, protasnb, renatoyamane, shaohua.li, ubuntu, venki |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.18.1 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Oldrich Plchot
2006-11-05 13:33:24 UTC
Jeremy, could you please take a look, see if we can get a patch out of this? Hello again, I think it could be ACPI related problem. Maybe some types of BIOS does not provide that frequency tables in a correct way. I heard some people resolved this problem by upgrading BIOS. Maybe we could chceck if we obtained correct values and if not, we could try values coded in the speedstep-centrino.c, which are based on the Intel datasheets. Olda Yes. Please check whether there are any BIOS updates (and also any special options inside you BIOS to enable this feature). And try having both acpi-cpufreq and speedstep-centrino driver (preferably with latest base kernel). Sometimes BIOS exports information in such a way that acpi-cpufreq driver can be enabled on Centrino platforms. Thanks, Venki bugme-daemon@bugzilla.kernel.org wrote: > Jeremy, could you please take a look, see if we can get a patch out of this? > As others said, this is something that should be fixable by getting info from ACPI rather than patching the driver. J Any updates on this problem? Does the CPU frequency still need to be hardcoded? Adding ACPI contacts. Hello, latest beta version of bios for my notebook resolved this issue, but I heard that not all manufacturers provide bios updates for older models and the problem still exists. If the bios is unable to pass correct values to kernel the only way is to use the patched speedstep-centrino.c with hard-coded values. That is a bad situation for the owners of the older notebooks where this problem exists. I wonder how FreeBSD does this, because when I tried my notebook with old BIOS with FreeBSD 7.0 Current it worked fine, maybe they are not relying on ACPI. If we rely only on ACPI and BIOS we have a problem as we are not able to push all vendors to release correct BIOS update:-( But the situeation improved at least for me... I am the lucky one. Best regards, Olda Then I guess we can ask Intel developers if it is possible to have "generic" table that fits one and for all and not necessarily does scaling optimal way but at least gives reasonable set of values. Any recommendations? Thanks. speedstep-centrino module don't work to me too! Can someone provide a cpufreq_frequency_table to my Pentium M 750 (1.86Ghz)? Datasheet available in: <http://download.intel.com/design/mobile/datashts/30526202.pdf> Best regards, Renato Subject: Re: CPU frequency scaling(cpufreq) does not work. speedstep-centrino.c problem bugme-daemon@bugzilla.kernel.org wrote: > Can someone provide a cpufreq_frequency_table to my Pentium M 750 (1.86Ghz)? > Datasheet available in: > <http://download.intel.com/design/mobile/datashts/30526202.pdf> > The trouble with newer Pentium M's (Dothan) is that they have 4 voltage grades (similar to different speed grades), and you need 4 tables to match. The tricky part is that it doesn't appear to be possible to tell what voltage grade your chip is without digging the table out of ACPI anyway. J Hi Len, can you help us? Our problem is that speedstep-centrino don't work with some Pentium M models, as all models available in this documents below: <http://download.intel.com/design/mobile/datashts/30526202.pdf> <http://download.intel.com/design/mobile/datashts/30218908.pdf> To this models is necessary use acpi_cpufreq, installing powersaved and configure parameter CPUFREQD_MODULE="acpi_cpufreq" (/etc/powersave/cpufreq) Currently, my .config in 2.6.21.1 is to my machine with Pentium M 750 Model (1.86Ghz) is: # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y Best regards, Renato acpi-cpufreq works on the system at hand, and so I advocate that this sighting be closed as WILL_NOT_FIX. Nobody is maintaining speedstep-centrino, and I do not advocate that it be enhanced. I have laptop (MAxdata 8100X) with dothan 1.6GHz and no luck - both speedstep-centrino and acpi-cpufreq (kernel 2.6.22 from gutsy). So there are STILL some old laptops with are in need for hardcoded freq tables (everyting was working on old ubuntu kernels with were pathed this way). Please don't ignore old machines... I asked davej about this and he said: The only safe way to use scaling on 'dothan' cores is with ACPI. We just have no way to tell which of the four sets of voltages is in use. People keep proposing patches to hardcode a set of tables for them which "works for them", but could do *anything* on someone elses system. Even if we added it as a CONFIG option, I'm worried that people will turn it on not understanding the consequences and either plague us with crappy bug reports of flaky kernels (or worse). (And you guarantee some distros will turn it on to "make hardware 'just work'") All-round crappy situation really, we're between a rock and a hard place, and ACPI is the best hope we've got. *** Bug 7607 has been marked as a duplicate of this bug. *** Oldrich and other reporters, were you able to use acpi_cpufreq? Has the problem been resolved for you? Thanks. This work fine to me: grep -i acpi ../linux-2.6.23.16/.config # Power management options (ACPI, APM) CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=m CONFIG_ACPI_BAY=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_PNPACPI=y CONFIG_THINKPAD_ACPI=m # CONFIG_THINKPAD_ACPI_DEBUG is not set CONFIG_THINKPAD_ACPI_BAY=y CONFIG_BLK_DEV_IDEACPI=y CONFIG_ATA_ACPI=y Regards, Renato S. Yamane Hello, since i have upgraded my notebook with a latest beta of available bios, everything started to work. From then, also acpi_cpufreq works. I think we would need info from someone whos bios still does not handle the CPU correctly. I am sorry, I can not post more relevant results. Thanks a lot, Oldrich Plchot Can't we close this bug then, if upgrading the BIOS fixes this issue? I don't have any problem with Kernel available in Debian Lenny or other release >=2.6.23.16 # hwinfo --bios 01: None 00.0: 10105 BIOS [Created at bios.174] Unique ID: rdCR.lZF+r4EgHp4 Hardware Class: bios BIOS Keyboard LED Status: Scroll Lock: off Num Lock: off Caps Lock: off Base Memory: 639 kB PnP BIOS: SST2400 BIOS: extended read supported BIOS32 Service Directory Entry: 0xea7c0 SMBIOS Version: 2.3 BIOS Info: #0 Vendor: "TOSHIBA" Version: "Version 2.00" Date: "02/07/2006" Start Address: 0xeb000 ROM Size: 512 kB Features: 0x02b3000000007f1a9f90 ISA supported PCI supported PCMCIA supported PnP supported APM supported BIOS flashable BIOS shadowing allowed CD boot supported BIOS ROM socketed EDD spec supported 1.2MB NEC 9800 Japanese Floppy supported 720kB Floppy supported 2.88MB Floppy supported Print Screen supported 8042 Keyboard Services supported Serial Services supported Printer Services supported CGA/Mono Video supported ACPI supported USB Legacy supported LS-120 boot supported ATAPI ZIP boot supported Smart Battery supported F12 Network boot supported In my case, this bug can be closed. Best regards, Renato S. Yamane |