Summary: | [2.6.19 regression] cpufreq powernow-k7: can't reach maximum speed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dustin Polke <DuPol> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | VERIFIED UPSTREAM | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=8255 | ||
Whiteboard: | linux-2.6.19-regression | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
configuration generated by genkernel without any changes
Changes to the standard genkernel configuration I made to enable frequencyscaling and ACPI dmesg.log |
Description
Dustin Polke
2007-02-01 09:52:04 UTC
(In reply to comment #0) > To configure the new kernel version, I copied > /etc/kernels/kernel-config-x86-2.6.18-gentoo-r6 to > /etc/kernels/kernel-config-x86-2.6.19-gentoo-r5 and ran genkernel in order to > use the settings of the previous kernel. > used the config of the previous version and ran oldconfig Uh, don't do such things. Reopen if you can reproduce with *fresh* kernel configuration and correct setup. It's totally unsafe to use use oldconfig between 2.6.18 and 2.6.19 (and between different kernels version in general). Genkernel is exactly doing this in general, isn't it? If you install a new kernel source and run 'genkernel all' then genkernel is checking for an existing config and if none for the kernel is found it uses the one stored in /usr/share/genkernel/${arch}/kernel-config-2.6 for 2.6 kernels and envokes 'make oldconfig'. I am using genkernel-3.4.5-r1 and here the first lines of /usr/share/genkernel/x86/kernel-config-2.6 reads: dustin@solaris ~ $ head /usr/share/genkernel/x86/kernel-config-2.6 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17-gentoo-r7 # Mon Oct 23 10:46:05 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y Notice that this config is for kernel version 2.6.17-gentoo-r7, so why shouldn't I start with the config file of a more recent kernel version that is already configured to suit my hardware better (i.e., I disabled unneeded modules, configured bootsplash options, etc.)? I've done now the following, as you requested: 1. I removed all config files for the 2.6.19-r5 from /usr/src/linux 2. I envoked genkernel with 'genkernel --menuconfig all', thus using the standard genkernel config file located in /usr/share/genkernel/x86/kernel-config-2.6 3. I changed the following options: (i) Disabled SMTP (ii) Changed processor type to AthlonXP (iii) Built ACPI components into the kernel (iv) Built Frequency scaling components into the kernel Result: The kernel shows exactly the aforementioned behavior, it runs with reduced speed at 933MHz. I will attach the configuration generated by genkernel without any changes and a diff with the changes I made to compile this kernel. I will test a kernel configuration without using genkernel as well and post the results later. Best regards, Dustin Created attachment 108875 [details]
configuration generated by genkernel without any changes
Created attachment 108877 [details]
Changes to the standard genkernel configuration I made to enable frequencyscaling and ACPI
Just tried kernel without using genkernel. Same result, so it is definitely genkernel unspecific. I can post diff of config file to standard config if needed. Update: With CONFIG_CPU_FREQ unset CPU runs at max frequency. I was able to reproduce this with vanilla source 2.6.19.2 as well. should be fixed in gentoo-sources-2.6.19-r6, reopen if not I tested now gentoo-sources-2.6.19-r6. Unfortunately, the problem still remains the same. solaris cpufreq # cat cpuinfo_max_freq 1266768 solaris cpufreq # cat scaling_governor performance solaris cpufreq # cat scaling_max_freq 950000 solaris cpufreq # cat scaling_cur_freq 933408 solaris cpufreq # cat scaling_available_frequencies 1266768 1000080 933408 800064 666720 solaris cpufreq # echo 800064 > scaling_max_freq solaris cpufreq # cat scaling_cur_freq 800064 solaris cpufreq # echo 1266768 > scaling_max_freq solaris cpufreq # cat scaling_cur_freq 933408 BR, Dustin To change the speed you need to select the userspace governor and write into scaling_cur_freq (rather than max) dustin@solaris ~ $ cd /sys/devices/system/cpu/cpu0/cpufreq/ dustin@solaris /sys/devices/system/cpu/cpu0/cpufreq $ ll total 0 drwxr-xr-x 2 root root 0 2007-03-07 21:16 . drwxr-xr-x 4 root root 0 2007-03-07 22:06 .. -r--r--r-- 1 root root 4096 2007-03-07 21:17 affected_cpus -r-------- 1 root root 4096 2007-03-07 21:17 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 2007-03-07 21:17 cpuinfo_max_freq -r--r--r-- 1 root root 4096 2007-03-07 21:17 cpuinfo_min_freq -r--r--r-- 1 root root 4096 2007-03-07 21:17 scaling_available_frequencies -r--r--r-- 1 root root 4096 2007-03-07 21:17 scaling_available_governors -r--r--r-- 1 root root 4096 2007-03-07 21:17 scaling_cur_freq -r--r--r-- 1 root root 4096 2007-03-07 21:17 scaling_driver -rw-r--r-- 1 root root 4096 2007-03-07 21:07 scaling_governor -rw-r--r-- 1 root root 4096 2007-03-07 21:16 scaling_max_freq -rw-r--r-- 1 root root 4096 2007-03-07 21:17 scaling_min_freq I am afraid that's not possible. Note which files are writable. What can be done is to set a lower and an upper limit for the cpu frequency. Within this range, certain frequencies are selectable which can be read from scaling_available_frequencies. From these frequencies a specific is chosen according to the governor set in scaling_governor. If you set scaling_governor to 'userspace', the cpu frequency is only changed explicitly from userpace, not according to some rules by the kernel itself. You're correct, sorry I read that through too quickly. Next step is to reproduce this on the latest development kernel, currently 2.6.21-rc3? Please enable CONFIG_CPU_FREQ_DEBUG and if the problem still exists, post dmesg output after trying to switch to the maximum frequency. Could you give me a hint, where to find this kernel version in portage? Is it in an overlay? Is it a gentoo kernel or vanilla? Or do I need it to download from somewhere else? They are normally in portage under vanilla-sources but 2.6.21 doesn't seem to be there for some reason. Instead you can just extract this tarball in /usr/src : http://www.us.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc3.tar.bz2 Okay. I compiled the 2.6.21-rc3 kernel. Problem exists here as well. Max available frequency is 1266768: solaris cpufreq # cat scaling_available_frequencies 1266768 1000080 933408 800064 666720 Max frequency threshold cannot be increased above 950000: solaris cpufreq # cat scaling_max_freq 950000 solaris cpufreq # echo 1266768 > scaling_max_freq solaris cpufreq # cat scaling_max_freq 950000 I compiled with 'CONFIG_CPU_FREQ_DEBUG=y', but there is no output in the logs, neither in dmesg nor message... Any idea where to look? Strange thing is: If I set governor to 'performance', I achieve max freq 950MHz. If I set governor to 'userspace', I achieve max freq 933MHz. Try adding cpufreq.debug=3 to your kernel parameters in your bootloader config Okay. Now I found something in the log. I attach full dmesg.log. I think the relevant part is around line 220. powernow: Minimum speed 666 MHz. Maximum speed 1266 MHz. freq-table: setting show_table for cpu 0 to cec867e0 freq-table: table entry 0: 1266768 kHz, 3085 index freq-table: table entry 1: 1000080 kHz, 3593 index freq-table: table entry 2: 933408 kHz, 3592 index freq-table: table entry 3: 800064 kHz, 4358 index freq-table: table entry 4: 666720 kHz, 4868 index cpufreq-core: setting new policy for CPU 0: 666720 - 1266768 kHz freq-table: request for verification of policy (666720 - 1266768 kHz) for cpu 0 freq-table: verification lead to (666720 - 1266768 kHz) for cpu 0 freq-table: request for verification of policy (666720 - 950000 kHz) for cpu 0 freq-table: verification lead to (666720 - 950000 kHz) for cpu 0 cpufreq-core: new min and max freqs are 666720 - 950000 kHz It seems that after detecting the correct max speed and setting the correct policy, the max speed is reduced and again validated, which leads to an incorrect max speed. Created attachment 112612 [details]
dmesg.log
Thanks for the logs, they should help. Please now file this bug at http://bugzilla.kernel.org if it is not there already. Attach those logs. Mention that you are using powernow-k7 and that it is a 2.6.19 regression still present in 2.6.21-rc. Post the new bug URL here when done. Filed upstream bug and added URL. Thanks. If there is no response after a couple of days, if you are really keen, you could attempt to do a bisection to find the patch which introduced this bug. It will take some time but is an interesting process. See http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ @Daniel: I tracked down the regression with git (s. upstream bug) and there seems to be already a patch available: http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04484.html Maybe it can be added to the affected kernels until upstream implements a solution? As you stated in the upstream bug, the patch does not solve the issue :( Is it possible to look into the commit using git? Maybe I can experiment a bit to find the issue... Yes, here's that commit in patch form: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=0916bd3ebb7cefdd0f432e8491abe24f4b5a101e closing until upstream bug is solved Increasing severity to major because kernel version 2.6.18-r6 has been removed from portage. One has to use now either very old kernel (2.6.16-r13 last stable before regression) or turn off frequency scaling. I do understand that Gentoo has no direct influence on solving this issue, but it appears to me that upstream is not working on this. There is no response on several posts commited by me :( This is fixed in recent kernel releases |