Scaling reports incorrect number of steps.

xpromisex · 06-29-2006, 04:14 PM

Hey guys - wondering if anyone can shed some light on this:

Since Arch updated to the 2.6.16.1 kernel (or so...), I've been having some problems with CPU scaling. I've redone this with the new 2.6.17 kernel, but none of this is working correctly. Basically, the number of steps reported by everything I know how to read reports the incorrect number of frequency scaling steps. To set up the scaling I did this:

modprobe p4_clockmod (I have a P4)
modprobe cpufreq_userspace
powernowd

Now powernowd reports the incorrect number of steps. Here is the output:

Code:

powernowd: PowerNow Daemon v0.97, (c) 2003-2006 John Clemens
powernowd: Found 1 scalable unit:  -- 1 'CPU' per scalable unit
powernowd:   cpu0: 2099Mhz - 2799Mhz (3 steps)

Previous to the kernel upgrade (to 2.6.16) I had EIGHT steps, not three, and I know for a fact that it was scaling down to the minimum 389MHz as opposed to the 2.10 GHz it's hitting now.

Here are the other signs that something is seriously wrong:

Code:

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2099947 2449938 2799930

Code:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
2099947

I don't understand. I have looked high and low, but I may be looking for the wrong things, as my searches have reported nothing at all useful.

Thank you in advance. If you need ANY more information, please just ask me - I will be more than happy to provide it. I would love to get this fixed.

Fluxx · 06-30-2006, 02:24 AM

The same behaviour here with a P4 in a Medion notebook. Only three available scaling frequencies with the Slackware-current kernel (2.6.16.22) and p4_clockmod. Nothing to change in /sys/devices/system/CPU/... --- I tried everything to have more steps, but without success.

Fluxx.

xpromisex · 06-30-2006, 09:43 AM

I'm glad to hear that I'm not the only one with the problem. But now - to fix it....

paolosca · 07-29-2006, 11:57 PM

Hi there,

I have a similar problem with Fedora 4 and a HP Omnibook xe4500 (P4 mobile 1.7), since I upgraded the kernel to 2.6.17 the CPU scaling is all wrong.

The CPU speed at boot is correct (1.7GHz) but since cpuinfo_max_freq is incorrectly set to 666000 instead of 1700000 Gnome's CPU frequency monitor reports the CPU as running at 255%.

The steps available in scaling_available_frequencies are now just 2 (666000 and 642000) while before there were many more.

It seems, in my case, that speedstep-smi driver is compiled in the new kernel and it's loaded by default, preventing me from loading p4-clockmod:

Quote:

# /sbin/modprobe p4_clockmod
FATAL: Error inserting p4_clockmod (/lib/modules/2.6.17-1.2143_FC4/kernel/arch/i386/kernel/cpu/cpufreq/p4-clockmod.ko): Device or resource busy

Cpuspeed relies on scaling_available_frequencies so it keeps setting the CPU at 666MHz. If I manually edit scaling_setspeed I can manage to set the speed to other frequencies (1200000 and 1700000).

Does anyone know how to disable speedstep-smi in order to load p4_clockmod or alternatively how to set the values in scaling_available_frequencies, cpuinfo_max_freq and cpuinfo_min_freq?

Thanks.

xpromisex · 07-30-2006, 11:31 PM

First of all, Please don't 'Hijack' threads. (Asking questions in someone else's thread to your own ends)

Second off, it's Okay in this instance....I suppose.

Really, all I believe that you would have to do is to recompile the kernel, using the old config as a base. (If you need help, you can search the forums on here or look through Google. Both should have good walkthroughs.)

paolosca · 07-31-2006, 07:15 AM

Sorry for hijacking, as you know there is little information about this problem and I thought any answer could be useful to all of us.

I don't really fancy the idea of building my own kernel. Given the rate at which Fedora updates the kernel I'm afraid I will end up compiling once a week or so.

For your information I tried all the following:

- Updated the BIOS (some fixed the problem in this way);
- Disabled ACPI (In some case it was related);
- Updated the kernel 3 times (the last one being a test version);
- I tried to manually overwrite cpuinfo_max_freq, cpuinfo_min_freq and scaling_available_frequencies files (I knew it wouldn't work

)
- Attempted to load p4-clockmod as the first module rebuilding initrd with mkinitrd;

None of the above worked for me.

As in your case I also had 8 steps (from 212 to 1700) before upgrading the kernel to 2.6.17.

You may try with other drivers as speedstep-acpi, speedstep-centrino, etc. On other forums I read of people using speedstep-centrino on a P4 mobile without problems.

Regards,

Paolo.

xpromisex · 08-01-2006, 10:16 AM

Paolo - No Big Deal. I try not to complain about it, but alot of other members will chew someone out for stealing threads.

I'm not sure what my problem is. I have repeated this on a newer model desktop that I just put together - with a similar chip (The first computer to have the problem is a pentium 4/M 2.8 GHz. The second is a Pentium Celeron 3.06 GHz.) and the second works flawlessly. (The Celeron also has Eight frequency scaling steps, so that isn't the problem.) Basically, I have really gotten nowhere in the past few months that I have had this problem, and I don't know why.

I really want to know if anyone is having this problem (Or similar problems) and whether or not someone is working on a fix for it.

EDIT: Is this only happening in Laptops???

paolosca · 08-01-2006, 10:37 PM

At the end I compiled my own kernel removing all the built-in cpu drivers and I compiled them as loadable modules. All the process is quite straight forward in Fedora and it took about 2 hours (which is far less than the time I spent googling around for a solution) and now my kernel is also optimized for my processor.

Now I can load again p4-clockmod and I have my 8 steps and right frequencies back.

By the way, are you sure you are using p4-clockmod? What does /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver says?

It took me a while to notice the kernel was loading speedstep-smi instead of p4-clockmod. Given that a few people complained about this problem I believe it may be a problem of a some processors that either don't work properly with speedstep-smi or they trick this driver into believing that they are something else.

Have a nice day,

Paolo.