BTW, the system bios is up to date (A13)

It's working now, after yum update.
I had already updated the kernel, so I'm not sure what fixed it.

Thanks,
Barry

Still having problems after software suspend (suspend-to-RAM)...
cpuspeed dies and won't restart.

Thanks,
Barry

Sorry to keep posting, but after reboot, cpuspeed is still failing to start.
It says Error: No speed steps could be determined!

still non-deterministic... only works occasionally... very frustrating

OK, I've figured out what is happening:
when the notebook is on A/C, cpuspeed will not start (or restart), saying "no
speed steps could be determined". If already started, it will not scale.

However, if booted when on battery, it works fine, and scales the CPU properly.

If booted on A/C, cpuspeed will not start or restart even after unplugging the
A/C...
i.e. it only works if initally booted on battery, and only while running on battery.

Thanks

Thanks so much for running that down Barry. I can confirm the same behavior on
my Dell Inspiron 6000 
Bios Version: A9 (same on A5)
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.60GHz
stepping        : 8
cpu MHz         : 800.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips        : 800.21

This was mostly or competely fixed for me recently, but now is not working
reliably again when on A/C.

I suspect the latest kernel (kernel-2.6.17-1.2139_FC5) has a regression.

Thanks,
Barry

I can confirm the same problem on Dell Latitude D400. cpuspeed works when laptop
is running on battery only and stops working when AC is connected. No messages
specific to this problem in dmesg output or in /var/log/messages.
I'm using kernel-2.6.17-12157_FC5, cpuspeed 1.2.1-1.33
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1700MHz
stepping        : 5
cpu MHz         : 600.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush
dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 1202.12

/etc/cpuspeed.conf:
VMAJOR=1
VMINOR=1

# uncomment this and set to the name of your CPUFreq module
#DRIVER="centrino"

# Let background (nice) processes speed up the cpu
#OPTS="$OPTS -n"

# Add your favorite options here
#OPTS="$OPTS -s 0 -i 10 -r -C"
OPTS="$OPTS -r -C -D"

# uncomment and modify this to check the state of the AC adapter
OPTS="$OPTS -a /proc/acpi/ac_adapter/*/state"

# uncomment and modify this to check the system temperature
#OPTS="$OPTS -t /proc/acpi/thermal_zone/*/temperature 75"

There is definitely a problem in the recent FC5 kernels.  I have a Compaq R3000Z
which used to have working cpu frequency scaling and I only recently noticed it
doesn't work.  I'm going to find a repo with all the old kernels and try to
download some old ones and determine when it "broke"

The Compaq R3000Z has an AMD processor:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 8
model name      : AMD Athlon(tm) XP Processor 3000+
stepping        : 2
cpu MHz         : 800.000
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext 3dnowext 3dnow ts fid vid ttp
bogomips        : 1597.94


In earlier FC5 kernels the cpuspeed daemon properly scaled the CPU between
800Mhz and 1600Mhz.

FWIW, it's working better in FC6, although I think it's still gotten stuck at
the lower speed after suspend/resume a few times.

Barry

Need to see some log output after it gets stuck to have a hope of diagnosing. If
possible, grab /var/log/messages, dmesg, ls -lR
/sys/devices/system/cpu/cpu*/cpufreq and cat
/sys/devices/system/cpu/cpu*/cpufreq/* output if/when it gets stuck...

Gregory, if you could do the same with the latest kernel and cpuspeed on your
Compaq, something might jump out as to why your system isn't working...

Created attachment 145382 [details]
var-log-messages

Created attachment 145383 [details]
dmesg

I'm having troubles in FC6 now (it had been working for a while)... 
CPUSpeed claims to be running
# rpm -q cpuspeed
cpuspeed-1.2.1-1.43.fc6

# service cpuspeed status
Frequency scaling enabled using ondemand governor

but the Gnome CPU Frequency Scaling Monitor is always showing 600MHz.


]# ls -lR /sys/devices/system/cpu/cpu*/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq:
total 0
-r--r--r-- 1 root root 4096 Jan 11 11:01 affected_cpus
-r-------- 1 root root 4096 Jan 11 11:01 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Jan 11 11:01 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Jan 11 11:01 cpuinfo_min_freq
drwxr-xr-x 2 root root    0 Jan 11 11:19 ondemand
-r--r--r-- 1 root root 4096 Jan 11 11:01 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Jan 11 11:00 scaling_available_governors
-r--r--r-- 1 root root 4096 Jan 11 11:01 scaling_cur_freq
-r--r--r-- 1 root root 4096 Jan 11 11:00 scaling_driver
-rw-r--r-- 1 root root    0 Jan 11 11:19 scaling_governor
-rw-r--r-- 1 root root 4096 Jan 11 11:01 scaling_max_freq
-rw-r--r-- 1 root root 4096 Jan 11 11:01 scaling_min_freq

/sys/devices/system/cpu/cpu0/cpufreq/ondemand:
total 0
-rw-r--r-- 1 root root 4096 Jan 11 11:32 ignore_nice_load
-rw-r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate
-r--r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate_max
-r--r--r-- 1 root root 4096 Jan 11 11:32 sampling_rate_min
-rw-r--r-- 1 root root 4096 Jan 11 11:32 up_threshold


# cat /sys/devices/system/cpu/cpu*/cpufreq/*
0
600000
1600000
600000
cat: /sys/devices/system/cpu/cpu0/cpufreq/ondemand: Is a directory
1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 
ondemand userspace performance 
600000
centrino
ondemand
600000
600000


/var/log/messages and dmesg attached

# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"|grep kernel|sort
kernel-2.6.18-1.2869.fc6.i686
kernel-devel-2.6.18-1.2798.fc6.i686
kernel-devel-2.6.18-1.2869.fc6.i686
kernel-headers-2.6.18-1.2798.fc6.i386
kernel-headers-2.6.18-1.2869.fc6.i386
# uname -a
Linux brwebn13.pennysaverusa.net 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:19
EST 2006 i686 i686 i386 GNU/Linux

Please let me know if I can provide any other info.

Thanks,
Barry

Looks like the big problem here is that you're winding up with scaling_max_freq
actually containing the same thing as scaling_min_freq. How that is happening
though, I'm not quite sure...

What can you see (if anything) in
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after a 'service cpuspeed
stop' and/or on bootup if cpuspeed is chkconfig'd off?

As a last resort, I think you ought to be able to force your actual max speed by
setting MAX_SPEED=1600000 in /etc/cpuspeed.conf and restarting cpuspeed.

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
600000
[root@brwebn13 ~]# service cpuspeed stop
Disabling ondemand cpu frequency scaling:                  [  OK  ]
[root@brwebn13 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
600000

Setting MAX_SPEED and restarting CPUSPEED doesn't seem to help or change what's
in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 

will try disabling cpuspeed and rebooting

Thanks,
Barry

Disabled cpuspeed with chkconfig, and rebooted...
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq still read 600000

Cpuspeed had been working OK in FC6 until a few days ago.

Thanks,
Barry

Damn. Anything in the bios relating to cpu speed that's been tweaked? (Or can be
tweaked?) I think its time to start digging into the kernel-side code. With
cpuspeed disabled and still only seeing 600MHz for a max freq on a fresh boot,
cpuspeed is completely eliminated as a suspect, so far as I can tell.

Just had another thought... Does the value in scaling_max_freq (w/cpuspeed
chkconfig'd off) change based on whether you boot with or without ac power
connected?

In case you didn't notice this in the messages log,
after restarting cpuspeed, I see this:
Jan 11 13:31:47 brwebn13 cpuspeed: Invalid governor "governor" specified,
falling back to ondemand

in /var/log/messages

Thanks,
Barry

Re AC power...
In FC5, I _definately_ noticed differences in cpuspeed's behavior depending on
whether AC was plugged in on boot.
Hadn't been having that problem in FC6, but I'll check it now.

Haven't made any BIOS changes lately.

Thanks,
Barry

OK... on AC power, it's always 600000
booting on battery, it's at 1600000
!

Is there a solution or workaround for this?

I checked the BIOS, it's set to always boot at 1.6 

Thanks,
Barry

(In reply to comment #21)
> In case you didn't notice this in the messages log,
> after restarting cpuspeed, I see this:
> Jan 11 13:31:47 brwebn13 cpuspeed: Invalid governor "governor" specified,
> falling back to ondemand

Yeah, there's a minor screw-up in that'll be fixed in the next build, which
should get pushed out tomorrow...

(In reply to comment #23)
> OK... on AC power, it's always 600000
> booting on battery, it's at 1600000
> !
> 
> Is there a solution or workaround for this?

Not that I know of just yet, but this isn't the first I've heard of this
happening, and knowing that its reproducable is progress toward a solution... :)

I'll have to dig into this a bit tomorrow. Can you attach dmesg output from both
an AC and a battery boot? I'm hoping maybe some difference in the two will pop
up that could be relevant...

I'm about to post 3 attachments.

First will be dmesg on AC. Note the Processor Speed (about 600) and the bogomips.

Next attachment will be on Batt... CPU speed about 1600, more bogomips.

Final attachment is another one on batt, but it shows 600MHz for some reason.

Thanks,
Barry

Created attachment 145469 [details]
dmesg after booting on AC power

Created attachment 145470 [details]
dmesg after booting on AC power

Comment on attachment 145469 [details]
dmesg after booting on AC power

duplicate

Created attachment 145471 [details]
dmesg after booting on batt power, CPU correctly shows 1594MHz

Created attachment 145472 [details]
another boot on batt power, but with CPU speed (incorrrectly) showing 600MHz

Another note:

If I boot on battery, everything is working fine.

As soon as I plug in the AC,  /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
drops to 600000
and CPU speed seems to stay at 600.

Thanks,
Barry

Interesting. The dmesg output seems to indicate the real problem is well before
we get into the cpu frequency scaling code. It looks like we're having issues
with the tsc. I'm slowly cobbling together a kernel build with some extra
debugging output added in places to see if we can't further isolate the problem,
but in the interim, if you would, please see what sort of scaling_max_freq
results you get if you boot the system with 'notsc' added to your kernel options.

with 'notsc', I get 1600000 in max freq with the A/C plugged in, so that's an
improvement.

Thanks,
Barry

ignore #33

The whole problem for me seems to be being caused by the 65watt "travel charger"
for my Dell D800.

When on batteries, everything is fine.
When on A/C with one charger, everything is fine.
When on A/C with the "travel charger", the system will not go over 600 MHz, no
matter what I do with 'notsc', etc.

I apologize profusely for the confusion.

Since the system can run at full speed with the battery, it would follow that it
should be able to run full speed (at least for a while) with batt + travel adapter.
If anyone knows how to get this to work better, I'd be very happy.

Thanks,
Barry

Hrm... I'm altering the distro to fc6, component to kernel and summary from
"CPUSPEED not working reliably on Pentium-M" to "CPU locked at lowest frequency
when using travel charger"... Not sure yet where to poke next, will ask around a
bit... DaveJ, any ideas?

Seems to be different, but at least semi-similar to bug 205305. Can you grab
dmesg output from a boot using the travel adapter with cpufreq.debug=7 in your
kernel params?

Created attachment 145650 [details]
dmesg on travel charger with cpufreq.debug=7

Interesting... So it looks like we at least partially recognize how fast the
processor is still, and our first call to verify 600MHz to 1.6GHz succeeds, but
then we immediately decide we should re-verify for 600 to 600MHz...

----8<----
speedstep-centrino: adding state 0 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 1 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 2 with frequency 1600000 and control value 1031
speedstep-centrino: adding state 3 with frequency 1400000 and control value 0e2d
speedstep-centrino: adding state 4 with frequency 1200000 and control value 0c24
speedstep-centrino: adding state 5 with frequency 1000000 and control value 0a1d
speedstep-centrino: adding state 6 with frequency 800000 and control value 0815
speedstep-centrino: adding state 7 with frequency 600000 and control value 0610
speedstep-centrino: centrino_cpu_init: cur=600000kHz
[...]
cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
----8<----

This appears to trigger when we switch from the userspace governor to the
ondemand governor, within the __cpufreq_set_policy function in
drivers/cpufreq/cpufreq.c. I'm still digging into the intermediate bits between
the two verify calls to see why we're locking down at 600MHz...

fwiw, this was in runlevel 1 with cpuspeed disabled, so I'm not sure if the
governor is getting changed or not.
Does the kernel change it?

Thanks,
Barry

Hrm... I believe we have things set up to default to userspace, and its only
when we fire up cpuspeed that we switch to ondemand, so perhaps this was the
transition from no gov to userspace?... Lemme roll a kernel w/some extra
dprintk's in there to give a bit more info on what's going on in there...

If you'd be so kind, please grab the kernel here:

http://people.redhat.com/jwilson/test_kernels/bz188453/

Install that, boot it w/cpufreq.debug=7 and slap some more dmesg output up here.
We'll get a bit more debug output around where we get locked down to 600MHz
that'll further isolate exactly where its happening...

Created attachment 146268 [details]
dmesg with test kernel on travel charger with cpufreq.debug=7

Hrm, okay... I'll dig into the CPUFREQ_INCOMPATIBLE section a bit more. However,
in the interim, can you see if the recent 2.6.19-based FC6 kernel improves the
situation? I have another report (bug 223816) of a similar situation that went
away after such an upgrade.

No apparent change with the 2895 kernel.

$ uname -a
Linux brwebn13.pennysaverusa.net 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18
EST 2007 i686 i686 i386 GNU/Linux

$ rpm -q kernel
kernel-2.6.19-1.2895.fc6


Thanks,
Barry

Unfortunately, this bug got lost in the shuffle for a bit... Before I get back
to poking at it, can you confirm this is still an issue with the latest
available kernel? Something 2.6.22.1 or later would be preferred.

Last I checked, it was still happening, but I'm guessing it's mainly a hardware
problem. See comment #34 above.

I'm OK if you close this bug, but if there's something else that can be done
without spending a lot of your time, it'd be nice.

Thanks!

FWIW, Dell says the travel charger will work with my D800 laptop but in a
'reduced performance' mode, so it is probably the BIOS that is restricting
something.

I would think it would be possible to get the laptop to use the battery for any
extra power needed for short bursts of higher CPU speed, but that's just a wild
guess.

Ah... Indeed, this does sound like its something Dell does in the bios, so we're
actually doing the right thing in this case. With a bit of work, one could
probably conjure up a way to override the throttling, but if we're doing what is
intended by the mfg here, its probably best not to.