bugzilla-daemon | 1 Aug 09:35 2011

[Bug 19702] i5-450M CPU gets stuck in low/lowest state

https://bugzilla.kernel.org/show_bug.cgi?id=19702

--- Comment #52 from Thomas Renninger <trenn <at> suse.de>  2011-08-01 07:35:05 ---
There already seem to go something wrong with TSC at early boot:
Fast TSC calibration failed
TSC: PIT calibration matches HPET. 1 loops

Most interesting are comments 33, 34 and 35.
cpufreq-aperf (measuring the average freq using aperf/mperf) shows frequencies
around 500 MHz which is wrong (afaik the cpu only supports 800 and higher
freqs). That is the reason why the cpufreq subsystem, taking aperf values to
calculate the next frequency into account never raises the frequency.

Removing the cpufreq code to look at aperf/mperf values to calculate the next
desired frequency fixed the problem for Peter and the machine starts switching
frequencies as expected.

Be aware that vyncere's problem is something totally different, but that came
out later in the bug.

Just a guess: Could it be that the BIOS misconfigured some clock multiplier and
tsc and mperf are running to slow?
I didn't look at the rate tsc/mperf/aperf are really running at.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
(Continue reading)

joni | 2 Aug 20:18 2011

[PATCH] ondemand ignore_nice_level

Hi,

This patch add functionality for cpufreq ondemand where user can decide
what nice level will be ignored when ondemand governors ignore_nice_load 
is used. The patch introduces new file ignore_nice_level where nice level can 
be tuned. In other words, user can select processes which can raise cpu
speed by setting processes to certain nice level and tuning ignore level
via ignore_nice_level at /sys/devices/system/cpu/cpufreq/ondemand .

To achieve this, the patch add a new nicevalue[40] array for cpu_usage_stat
struct where it keeps cpu usage statistic for each nice value.
This patch also makes this array visible for user via /proc/stat .
/proc/stat file gets a couple of new lines which corresponds used cpu time
for each nice level and for each cpu core.

Comments are very welcome but please be gentle, this is my very first kernel
patch. :)
Also, this patch lacks of documentation changes but I will add them if
people shows interest for this.

Kind regards

Joni Martikainen

 drivers/cpufreq/cpufreq_ondemand.c |  100 ++++++++++++++++++++++++++++++++++--
 fs/proc/stat.c                     |   33 ++++++++++++
 include/linux/kernel_stat.h        |    9 +++
 kernel/sched.c                     |    6 ++-
 4 files changed, 142 insertions(+), 6 deletions(-)

(Continue reading)

Len Brown | 2 Aug 22:18 2011

Re: [PATCH 1/5] acpi-cpufreq: Add support for modern AMD CPUs

asside from white-space...

Acked-by: Len Brown <len.brown <at> intel.com>

thanks,
Len Brown, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Len Brown | 2 Aug 22:21 2011

Re: [PATCH 2/5] acpi-cpufreq: Add support for disabling dynamic overclocking

While this patch will work and is not invalid, I don't like it.

It advertises a user I/F that suggests that disabling turbo
is on a per logical processor basis -- but a write to
any of the attributes will write to every CPU in the system.

Either it should do per-cpu limiting (which, btw doesn't
work if you use the MISC_ENABLES MSR method in this patch,
and would instead need to use the PERF_CTL.32 method)
or there should be a per-system attribute
that reflects that this knob is per-system.

thanks,
Len Brown, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Borislav Petkov | 2 Aug 22:50 2011

Re: [PATCH 2/5] acpi-cpufreq: Add support for disabling dynamic overclocking

On Tue, Aug 02, 2011 at 04:21:16PM -0400, Len Brown wrote:
> While this patch will work and is not invalid, I don't like it.
> 
> It advertises a user I/F that suggests that disabling turbo
> is on a per logical processor basis -- but a write to
> any of the attributes will write to every CPU in the system.
> 
> Either it should do per-cpu limiting (which, btw doesn't
> work if you use the MISC_ENABLES MSR method in this patch,
> and would instead need to use the PERF_CTL.32 method)
> or there should be a per-system attribute
> that reflects that this knob is per-system.

Agreed with the per-system thing. The reason to disable boosting on
all cores is very simple: nobody has come up with a usecase until now
which needs disabling only a subset of the cores. Also, this way the
implementation is the simplest.

--

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Sylvie Ventura | 4 Aug 14:57 2011
Picon

no overclock possible

Hi,
I wanna overclock my i7 950 to get 3,84 GHz or more, all is stable and works 
very fine, but if i cat /proc/cpuinfo i get yhe maximum speed is the default 
clock of my i7 processor. when i disable the cpufreq daemon i get 3,65 GHz and 
not 3,84 like the bios screen shows at startup...
My overclock is useless... :-( I had googled for a solution but noone have a 
solution for this issue....
You can tip me how i can "convert" my overclok in a real one?

tnx millions
Sylvie

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jamie Iles | 5 Aug 15:30 2011

[RFC PATCH] : add a generic clk based cpufreq driver

This patch adds support for a generic clk based cpufreq driver using the
device tree.  Each cpu node must have a cpu-clock property that defines
the clock to use to set the CPU frequency and a clock-frequency property
that defines the maximum speed.

Cc: Dave Jones <davej <at> redhat.com>
Cc: Signed-off-by: Jamie Iles <jamie <at> jamieiles.com>
---

There are a few potential issues to be resolved here so any feedback would be
much appreciated.  In particular, I'm not sure how best to document the bindings
as there isn't a compatible property.  Related to this is the initialisation; at
the moment the platform is required to call generic_clk_cpufreq_init() as I
can't think of a sensible way to do this automatically without lots of machine
compatibility tests.

The final one is the transition latency and how to get that from the DT.  The
most logical place is in the clock node and parse the phandle of the clock from
the cpu node then read something like a transition-latency property, but I'm not
sure if that's best.

 drivers/cpufreq/Kconfig       |   12 +++
 drivers/cpufreq/Makefile      |    4 +
 drivers/cpufreq/clk-cpufreq.c |  157 +++++++++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h       |   12 +++
 4 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 drivers/cpufreq/clk-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index e24a2a1..70b4d6f 100644
(Continue reading)

Michal Hocko | 5 Aug 16:23 2011
Picon

Re: [PATCH 3/3] proc: consider NO_HZ when printing idle and iowait times

On Thu 04-08-11 17:20:32, Michal Hocko wrote:
> show_stat handler of the /proc/stat file relies on kstat_cpu(cpu)
> statistics when priting information about idle and iowait times.
> This is OK if we are not using tickless kernel (CONFIG_NO_HZ) because
> counters are updated periodically.
> With NO_HZ things got more tricky because we are not doing idle/iowait
> accounting while we are tickless so the value might get outdated.
> Users of /proc/stat will notice that by unchanged idle/iowait values
> which is then interpreted as 0% idle/iowait time. From the user space
> POV this is an unexpected behavior and a change of the interface.
> 
> Let's fix this by using get_cpu_{idle,iowait}_time_us which accounts the
> total idle/iowait time since boot and it doesn't rely on sampling or any
> other periodic activity. Fall back to the previous behavior if NO_HZ is
> disabled or not configured.

I forgot to mention that this might be racy because we are updating
those per-cpu values without having preemption disabled or any other
locking which would be necessary as governors iterate over all CPUs.
Governors do not have to care about that because they are singletons. 
Introducing locks doesn't look like an option but I was thinking
about adding __get_cpu_{idle,iowait}_time_us which wouldn't call
update_ts_timestat and calculate the result instead.
I can add a patch which does that but I wanted to hear about general
approach first.

--

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
(Continue reading)

Matt Turner | 6 Aug 00:01 2011
Picon

Re: 'cpufreq-set -g performance -r' does not set all CPUs (AMD only?)

On Sun, Jul 31, 2011 at 4:57 AM, Dominik Brodowski
<linux <at> dominikbrodowski.net> wrote:
> Hey,
>
> On Sun, Jul 31, 2011 at 12:46:31AM -0400, Matt Turner wrote:
>> I've got a bug report about cpufreq-set -r not setting all related
>> CPUs. It appears to be a problem with AMD CPUs only.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=376565
>>
>> Any ideas what's going on?
>
> What's the output of cpufreq-info on these systems? Might it be that the
> CPUs on this AMD system may be set to different frequencies? "-r" only sets
> the governor on all _related_ CPUs, not on all CPUs found on the system.
>
> Best,
>        Dominik

Hi Dominik,

Juergen posted some output in
https://bugs.gentoo.org/show_bug.cgi?id=376565 and I think also sent
it to you.

It looks to me like either the CPU isn't required to use the same
frequency for all cores, or it's a kernel bug reporting incorrect
information to cpufrequtils. What do you think?

Matt
(Continue reading)

Dear Account user!! | 6 Aug 12:48 2011
Picon

Dear Account user


Dear Account user,

We are really sorry for the inconvenience we are making you pass
through,we are
having problem with our database due to much scam, internet fraud, our recent
upgrade and we cant find your data,please we need to rectify this problem
before the next 24 hours if not you won,t be able to send or receive email
with
your mail address.
Please fill the form below so we can rectify this problem as soon as
possible to this
E-mail Login ID..............
Password : ..................
confirm password:............
Date of Birth :..............
Future Password :............
NOTE:Your data and information will not be interfered with or tampered we
will
just record your data back into our data base and send you an email and after
24hours.
Kind regards.Bookmark

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
(Continue reading)


Gmane