The way it is currently done, I don't think valid CPU frequency listing
via "scaling_cur_freq", or /proc/cpuinfo, is expected to work. Why not?
Because the required code is never executed, on purpose. Here is an
excerpt from a commit (see the bit about NOHZ full)
commit f3eca381bd49d708073ba1a9af
CPU frequency scaling driver: intel_pstate
CPU frequency scaling governor: powersave
HWP: disabled.
Purpose to verify that the driver is working correctly, regardless of CPU
frequencies reported.
A single threaded load was applied to CPU 5 at 347 hertz sleep/work frequency.
The load was increase
There is a high probability that the root issue here is related to some work
done in August September.
There was already an outstanding issue with intel_cpufreq driver / schedutil
governor, hwp enabled.
References:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5
I redid the Phoronix Stress-NG 0.16.04: Socket Activity test, the one
that showed such a dramatic difference in their test. I increased to
number of test runs from 3 to 10 and time per run from 30 to 60 seconds.
I got:
250Hz kernel (generic): 6608.74 Bogo Op/s, Deviation 0.56%
1000Hz kernel (lowla
Yes, this happens also with the mainline kernel.
It also happens with the intel_cpufreq CPU frequency scaling driver
(i.e. the intel_pstate driver in passive mode), and all governors. It
also happens with the acpi-cpufreq CPU frequency scaling driver, and all
governors. However the manifestations
I confirm your findings.
In my case I am using: The intel_pstate CPU frequency scaling driver;
powersave CPU frequency scaling governor; HWP, HardWare Pstate, control
is disabled; A mainline kernel, 6.8-rc1, compiled with the kernel
configuration changes being considered in that other bug report.
For the Stress-NG 0.16.04: pts/stress-ng-1.11.0 [Test: Socket Activity]
I get:
6633.31 Bogo Ops/s on a 1000Hz kernel. 0.9% improvement.
6572.92 Bogo Ops/s on a 250 Hz kernel.
I did this in a hurry, and will re-test tonight or tomorrow.
--
You received this bug notification because you are a mem
Before my post yesterday, I had never used the stress-ng utility, and
only did so to repeat the originally posted test case. However, there
was run to run variability with the stress-ng test that I could not
understand for a 100% user, 0% system, type program. I decided to retest
using one my own C
I found this bug report by accident, while searching for something else.
I pretty much only use mainline kernels and only 1000 Hertz.
I support this proposed default Ubuntu kernel configuration change.
The tick ISR is incredibly efficient (less than 2 uSec on my test
system), and I do not understa
O.K. thank you for your input. I confirm deletion of "--video=vmvga"
allows things to continue.
Historically, that was needed in and since 2013, when the default video
"cirrus" did not work. I now observe the default video is "qxl" which
seems to work.
Ya, apport logs are not needed for this bug.
I would still likes to know what MSR 0x64F says, as per comment #20.
Yes, thermald should have been disabled for all of this stuff, and I
thought it was.
Recall one the askubuntu threads, where I suggested writing 0x4005C to
MSR 0x1FC. Do so at your own risk.
Your hardware seems to have issues,
Your processor is indicating this:
PROCHOT# or FORCEPR# Event (bit 2, RO) — Indicates whether PROCHOT# or FORCEPR#
is being
asserted by another agent on the platform.
The related sticky log bit is also set.
This is something I suspected a couple of months ago, on one of those
askubuntu threads.
Sorry, 0x16f was wrong, it should have been 0x64F. I have no idea why
you are doing strace on this stuff. Since you haven't used my decoder,
it will be sometime before I manually decode.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ther
Since the intel_pstate driver is asking for 3.4 GHz, but the processor
itself is only granting 0.8 GHz we now know that the throttling is
within the processor and not externally driven.
It might be related to what koba noted in comment #8, I don't know.
The processor has MSRs with bits to indicat
When the frequency seems stuck at 800 MHz, then please put a load on a
CPU and look at the pstate request and granted MSR's.
Example, where I force CPU 2:
$ taskset -c 2 yes > /dev/null
and then look at the request and granted pstates:
$ sudo rdmsr --bitfield 15:8 -u -a 0x199
8
8
48
8
30
8
8
8
Try changing to the powersave governor. If something else set another
pstate request and the intel_pstate driver doesn't know about it, then
with the performance governor it might never send a new pstate request.
All of this is very similar to a few months ago, on askubuntu and the path of
invest
If the intel_pstate scaling driver is "active" then "powersave" is the
default governor. If the driver "passive" or the is the acpi-cpufreq
driver during boot, then the default governor will be "ondemand". Note
that "active-powersave" is crudely the equivalent of "passive-ondemand".
You can elimina
He is using the intel_pstate CPU frequency scaling driver. Now by
default processors without HWP will boot into the intel_pstate driver in
passive mode (A.K.A. intel_cpufreq).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to thermald in Ubu
** No longer affects: linux
--
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/1215665
Title:
With Kernel 3.11RC6 Ubuntu servguide PDF compile crashes
Status in linux package in Ubuntu:
F
Within the context of this bug report it is valid, as it is specifically
about the mainline PPA.
** Changed in: linux (Ubuntu)
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bu
When we try to help people, either here on launchpad or on forums, very
often we would like them to try the latest mainline kernel, just as a
test to determine if the issue has already been fixed upstream. This bug
prevents that useful option for previous Ubuntu versions.
This dependency should be
Public bug reported:
Modern Intel Processors (since Skylake) with HWP (HardWare Pstate)
control enabled and Idle State 2, C1E, enabled can incorrectly drop the
CPU frequency with an extremely slow recovery time.
The fault is not within HWP itself, but within the internal idle
detection logic. One
For what it's worth, the versions of things in my test computers, all
servers, no GUI:
name: serv-ff (a 20.04 VM, that has not had an update since around February
12th):
initramfs-tools: 0.133ubuntu14
kmod; 26-3ubuntu1
name: s18 (a physical i5-9600K based computer, up to date as of a few days ag
** Changed in: kmod (Ubuntu)
Status: New => Confirmed
--
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/1864992
Title:
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() c
I have a 20.04 VM that I had not run for awhile (Feb 12th). It has kmod
version 26-3ubuntu1, and installed mainline kernel
5.6.0-050600rc4-lowlatency fine.
The other two physical 20.04 test servers have kmod version 27-1ubuntu1,
and both spew the error 5600 times during kernel installation the fir
*** This bug is a duplicate of bug 1863261 ***
https://bugs.launchpad.net/bugs/1863261
I don't think this is duplicate either. I agree that this seems to be in
the kernel, but don't yet have proof. If I compile the mainline kernel
(5.6-rc4) myself i get this error 5600 times (once per module):
Each CPU can have a different request into the PLL (phase locked loop),
but the highest one wins, and their vote does not count if they are in
an idle state deeper than C1. You can observe this manually by reading
the pstate request and granted MSRs directly (requires msr-tools, and
the msr module
There is only one PLL (Phase Locked Loop) in the processor, all CPUs get
the resulting clock. When they go into deep idle states (deeper than C1,
at least for my processor) then they give up their vote into the PLL as
to what the frequency should be. Your single 100% task is dedicating the
CPU freq
@Davide Sangalli: What you describe and show in your comment #80 is
correct and exactly what should happen. Your processor is spending an
extraordinary amount of time in C1 as opposed to deeper idle states. At
what sampling frequency do you run i7z? I would suggest once every 15
seconds or so, so t
Ever since the default changed to never blanking the screen, and after I
whined in comment #18 above, I have been running this in
/etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT=" consoleblank=300 "
always save a copy of grub first, and do "sudo update-grub afterwards",
then re-boot.
--
You recei
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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/1844201
Title:
turbostat is over constrained by dependencies
Status
You do not need any logs for this bug report.
** Changed in: linux (Ubuntu)
Status: Incomplete => New
--
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/1844201
Title:
turbostat is o
Public bug reported:
For processors on which it works, turbostat is a very very good
diagnostic tool. For many upstream escalations, it is the preferred
tool. However the Ubuntu implementation doesn't actually execute
turbostat directly, but rather goes to some script with incredibly
tight, and un
the source code for the serverguide is migrating to a different markup
language for 20.04. The migration was done a few days before these
revisions were committed. They need to be copied to the new source. I am
attempting to add "target to series" stuff to this bug report, but it is
not working, li
Several posters are asking for the mainline builds to be fixed. The
mainline builds are an exact reflection of the upstream git master
repositories. Therefore they have to wait for Seth's patch submission,
which has been picked up and accepted by the kbuild team, to propagate
it's way to the mainli
This is duplicate with bug 1830961.
--
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/1836373
Title:
Mainline builds for 5.1 and 5.2 failing for amd64 and i386
Status in linux package in U
If I make the same changes to the Makefile as per the link in comment
#16, then the kernel compiles fine and without the zillions of warnings
I mentioned in comment #13. However I can not find this anywhere
"upstream" as the notes seem to indicate.
doug@serv-ee:~/temp-k-git/linux$ git diff
diff --
I get the same on my 16.04 test server.
However, things seems to work fine, if I allocate enough memory, on my
test 18.04 server VM (which runs on the aforementioned 16.04 test
server).
My real purpose here is to update the Ubuntu serverguide to deal with
bug 1769130.
--
You received this bug n
Part of this bug report is a duplicate with bug 1766728, and I believe
that was fixed as of a couple of hours ago. The other part of this bug
report, about needing libssl1.1, isn't fixed, as far as I know.
--
You received this bug notification because you are a member of Kernel
Packages, which is
@Eric (although you do not seem to have subscribed to this bug report).
Your issue is different than what this bug report is/was covering.
--
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/164
Kernel 4.12-rc1 has this change, so the console now defaults to never
going blank. I disagree with this change.
--
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/869017
Title:
Ubuntu server
@Walter: On our forums exchanges, I missed that your "stuck" messages
have "[ksmd:64]" at the end. I get that often also, but I also sometimes
get "[qemu-system-x86:8549]" and "[qemu-system-x86:8552]".
I do not know what commits may or may not have been migrated back to
kernel 4.10. At least for m
For me these messages were a side effect of unattended upgrades, and the
os-prober running as some auto-removal thing. All stuff that I do not
want, and did not use to be the default. Having either disabled or
uninstalled that stuff, I now expect these message to go away.
--
You received this bug
The correct upstream link is:
https://bugzilla.kernel.org/show_bug.cgi?id=194835
--
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/1671287
Title:
I'm not working with SGI, JFS and QNX4.
St
The upstream link is no good, and I haven't been able to find it on
bugzilla.kernel.org by searching.
It is unclear to me why this bug report was set to incomplete.
While I do get the log entries listed herein, I am also using the latest
mainline kernel, 4.11-rc5 (but also noticed it for the last
@fish : Yes your issue does not belong here.
To figure out where your issue actually belongs, some details are
missing:
If your stuck at low frequency issue only occurs after a suspend and on
battery power, then your issue is covered by:
https://bugzilla.kernel.org/show_bug.cgi?id=90041 (and it i
@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.
>
@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 would not expect to see this issue in 16.04, and don't on my test
16.04 server, with the default, up to date, kernel. (Linux s15
4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux).
--
You received this bug notification because you are a member of Kernel
I tested kernel 4.10-rc1, and the issue is solved with it.
I'm not sure how to test the yakkety proposed kernel, because the
instructions seems to be for a desktop computer, and this issue shows up
much much more clearly on my server computers.
--
You received this bug notification because you a
I didn't see the third commit mentioned which I thought was also
required:
mm: memcontrol: use special workqueue for creating per-memcg caches
Anyway, I'll test also, once kernel 4.10-rc1 is ready.
The upstream bug report is this one:
https://bugzilla.kernel.org/show_bug.cgi?id=172991
** Bug w
One of the 3 patches was included in the mainline kernel sometime ago.
It fixed SLAB, but not SLUB. The other two patches are now in the
mainline kernel and will appear in kernel 4.10-RC1. I'll re-test then.
--
You received this bug notification because you are a member of Kernel
Packages, which
> Are you sure SLAB vs. SLUB fixed this?
No, it does not fix the issue. However, the issue is more difficult to
re-produce. It seems easy enough to reproduce on my test server, but
seems to not happen on my test LapTop.
There are 3 related upstream commits that fix the issue (at least in my
testi
> Doug - you should start a new bug to address your issue as this
> one will auto-close as soon as the next kernel is uploaded.
I do not understand. This one is not solved, as there two levels of
contributing factors. This one should be set back to a status of "In
Progress". Once both SLAB and SLU
I filed two bug reports upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=172991
https://bugzilla.kernel.org/show_bug.cgi?id=172981
I also made a kernel 4.8-rc8 with 81ae6d03 reverted (because it is so trivial
to revert) and no matter how hard I beat on it I can not get it to mess up.
**
I was working on the assumption that the same commit was causing both
the SLAB and the remaining SLUB issues, however it turns out that
assumption was incorrect.
The commit that causes the SLAB issue is:
801faf0db8947e01877920e848a4d338dd7a99e7
"mm/slab: lockless decision to grow cache"
The commi
In case anyone is interested:
I got this far with the kernel bisection, but can only continue on Tuesday,
maybe Monday night.
** Attachment added: "bisection - thus far"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+attachment/4748136/+files/bla1.txt
--
You received this bu
Note: For kernel work, I only use and compile kernels from the main
kernel.org git branch. I steal the Ubuntu kernel configuration.
The issue of a high number of kworker threads does not exist in kernel 4.6, but
does in 4.7-rc1.
When using "SLUB" it is a little difficult to detect on my Yakkety t
>From my experiments, it seems the issue is not 100% solved, but is much much
>much less probable.
On my Yakkety test Laptop, if I go back to kernel 4.4.0-9136-generic I can not
create the high number of kworker threads. If I boot with kernel
4.8.0-16-generic, I can create the high number of kwo
I confirm that reverting the SLAB / SLUB changes in the ubuntu kernel
configuration file for mainline kernel 4.8-rc7 to the state they were in
for mainline kernel 4.7-rc4 fixes the issue (note, I disable debug,
because otherwise it takes over twice as long to compile the kernel, and
it is enormous)
This issue was introduced with the massive kernel configurations changes
between mainline kernels 4.7-rc4 and 4.7-rc5. While I have been working
on it for a couple of weeks, I was never able to isolate the exact
kernel configuration change cause. I am compiling a kernel now (4.8-rc7)
reverting this
@Haw Loeung: In addition to what I wrote earlier:
> With the new Ubuntu archive servers, we saw constantly high load
> and after some tinkering, we found that it was mostly CPUs
> being woken up to see if they should enter idle states.
> Changing the CPU frequency scaling governor to "performance"
@Haw Loeung: It would be good to understand in more detail your
findings. As far as I know (and I am not an expert in this area), great
care has been taken to avoid things like wakeups just to decide to go
idle.
I did a test on my computer (Ubuntu 16.04 server, no GUI), but to avoid
extra overhead
The table formatting got messed up, trying again:
Load: idle0.5XX 2X 3X 4X 5X 100%
powersave 570811037 16075 29147 45913 61165 76650 81695
3.817.3610.72 19.43 30.61 40.78 51.10 54.46
performance
Using kernel 4.8-rc5 I did some energy tests, using a SpecPower simulator that
I made one time. I reused intel_pstate powersave data from a previous test.
Reference:
http://marc.info/?l=linux-kernel&m=147326197513427&w=2
Big numbers are Joules (package Joules from turbostat)
Smaller numbers are
>> The preferred governor with the intel_pstate driver is powersave.
> Do you have some references/proof for that? This is contrary to what
> kernel developers say, see comment 1.
In my opinion, that reference is obsolete.
While I don't work for Intel, the intel_pstate CPU frequency driver is
pr
What has been done here is incorrect.
The old "ondemand" script was modified so that if the intel_pstate
driver was being used, and therefore "ondemand" did not exist, it would
fall through to setting the "powersave" governor (refer to bug
#1314643). Note that "powersave" with the intel_pstate CPU
This issue no longer occurs on my computer.
The a fresh install on linux was done, and now the system is using
systemd whereas previously it was not. I am not certain systemd is the
difference, it is just my best guess.
--
You received this bug notification because you are a member of Kernel
Pac
Yes, the bug persists through kernel 4.4.
Having isolated the issue down to the exact causal commit, I do not know
what else I can do to move this one along.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.la
I found this:
https://lkml.org/lkml/2016/1/25/1233
and this:
https://bugzilla.kernel.org/show_bug.cgi?id=110931
** Bug watch added: Linux Kernel Bug Tracker #110931
http://bugzilla.kernel.org/show_bug.cgi?id=110931
--
You received this bug notification because you are a member of Kernel
Pack
> Upstream is discussing a fix that might allow both configurations
@Tim, could you point us to the upstream discussion?
--
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/1534647
Title:
Col
No, apport-collect 1534647 is not needed for this bug report.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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/1534647
T
** Description changed:
Late in the kernel 4.4 RC (Release Candidate) cycle (between rc7 and
rc8), Ubuntu implemented an amd64 kernel configuration change enabling
CONFIG_ZONE_DEVICE.
The related email: https://lists.ubuntu.com/archives/kernel-
team/2016-January/067683.html
- The c
Public bug reported:
Late in the kernel 4.4 RC (Release Candidate) cycle (between rc7 and
rc8), Ubuntu implemented an amd64 kernel configuration change enabling
CONFIG_ZONE_DEVICE.
The related email: https://lists.ubuntu.com/archives/kernel-
team/2016-January/067683.html
The commit message does
This issue persists though kernel 4.4-rc8.
--
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/1504584
Title:
As of kernel 4.3-rc1 system will not stay in S3 suspend
Status in Linux:
Confi
Additional information:
After a fresh boot with the bad kernel, turbostat shows: Pkg%pc6 =
97.84%; PkgWatt 4.01; CorWatt 0.28; GFXWatt 0.23.
Then after the first suspend resume, turbostat shows: Pkg%pc6 = 0.00%;
PkgWatt 10.08; CorWatt 3.04; GFXWatt 3.51.
PkgTmp goes up by more than 10 degrees.
Created attachment 118874
an edited version of the file the previous attachment asked for
I edited just to remove many lines of 0's.
--
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/1504584
Created attachment 118873
requested dmesg with drm.debug=14
Possibly relevant excerpt:
[ 399.518389] [drm] stuck on render ring
[ 399.518686] [drm] GPU HANG: ecode 6:0:0xfeff, reason: Ring hung, action:
reset
[ 399.518686] [drm] GPU hangs can indicate a bug anywhere in the entire gfx
sta
(In reply to Jani Nikula from comment #6)
> Did you double check the bisect by running both dc4be6071a24 and
> dc4be6071a24^ ?
Yes, of course, and I said so in my initial e-mail.
Truth be known, this was my second bisection, as I must have made a mistake in
my first attempt, because the double ch
(In reply to Jani Nikula from comment #8)
> First, run dc4be6071a24 and try suspend/resume
> several times, and see if it's 100% reproducible or not.
Yes, it happens every time. To say 100%, I would have to have a sample
space of about 1000 attempts. I did not do that many.
--
You received this
** Bug watch added: freedesktop.org Bugzilla #92414
https://bugs.freedesktop.org/show_bug.cgi?id=92414
** Also affects: linux via
https://bugs.freedesktop.org/show_bug.cgi?id=92414
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member
For your Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz processor, what is the
normal minimum pstate? I ask because I have only seen on battery power
resume from suspend issues that are related to Clock Modulation becoming
enabled. i.e. I am wondering if 800MHz is a normal minimum frequency or
below the
You don't need the logs. I already figured out the root issue, and already
submitted it upstream.
apport-collect has never worked for me. setting to "Triaged'
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ke
Public bug reported:
Note: this bug report is just for local tracking of an upstream issue:
Reference:
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077592.html
also copied below:
This started somewhere between Kernel 4.2 and 4.3-rc1,
but I only noticed it a day ago.
The first S
Isn't there another issue within this bug report? Why doesn't the acpi-
cpufreq frequency scaling driver support the higher available clock
frequencies?
Actually, maybe it does. Observe processor 3 from the cpuinfo listing:
processor : 3
...
cpu MHz : 2901.000
It is in turbo mode.
To the best of my knowledge, this specific (resume from suspend,
intel_pstate, performance mode) issue has been fixed in the upstream
kernel. However, I never understood this issue to be specific to battery
mode, an interesting twist.
Note that there are other issues, and sometimes it is hard to s
@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
@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
, just use primitive
commands and not these higher level utilities (that I neither use or
know anything about). For example use:
grep MHz /proc/cpuinfo
to observe CPU frequencies.
The commit that, I think, fixes this issue is:
commit 6c1e45917dec5e7c99ba8125fd8cc50f6e482a21
Author: Doug Smythies
@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
The kernel configuration is O.K. with respect to this issue as of kernel
4.1, and dmidecode works. Thanks.
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubu
** Description changed:
There is a relatively new kernel configuration parameter, CONFIG_DEVMEM.
- I do not understand why, but for some reason "is not set" for Ubuntu, and
therefore dmidecode does not work.
+ I do not understand why, but for some reason "is not set" for Ubuntu, and
therefore
You do not need the apport stuff for this bug report, it is not
relevant.
** Changed in: linux (Ubuntu)
Status: Incomplete => New
--
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/1462
Public bug reported:
There is a relatively new kernel configuration parameter, CONFIG_DEVMEM.
I do not understand why, but for some reason "is not set" for Ubuntu, and
therefore dmidecode does not work.
I think that, in general, we want dmidecode to work.
I found this:
https://lists.ubuntu.com
see also: https://bugzilla.kernel.org/show_bug.cgi?id=90421
particularly the entries from Marien.
This issue does not manifest the same for all i7 processors.
** Bug watch added: Linux Kernel Bug Tracker #90421
http://bugzilla.kernel.org/show_bug.cgi?id=90421
--
You received this bug notifi
*** This bug is a duplicate of bug 1314653 ***
https://bugs.launchpad.net/bugs/1314653
** This bug is no longer a duplicate of bug 1411802
"powersave" governor should be listed as one possible value for the ondemand
init.d script
** This bug has been marked a duplicate of bug 1314653
sy
*** This bug is a duplicate of bug 1411802 ***
https://bugs.launchpad.net/bugs/1411802
** This bug has been marked a duplicate of bug 1411802
"powersave" governor should be listed as one possible value for the ondemand
init.d script
--
You received this bug notification because you are a
I reviewed the Ubuntu kernel team e-mail thread.
I do not understand why the bug patch submitted upstream on November 6th seems
to have stalled.
I did observe that there wasn't an "ACK", that I could find.
So I wondered of the patch had been modified or another solution was found.
Is there any way
Thanks for your rapid attention on this one.
Just for completeness, I want to expand on this statement from the description:
"my system does seem to benefit from blk-mq"
That is, unless the IO load is high. With very high disk IO load, things fall
apart. For example I had a single disk seek time
1 - 100 of 128 matches
Mail list logo
