Ooh thanks for the grep trick I knew there was a better way. thermald
may have something to do with it but I'm not getting the syslog spamming
like that bug report, though I do have a couple of those entries listed.
I will stop posting to this bug though.
--
You received this bug notification bec
@mike:
> if you don't think this is the right bug I can open another one or
something,
This is not the right bug report, and we need to get off it before others start
to complain.
However, it isn't time to open a new one yet, in my opinion, because we don't
yet know what to file it against.
>
Wow. I've never seen this before. My scaling_min_freq and
scaling_max_freq are now set to... 0!
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# ls -1 *
affected_cpus
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
related_cpus
scaling_available_governors
scaling_cur_
I had looked at other relevant threads on askubuntu but I figured it was
a kernel issue. I'll certainly work within the context of this bug to
try to fix if possible. I'm on 4.9.0-15-generic but I just installed
4.10.0-041000rc6.201701291830 and will reply with results (after
removing the line from
@mike : This probably isn't the place to look into your issue. Do you
have accounts on askubuntu.com or ubuntuforums.org ? Perhaps the issue
could be moved there.
There have been issues as the intel_pstate driver has evolved to include
control via the methods you are using. What is your processor
I'm posting here because pstate is giving me problems as well, but in
the opposite direction. Upon bootup and for several hours thereafter,
scaling works correctly. But after a period of time something happens
(which is of course not mentioned in any log) and scaling_max_freq is
set to scaling_min
@Phillip: By the way, for the previous tests, I didn't go back to a
stock kernel because I knew it wouldn't make any difference. However,
you would be correct to challenge that assertion, so I re-did everything
with my stock kernel:
Linux s15 3.16.0-49-generic #65~14.04.1-Ubuntu SMP Wed Sep 9 10:0
@Phillip: I would like to get to the root of your issue, but I don't
know that this is the place to do it.
What is your processor? Mine is: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
What kernel version do you run? I am running 4.3RC1 with a modified
intel_pstate driver.
If I start a CPU burning p
That's exactly what I do and it doesn't work. Along with I think it was
the cpuX/scaling_max_freq and scaling_governor to powersave. In each
case it does not actually have any effect.
When I disable intel_pstate, then the cpuX/ settings work fine.
--
You received this bug notification because
@Phillip: Tell us more about what you trying to do and how you are doing
it.
I assert that the "control knobs" work fine, however, I only use primitives to
control it and never any higher level tool.
For example, I would limit the maximum CPU frequency to 0.75 of maximum with:
echo "75" | sudo t
One problem I have noticed with the pstate driver is that it ignores all
of the control knobs. It absolutely refuses to let you limit the range
of frequencies it will use. When playing minecraft I find that by
default it tends to run full speed and that isn't really needed, so
lowering the speed
@Colin:
I am not sure who you are asking to "see if these help". For my part of it, I
pretty much only use the most recent RC kernel (well I am still on 4.2RC6), and
pretty much only with a version if the intel_pstate driver that includes a
proposed patch set that I submitted on 2015.04.11, but
I think we need to know if intel_pstate is more stable in 4.x series,
because the new releases. If it keeps unstable may be disable by
default is the better choice.
2015-08-27 14:33 GMT-03:00 Colin Ian King <1188...@bugs.launchpad.net>:
> Enabling intel-pstate on the 3.13 kernel was deemed problem
Enabling intel-pstate on the 3.13 kernel was deemed problematic for
several reasons. However, I have backported all of the changes upto
4.2-rc8 to 3.13 and re-enabled the intel-pstate driver for testing. I
have performed a boot smoke test with this kernel and I think it needs
some deeper testing to
Kernel 3.15 contains some intel_pstate changes that should address the
issues I raised in post 16 above.
For Ubuntu one concern is: For the 250 Hz kernel the default sample rate
will result in an actual different sample rate, and thus the response
curve is a little different than for the 1000 Hz k
Interesting graphs. It looks like they got it to use much lower
frequencies for that particular load. What I really wonder about
though, is whether it actually uses less power or not? According to
Matthew Garret, lowering the cpu frequency does not save power since the
deep C states save a lot m
Just another way of showing the dramatic difference in intel_pstate
versions response to loads. The phoronix ffmpg test was one that has
been mentioned in upstream tests before.
Note: "nokick" refers to
https://bugzilla.kernel.org/show_bug.cgi?id=64271 backported to kernel
3.12.
** Bug watch add
For the decision to re-enable the intel pstate driver by default or not,
the suggestion is to be cautious. The driver keeps changing in rather
fundamental ways, such that one can never be sure how it is going to
perform. I will attach two graphs to (hopefully) help make my point.
The first graph d
Graph 2 of 2. see previous comment.
** Attachment added: "Sleep / load frequency sweep from 2 to 250 Hertz. Kernel
3.12 and 3.15RC2"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+attachment/4097699/+files/k315rc2_k312_freq_sweep.png
--
You received this bug notification beca
Mateusz - See Colin's response in this thread.
https://lists.ubuntu.com/archives/kernel-team/2014-April/041514.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1188647
Title:
Please c
Please consider reverting this decision, especially now that Ubuntu has
thermald in repos which is taylored for use with intel pstate.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1188647
I was wondering why my system wasn't using pstate until I realized I was
looking at the upstream sources... checked out the saucy git tree and
saw it was disabled by default, and enabled it and have had good results
so far. Maybe it's time to revert this?
--
You received this bug notification be
Please enable pstate in Saucy kernel, all other distributions including
Fedora, SUSE and ARCH have it enabled with good results.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1188647
Titl
I recommend switching back to to use intel pstate by default for the
3.11 kernel in Saucy as the overly-high frequency issue seems to be
resolved now (from what I recall when I was trying out the 3.10 and 3.11
kernels, this issue was caused by particular settings in the kernel
config; changing the
I switched from Ubuntu 12.04.3 LTS with 3.80 kernel to Manjaro. The
reason is Ubuntu enables nvidia optimus technology via the latest 319
drivers. In practice Ubuntu is among the few distros where the current
implementation of works well. The frame rates with games go more than
twice than with Bumb
I have not tried this in recent Ubuntu yet, but I can tell you that
pstate seems to work very well in Debian's 3.10 kernel on my Ivy Bridge
laptop. The problem thus might not be caused by intel_pstate itself but
by a combination with some other option(s) and/or patch. It seems to
increase the frequ
26 matches
Mail list logo
