acpi-cpufreq doesn't allow >800Mhz on Fujistu T4220

[ChrisDebenham]

Binary package hint: linux-source-2.6.24

If the machine (Fujitsu T4220) is booted without any cpufreq modules it runs at 2Ghz.
Soon after I run 'modprobe acpi-cpufreq' the speed drops to 800Mhz
When I load the acpi-cpufreq module at first it reports 2001000 for cpuinfo_cur_freq but drops through each of the available frequencies at a rate of about 1 step per second.
After this no matter what I do I can't increase this (regardless of cpufreq governor used)
According to /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq the max speed is 2001000 but scaling_max_freq is set to 800000 and can not be changed. I have tried "echo 2001000 > scaling_max_freq" but no change is made.

Below is data I hope is useful

# uname -a
Linux fugue 2.6.24-2-generic #1 SMP Thu Dec 13 23:21:19 GMT 2007 x86_64 GNU/Linux

root@fugue:/sys/devices/system/cpu/cpu0/cpufreq# grep "." *
affected_cpus:0 1
cpuinfo_cur_freq:800000
cpuinfo_max_freq:2001000
cpuinfo_min_freq:800000
scaling_available_frequencies:2001000 2000000 1600000 1200000 800000
scaling_available_governors:userspace performance
scaling_cur_freq:800000
scaling_driver:acpi-cpufreq
scaling_governor:userspace
scaling_max_freq:800000
scaling_min_freq:800000
scaling_setspeed:800000

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 3994.31
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 3989.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[Ryan (ryan-redhat-bugs)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc9 Firefox/2.0.0.9

Description of problem:
On my Santa Rosa based Fujitsu T4220 notebook the CPU frequency is permanently stuck at 800MHz (actual max is 2GHz) no matter what the load. This occurs no matter which governor is selected (userspace, ondemand, performance etc..).

On resume from suspend to ram, the frequency fluctuates between 800MHz and 1.6GHz for approx. a minute, and then goes back to being stuck at 800MHz.

Version-Release number of selected component (if applicable):
kernel-2.6.24-0.42.rc3.git1.fc9

How reproducible:
Always

Steps to Reproduce:
1. boot into fedora
2. check /cat/proc/cpuinfo ( will be 800MHz )
3. run something cpu intensive
3. check cpuinfo (still stuck at 800MHz)

Actual Results:
The CPU frequency doesn't change

Expected Results:
The frequency should increase to max if needed and go back to min when not.

Additional info:

[Ryan (ryan-redhat-bugs)]

Created attachment 271951
lspci -vv output

[Ryan (ryan-redhat-bugs)]

Created attachment 271961
lspci -vvn output

[Ryan (ryan-redhat-bugs)]

Created attachment 271971
dmidecode output

[Ryan (ryan-redhat-bugs)]

[ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus scaling_available_frequencies scaling_governor
cpuinfo_cur_freq scaling_available_governors scaling_max_freq
cpuinfo_max_freq scaling_cur_freq scaling_min_freq
cpuinfo_min_freq scaling_driver scaling_setspeed

[root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
0 1
800000
2001000
800000
2001000 2000000 1600000 1200000 800000
userspace performance
800000
acpi-cpufreq
performance
800000
800000

Also, I am not sure how relevant this is, but
/proc/acpi/processor/CPU0/throttling outputs "<not supported>".

I have the same problems on every linux distro I have tried on this laptop

[Ryan (ryan-redhat-bugs)]

Created attachment 274581
dmesg output

Here's my dmesg

[Jaakko (jaakko-redhat-bugs)]

On updated Fedora 8, on Dell Inspiron 9300 laptop, I have the same problem.
Frequency policy is stuck at 800 MHz. Scaling worked in the past on some
earlier FC, not sure if I paid attention so much on FC7.

# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 800 MHz - 1.73 GHz
  available frequency steps: 1.73 GHz, 1.33 GHz, 1.07 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
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 up bts est tm2
bogomips : 1597.42
clflush size : 64

# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
   *T0: 00%
    T1: 12%
    T2: 25%
    T3: 37%
    T4: 50%
    T5: 62%
    T6: 75%
    T7: 87%

[Chuck (chuck-redhat-bugs)]

(In reply to comment #4)
> [ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
> affected_cpus scaling_available_frequencies scaling_governor
> cpuinfo_cur_freq scaling_available_governors scaling_max_freq
> cpuinfo_max_freq scaling_cur_freq scaling_min_freq
> cpuinfo_min_freq scaling_driver scaling_setspeed
>
> [root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
> 0 1
> 800000
> 2001000
> 800000
> 2001000 2000000 1600000 1200000 800000

That 2001000 doesn't look right...

Try:

# echo "2000000" >scaling_max_freq

[Ryan (ryan-redhat-bugs)]

(In reply to comment #7)
> (In reply to comment #4)
> > [ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
> > affected_cpus scaling_available_frequencies scaling_governor
> > cpuinfo_cur_freq scaling_available_governors scaling_max_freq
> > cpuinfo_max_freq scaling_cur_freq scaling_min_freq
> > cpuinfo_min_freq scaling_driver scaling_setspeed
> >
> > [root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
> > 0 1
> > 800000
> > 2001000
> > 800000
> > 2001000 2000000 1600000 1200000 800000
>
> That 2001000 doesn't look right...

Yeah, I'm not sure about that either.

>
> Try:
>
> # echo "2000000" >scaling_max_freq
>

I've tried that before and it has no effect. I can try echoing anything into
that file as root and it will not change from '800000'

I've noticed a few other people with Fujitsu laptops (not just T4220's) with the
same problem as me. All the machines have the following in their dmesg output:

ACPI: EC: Look up EC in DSDT
ACPI Error (tbinstal-0134): Table has invalid signature [ ], must be SSDT,
PSDT or OEMx [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_._INI] (Node
f7801440), AE_BAD_SIGNATURE

I don't know enough about how ACPI works to say whether that has anything to do
with /proc/acpi/processor/CPU0/throttling saying "<not supported>", or if it is
even relevant, but it seems to be a common theme.

[Jaakko (jaakko-redhat-bugs)]

Created attachment 289802
dmesg output of booting with cpufreq.debug=7 option

Line 443 says
"freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0"
which is correct, but line 446 says
"freq-table: verification lead to (800000 - 800000 kHz) for cpu 0"
and cpu remains stuck at 800MHz for me.

[Leann Ogasawara (leannogasawara)]

Hi Chris,

Thank you for taking the time to report this bug and helping to make Ubuntu better. Per the kernel teams bug policy, can you also attach the following information:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

Please be sure to attach each file as a separate attachment. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

[ChrisDebenham (chris-debenham)]

My apologies for not including that data.
It has been attached now.
BTW. This looks to be reported in the RedHat bugzilla as bug 403651

[Leann Ogasawara (leannogasawara)]

Thanks Chris. Usually we'd be able to monitor the upstream bug report from this launchpad report but for some reason it's not letting me set it up. I'll have to inquire why. Regardless, I'm reassigning your report to the kernel team. Thanks!

[Ryan Campbell (rcampbell)]

Someone posted the following on the T4220 wiki page ( https://help.ubuntu.com/community/T4220 ):

"Actually the problem lies in the ACPI-DSDT. The Linux-Kernel reports to be WIN-Vista-compatible, therefore the DSDT tries to load an additional piece of AML code in this case, which is not ACPI-compatible. After this bug there is a missing temperature offset, an the kernel starts to thermo-throttle CPU. The incomplete load of the vista table is also the reason for the missing symbols in the button-events.

      2 Solutions are possible:

      switch off Vista compatibility in ACPI (acpi_osi="!Windows 2006")

      use modified DSDT: http://ginkel2.boerde.de/Lifebook_4220/lt4220.tgz "

I've tested the acpi_osi= kernel option and it appear to solve my cpu scaling issues, so this bug can probably be marked closed.

[Leann Ogasawara (leannogasawara)]

Hi Ryan,

Thanks for the info. Chris, can you confirm if this helps resolve the issue you are seeing? Thanks.

[ChrisDebenham (chris-debenham)]

I have tried the acpi_osi option and it works great.
cpu scaling is working fine at the moment.
So that is a workaround, but I wouldn't consider it a proper fix as it requires manual editing of the grub menu.lst for anyone who hits this issue.
Is there some way of making this automated so others don't have the same problem?

[Dennis M. (ranpha1)]

Ryan Campbell

I can confirm that the wiki page works. I know it's my page. The entry about DSDT is somebody called Ginkel.
I'm now in the proces of the second solution because the first worked but when i unplugged the power it got stuck to 800 even when i replugged the power adapter

[Dennis M. (ranpha1)]

MartinGinkel
came with the right DSDT solution
I got CPU scaling working now

Got no idea where to upload this to for mainstream

[Leann Ogasawara (leannogasawara)]

Hi Guys,

I'm glad to hear there is at least a workaround for this bug. I spoke with a member of the kernel team and this is probably as good as this will get in terms of a "solution" prior to the Hardy Heron release. It is not a matter of importance of the bug, but rather the amount of resources we have available to resolve it. With the development cycle for Hardy now entering feature freeze, the teams must now focus on resolving high and critical bugs which have no fixes or documented workarounds. I'll leave this report open, but this will be marked as "Won't Fix" for the Hardy release. Thanks.

[Colin Ian King (colin-king)]

Unfortunately the problem lies in the ACPI-DSDT: One could put quirks in the kernel to try and work around the broken DSDT, but an updated DSDT (http://ginkel2.boerde.de/Lifebook_4220/lt4220.tgz) is probably the correct approach to fix this one.

[haplo_09 (haplo-09)]

Can someone please have a guide how to integrate the DSDT, and get scaling working!

[haplo_09 (haplo-09)]

Aslo, does anyone know where to insert acpi_osi line ?

[Łukasz (ukasz-redhat-bugs)]

Created attachment 298400
dmesg with options acpi=debug cpufreq.debug=7

[Łukasz (ukasz-redhat-bugs)]

Comment on attachment 298400
dmesg with options acpi=debug cpufreq.debug=7

I have the same problem on a Thinkpad R61i with an up-to-date Fedora 8.

I don't get any of the ACPI errors mentioned earlier but scaling_max_frequency
is also stuck at 800000.
$ echo 1467000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
 doesn't change it.

[Jaakko (jaakko-redhat-bugs)]

About my case, comment #9. This was caused by dust that prevented
the GPU fan from spinning. Works now fine. The root cause was hinted
by running the Dell Diagnostics software that came with the computer.

[Łukasz (ukasz-redhat-bugs)]

It looks like removing both the battery and AC connector had fixed the problem
in my case.

[Bug (bug-redhat-bugs)]

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Christopher Berner (cberner)]

Can someone upload the DSDT file somewhere? the original source seems to no longer exist.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Christopher Berner (cberner)]

I installed Ubuntu 8.10 via Wubi, and this bug is not present there. I have not tested it with a regular install of 8.10

[Jay (jay-redhat-bugs)]

I believe that I am seeing the same type of behaviour in Fedora 11 x86_64. I have a Pentium Dual Core E2180 running on an abit ab9 pro motherboard. The first core (CPU0) does not seem to scale ever.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz
stepping : 13
cpu MHz : 1224.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips : 4079.98
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz
stepping : 13
cpu MHz : 1224.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips : 4079.40
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

# cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 1.22 GHz - 2.04 GHz
  available frequency steps: 2.04 GHz, 1.63 GHz, 1.22 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.22 GHz and 1.22 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.22 GHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 1.22 GHz - 2.04 GHz
  available frequency steps: 2.04 GHz, 1.63 GHz, 1.22 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.22 GHz and 2.04 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.22 GHz (asserted by call to hardware).

This looks to be a bug in the acpi-cpufreq driver as I also see the same issue in Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/324211)

[Jay (jay-redhat-bugs)]

Created attachment 346232
jay's lscpi -vv output

[Jay (jay-redhat-bugs)]

Created attachment 346233
lspci -vvn output

[Jay (jay-redhat-bugs)]

Created attachment 346234
jay's lsmod output

[Jay (jay-redhat-bugs)]

Created attachment 346235
jay's dmidecode output

[Jay (jay-redhat-bugs)]

Created attachment 346236
jay's dmesg output

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[C. Brayton (cbrayton-boizebueditorial)]

in lucid, with grub2, add acpi_osi=\\\"!Windows 2006\\\" to /etc/default/grub (or to /boot/grub.menu.lst, under boot parameters for kernel to be loaded).

This fix, however, did not work for me. I still boot up, login, have frequency scaling working properly (governor ondemand -d 1000000 -u 2000000) for a period of time (which varies), and then cpu falls to lowest freq and is stuck there. (Forum browsing suggests this may be DSDT-related. Sadly, the Ginkel Fix is no longer available.)

After this occurs, I get the following readings

(1) cpufreq-info (note the maddeningly persistent "between [minimum] and [minimum]"):

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 1000 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 2.00 GHz:2.16%, 1.67 GHz:20.58%, 1.33 GHz:5.83%, 1000 MHz:71.43% (815)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 2.00 GHz:2.02%, 1.67 GHz:0.21%, 1.33 GHz:4.80%, 1000 MHz:92.97% (438)

(2) cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2500 @ 2.00GHz
stepping : 8
cpu MHz : 1000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
bogomips : 3995.08
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2500 @ 2.00GHz
stepping : 8
cpu MHz : 1000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags...

[C. Brayton (cbrayton-boizebueditorial)]

from dmesg | grep CPU (attached)

What does the following mean?

"[ 40.806951] CPUFREQ: Per core ondemand sysfs interface is deprecated "

[C. Brayton (cbrayton-boizebueditorial)]

As u can see, my laptop is a Dell Latitude with a T2500 processor ...