Bug 16072 - [HP Pavilion dm1-1110ev] Cpufreq doesn't work at all ( Intel Celeron U2300 )
Summary: [HP Pavilion dm1-1110ev] Cpufreq doesn't work at all ( Intel Celeron U2300 )
Status: CLOSED DOCUMENTED
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: cpufreq
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-28 16:14 UTC by Markos Chandras
Modified: 2011-07-30 04:56 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.34
Tree: Mainline
Regression: No


Attachments
kernel config (70.46 KB, application/octet-stream)
2010-05-28 16:14 UTC, Markos Chandras
Details
acpidump (226.34 KB, application/octet-stream)
2010-07-05 10:56 UTC, Markos Chandras
Details
dmidecode (8.70 KB, application/octet-stream)
2010-07-05 10:56 UTC, Markos Chandras
Details
dmidecode PB (10.46 KB, text/plain)
2010-07-06 07:31 UTC, Patrick Viane
Details
acpidump PB (184.51 KB, text/plain)
2010-07-06 07:37 UTC, Patrick Viane
Details

Description Markos Chandras 2010-05-28 16:14:47 UTC
Created attachment 26570 [details]
kernel config

Hi

Cpufreq kernel driver doesn't work for this laptop/cpu at all. 

1)CONFIG_CPU_FREQ is compiled in kernel:

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

2)cpu-info show no result

cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

3)cat /proc/cpufinfo

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Genuine Intel(R) CPU           U2300  @ 1.20GHz
stepping	: 10
cpu MHz		: 1199.932
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	: 13
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 nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 2399.86
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		: 23
model name	: Genuine Intel(R) CPU           U2300  @ 1.20GHz
stepping	: 10
cpu MHz		: 1199.932
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	: 13
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 nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 2400.03
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

4) powertop -d output

PowerTOP 1.11   (C) 2007, 2008 Intel Corporation 

Collecting data for 15 seconds 


Cn	          Avg residency
C0 (cpu running)        ( 0,1%)
polling		  0,0ms ( 0,0%)
C1 mwait	 54,6ms (50,1%)
C4 mwait	  2,1ms (49,8%)
P-states (frequencies)
Wakeups-from-idle per second : 241,9	interval: 15,0s
no ACPI power usage estimate available
Top causes for wakeups:
  46,4% ( 20,9)     <kernel core> : hrtimer_start (tick_sched_timer) 
  22,1% (  9,9)              phy0 : __mod_timer (ath_ani_calibrate) 
  11,1% (  5,0)     <kernel core> : __mod_timer (cursor_timer_handler) 
   8,9% (  4,0)     <kernel core> : __mod_timer (rh_timer_func) 
   5,2% (  2,3)     <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 
   2,1% (  0,9)              phy0 : queue_delayed_work (delayed_work_timer_fn) 
   0,6% (  0,3)       <interrupt> : ahci 
   0,4% (  0,2)     <kernel core> : __mod_timer (dev_watchdog) 
   0,4% (  0,2)     <kernel core> : __mod_timer (sync_supers_timer_fn) 
   0,4% (  0,2)          events/0 : queue_delayed_work (delayed_work_timer_fn) 
   0,4% (  0,2)              init : hrtimer_start_range_ns (hrtimer_wakeup) 
   0,3% (  0,1)    wpa_supplicant : hrtimer_start_range_ns (hrtimer_wakeup) 
   0,3% (  0,1)    NetworkManager : hrtimer_start_range_ns (hrtimer_wakeup) 
   0,3% (  0,1)       bdi-default : __mod_timer (process_timeout) 
   0,3% (  0,1)         flush-8:0 : __mod_timer (process_timeout) 
   0,1% (  0,1)    wpa_supplicant : queue_delayed_work (delayed_work_timer_fn) 
   0,1% (  0,1)     <kernel core> : enqueue_task_rt (sched_rt_period_timer) 
   0,1% (  0,1)     <kernel core> : __mod_timer (sta_info_cleanup) 
   0,1% (  0,1)              hald : hrtimer_start_range_ns (hrtimer_wakeup) 
   0,1% (  0,1)              cron : hrtimer_start_range_ns (hrtimer_wakeup) 

A USB device is active  0,0% of the time:
USB device  2-4 : HP Webcam-50 (QCM)

Suggestion: increase the VM dirty writeback time from 5,00 to 15 seconds with:
  echo 1500 > /proc/sys/vm/dirty_writeback_centisecs 
This wakes the disk up less frequently for background VM activity

Suggestion: Enable SATA ALPM link power management via: 
  echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
or press the S key.

Suggestion: Enable the CONFIG_CPU_FREQ_STAT kernel configuration option.
This option allows PowerTOP to show P-state percentages 
P-states correspond to CPU frequencies.

Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option.
This option will automatically disable UHCI USB when not in use, and may
save approximately 1 Watt of power.

Recent USB suspend statistics
Active  Device name
  0,0%	USB device  4-2 : HP Integrated Module (Broadcom Corp)
  0,0%	USB device  2-4 : HP Webcam-50 (QCM)
  0,0%	USB device usb7 : UHCI Host Controller (Linux 2.6.34-gentoo-bookie uhci_hcd)
  0,0%	USB device usb6 : UHCI Host Controller (Linux 2.6.34-gentoo-bookie uhci_hcd)
  0,0%	USB device usb5 : UHCI Host Controller (Linux 2.6.34-gentoo-bookie uhci_hcd)
  0,0%	USB device usb4 : UHCI Host Controller (Linux 2.6.34-gentoo-bookie uhci_hcd)
  0,0%	USB device usb3 : UHCI Host Controller (Linux 2.6.34-gentoo-bookie uhci_hcd)
  0,0%	USB device usb2 : EHCI Host Controller (Linux 2.6.34-gentoo-bookie ehci_hcd)
  0,0%	USB device usb1 : EHCI Host Controller (Linux 2.6.34-gentoo-bookie ehci_hcd)


Let me know if you need more information

Thanks
Comment 1 Robert Bradbury 2010-06-25 07:02:05 UTC
See Kernel Bug #14771 and Gentoo Bug #287463.

The "ondemand" scheduler was changed circa Linux 2.6.30 so it no longer works correctly.  (Patch to p4-clockmod.c is attached to the Gentoo bug report).

Kernel developers seem to believe that everyone is running Intel CPU's with "Enhanced" SpeedStep capabilities with an ACPI BIOS which has power control (_PCT) abilities.  If either are unavailable then the acpi-cpufreq driver is unlikely to work.  For the "ondemand" scheduler to work correctly it needs to be fixed so detects non-enhanced Intel SpeedStep processors *or* non-_PCT enabled ACPI BIOS conditions and reverts the ondemand scheduler that found prior to Linux 2.6.30 (though changing p4-clockmod.c: policy->cpuinfo.transition_latency to the old value -- or some other modifications).

In your case I think the Celeron may have "Enhanced" SpeedStep capabilities, but if the HP ACPI BIOS doesn't have the "_PCT" controls the acpi-cpufreq functions are unlikely to work.  You need to build the kernel with both acpi-cpufreq and ondemand as modules and flip back and forth between them with ACPI debugging enabled.  If you attempt to modprobe acpi-cpufreq and get "No such device" (ENODEV) it is likely your BIOS is the source of the problem.
Comment 2 Markos Chandras 2010-06-25 09:01:42 UTC
Thanks for the quick tip, but I have found multiple references over the inet, complaining about broken support on this kinda of CPU. Is it possible that all of them had a broken bios? Initially, I assumed that this cpu is quite new and kernels developers didn't have time to add support for it
Comment 3 Patrick Viane 2010-07-03 12:42:38 UTC
Hi,

I can confirm the same problem on a Packard Bell Easynote Butterfly XS with the same processor. I've tried running kernel-2.6.35-rc3 (x86_64) but the problem persisted. The cpu runs quite hot for a processor of this type: 46-51°C (idle - normal use).

Booting with kernel parameter "cpufreq.debug=7" gave the following relevant information in dmesg:

acpi-cpufreq: acpi_cpufreq_init
acpi-cpufreq: acpi_cpufreq_early_init
cpufreq-core: trying to register driver acpi-cpufreq
cpufreq-core: adding CPU 0
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
acpi-cpufreq: No P-States
cpufreq-core: initialization failed
cpufreq-core: adding CPU 1
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: CPU 1: _PPC is 0 - frequency not limited
acpi-cpufreq: No P-States
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver acpi-cpufreq
cpufreq-core: unregistering CPU 0
cpufreq-core: unregistering CPU 1
cpufreq-core: trying to register driver p4-clockmod
cpufreq-core: adding CPU 0
speedstep-lib: x86: 6, model: 17
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition of frequency scaling. You should use that instead of p4-clockmod, if possible.
cpufreq-core: initialization failed
cpufreq-core: adding CPU 1
speedstep-lib: x86: 6, model: 17
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition of frequency scaling. You should use that instead of p4-clockmod, if possible.
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver p4-clockmod
cpufreq-core: unregistering CPU 0
cpufreq-core: unregistering CPU 1

This problem is probably related to https://bugzilla.kernel.org/show_bug.cgi?id=15377 (same cpu, no P-states in powertop).

Thanks for any help.
Comment 4 Thomas Renninger 2010-07-05 10:35:30 UTC
> I assumed that this cpu is quite new and kernels developers didn't have
> time to add support for it
This should more read more like:
CPU is quite new and BIOS developers didn't have time to add support for it...

Best you:
  - Check that the latest BIOS running
  - Check BIOS settings for power management, speedstep, cpufreq or related
    options you can enable
  - If things still do not work, please attach acpidump and dmidecode.

How old are these machines about? HP cares about Linux support and chances that they add cpufreq support to their BIOSes if it makes sense aren't that bad if these are recent machines.
Comment 5 Thomas Renninger 2010-07-05 10:46:22 UTC
Because there are several reports:
Please check whether you have the "est" flag in /proc/cpuinfo showing up.
cpuinfo from the reporter has this bit set, others may have not.
Their CPUs simply do not support CPU frequency scaling then.
Comment 6 Markos Chandras 2010-07-05 10:56:09 UTC
Created attachment 27016 [details]
acpidump
Comment 7 Markos Chandras 2010-07-05 10:56:58 UTC
Created attachment 27017 [details]
dmidecode
Comment 8 Markos Chandras 2010-07-05 11:02:20 UTC
Afaik the BIOS is pretty new so is the laptop. I am pretty sure it is a brand new model ( 2-3 months old )

I 've seen several reports over the inet complaining about missing cpufreq support on this CPU

http://software.intel.com/en-us/articles/enhanced-intel-speedstepr-technology-and-demand-based-switching-on-linux/ ( look @comments )

And yes, my CPU has est flag on /proc/cpuinfo
Comment 9 Patrick Viane 2010-07-06 07:31:16 UTC
Created attachment 27032 [details]
dmidecode PB
Comment 10 Patrick Viane 2010-07-06 07:37:07 UTC
Created attachment 27033 [details]
acpidump PB
Comment 11 Patrick Viane 2010-07-06 07:50:40 UTC
AFAIK the PB notebook was introduced in Q1 2010, the newest BIOS is installed.
As it has the same processor as the HP, the "est" flag in /proc/cpuinfo is present.

This is an Ultra low voltage processor, which should help give these laptops up to 8 hours of battery life. Sadly, no frequency scaling means a 25% or higher penalty in battery life.

This is a link to the Intel specifications page, which includes a link to the data-sheet (was updated for this CPU): http://ark.intel.com/Product.aspx?id=42779
Comment 12 Kostya Stopani 2010-08-02 18:56:35 UTC
Hi,

I am experiencing a similar problem with a Thinkpad X200s laptop (CPU is the same -- SU2300, kernel version 2.6.34.1) with the latest BIOS version. Acpi-thinkpad module produces exactly the same output in dmesg as in comment #3. The CPU has est flag in /proc/cpuinfo indeed.

And there is also an _OSI condition is DSDT, kernel writes in dmesg:

        ACPI: BIOS _OSI(Linux) query ignored

during boot.
Comment 13 Markos Chandras 2010-10-22 15:33:39 UTC
Do you need any additional information to address this bug? Just tried 2.6.36 and the problem is still there
Comment 14 Thomas Renninger 2010-10-22 19:37:18 UTC
Sorry, I forgot about this one.
There was a thread about this CPU type on the cpufreq list recently:
http://www.spinics.net/lists/cpufreq/msg01764.html

It came out this type of CPU is not speedstep capable, but is still exporting EST CPU capability (compare with flags /proc/cpuinfo).
You might want to verify with the Intel CPU sheet the guy found.

This one should get closed.
I close this one documented, others might want to read it up again.
Comment 15 Robert Bradbury 2010-10-22 21:09:24 UTC
This shiould not be closed as an "undicumemented bug".  The machine is a
standard HP Pavilion A630N machine (presumably which hundreds of thousands
were manufactured in the 2003-2005 time frame).

In monitoring the Gentoo bug framework I am aware that there are laptops
being manufactured to date (2010) which contain Bios which do not contain
the proper code to  properly inform about the BIOS capabilities.

In short there are still machines which exist out there which WILL NOT
PERFORM properly on what ACPI code is supposed to exisit.  Because it
doesn't exist or cannot be programmed into the machines.   The P4-clockmod
change was/is wrong -- the P4 clockmod driver worked fine for these machines
before the "correction"  I have a machine which works fine backing down to
1.75 GHz or even 750 Mhz.   And I can watch the power consumption decrease
on a Watt-Meter which the machine is plugged into.

Though I am running a gentoo-2.6.35-r10 kernel (whiich I presume is roughly
equivalent to the final release of 2.6.35.   The p4-clockmod, e.g.
arch/x86/kernel/cpu/cpufreq/p4-clockmod.c

is backtracked to ~the 2.6.28 release (or perhaps somehat later)  Because
that is the release which worked on these machines.  Subsequent releases do
not allow P4 clockmod control and are therefore worthless.  There are two
dividing lines -- some people want their machine to be responsive -- and
that may have prompted the change in p4-clockmod.c  And there are others who
may have reasons to leave their computers on (such as to provide web
services)  who may desire minimal CPU/power consumption at all times.   The
current p4-clockmod.c situation prevents that and that is why I am forced to
run an older instantiation of that driver.

It is not a problem which can be resolved by throwing out the older or
un-upgraded (in terms of BIOS capabilities with respect to ACPI).  The
proper response is for Linux to determine if the machine does have advanced
ACPI control capanilities -- and if it does not allow for old-style P4
clockmod fallback..

Because that is what works and it should not be a Linux position to force
people into less than 5 y.o. machines.  p4-clocmod.c used to work perfectly
in reducing power consumption.  It currently does not.  Thus in the current
release of Linux it cannot be viewed as being "green".
Comment 16 Robert Bradbury 2010-10-22 21:48:19 UTC
On Fri, Jun 25, 2010 at 5:02 AM, <bugzilla-daemon@bugzilla.kernel.org>wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=16072
>
> --- Comment #2 from Markos Chandras <hwoarang@gentoo.org>  2010-06-25
> 09:01:42 ---
> Thanks for the quick tip, but I have found multiple references over the
> inet,
> complaining about broken support on this kinda of CPU. Is it possible that
> all
> of them had a broken bios? Initially, I assumed that this cpu is quite new
> and
> kernels developers didn't have time to add support for it
>

Markos, the CPU is very old (~5+ years).  There are still CPU/BIOS
combinations wch may be coming out which do not properly support the ACPI
power saving options [1] -- and thus one must fall back on the old
p4-clockmod power saving features.  Which did indead work and should not be
effectively disabled as has been the case with more recent releases of
Linux.

Please feel free to contact me for the specific modiification in
p4-clockmod.c which should be removed in order to provide the normal power
saving features.

Best,
Robert

1. It is a very complex situation in terms of what the CPUs are capable of
and what the BIOS is capable of (in terms of managing power conservation).
 In terms of my current read of the Linux code these are in two separate
realms from a development standpoint.  In an ideal world everything would be
going through ACPI and it would manage power use.  In reality that world
does not exist and one should be able to deal with it.  Thus problems with
p4-clockmod.c.
Comment 17 Markos Chandras 2010-10-22 21:59:15 UTC
I am really sad to see this bug closed as, apparently, CANTFIX. Rober, can you please attach a working diff of p4-clockmod.c based on the old kernel so I can take advantage of it and save the battery of my *brand new* netbook? Thank you
Comment 18 Thomas Renninger 2010-10-22 23:52:22 UTC
Sigh, a p4_clockmod discussion again.
I promised myself to stay out of those, but as you provide quite some wrong information let's clear some things up:

> This shiould not be closed as an "undicumemented bug".  The machine is a
> standard HP Pavilion A630N machine (presumably which hundreds of thousands
> were manufactured in the 2003-2005 time frame).
Which does not support CPU frequency scaling, where is the problem?
The CPU itself simply cannot do it.

> In monitoring the Gentoo bug framework I am aware that there are laptops
> being manufactured to date (2010) which contain Bios which do not contain
> the proper code to  properly inform about the BIOS capabilities.
This has nothing to do with BIOS capabilities.

> There are two dividing lines -- some people want their machine to be
> responsive -- and that may have prompted the change in p4-clockmod.c
This high transition latency will cause that you cannot properly work with it.
It may not be that bad if you use it as a server without user interaction, but also there p4_clockmod will not save any/much power, see below.

> And I can watch the power consumption decrease on a Watt-Meter which the
> machine is plugged into.
How much is this for a totally idle system?
Please try again, I do not believe this.

Hmm, this machine does not even support C2...

Still I doubt you gain any/much power consumption with p4_clockmod.
Can you do some checks please if you still have the power meter and measure power consumption if:
  1) p4_clockmod not used and machine is as idle as possible
     (top, kill some processes if necessary)
  2) p4_clockmod is used and machine is as idle as possible
     (top, kill some processes if necessary).
  3) Fully utilized CPU (do "cat /dev/zero >/dev/null &" two or three times and
     kill it again after measuring) with p4_clockmod unused
  4) Fully utilized CPU (do "cat /dev/zero >/dev/null &" two or three times and
     kill it again after measuring) with p4_clockmod used
  5) You should see such a line in dmesg:
     "using mwait in idle threads"
     If this is the case try: idle=halt boot param
     and measure the same as done in 1. (double check that the message in dmesg
     disappeared).
Comment 19 Patrick Viane 2010-10-23 06:03:16 UTC
Same sentiment here (sadness) as expressed by Markos Chandras in Comment #17.

The CPU is clearly capable of frequency scaling (and voltage scaling).

Please consider the following:
> Comment #14
> It came out this type of CPU is not speedstep capable
Somewhat misleading: the CPU is "Enhanced Intel SpeedStep® Technology" capable, and should (imo) be handled by the acpi-cpufreq driver. 

> You might want to verify with the Intel CPU sheet the guy found.
I did: please see for yourself at http://www.intel.com/design/mobile/datashts/321111.pdf

> Comment #15
> The machine is a standard HP Pavilion A630N machine
Incorrect: see discription of bug: "[HP Pavilion dm1-1110ev] Cpufreq doesn't work at all ( Intel Celeron U2300 )".  AFAIK this notebook was introduced in Q1 2010. (As were many other notebooks using this CPU)

> Comment #16
> Markos, the CPU is very old (~5+ years). 
Incorrect: launch date of this CPU was Q3 '09; please see: http://ark.intel.com/Product.aspx?id=42779
These CPU's are still being sold/implemented.

> Comment #18
> Sigh, a p4_clockmod discussion again.
Yes, I think the correct discussion should mostly be about acpi-cpufreq.

But just to make certain: in case of overheating, where does linux control the thermal protection of these CPU's? Especially now, WITHOUT drivers?  If the answer here is p4_clockmod (or acpi-cpufreq), one might even think about raising the importance of this bug, considering the potential overheating isues, which are of course not uncommon in notebooks.

>  machine is a
> > standard HP Pavilion A630N machine (presumably which hundreds of thousands
> > were manufactured in the 2003-2005 time frame).
> Which does not support CPU frequency scaling, where is the problem?
> The CPU itself simply cannot do it.
I hope it is clear by now that the SU2300 in the HP Pavilion dm1-1110ev *DOES* support CPU frequency scaling.

> Hmm, this machine does not even support C2...
Luckily for us, the SU2300 supports C1/AutoHALT, C1/MWAIT, C2, C3 and C4, otherwise we would all (presumably) be forced to go back to running Windows on our notebooks.

I hope this bug can be truly resolved, if not, can anyone point me to the  "documentation" with which to "Resolve" this bug, as mentioned in the bug "Status"?

Thanks.
Comment 20 Markos Chandras 2010-10-23 11:28:13 UTC
I am not that familiar with the whole concept, but it looks quite strange to me how is it possible for a brand new *netbook* to have a CPU that does not support frequency scaling ( It is speedstep capable according to the docs ). Sad thing I never tried running windows on it so verify whether it works or not. Either HP has failed really bad or I don't know...
Comment 21 Patrick Viane 2010-10-24 10:03:34 UTC
After a deeper look into the link provided by Thomas Renninger in Comment #14, and into the datasheet (both of which I should have done in the first place instead of skimming them, sorry for that), it's clear that an important point is the reference to the datasheet, page 30, note 10, which states: "SU2300 processor operates at same core frequency in HFM and LFM" (HFM = Highest Frequency Mode, LFM = Lowest Frequency Mode).  *If* the processor doesn't have a Super Low Frequency Mode (SuperLFM) as stated on page 26 of the datasheet (not really clear), the processor would indeed run at only one frequency.  So it looks like "Enhanced Intel SpeedStep Technology" doesn't automatically imply frequency scaling.

Without SuperLFM, voltage scaling and/or C-states seem to be the best candidates to explain why battery life under Windows was longer than under Linux (but I'm not the expert here).

The question in my previous comment about thermal management in situations where one is not able to load p4-clockmod as a "driver of last resort", stems from the following remark at https://patchwork.kernel.org/patch/7786/ and similar comments elsewhere:
> This is one reason why in .30 the user interface for p4-clockmod is disabled.
> It'll only get throttled when ACPI goes into OMG I'M OVERHEATING mode,
> and ramp back up once it cools off.
Comment 22 Thomas Renninger 2010-10-24 23:10:02 UTC
> But just to make certain: in case of overheating, where does linux control
> the
> thermal protection of these CPU's? Especially now, WITHOUT drivers?
There is for example a HW based thermal protection.
The HW will throttle (same technique as p4_clockmod) automatically and send a MCE (Machine Check Exception) to inform the user.
Compare with:
arch/x86/kernel/cpu/mcheck/therm_throt.c
Even if this should not be implemented, the CPU will always have a "switch off hard" mechanism in case of not working or missing fans and similar.

> If the
> answer here is p4_clockmod (or acpi-cpufreq), one might even think about
> raising the importance of this bug, considering the potential overheating
> isues, which are of course not uncommon in notebooks.
As it's not only HP, but several vendors (every?) showing this issue with this specific CPU model, I expect it's working as designed.
Comment 23 Robert Bradbury 2010-10-25 17:33:51 UTC
Thomas, you should have such a P4 machine plugged into a watt-meter as I currently have.  I am (with the kernel modified back to the old p4-clockmod driver) able to detect a significant power savings as the machine scales itself back from 2.8 Ghz to lesser speed power savings [1].

p4-clockmod, as distributed prior to ~2.6.30, *did* work, in at least lowering power consumption when it did not need to be running at 2.8GHz (which on my machine might be only 2-4 hours/day).  Mucking with the BIOS to add "real" ACPI support for reduced power consumption (if the CPU can even support it) is way beyond the capabilities of most users of Linux.

I think the problem is that some kernel developer didn't like the responsiveness of  a machine using p4-clockmod and changed the timing which allowed it to work quite effectively on many/most desktop machines [2].

Its simple for me -- I just change the code back to what worked when I upgrade kernels.  But unless you are comfortable hacking the kernel (not something I consider likely with most Ubuntu users) that is difficult.

Now if the kernel developers would like to release BIOS code for a HP Pavilion with a Pentium IV Prescott CPU which *does* support acpi-cpufreq and no longer generates the message: "cpufreq-core: initialization failed" then I would be willing to consider testing it.

1. The power savings dropping from 2.8 GHz to 350 MHz is 144 to 109 W or nearly 24%.
2. This is spite of the fact that p4-clockmod has a variety of information/adjustment params in /sys/devices/system/cpu/cpu0/cpufreq which could be set to manage the responsiveness of the machine for various workloads [3].  It seems to be a case of using a sledge-hammer to fix something that could have been fixed with a jeweler's screwdriver.
3. Which appear to be undocumented.  So unless you know how to read the source code you cannot "tune" the machine easily.
Comment 24 Thomas Renninger 2010-10-28 15:30:57 UTC
Robert: Please stop writing wrong assumptions you claim to know for sure. Also only providing half information is nearly as bad as writing wrong ones.
> The power savings dropping from 2.8 GHz to 350 MHz is 144 to 109 W or nearly
> 24%.
I expect this is when the CPU is fully utilized?
The fact that you missed out some measures, smells like you do not like the data, right?
But this bug is about something totally else, please open a new bug, add me to CC and attach all info requested in comment #18. This is not about compiling a kernel, it's simply measuring with a reboot in between, it doesn't take long...


For this very specific CPU this is about, I asked people who may have an idea, but did not get an answer yet. Until now I expect freq switching is not supported. But as deep C-states are, it's not that bad, you want to sleep as soon as possible anyway.

Note You need to log in before you can comment on or make changes to this bug.