Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
Ben Hutchings wrote: It is not EeePC-specific. cpufreq modules are loaded by the cpufrequtils package, and it is now loading the wrong modules due to a change in the installation location of the modules. This is bug #636141, fixed in version 007-2. I can confirm this: * Removed the blacklist entry for p4_clockmod * updated to cpufrequtils 007-2 (*) * reboot Now everything works as expected. (*) let's say: reeinstalled with purge because version 007-2 was updated in the last days and I am not shure if it was allready installed when I blacklisted p4_clockmod. After purge-reinstall I needed to upgrade libcpufreq0 by hand to 007-2 (??) because 007-1 was installed after upgrade of cpufrequtils (missing dependency?) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e47a643.7020...@web.de
Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
Am 11.08.2011 23:27, schrieb Jonathan Nieder: Please try blacklisting p4-clockmod or loading acpi-cpufreq first, to see if that helps. The too long transition latency of HW message comes from __cpufreq_governor() in drivers/cpufreq/cpufreq.c and indicates that (policy-cpuinfo.transition_latency policy-governor-max_transition_latency) was true. Which leads to the same conclusion: based on $ git show -s v2.6.30-rc1~678^2 commit 36e8abf3 Author: Dave Jones da...@redhat.com Date: Thu Mar 5 00:16:26 2009 -0500 [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor. The latency of p4-clockmod sucks so hard that scaling on a regular basis with ondemand is a really bad idea. Signed-off-by: Matthew Garrett mj...@srcf.ucam.org Signed-off-by: Dave Jones da...@redhat.com I suspect we really want to be using acpi-cpufreq, not p4-clockmod. So we're closing in. Blacklisting works. I put it into /etc/modprobe.d/eeepc.conf, which belongs to eeepc-acpi-scripts (see patch). Now the question is: is it an EEE-PC only problem or does this happen to other systems too? If it is EEE-PC only: how does it work to get the patch to the eeepc-acpi-scripts team? New Bugreport (sorry, I never had a cross package problem)? --- /etc/modprobe.d/eeepc.conf 2010-11-12 13:08:34.0 +0100 +++ eeepc.conf 2011-08-12 18:01:19.0 +0200 @@ -3,3 +3,4 @@ blacklist snd_pcsp blacklist i2c_i801 options snd_hda_intel power_save=5 +blacklist p4-clockmod [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011 [0.00] Disabled fast string operations [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e2000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7f7a (usable) [0.00] BIOS-e820: 7f7a - 7f7ae000 (ACPI data) [0.00] BIOS-e820: 7f7ae000 - 7f7f (ACPI NVS) [0.00] BIOS-e820: 7f7f - 7f80 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] NX (Execute Disable) protection: active [0.00] DMI present. [0.00] DMI: ASUSTeK Computer INC. 1000H/1000H, BIOS 180303/03/2009 [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x7f7a0 max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-D uncachable [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask 08000 write-back [0.00] 1 base 07F80 mask 0FF80 uncachable [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] found SMP MP-table at [c00ff780] ff780 [0.00] initial memory mapped : 0 - 01a0 [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: -379fe000 [0.00] 00 - 20 page 4k [0.00] 20 - 003780 page 2M [0.00] 003780 - 00379fe000 page 4k [0.00] kernel direct mapping tables up to 379fe000 @ 19fa000-1a0 [0.00] RAMDISK: 378dc000 - 37c66000 [0.00] Allocated new RAMDISK: 37552000 - 378db436 [0.00] Move RAMDISK from 378dc000 - 37c65435 to 37552000 - 378db435 [0.00] ACPI: RSDP 000fb9e0 00014 (v00 ACPIAM) [0.00] ACPI: RSDT 7f7a 0003C (v01 A_M_I_ OEMRSDT 03000903 MSFT 0097) [0.00] ACPI: FACP 7f7a0200 00084 (v02 A_M_I_ OEMFACP 03000903 MSFT 0097) [0.00] ACPI: DSDT 7f7a05b0 05342 (v01 A1028 A1028000 INTL 20051117) [0.00] ACPI: FACS 7f7ae000 00040 [0.00] ACPI: APIC 7f7a0390 0005C (v01 A_M_I_ OEMAPIC 03000903 MSFT 0097) [0.00] ACPI: MCFG 7f7a03f0 0003C (v01 A_M_I_ OEMMCFG 03000903 MSFT 0097) [0.00] ACPI: OEMB 7f7ae040 00061 (v01 A_M_I_ AMI_OEM 03000903 MSFT 0097) [0.00] ACPI: HPET 7f7a5900 00038 (v01 A_M_I_ OEMHPET 03000903
Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
On Fri, Aug 12, 2011 at 06:11:23PM +0200, Thomas Renard wrote: Am 11.08.2011 23:27, schrieb Jonathan Nieder: Please try blacklisting p4-clockmod or loading acpi-cpufreq first, to see if that helps. The too long transition latency of HW message comes from __cpufreq_governor() in drivers/cpufreq/cpufreq.c and indicates that (policy-cpuinfo.transition_latency policy-governor-max_transition_latency) was true. Which leads to the same conclusion: based on $ git show -s v2.6.30-rc1~678^2 commit 36e8abf3 Author: Dave Jones da...@redhat.com Date: Thu Mar 5 00:16:26 2009 -0500 [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor. The latency of p4-clockmod sucks so hard that scaling on a regular basis with ondemand is a really bad idea. Signed-off-by: Matthew Garrett mj...@srcf.ucam.org Signed-off-by: Dave Jones da...@redhat.com I suspect we really want to be using acpi-cpufreq, not p4-clockmod. So we're closing in. Blacklisting works. I put it into /etc/modprobe.d/eeepc.conf, which belongs to eeepc-acpi-scripts (see patch). Now the question is: is it an EEE-PC only problem or does this happen to other systems too? [...] It is not EeePC-specific. cpufreq modules are loaded by the cpufrequtils package, and it is now loading the wrong modules due to a change in the installation location of the modules. This is bug #636141, fixed in version 007-2. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110812164058.gl29...@decadent.org.uk
Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
Thomas Renard wrote: ok.txt: 2.6.39-2-686-pae fail.txt: 3.0.0-1-686-pae Thanks. Looks like the cpufreq driver doesn't get loaded early enough to be included in these logs. From the original report: p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible. ondemand governor failed, too long transition latency of HW, fallback to performance governor p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available cpufreq-nforce2: No nForce2 chipset. powernow: This module only works with AMD K7 CPUs ondemand governor failed, too long transition latency of HW, fallback to performance governor Please try blacklisting p4-clockmod or loading acpi-cpufreq first, to see if that helps. The too long transition latency of HW message comes from __cpufreq_governor() in drivers/cpufreq/cpufreq.c and indicates that (policy-cpuinfo.transition_latency policy-governor-max_transition_latency) was true. Which leads to the same conclusion: based on $ git show -s v2.6.30-rc1~678^2 commit 36e8abf3 Author: Dave Jones da...@redhat.com Date: Thu Mar 5 00:16:26 2009 -0500 [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor. The latency of p4-clockmod sucks so hard that scaling on a regular basis with ondemand is a really bad idea. Signed-off-by: Matthew Garrett mj...@srcf.ucam.org Signed-off-by: Dave Jones da...@redhat.com I suspect we really want to be using acpi-cpufreq, not p4-clockmod. So we're closing in. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110811212746.gc8...@elie.gateway.2wire.net
Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
Package: linux-2.6 Version: 3.0.0-1 Severity: normal EXACT STEPS LEADING TO PROBLEM (done as root): 1. echo ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2. cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor EXPECTED OUTCOME: ondemand ACTUAL OUTCOME: performance Gnome cpufreq applet shows Performance. This also cannot be changed to Ondemand, another frequency cannot be selected neither. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: cpufrequtils 007-2 gnome-applets 2.30.0-4 (for cpufreq-applet) OTHER COMMENTS: cpufreq-applet shows the frequencies: 1.6GHz, 1.4GHz, 1.2GHz, 999MHz, 799MHz, 599MHz, 399MHz, 199MHz but 1.6GHz, 1.33GHz and 799MHz are expected only (like in = 2.39.x) I tried the same with a Lenovo t420i with linux-image-3.0.0-1-amd64 and it works as expected (so cpufreq works). On the EEE-PC it worked fine with 2.6.39-2-i686-pae. -- Package-specific info: ** Version: Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-3.0.0-1-686-pae root=/dev/mapper/bigend-root ro quiet printk.time=0 splash video=i915:modeset=1 ** Tainted: CO (5120) * Module from drivers/staging has been loaded. * Out-of-tree module has been loaded. ** Kernel log: speakup: module is from the staging directory, the quality is unknown, you have been warned. input: Speakup as /devices/virtual/input/input12 initialized device: /dev/synth, node (MAJOR 10, MINOR 25) speakup 3.1.6: initialized synth name on entry is: (null) speakup_soft: module is from the staging directory, the quality is unknown, you have been warned. synth probe initialized device: /dev/softsynth, node (MAJOR 10, MINOR 26) Adding 3903484k swap on /dev/mapper/bigend-swap. Priority:-1 extents:1 across:3903484k EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (sda1): using internal journal EXT3-fs (sda1): mounted filesystem with ordered data mode EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (dm-5): using internal journal EXT3-fs (dm-5): mounted filesystem with ordered data mode EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (dm-3): using internal journal EXT3-fs (dm-3): mounted filesystem with ordered data mode EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (dm-4): using internal journal EXT3-fs (dm-4): mounted filesystem with ordered data mode RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. FS-Cache: Loaded FS-Cache: Netfs 'nfs' registered for caching Installing knfsd (copyright (C) 1996 o...@monad.swb.de). fuse init (API version 7.16) pciehp: Unknown parameter `pciehp_slot_with_bus' NET: Registered protocol family 15 alg: No test for cipher_null (cipher_null-generic) alg: No test for ecb(cipher_null) (ecb-cipher_null) alg: No test for digest_null (digest_null-generic) alg: No test for compress_null (compress_null-generic) padlock_sha: VIA PadLock Hash Engine not detected. NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team DECnet: Routing cache hash table of 1024 buckets, 8Kbytes NET: Registered protocol family 12 ATL1E :03:00.0: irq 44 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready input: ACPI Virtual Keyboard Device as /devices/virtual/input/input13 ADDRCONF(NETDEV_UP): wlan0: link is not ready apm: BIOS not found. Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 composite sync not supported composite sync not supported lp: driver loaded but no devices found ppdev: user-space parallel port driver p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible. ondemand governor failed, too long transition latency of HW, fallback to performance governor p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available cpufreq-nforce2: No nForce2 chipset. powernow: This module only works with AMD K7 CPUs ondemand governor failed, too long transition latency of HW, fallback to performance governor ondemand governor failed, too long transition latency of HW, fallback to performance governor Ebtables v2.0 registered ip_tables: (C) 2000-2006 Netfilter Core Team ip6_tables: (C) 2000-2006 Netfilter Core Team Disabling lock debugging due to kernel taint vboxdrv: Found 2 processor cores. vboxdrv: fAsync=0 offMin=0x1e0 offMax=0x1950 vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. vboxdrv: Successfully loaded version 4.0.8 (interface 0x0018). composite sync not supported composite
Bug#637395: linux-image-3.0.0-1-686-pae: EEE-PC 1000H: cpufreq cannot be set to ondemand
Hi Thomas, Thomas Renard wrote: EXACT STEPS LEADING TO PROBLEM (done as root): 1. echo ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2. cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor EXPECTED OUTCOME: ondemand ACTUAL OUTCOME: performance What is your detected list of available governors? # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors powersave userspace conservative ondemand performance [...] cpufreq-applet shows the frequencies: 1.6GHz, 1.4GHz, 1.2GHz, 999MHz, 799MHz, 599MHz, 399MHz, 199MHz but 1.6GHz, 1.33GHz and 799MHz are expected only (like in = 2.39.x) I tried the same with a Lenovo t420i with linux-image-3.0.0-1-amd64 and it works as expected (so cpufreq works). On the EEE-PC it worked fine with 2.6.39-2-i686-pae. Hmm, weird. Maybe it's using a different cpufreq driver than before. Please attach dmesg output from booting the good and bad kernels, without the speakup and virtualbox drivers if possible. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810214553.gd7...@elie.gateway.2wire.net
