FS#10505 - New p4_clockmod makes cpufreq-info report erroneous frequencies

Attached to Project: Arch Linux
Opened by Stefan Bergström (Bebo) - Monday, 26 May 2008, 14:17 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 May 2009, 11:41 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Since the upgrade to kernel26 2.6.25.4-1 (from 2.6.24.4-1), cpufreq-info reports very strange scaling frequencies. As reported by /proc/cpuinfo, I have an "Intel(R) Pentium(R) 4 CPU 1.90GHz" cpu (cpu family 15, model 1), and therefore I have to use the p4_clockmod module to do frequency scaling. Previously cpufreq-info reported good numbers, i.e. lowest 475 MHz and highest 1.9 GHz, but when I load p4_clockmod after the upgrade, cpufreq-info reports lowest 3.85 GHz and highest 15.40 GHz, which is obviously completely wrong.

When I start cpufreq manually (/etc/rc.d/cpufreq start (I usually start it backgrounded at boot)), I get the following error message:

Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
for example because of hardware which cannot be set to a specific frequency
or because the userspace governor isn't loaded?

Yes, I am root when I do this, and lsmod reports that cpufreq_ondemand and p4_clockmod are loaded. Oh, come to think of it, the error message probably occur since my settings in /etc/conf.d/cpufreq do not match the erroneous frequencies reported by cpufreq-info (since I'm using the old, correct values).


Additional info:

* kernel 2.6.25.4-1
* cpufrequtils 002-3


Steps to reproduce:

Ah, well, have an old computer, upgrade to kernel 2.6.25.4-1, modprobe p4_clockmod, and run cpufreq-info.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Saturday, 09 May 2009, 11:41 GMT
Reason for closing:  Fixed
Comment by Thomas Bächler (brain0) - Monday, 26 May 2008, 18:56 GMT
Could you give the contents of the following files in /sys/devices/system/cpu/cpu0/cpufreq: cpuinfo_* scaling_available_frequencies, scaling_max_freq, scaling_min_freq

Furthermore, if you simply set a governor without setting min/max frequencies (for example "cpufreq-set -g ondemand" or by commenting the lines in conf.d/cpufreq), does it change the frequency?
Comment by Stefan Bergström (Bebo) - Monday, 26 May 2008, 19:26 GMT
Sure, I just have to reboot the box first. I got some kernel error when I tried to rmmod p4_clockmod. I was going to set a governor without specifiying min/max frequencies, as you asked me, but thought I should start "from scratch". Apparently a mistake. Don't know what I did, but I got this in dmesg:

BUG: unable to handle kernel paging request at f8c4c75c
IP: [<c026f87a>] __cpufreq_governor+0x1a/0x110
*pde = 37acc067 *pte = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: p4_clockmod(+) usblp speedstep_lib freq_table act_police sch_ingress cls_u32 sch_sfq sch_htb nvidia(P) agpgart xt_DSCP iptable_mangle ipt_LOG xt_comment xt_tcpudp xt_mac xt_NFQUEUE xt_state iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 iptable_raw ip_tables x_tables joydev snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss usbhid hid ff_memless parport_pc snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore ppdev ehci_hcd emu10k1_gp lp parport ppp_generic slhc gameport uhci_hcd i2c_i801 i2c_core usbcore sr_mod cdrom shpchp pci_hotplug intel_rng sg dcdbas evdev thermal processor fan button battery ac nf_conntrack_ftp nf_conntrack dm_crypt dm_mod fuse dmfe rtc_cmos rtc_core rtc_lib reiserfs sd_mod pata_acpi ata_piix libata scsi_mod dock [last unloaded: cpufreq_ondemand]

Pid: 7645, comm: modprobe Tainted: P (2.6.25-ARCH #1)
EIP: 0060:[<c026f87a>] EFLAGS: 00210292 CPU: 0
EIP is at __cpufreq_governor+0x1a/0x110
EAX: f7fe4a00 EBX: f75dfdd0 ECX: f8c4c740 EDX: 00000001
ESI: f7fe4a00 EDI: 00000000 EBP: 00000001 ESP: f75dfd7c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 7645, ti=f75de000 task=e1884600 task.ti=f75de000)
Stack: f75dfdd0 00000000 f75dfde8 f75dfdd0 00000000 00000000 f7fe4a00 c0270099
00000004 f7fe4a4c f7fe4a00 00200246 c0271050 f7fe4a4c c03a47bc c1806030
c036fb3c f7fe4a00 c03feb84 c1806028 00000000 00000001 00000000 00000000
Call Trace:
[<c0270099>] __cpufreq_set_policy+0xf9/0x140
[<c0271050>] cpufreq_add_dev+0x420/0x4f0
[<c02712a0>] handle_update+0x0/0x10
[<c025dba7>] sysdev_driver_register+0x67/0xc0
[<c0270142>] cpufreq_register_driver+0x62/0x110
[<f92d603c>] cpufreq_p4_init+0x3c/0x50 [p4_clockmod]
[<c014ec6e>] sys_init_module+0x13e/0x1bd0
[<c0170d50>] arch_get_unmapped_area_topdown+0x0/0x180
[<f8c57250>] cpufreq_frequency_table_verify+0x0/0x124 [freq_table]
[<c01095d0>] sys_mmap2+0xd0/0xe0
[<c01050d8>] sysenter_past_esp+0x6d/0xa5
=======================
Code: e9 2c f1 ed ff 8d b6 00 00 00 00 8d bf 00 00 00 00 83 ec 1c 89 74 24 10 89 c6 89 6c 24 18 89 d5 89 5c 24 0c 89 7c 24 14 8b 48 28 <8b> 41 1c 85 c0 74 09 3b 46 14 0f 82 b8 00 00 00 8b 51 28 85 d2
EIP: [<c026f87a>] __cpufreq_governor+0x1a/0x110 SS:ESP 0068:f75dfd7c
---[ end trace e05b63aa7e3b3970 ]---


Well, I'll post the info you requested after reboot...
Comment by Stefan Bergström (Bebo) - Monday, 26 May 2008, 19:41 GMT
Back in business... Okay, I've just modprobed p4_clockmod and then cpufreq_ondemand. Then I did "cpufreq-set -c 0 -g ondemand", and it seems to be working - the cpu is changing frequencies in a seemingly normal way.

Now, to the /sys stuff.

# cd /sys/devices/system/cpu/cpu0/cpufreq
# cat cpuinfo_*
5775000
15400000
3850000
# cat scaling_available_frequencies
3850000 5775000 7700000 9625000 11550000 13475000 15400000
# cat scaling_max_freq
15400000
# cat scaling_min_freq
3850000


Comment by Stefan Bergström (Bebo) - Thursday, 29 May 2008, 17:30 GMT
I did (kind of) write it in my last comment, but here it is in more explicit terms: after commenting out the min_freq and max_freq lines I had in /etc/conf.d/cpufreq it seems to be working. cpufreq-info still reports insane frequencies, but the scaling seems to be working. I'm using kde's System Guard to monitor the cpu frequency and the frequency is changing in a, uhm, "familiar fashion".
Comment by Thomas Bächler (brain0) - Thursday, 29 May 2008, 17:53 GMT
So this is merely a cosmetic bug. You could search the kernel.org bugzilla or lkml for hints, maybe I'll get to do it. Or maybe locate the git commit that causes the bug.
Comment by Tobias Powalowski (tpowa) - Sunday, 10 August 2008, 21:55 GMT
shouldn't we close this bug?
Comment by Stefan Bergström (Bebo) - Monday, 11 August 2008, 07:35 GMT
Not sure how you want to handle it. cpufreq-info still shows insane values, but it works as long as I don't specify min_freq or max_freq in /etc/conf.d/cpufreq.
Comment by Tobias Powalowski (tpowa) - Sunday, 08 March 2009, 15:56 GMT
status of this?
Comment by Stefan Bergström (Bebo) - Sunday, 08 March 2009, 16:18 GMT
It is still the same:

# cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: p4-clockmod
CPUs which need to switch frequency at the same time: 0
hardware limits: 3.85 GHz - 15.40 GHz
available frequency steps: 3.85 GHz, 5.78 GHz, 7.70 GHz, 9.63 GHz, 11.55 GHz, 13.48 GHz, 15.40 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 3.85 GHz and 15.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 3.85 GHz.

Definitely not correct :) but scaling works.

Loading...