[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full breaks CPU frequency reporting
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 f3eca381bd49d708073ba1a9af4fa6ea5d5810a6 Author: Thomas Gleixner Date: Fri Apr 15 21:20:04 2022 +0200 x86/aperfmperf: Replace arch_freq_get_on_cpu() Reading the current CPU frequency from /sys//scaling_cur_freq involves in the worst case two IPIs due to the ad hoc sampling. The frequency invariance infrastructure provides the APERF/MPERF samples already. Utilize them and consolidate this with the /proc/cpuinfo readout. The sample is considered valid for 20ms. So for idle or isolated NOHZ full CPUs the function returns 0, which is matching the previous behaviour. There was couple of later commits and now it prints out the minimum CPU frequency when it thinks the number are stale. With NOHz full it always thinks the numbers are stale. The intel_cpufreq driver seems to display CPU frequencies okay, but only the pstate that was requested, not the actual frequency granted. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-lowlatency-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051733 Title: Specifying nohz_full breaks CPU frequency reporting Status in linux-signed-lowlatency-hwe-6.5 package in Ubuntu: Confirmed Bug description: With the lowlatency kernel, if I specify "nohz_full=1-15" boot parameter then CPU frequency reporting doesn't work for the logical cores 1-15. That is, only logical core 0 shows varying CPU frequency in its /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq file, all other cores constantly show 80 in their scaling_cur_freq files (which is the lowest supported frequency) regardless of the CPU load. Steps to reproduce: 1. Add "nohz_full=1-15" (specify the core numbers to include all logical cores except 0) to kernel boot options in /etc/default/grub. 2. Run `sudo update-grub` and reboot. 3. Upon booting, run a multithreaded workload. For example, run `openssl speed -multi $(nproc --all)`. 4. In another console, monitor CPU frequencies by running `watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq`. Actual results: All cores specified in "nohz_full" parameter always report their lowest frequency. Despite that, the actual performance seems to be as if frequency scaling actually works (i.e. according to benchmarks, the performance seems to be similar with and without the "nohz_full" parameter). Expected results: All cores must report their actual frequency depending on the load. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-lowlatency 6.5.0-15.15.1.1~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15.1.1~22.04.1-lowlatency 6.5.3 Uname: Linux 6.5.0-15-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jan 30 23:39:51 2024 InstallationDate: Installed on 2015-05-01 (3196 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: linux-signed-lowlatency-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-05-14 (626 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full breaks CPU frequency reporting
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 increased then deceased. The intel_pstate_tracer.py utility was run during the test capturing the attached. All pstates were used and appropriate per the load. ** Attachment added: "all_cpu_frequencies.png" https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+attachment/5744261/+files/all_cpu_frequencies.png -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-lowlatency-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051733 Title: Specifying nohz_full breaks CPU frequency reporting Status in linux-signed-lowlatency-hwe-6.5 package in Ubuntu: Confirmed Bug description: With the lowlatency kernel, if I specify "nohz_full=1-15" boot parameter then CPU frequency reporting doesn't work for the logical cores 1-15. That is, only logical core 0 shows varying CPU frequency in its /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq file, all other cores constantly show 80 in their scaling_cur_freq files (which is the lowest supported frequency) regardless of the CPU load. Steps to reproduce: 1. Add "nohz_full=1-15" (specify the core numbers to include all logical cores except 0) to kernel boot options in /etc/default/grub. 2. Run `sudo update-grub` and reboot. 3. Upon booting, run a multithreaded workload. For example, run `openssl speed -multi $(nproc --all)`. 4. In another console, monitor CPU frequencies by running `watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq`. Actual results: All cores specified in "nohz_full" parameter always report their lowest frequency. Despite that, the actual performance seems to be as if frequency scaling actually works (i.e. according to benchmarks, the performance seems to be similar with and without the "nohz_full" parameter). Expected results: All cores must report their actual frequency depending on the load. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-lowlatency 6.5.0-15.15.1.1~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15.1.1~22.04.1-lowlatency 6.5.3 Uname: Linux 6.5.0-15-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jan 30 23:39:51 2024 InstallationDate: Installed on 2015-05-01 (3196 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: linux-signed-lowlatency-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-05-14 (626 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full breaks CPU frequency reporting
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=d51847acb018d83186e4af67bc93f9a00a8644f7 https://bugzilla.kernel.org/show_bug.cgi?id=217597 ** Bug watch added: Linux Kernel Bug Tracker #217597 https://bugzilla.kernel.org/show_bug.cgi?id=217597 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-lowlatency-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051733 Title: Specifying nohz_full breaks CPU frequency reporting Status in linux-signed-lowlatency-hwe-6.5 package in Ubuntu: Confirmed Bug description: With the lowlatency kernel, if I specify "nohz_full=1-15" boot parameter then CPU frequency reporting doesn't work for the logical cores 1-15. That is, only logical core 0 shows varying CPU frequency in its /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq file, all other cores constantly show 80 in their scaling_cur_freq files (which is the lowest supported frequency) regardless of the CPU load. Steps to reproduce: 1. Add "nohz_full=1-15" (specify the core numbers to include all logical cores except 0) to kernel boot options in /etc/default/grub. 2. Run `sudo update-grub` and reboot. 3. Upon booting, run a multithreaded workload. For example, run `openssl speed -multi $(nproc --all)`. 4. In another console, monitor CPU frequencies by running `watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq`. Actual results: All cores specified in "nohz_full" parameter always report their lowest frequency. Despite that, the actual performance seems to be as if frequency scaling actually works (i.e. according to benchmarks, the performance seems to be similar with and without the "nohz_full" parameter). Expected results: All cores must report their actual frequency depending on the load. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-lowlatency 6.5.0-15.15.1.1~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15.1.1~22.04.1-lowlatency 6.5.3 Uname: Linux 6.5.0-15-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jan 30 23:39:51 2024 InstallationDate: Installed on 2015-05-01 (3196 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: linux-signed-lowlatency-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-05-14 (626 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
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 (lowlatency): 6591.27 BOgo Op/s, Deviation 0.39%, 0.3% performance degradation My kernel was mainline 6.8-rc1 using Ubuntu kernel configurations. I posted about this the Phoronix thread. -- 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/2051342 Title: Enable lowlatency settings in the generic kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] Ubuntu provides the "lowlatency" kernel: a kernel optimized for applications that have special "low latency" requirements. Currently, this kernel does not include any specific UBUNTU SAUCE patches to improve the extra "low latency" requirements, but the only difference is a small subset of .config options. Almost all these options are now configurable either at boot-time or even at run-time, with the only exception of CONFIG_HZ (250 in the generic kernel vs 1000 in the lowlatency kernel). Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel. Enabling the low-latency settings in the generic kernel has been evaluated before, but it has been never finalized due to the potential risk of performance regressions in CPU-intensive applications (increasing HZ from 250 to 1000 may introduce more kernel jitter in number crunching workloads). The outcome of the original proposal resulted in a re-classification of the lowlatency kernel as a desktop- oriented kernel, enabling additional low latency features (LP: #2023007). As we are approaching the release of the new Ubuntu 24.04 we may want to re-consider merging the low-latency settings in the generic kernel again. Following a detailed analysis of the specific low-latency features: - CONFIG_NO_HZ_FULL=y: enable access to "Full tickless mode" (shutdown clock tick when possible across all the enabled CPUs if they are either idle or running 1 task - reduce kernel jitter of running tasks due to the periodic clock tick, must be enabled at boot time passing `nohz_full=`); this can actually help CPU-intensive workloads and it could provide much more benefits than the CONFIG_HZ difference (since it can potentially shutdown any kernel jitter on specific CPUs), this one should really be enabled anyway, considering that it is configurable at boot time - CONFIG_RCU_NOCB_CPU=y: move RCU callbacks from softirq context to kthread context (reduce time spent in softirqs with preemption disabled to improve the overall system responsiveness, at the cost of introducing a potential performance penalty, because RCU callbacks are not processed by kernel threads); this should be enabled as well, since it is configurable at boot time (via the rcu_nocbs= parameter) - CONFIG_RCU_LAZY=y: batch RCU callbacks and then flush them after a timed delay instead of executing them immediately (c'an provide 5~10% power-savings for idle or lightly-loaded systems, this is extremely useful for laptops / portable devices - https://lore.kernel.org/lkml/20221016162305.2489629-3-j...@joelfernandes.org/); this has the potential to introduce significant performance regressions, but in the Noble kernel we already have a SAUCE patch that allows to enable/disable this option at boot time (see LP: #2045492), and by default it will be disabled (CONFIG_RCU_LAZY_DEFAULT_OFF=y) - CONFIG_HZ=1000 last but not least, the only option that is *only* tunable at compile time. As already mentioned there is a potential risk of regressions for CPU-intensive applications, but they can be mitigated (and maybe they could even outperformed) with NO_HZ_FULL. On the other hand, HZ=1000 can improve system responsiveness, that means most of the desktop and server applications will benefit from this (the largest part of the server workloads is I/O bound, more than CPU- bound, so they can benefit from having a kernel that can react faster at switching tasks), not to mention the benefit for the typical end users applications (gaming, live conferencing, multimedia, etc.). With all of that in place we can provide a kernel that has the flexibility to be more responsive, more performant and more power efficient (therefore more "generic"), simply by tuning run-time and boot-time options. Moreover, once these changes are applied we will be able
[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full disables CPU frequency scaling
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 of the incorrectly reported scaling_cur_freq can be anywhere from wrong to correct. Example 1: 100% load on all 12 CPUs; acpi-cpufreq; schedutil: doug@s19:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:485 /sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:4101000 except for CPU 0, which seems to be reporting as is it is using a different driver, the results are correct. Example 2: 100% load on CPU 4 only; acpi-cpufreq; ondemand: doug@s19:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:4799876 /sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:4101000 /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:80 /sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:80 Again, except for CPU 0, the results are correct. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-lowlatency-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051733 Title: Specifying nohz_full disables CPU frequency scaling Status in linux-signed-lowlatency-hwe-6.5 package in Ubuntu: Confirmed Bug description: With the lowlatency kernel, if I specify "nohz_full=1-15" boot parameter then CPU frequency scaling doesn't work for the logical cores 1-15. That is, only logical core 0 shows varying CPU frequency in its /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq file, all other cores constantly show 80 in their scaling_cur_freq files (which is the lowest supported frequency) regardless of the CPU load. Steps to reproduce: 1. Add "nohz_full=1-15" (specify the core numbers to include all logical cores except 0) to kernel boot options in /etc/default/grub. 2. Run `sudo update-grub` and reboot. 3. Upon booting, run a multithreaded workload. For example, run `openssl speed -multi $(nproc --all)`. 4. In another console, monitor CPU frequencies by running `watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq`. Actual results: All cores specified in "nohz_full" parameter are always at their lowest frequency. Expected results: All cores must scale the frequency up with active load. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-lowlatency 6.5.0-15.15.1.1~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15.1.1~22.04.1-lowlatency 6.5.3 Uname: Linux 6.5.0-15-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jan 30 23:39:51 2024 InstallationDate: Installed on 2015-05-01 (3196 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: linux-signed-lowlatency-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-05-14 (626 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full disables CPU frequency scaling
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. My main test server with Ubuntu 20.04.6. Note also, in my case, the CPU frequencies actually seem to be scaling properly, it is just that they are not being reported properly via "/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq". -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-lowlatency-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051733 Title: Specifying nohz_full disables CPU frequency scaling Status in linux-signed-lowlatency-hwe-6.5 package in Ubuntu: Confirmed Bug description: With the lowlatency kernel, if I specify "nohz_full=1-15" boot parameter then CPU frequency scaling doesn't work for the logical cores 1-15. That is, only logical core 0 shows varying CPU frequency in its /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq file, all other cores constantly show 80 in their scaling_cur_freq files (which is the lowest supported frequency) regardless of the CPU load. Steps to reproduce: 1. Add "nohz_full=1-15" (specify the core numbers to include all logical cores except 0) to kernel boot options in /etc/default/grub. 2. Run `sudo update-grub` and reboot. 3. Upon booting, run a multithreaded workload. For example, run `openssl speed -multi $(nproc --all)`. 4. In another console, monitor CPU frequencies by running `watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq`. Actual results: All cores specified in "nohz_full" parameter are always at their lowest frequency. Expected results: All cores must scale the frequency up with active load. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-lowlatency 6.5.0-15.15.1.1~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15.1.1~22.04.1-lowlatency 6.5.3 Uname: Linux 6.5.0-15-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jan 30 23:39:51 2024 InstallationDate: Installed on 2015-05-01 (3196 days ago) InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: linux-signed-lowlatency-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-05-14 (626 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-hwe-6.5/+bug/2051733/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
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 member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2051342 Title: Enable lowlatency settings in the generic kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] Ubuntu provides the "lowlatency" kernel: a kernel optimized for applications that have special "low latency" requirements. Currently, this kernel does not include any specific UBUNTU SAUCE patches to improve the extra "low latency" requirements, but the only difference is a small subset of .config options. Almost all these options are now configurable either at boot-time or even at run-time, with the only exception of CONFIG_HZ (250 in the generic kernel vs 1000 in the lowlatency kernel). Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel. Enabling the low-latency settings in the generic kernel has been evaluated before, but it has been never finalized due to the potential risk of performance regressions in CPU-intensive applications (increasing HZ from 250 to 1000 may introduce more kernel jitter in number crunching workloads). The outcome of the original proposal resulted in a re-classification of the lowlatency kernel as a desktop- oriented kernel, enabling additional low latency features (LP: #2023007). As we are approaching the release of the new Ubuntu 24.04 we may want to re-consider merging the low-latency settings in the generic kernel again. Following a detailed analysis of the specific low-latency features: - CONFIG_NO_HZ_FULL=y: enable access to "Full tickless mode" (shutdown clock tick when possible across all the enabled CPUs if they are either idle or running 1 task - reduce kernel jitter of running tasks due to the periodic clock tick, must be enabled at boot time passing `nohz_full=`); this can actually help CPU-intensive workloads and it could provide much more benefits than the CONFIG_HZ difference (since it can potentially shutdown any kernel jitter on specific CPUs), this one should really be enabled anyway, considering that it is configurable at boot time - CONFIG_RCU_NOCB_CPU=y: move RCU callbacks from softirq context to kthread context (reduce time spent in softirqs with preemption disabled to improve the overall system responsiveness, at the cost of introducing a potential performance penalty, because RCU callbacks are not processed by kernel threads); this should be enabled as well, since it is configurable at boot time (via the rcu_nocbs= parameter) - CONFIG_RCU_LAZY=y: batch RCU callbacks and then flush them after a timed delay instead of executing them immediately (c'an provide 5~10% power-savings for idle or lightly-loaded systems, this is extremely useful for laptops / portable devices - https://lore.kernel.org/lkml/20221016162305.2489629-3-j...@joelfernandes.org/); this has the potential to introduce significant performance regressions, but in the Noble kernel we already have a SAUCE patch that allows to enable/disable this option at boot time (see LP: #2045492), and by default it will be disabled (CONFIG_RCU_LAZY_DEFAULT_OFF=y) - CONFIG_HZ=1000 last but not least, the only option that is *only* tunable at compile time. As already mentioned there is a potential risk of regressions for CPU-intensive applications, but they can be mitigated (and maybe they could even outperformed) with NO_HZ_FULL. On the other hand, HZ=1000 can improve system responsiveness, that means most of the desktop and server applications will benefit from this (the largest part of the server workloads is I/O bound, more than CPU- bound, so they can benefit from having a kernel that can react faster at switching tasks), not to mention the benefit for the typical end users applications (gaming, live conferencing, multimedia, etc.). With all of that in place we can provide a kernel that has the flexibility to be more responsive, more performant and more power efficient (therefore more "generic"), simply by tuning run-time and boot-time options. Moreover, once these changes are applied we will be able to deprecate the lowlatency kernel, saving engineering time and also reducing power consumption (required to build the kernel and do all the testing). Optionally, we can also provide optimal "lowlatency" settings as a user-space packa
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
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 CPU loading programs. I also did only 1 thread and forced CPU affinity. I also tried to get a more accurate estimate of the tick ISR execution time. Trace only does time stamping to the microsecond, making it difficult. For the 1000Hz kernel and a 100 second trace, 10 tick ISRs were captured. min 0, average 0.7, max 2 uSec. 250Hz kernel test time (less is better): 300.14 seconds (100% user 0% system). For the 1000 Hertz kernel the extra execution time prediction is: 0.7 uSec/tick * 750 extra ticks/sec * 300.14 sec = 0.16 sec For a predicted execution time of 300.30 seconds. 1000Hz kernel test time: 300.32 seconds. 1000Hz+nohz_full test time: 300.08 seconds. In an attempt to get a better model the processor CPU frequency was changed from 4.8 GHz to 0.80 GHz. Tick ISR: min 3, average 4.0, max 11 uSec. Note: of the 10 tick ISRs captured the 11 uSec one was a one time outlier. 250Hz kernel test time: 429.25 For the 1000 Hertz kernel the extra execution time prediction is: 4.0 uSec/tick * 750 extra ticks/sec * 429.25 sec = 1.29 sec For a predicted execution time of 430.53 seconds. 1000Hz kernel test time: 430.38 seconds. -- 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/2051342 Title: Enable lowlatency settings in the generic kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] Ubuntu provides the "lowlatency" kernel: a kernel optimized for applications that have special "low latency" requirements. Currently, this kernel does not include any specific UBUNTU SAUCE patches to improve the extra "low latency" requirements, but the only difference is a small subset of .config options. Almost all these options are now configurable either at boot-time or even at run-time, with the only exception of CONFIG_HZ (250 in the generic kernel vs 1000 in the lowlatency kernel). Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel. Enabling the low-latency settings in the generic kernel has been evaluated before, but it has been never finalized due to the potential risk of performance regressions in CPU-intensive applications (increasing HZ from 250 to 1000 may introduce more kernel jitter in number crunching workloads). The outcome of the original proposal resulted in a re-classification of the lowlatency kernel as a desktop- oriented kernel, enabling additional low latency features (LP: #2023007). As we are approaching the release of the new Ubuntu 24.04 we may want to re-consider merging the low-latency settings in the generic kernel again. Following a detailed analysis of the specific low-latency features: - CONFIG_NO_HZ_FULL=y: enable access to "Full tickless mode" (shutdown clock tick when possible across all the enabled CPUs if they are either idle or running 1 task - reduce kernel jitter of running tasks due to the periodic clock tick, must be enabled at boot time passing `nohz_full=`); this can actually help CPU-intensive workloads and it could provide much more benefits than the CONFIG_HZ difference (since it can potentially shutdown any kernel jitter on specific CPUs), this one should really be enabled anyway, considering that it is configurable at boot time - CONFIG_RCU_NOCB_CPU=y: move RCU callbacks from softirq context to kthread context (reduce time spent in softirqs with preemption disabled to improve the overall system responsiveness, at the cost of introducing a potential performance penalty, because RCU callbacks are not processed by kernel threads); this should be enabled as well, since it is configurable at boot time (via the rcu_nocbs= parameter) - CONFIG_RCU_LAZY=y: batch RCU callbacks and then flush them after a timed delay instead of executing them immediately (c'an provide 5~10% power-savings for idle or lightly-loaded systems, this is extremely useful for laptops / portable devices - https://lore.kernel.org/lkml/20221016162305.2489629-3-j...@joelfernandes.org/); this has the potential to introduce significant performance regressions, but in the Noble kernel we already have a SAUCE patch that allows to enable/disable this option at boot time (see LP: #2045492), and by default it will be disabled (CONFIG_RCU_LAZY_DEFAULT_OFF=y) - CONFIG_HZ=1000 las
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
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 understand your test results as I would have expected a lot less difference. Using mainline kernel 6.8-rc1 and limiting my test system max CPU frequency so that I get similar bogo op/s as you I get: - CONFIG_HZ=250 : 14853.14 bogo ops/s - CONFIG_HZ=1000 : 14714.01 bogo ops/s (0.94% worse) - CONFIG_HZ=1000+nohz_full : 15100 bogo ops/s (1.6% better) There is no power or thermal or active cores throttling on my test system. Note: with my CPU frequency limited for this test, the tick ISR takes about 4 uSec. The difference between the 250 and 1000 Hz kernel tests is 750 tick interrupts per second or 3 milliseconds or about 0.3% If I do not limit my max CPU frequency I get: - CONFIG_HZ=250 : 38518.64 bogo ops/s - CONFIG_HZ=1000 : 37765.55 bogo ops/s (2.0% worse) - CONFIG_HZ=1000+nohz_full : 39391.32 bogo ops/s (2.3% better) There was no power or thermal or active cores throttling for this test. However I did have to raise my processor max temperature limit from 75 to 80 degrees C for this test. Also the power is very close to the limit at 122 watts, where it will throttle at 125 watts. -- 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/2051342 Title: Enable lowlatency settings in the generic kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] Ubuntu provides the "lowlatency" kernel: a kernel optimized for applications that have special "low latency" requirements. Currently, this kernel does not include any specific UBUNTU SAUCE patches to improve the extra "low latency" requirements, but the only difference is a small subset of .config options. Almost all these options are now configurable either at boot-time or even at run-time, with the only exception of CONFIG_HZ (250 in the generic kernel vs 1000 in the lowlatency kernel). Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel. Enabling the low-latency settings in the generic kernel has been evaluated before, but it has been never finalized due to the potential risk of performance regressions in CPU-intensive applications (increasing HZ from 250 to 1000 may introduce more kernel jitter in number crunching workloads). The outcome of the original proposal resulted in a re-classification of the lowlatency kernel as a desktop- oriented kernel, enabling additional low latency features (LP: #2023007). As we are approaching the release of the new Ubuntu 24.04 we may want to re-consider merging the low-latency settings in the generic kernel again. Following a detailed analysis of the specific low-latency features: - CONFIG_NO_HZ_FULL=y: enable access to "Full tickless mode" (shutdown clock tick when possible across all the enabled CPUs if they are either idle or running 1 task - reduce kernel jitter of running tasks due to the periodic clock tick, must be enabled at boot time passing `nohz_full=`); this can actually help CPU-intensive workloads and it could provide much more benefits than the CONFIG_HZ difference (since it can potentially shutdown any kernel jitter on specific CPUs), this one should really be enabled anyway, considering that it is configurable at boot time - CONFIG_RCU_NOCB_CPU=y: move RCU callbacks from softirq context to kthread context (reduce time spent in softirqs with preemption disabled to improve the overall system responsiveness, at the cost of introducing a potential performance penalty, because RCU callbacks are not processed by kernel threads); this should be enabled as well, since it is configurable at boot time (via the rcu_nocbs= parameter) - CONFIG_RCU_LAZY=y: batch RCU callbacks and then flush them after a timed delay instead of executing them immediately (c'an provide 5~10% power-savings for idle or lightly-loaded systems, this is extremely useful for laptops / portable devices - https://lore.kernel.org/lkml/20221016162305.2489629-3-j...@joelfernandes.org/); this has the potential to introduce significant performance regressions, but in the Noble kernel we already have a SAUCE patch that allows to enable/disable this option at boot time (see LP: #2045492), and by default it will be disabled (CONFIG_RCU_LAZY_DEFAULT_OFF=y) - CONFIG_HZ=1000 last but not least, the only option that is *only*
[Kernel-packages] [Bug 1950914] Re: [daily jammy-live-server-amd64] Hangs at start of VM installation
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. -- 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/1950914 Title: [daily jammy-live-server-amd64] Hangs at start of VM installation Status in subiquity: Invalid Status in libvirt package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: I downloaded the 2021.11.14 daily: -rw-rwxr--+ 1 doug doug 1277655040 Nov 14 09:12 jammy-live-server- amd64.iso I tried to install it as a VM on a debian 11 server host and an Ubuntu 20.04.3 server host, both were up to date as of a few days ago. Command used (pretty much the same command I have used for years): virt-install -n serv-jj -r 8192 \ --disk path=/home/doug/vm/serv-jj.img,bus=virtio,size=50 \ -c jammy-live-server-amd64-2021-11-14.iso \ --network bridge=br0,model=virtio,mac=52:54:00:27:1c:6e \ --video=vmvga --graphics vnc,listen=0.0.0.0 --noautoconsole -v --vcpus=4 On both hosts it just hangs a after a couple of seconds. "virsh list" shows it running and "virsh destroy" does work. Note: I have never used the new installer before, I have always used the legacy Debain installer in the past, but I gather is is no longer supported. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1950914/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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, and assems to be asserting the external PROCHOT bit. If it were me, I would disable turbo boost in BIOS, and boot into passive mode with the schedutil governor: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=passive cpufreq.default_governor=schedutil" -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:1 MiB L3 cache:6 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulne rable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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. As to why the bit does not go back to 0, I do not know, that would be your hardware. Please also provide the contents of MSR 0x1B2. Note that your processor is also indicating a past power limit, via the log bit. However, many do as they come out of the BIOS to the O.S., so it might be a red herring. One has to clear the log bit and then watch for it becoming set again to know for certain. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:1 MiB L3 cache:6 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulne
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:1 MiB L3 cache:6 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulne rable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitizatio n Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 indicate the reasons it is throttling, which is the next place to look. Myself, I am tried of decoding the common MSR bits, so I wrote a decoder. It is at (coded so as to avoid bots): double u double u double u dot smythies dot com /~doug/temp_kernel/ Both the c code and compiled, msr-decoder.c run as sudo: "sudo ./msr-decoder" and post the output here. There is also a log bit reset program, that clears held bits for ongoing work. If you do not want to use my programs, then read MSR's 0x19c, 0x1aa, 0x1b1, 0x16f, 0x1fc and post the contents here. As a side note: Your /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq:80 is not 50% of maximum as dictated by /sys/devices/system/cpu/intel_pstate/min_perf_pct:50. I had thought the two getting out of sync had been fixed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache:
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 8 33 8 8 and $ sudo rdmsr --bitfield 15:8 -u -a 0x198 48 48 48 48 48 48 48 48 48 48 48 48 So, and as expected, I am asking for the highest patete possible for CPU 2 and being given pstate 48 on all CPUs. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:1 MiB L3 cache:6 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulne rable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 investigation is the same. References: https://askubuntu.com/questions/1360985/all-cpus-stuck-at-800mhz-ubuntu-20-04-3 https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts-significant-throttling-of-intel-i7-processor https://askubuntu.com/questions/1379048/intel-pstate-driver-not-being-loaded-when-added-to-grub-file To check all operating parameters I do not mean to use cpufreq-info. I mean do: grep . /sys/devices/system/cpu/intel_pstate/* and grep . /sys/devices/system/cpu/cpu*/cpufreq/* For posting herein, and as a long as you have checked that the repeated information is the same, the second one can be shortened to (choose whatever CPU you want): grep . /sys/devices/system/cpu/cpu2/cpufreq/* -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 eliminate these default settings by stopping and disabling the "ondemand" service. Without the service, the governor will be as defined by the kernel configuration file or the grub command line. Recently, Ubuntu has changed to "schedutil" as the default in the kernel configuration. $ grep CONFIG_CPU_FREQ_DEFAULT /boot/config-5.11.0-40-generic # 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_SCHEDUTIL=y For these "few minutes" you mention, please run a load, for example "$ yes > /dev/null", while at the same time running the following turbostat command in another terminal: sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 10 And check all operating parameters after the slow down looking for any limiting change. Post the turbostat output here. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz
[Kernel-packages] [Bug 1945221] Re: CPU frequency stuck at minimum value..again Ubuntu 20.04.3
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 Ubuntu. https://bugs.launchpad.net/bugs/1945221 Title: CPU frequency stuck at minimum value..again Ubuntu 20.04.3 Status in thermald package in Ubuntu: In Progress Bug description: I would really like to find out why my cpu's keep reverting back to a cpu powersave mode after I get a kernel update then reboot. I cleaned my laptops vent but this seems to happen whenever a new kernel is updated and installed. https://askubuntu.com/questions/1366090/ubuntu-20-04-3-lts- significant-throttling-of- intel-i7-processor?noredirect=1#comment2345549_1366090 Description:Ubuntu 20.04.3 LTS Release:20.04 Computer Summary Computer Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Memory 16315MB (4407MB used) Machine TypeLaptop Operating SystemUbuntu 20.04.3 LTS User Name rt (rt) Date/Time Mon 30 Aug 2021 02:33:09 PM EDT Display Resolution 1920x1080 pixels OpenGL Renderer Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) X11 Vendor The X.Org Foundation Audio Devices Audio Adapter HDA-Intel - HDA Intel HDMI Audio Adapter HDA-Intel - HDA Intel PCH Audio Adapter USB-Audio - USB Audio Device Input Devices Power Button Sleep Button Lid Switch Power Button AT Translated Set 2 keyboard USB Audio Device ETPS/2 Elantech Touchpad Logitech Anywhere MX Video Bus HDA Intel PCH Mic HDA Intel PCH Front Headphone HDA Intel HDMI HDMI/DP,pcm:3 HDA Intel HDMI HDMI/DP,pcm:7 HDA Intel HDMI HDMI/DP,pcm:8 HDA Intel HDMI HDMI/DP,pcm:9 HDA Intel HDMI HDMI/DP,pcm:10 Printers (CUPS) OfficeJet_Pro_6978 Default SCSI Disks TSSTcorp CDDVDW SN-208DB ATA INTEL SSDMCEAC12 ATA ST1000LM014-1EJ1 Operating System Version Kernel Linux 5.4.0-81-generic (x86_64) Version #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 C Library GNU C Library / (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 DistributionUbuntu 20.04.3 LTS Current Session Computer Name sys76 User Name rt (rt) Languageen_US.UTF-8 () Home Directory /home/rt Misc Uptime 20 minutes Load Average0.83, 1.37, 1.62 Available entropy in /dev/random3649 bits (healthy) rt@sys76:~$ dpkg -l *freq* | grep ii rt@sys76:~$ rt@sys76:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6 Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt 2.95800 334747 2.160.01 2.76800 306949 2.150.01 5.85800 512248 2.730.01 11.87 800 800847 3.410.04 8.23800 577847 2.860.05 rt@sys76:~$ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Stepping:3 CPU MHz: 798.103 CPU max MHz: 3400. CPU min MHz: 800. BogoMIPS:4788.65 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache:1 MiB L3 cache:6 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulne rable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitizatio n Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB conditional
[Kernel-packages] [Bug 1215665] Re: With Kernel 3.11RC6 Ubuntu servguide PDF compile crashes
** 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: Fix Released Bug description: I often run the current release candidate (RC) on a 12.04 server computer. When compiling any non-english PDF version of the Ubuntu server guide, one of the programs crashes (and creates a log, which I will attach shortly, but summary below). While it has been a very long time since I tried to compile a non-english PDF serverguide, I did more work to narrow down the issue: Kernel: Ubuntu 3.11 RC5 = No Problem (actually, all tested kernels <= 3.11 RC5) Kernel: Kernel.org 3.11 RC5 = No Problem Kernel: Ubuntu 3.11 RC6 = Problem Kernel: Kernel.org 3.11 RC6 = Problem Someone else has reported the same issue ( http://ubuntuforums.org/showthread.php?t=2168771 ) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b6061972239, pid=2950, tid=47114532034304 # # JRE version: 6.0_27-b27 # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.12.6 # Distribution: Ubuntu 12.04 LTS, package 6b27-1.12.6-1ubuntu0.12.04.2 # Problematic frame: # J java.lang.String.charAt(I)C # # An error report file with more information is saved as: # /home/doug/sguide-1310/cg01/hs_err_pid2950.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # Aborted (core dumped) make: *** [serverguide-pdf] Error 134 doug@s15:~/sguide-1310/cg01$ cat /proc/version_signature cat: /proc/version_signature: No such file or directory doug@s15:~/sguide-1310/cg01$ doug@s15:~/sguide-1310/cg01$ lsb_release -rd Description:Ubuntu 12.04.3 LTS Release:12.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1215665/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1926938] Re: Recent mainline packages are built with Hirsuite 21.04, not Focal 20.04 LTS
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://bugs.launchpad.net/bugs/1926938 Title: Recent mainline packages are built with Hirsuite 21.04, not Focal 20.04 LTS Status in linux package in Ubuntu: Confirmed Bug description: Hi all, The Mainline wiki states that the mainline kernels are built with the previous LTS toolchain, but the recent 5.12.x and 5.11.x releases are being built with Hirsuite 21.04, and before that Groovy? If this is intentional, then the wiki should be updated to reflect the change in policy. From https://wiki.ubuntu.com/Kernel/MainlineBuilds Mainline kernel build toolchain These kernels are built with the toolchain (gcc, g++, etc.) from the previous Ubuntu LTS release. (e.g. Ubuntu 14.04 "Trusty Tahr" / 16.04 "Xenial Xerus" / 18.04 "Bionic Beaver", etc.) Therefore, out-of-tree kernel modules you already have built and installed for use with your release kernels are not likely to work with the mainline builds. The 5.12 kernel was built with GCC 10.3.0, and 5.11.16 with 10.2.0. On my Focal LTS system I have GCC 9.3.0. The Mainline kernel build toolchain These kernels are built with the toolchain (gcc, g++, etc.) from the previous Ubuntu LTS release. (e.g. Ubuntu 14.04 "Trusty Tahr" / 16.04 "Xenial Xerus" / 18.04 "Bionic Beaver", etc.) Therefore, out-of-tree kernel modules you already have built and installed for use with your release kernels are not likely to work with the mainline builds. The *linux-headers-generic* packages have unmet dependencies on 20.04 LTS. I could install Groovy built kernels fine, but the Hirsuite ones built with GCC 10.3.0 appear to require libc6 >= 2.33. So the new kernels can't be installed on Focal (libc 2.31). Thanks, Mark To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926938/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1926938] Re: Recent mainline packages are built with Hirsuite 21.04, not Focal 20.04 LTS
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 eliminated such that Ubuntu Mainline kernels can be installed on any valid Ubuntu release at least back to the previous LTS, as has been the normal situation for at least a decade. Earlier someone was asking how to compile the mainline kernel. My notes, without the optimizations someone else was mentioning, on "how to" are here, and they are current, even thou there is a 15.10 tag: https://askubuntu.com/questions/718381/how-to-compile-and-install- custom-mainline-kernel/718662#718662 -- 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/1926938 Title: Recent mainline packages are built with Hirsuite 21.04, not Focal 20.04 LTS Status in linux package in Ubuntu: Confirmed Bug description: Hi all, The Mainline wiki states that the mainline kernels are built with the previous LTS toolchain, but the recent 5.12.x and 5.11.x releases are being built with Hirsuite 21.04, and before that Groovy? If this is intentional, then the wiki should be updated to reflect the change in policy. From https://wiki.ubuntu.com/Kernel/MainlineBuilds Mainline kernel build toolchain These kernels are built with the toolchain (gcc, g++, etc.) from the previous Ubuntu LTS release. (e.g. Ubuntu 14.04 "Trusty Tahr" / 16.04 "Xenial Xerus" / 18.04 "Bionic Beaver", etc.) Therefore, out-of-tree kernel modules you already have built and installed for use with your release kernels are not likely to work with the mainline builds. The 5.12 kernel was built with GCC 10.3.0, and 5.11.16 with 10.2.0. On my Focal LTS system I have GCC 9.3.0. The Mainline kernel build toolchain These kernels are built with the toolchain (gcc, g++, etc.) from the previous Ubuntu LTS release. (e.g. Ubuntu 14.04 "Trusty Tahr" / 16.04 "Xenial Xerus" / 18.04 "Bionic Beaver", etc.) Therefore, out-of-tree kernel modules you already have built and installed for use with your release kernels are not likely to work with the mainline builds. The *linux-headers-generic* packages have unmet dependencies on 20.04 LTS. I could install Groovy built kernels fine, but the Hirsuite ones built with GCC 10.3.0 appear to require libc6 >= 2.33. So the new kernels can't be installed on Focal (libc 2.31). Thanks, Mark To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926938/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1917813] [NEW] HWP and C1E are incompatible - Intel processors
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 difference between OS driven pstate control and HWP driven pstate control is that the OS knows the system was not actually idle, but HWP does not. Another difference is the incredibly sluggish recovery with HWP. The problem only occurs when Idle State 2, C1E, is involved. Not all processors have the C1E idle state. The issue is independent of C1E auto-promotion, which is turned off in general, as far as I know. With all idle states enabled the issue is rare. The issue would manifest itself in periodic workflows, and would be extremely difficult to isolate (It took me over 1/2 a year). The purpose of this bug report is to link to the upstream bug report, where readers can find tons of detail. I'll also set it to confirmed, as it has already been verified on 4 different processor models, and I do not want the bot asking me for files that are not required. Workarounds include: . don't use HWP. . disable idle state 2, C1E . change the C1E idle state to use MWAIT 0x03 instead of MWAIT 0x01 (still in test. documentation on the MWAIT least significant nibble is scant). ** Affects: linux Importance: Unknown Status: Unknown ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Summary changed: - HWP and C1E are incompatible - Intel prcoessors + HWP and C1E are incompatible - Intel processors ** Bug watch added: Linux Kernel Bug Tracker #210741 https://bugzilla.kernel.org/show_bug.cgi?id=210741 ** Also affects: linux via https://bugzilla.kernel.org/show_bug.cgi?id=210741 Importance: Unknown Status: Unknown -- 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/1917813 Title: HWP and C1E are incompatible - Intel processors Status in Linux: Unknown Status in linux package in Ubuntu: Confirmed Bug description: 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 difference between OS driven pstate control and HWP driven pstate control is that the OS knows the system was not actually idle, but HWP does not. Another difference is the incredibly sluggish recovery with HWP. The problem only occurs when Idle State 2, C1E, is involved. Not all processors have the C1E idle state. The issue is independent of C1E auto-promotion, which is turned off in general, as far as I know. With all idle states enabled the issue is rare. The issue would manifest itself in periodic workflows, and would be extremely difficult to isolate (It took me over 1/2 a year). The purpose of this bug report is to link to the upstream bug report, where readers can find tons of detail. I'll also set it to confirmed, as it has already been verified on 4 different processor models, and I do not want the bot asking me for files that are not required. Workarounds include: . don't use HWP. . disable idle state 2, C1E . change the C1E idle state to use MWAIT 0x03 instead of MWAIT 0x01 (still in test. documentation on the MWAIT least significant nibble is scant). To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1917813/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
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 ago): initramfs-tools: 0.136ubuntu1 kmod; 27-1ubuntu1 name: s15 (a physical i7-2600K based computer, up to date as of a few days ago): initramfs-tools: 0.136ubuntu1 kmod; 27-1ubuntu1 -- 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() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
** 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() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
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 first time. If I reinstall the same kernel there are no errors spewed. If I purge the kernel and re-install it, then the error is spewed 5600 times again. -- 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() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
*** 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): depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/home/doug/temp-k-git/linux/debian/linux- image/lib/modules/5.6.0-rc4-stock/modules.builtin.bin' but the file is there (well, afterwards at least). I didn't notice this with kernel 5.6-rc2, but might not have been looking. -- 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() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://laun
[Kernel-packages] [Bug 1768976] Re: Ubuntu 18.04 is overheating after upgrade from 16.04
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 must already be loaded). Example (requested, granted, 100% load on CPU 3): root@s15:/home/doug/temp-git-git# rdmsr --bitfield 15:8 -d -a 0x199 16 16 16 38 16 16 16 16 root@s15:/home/doug/temp-git-git# rdmsr --bitfield 15:8 -d -a 0x198 36 35 36 36 36 36 36 36 Where 38 is the max and 16 in the min for my i7-2600K. Why only 36 granted? because actually I guess three cores are active at the time of the sample. From turbostat: cpu0: MSR_TURBO_RATIO_LIMIT: 0x23242526 35 * 100.0 = 3500.0 MHz max turbo 4 active cores 36 * 100.0 = 3600.0 MHz max turbo 3 active cores 37 * 100.0 = 3700.0 MHz max turbo 2 active cores 38 * 100.0 = 3800.0 MHz max turbo 1 active cores Note: I ran the above as root because there is a lot over overhead running it under "sudo", which tends to result in another CPU requesting a high pstate by the time the sample is actually taken. Now, the different reported CPU frequencies, for your example where there is no dominant load, is another story. While there is only one PLL, your mostly idle CPUs would be "awake" at different times, with the PLL ramping up and down based on which incoming votes and requests are being used. Hope this helps, and apologies for this digression on this bug report. -- 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/1768976 Title: Ubuntu 18.04 is overheating after upgrade from 16.04 Status in linux package in Ubuntu: Confirmed Status in xserver-xorg-video-nouveau package in Ubuntu: Confirmed Bug description: Ubuntu is overheating at my laptop. Opening youtube on firefox is enough for critical temperature shutdown. Using lm-sensors for monitoring on 18.04 the temp varies between 70 and 85°C with only firefox or chrome open and doing nothing. On my old 16.04 with same using, the temp varies between 55 and 70°C. First thought was the driver nouveau is the problem, and finally I was able to install by add "nouveau.modeset=0" at livecd boot options, without temp shutdown. After install I disable the nouveau at modprobe blacklist, but the system continues overheating and shutdown with basic usage. I have no idea what's happening with the bionic at my laptop. My laptop is a Samsung RF411 i5 2nd Generation and Geforce 540M. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader-core 1:18.04.17 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Thu May 3 16:22:40 2018 InstallationDate: Installed on 2018-04-27 (6 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: No upgrade log present (probably fresh install) VarLogDistupgradeAptHistorylog: Start-Date: 2018-04-27 15:46:02 End-Date: 2018-04-27 15:46:02 VarLogDistupgradeAptlog: Log time: 2018-04-27 15:45:39.753331 Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Log time: 2018-04-27 15:46:04.859979 VarLogDistupgradeApttermlog: Log started: 2018-04-27 15:46:02 Log ended: 2018-04-27 15:46:02 --- .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edir 2354 F pulseaudio CompositorRunning: None DistUpgraded: Fresh install DistroCodename: bionic DistroRelease: Ubuntu 18.04 DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 4.15.0-20-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 4.15.0-22-generic, x86_64: installed GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Samsung Electronics Co Ltd 2nd Generation Core Processor Family Integrated Graphics Controller [144d:c0a5] Subsystem: Samsung Electronics Co Ltd GF108M [GeForce GT 540M] [144d:c0a5] HibernationDevice: RESUME=UUID=e7a61aee-64c2-4c88-b4e1-4de481d0f88d InstallationDate: Installed on 2018-04-27 (36 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) MachineType: SAMSUNG ELECTRONICS CO., LTD. RF511/RF411/RF711 NonfreeKernelModules: wl Package: xserver-xorg-video-nouveau 1:1.0.15-2 PackageArchitecture: amd64 ProcFB: 0 inteldrmfb ProcKernelCm
[Kernel-packages] [Bug 1768976] Re: Ubuntu 18.04 is overheating after upgrade from 16.04
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 frequency for all, for when they are active. -- 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/1768976 Title: Ubuntu 18.04 is overheating after upgrade from 16.04 Status in linux package in Ubuntu: Confirmed Status in xserver-xorg-video-nouveau package in Ubuntu: Confirmed Bug description: Ubuntu is overheating at my laptop. Opening youtube on firefox is enough for critical temperature shutdown. Using lm-sensors for monitoring on 18.04 the temp varies between 70 and 85°C with only firefox or chrome open and doing nothing. On my old 16.04 with same using, the temp varies between 55 and 70°C. First thought was the driver nouveau is the problem, and finally I was able to install by add "nouveau.modeset=0" at livecd boot options, without temp shutdown. After install I disable the nouveau at modprobe blacklist, but the system continues overheating and shutdown with basic usage. I have no idea what's happening with the bionic at my laptop. My laptop is a Samsung RF411 i5 2nd Generation and Geforce 540M. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader-core 1:18.04.17 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Thu May 3 16:22:40 2018 InstallationDate: Installed on 2018-04-27 (6 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: No upgrade log present (probably fresh install) VarLogDistupgradeAptHistorylog: Start-Date: 2018-04-27 15:46:02 End-Date: 2018-04-27 15:46:02 VarLogDistupgradeAptlog: Log time: 2018-04-27 15:45:39.753331 Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Log time: 2018-04-27 15:46:04.859979 VarLogDistupgradeApttermlog: Log started: 2018-04-27 15:46:02 Log ended: 2018-04-27 15:46:02 --- .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edir 2354 F pulseaudio CompositorRunning: None DistUpgraded: Fresh install DistroCodename: bionic DistroRelease: Ubuntu 18.04 DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 4.15.0-20-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 4.15.0-22-generic, x86_64: installed GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Samsung Electronics Co Ltd 2nd Generation Core Processor Family Integrated Graphics Controller [144d:c0a5] Subsystem: Samsung Electronics Co Ltd GF108M [GeForce GT 540M] [144d:c0a5] HibernationDevice: RESUME=UUID=e7a61aee-64c2-4c88-b4e1-4de481d0f88d InstallationDate: Installed on 2018-04-27 (36 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) MachineType: SAMSUNG ELECTRONICS CO., LTD. RF511/RF411/RF711 NonfreeKernelModules: wl Package: xserver-xorg-video-nouveau 1:1.0.15-2 PackageArchitecture: amd64 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic root=UUID=db38a22c-0e9f-4e1a-b9f7-f7aac2544394 ro quiet splash nouveau.runpm=0 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-4.15.0-22-generic N/A linux-backports-modules-4.15.0-22-generic N/A linux-firmware 1.173.1 Tags: bionic ubuntu Uname: Linux 4.15.0-22-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/26/2011 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 10HX.M034.20110426.SSH dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: RF511/RF411/RF711 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: 10HX dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.
[Kernel-packages] [Bug 1768976] Re: Ubuntu 18.04 is overheating after upgrade from 16.04
@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 that you don't wake up CPUs just to ask them status stuff. Everyone with this problem: If you don't bisect the kernel to isolate the offending commit, as has been asked for a couple of times now, then there will never be any progress for this bug report. -- 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/1768976 Title: Ubuntu 18.04 is overheating after upgrade from 16.04 Status in linux package in Ubuntu: Confirmed Status in xserver-xorg-video-nouveau package in Ubuntu: Confirmed Bug description: Ubuntu is overheating at my laptop. Opening youtube on firefox is enough for critical temperature shutdown. Using lm-sensors for monitoring on 18.04 the temp varies between 70 and 85°C with only firefox or chrome open and doing nothing. On my old 16.04 with same using, the temp varies between 55 and 70°C. First thought was the driver nouveau is the problem, and finally I was able to install by add "nouveau.modeset=0" at livecd boot options, without temp shutdown. After install I disable the nouveau at modprobe blacklist, but the system continues overheating and shutdown with basic usage. I have no idea what's happening with the bionic at my laptop. My laptop is a Samsung RF411 i5 2nd Generation and Geforce 540M. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader-core 1:18.04.17 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Thu May 3 16:22:40 2018 InstallationDate: Installed on 2018-04-27 (6 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: No upgrade log present (probably fresh install) VarLogDistupgradeAptHistorylog: Start-Date: 2018-04-27 15:46:02 End-Date: 2018-04-27 15:46:02 VarLogDistupgradeAptlog: Log time: 2018-04-27 15:45:39.753331 Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Log time: 2018-04-27 15:46:04.859979 VarLogDistupgradeApttermlog: Log started: 2018-04-27 15:46:02 Log ended: 2018-04-27 15:46:02 --- .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edir 2354 F pulseaudio CompositorRunning: None DistUpgraded: Fresh install DistroCodename: bionic DistroRelease: Ubuntu 18.04 DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 4.15.0-20-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 4.15.0-22-generic, x86_64: installed GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Samsung Electronics Co Ltd 2nd Generation Core Processor Family Integrated Graphics Controller [144d:c0a5] Subsystem: Samsung Electronics Co Ltd GF108M [GeForce GT 540M] [144d:c0a5] HibernationDevice: RESUME=UUID=e7a61aee-64c2-4c88-b4e1-4de481d0f88d InstallationDate: Installed on 2018-04-27 (36 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) MachineType: SAMSUNG ELECTRONICS CO., LTD. RF511/RF411/RF711 NonfreeKernelModules: wl Package: xserver-xorg-video-nouveau 1:1.0.15-2 PackageArchitecture: amd64 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic root=UUID=db38a22c-0e9f-4e1a-b9f7-f7aac2544394 ro quiet splash nouveau.runpm=0 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-4.15.0-22-generic N/A linux-backports-modules-4.15.0-22-generic N/A linux-firmware 1.173.1 Tags: bionic ubuntu Uname: Linux 4.15.0-22-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/26/2011 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 10HX.M034.20110426.SSH dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: RF511/RF411/RF711 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LT
[Kernel-packages] [Bug 869017] Re: Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)
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 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 enables screenblanking, concealing crashdumps (DPMS is not used) Status in kbd package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in kbd source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Status in kbd package in Debian: Fix Released Bug description: James Rice of Jump Networks noticed that there is a screen-blanker enabled on Ubuntu Server. James notes that this blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that the crash output is invisible which is unhelpful on a server (virtual or otherwise). Ideally the screen should (at a minimum) be turned on and unblanked at the point of an OOPs/crash being printed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1844201] Re: turbostat is over constrained by dependencies
** 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 in linux package in Ubuntu: Confirmed Bug description: 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 unnecessary, kernel version dependency checks. This makes it difficult when trying to help others when we want them to try a newer or older kernel, and often we have to get them to override this and use turbostat directly. While turbostat is part of the kernel source tree, it does not depend on the kernel version at all. Here is an excerpt from a recent e-mail [1] from the turbostat maintainer: > FWIW, > > The latest turbostat and x86_energy_perf_policy utilities > in the upstream kernel tree should always be backward compatible > with all old kernels. If that is EVER not the case, I want to know about it. > > Yes, I know that some distros ship old versions of these utilities built > out of their matching kernel tree snapshots. > Yes, applying upstream fixes to .stable for such distros is a good thing. > > However, the better solution for these particular utilities, is that they > simply always use upstream utilities -- even with old kernels. > > When somebody reports a problem and I need them to run these tools, > 100% of the time, I start by sending them the latest upstream version > to replace the old version shipped by the distro. I have been using turbostat for several years, minus the Ubuntu part, and never had a problem with any version of turbostat with any kernel. This bug report is to request the deletion of the dependency check for Ubuntu. I am not saying it always has to be the latest version, but it should not be crippled by the dependency check. [1] https://marc.info/?l=linux-pm&m=156770359620861&w=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1844201/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1844201] Re: turbostat is over constrained by dependencies
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 over constrained by dependencies Status in linux package in Ubuntu: New Bug description: 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 unnecessary, kernel version dependency checks. This makes it difficult when trying to help others when we want them to try a newer or older kernel, and often we have to get them to override this and use turbostat directly. While turbostat is part of the kernel source tree, it does not depend on the kernel version at all. Here is an excerpt from a recent e-mail [1] from the turbostat maintainer: > FWIW, > > The latest turbostat and x86_energy_perf_policy utilities > in the upstream kernel tree should always be backward compatible > with all old kernels. If that is EVER not the case, I want to know about it. > > Yes, I know that some distros ship old versions of these utilities built > out of their matching kernel tree snapshots. > Yes, applying upstream fixes to .stable for such distros is a good thing. > > However, the better solution for these particular utilities, is that they > simply always use upstream utilities -- even with old kernels. > > When somebody reports a problem and I need them to run these tools, > 100% of the time, I start by sending them the latest upstream version > to replace the old version shipped by the distro. I have been using turbostat for several years, minus the Ubuntu part, and never had a problem with any version of turbostat with any kernel. This bug report is to request the deletion of the dependency check for Ubuntu. I am not saying it always has to be the latest version, but it should not be crippled by the dependency check. [1] https://marc.info/?l=linux-pm&m=156770359620861&w=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1844201/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1844201] [NEW] turbostat is over constrained by dependencies
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 unnecessary, kernel version dependency checks. This makes it difficult when trying to help others when we want them to try a newer or older kernel, and often we have to get them to override this and use turbostat directly. While turbostat is part of the kernel source tree, it does not depend on the kernel version at all. Here is an excerpt from a recent e-mail [1] from the turbostat maintainer: > FWIW, > > The latest turbostat and x86_energy_perf_policy utilities > in the upstream kernel tree should always be backward compatible > with all old kernels. If that is EVER not the case, I want to know about it. > > Yes, I know that some distros ship old versions of these utilities built > out of their matching kernel tree snapshots. > Yes, applying upstream fixes to .stable for such distros is a good thing. > > However, the better solution for these particular utilities, is that they > simply always use upstream utilities -- even with old kernels. > > When somebody reports a problem and I need them to run these tools, > 100% of the time, I start by sending them the latest upstream version > to replace the old version shipped by the distro. I have been using turbostat for several years, minus the Ubuntu part, and never had a problem with any version of turbostat with any kernel. This bug report is to request the deletion of the dependency check for Ubuntu. I am not saying it always has to be the latest version, but it should not be crippled by the dependency check. [1] https://marc.info/?l=linux-pm&m=156770359620861&w=2 ** Affects: linux (Ubuntu) Importance: Undecided Status: 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 over constrained by dependencies Status in linux package in Ubuntu: New Bug description: 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 unnecessary, kernel version dependency checks. This makes it difficult when trying to help others when we want them to try a newer or older kernel, and often we have to get them to override this and use turbostat directly. While turbostat is part of the kernel source tree, it does not depend on the kernel version at all. Here is an excerpt from a recent e-mail [1] from the turbostat maintainer: > FWIW, > > The latest turbostat and x86_energy_perf_policy utilities > in the upstream kernel tree should always be backward compatible > with all old kernels. If that is EVER not the case, I want to know about it. > > Yes, I know that some distros ship old versions of these utilities built > out of their matching kernel tree snapshots. > Yes, applying upstream fixes to .stable for such distros is a good thing. > > However, the better solution for these particular utilities, is that they > simply always use upstream utilities -- even with old kernels. > > When somebody reports a problem and I need them to run these tools, > 100% of the time, I start by sending them the latest upstream version > to replace the old version shipped by the distro. I have been using turbostat for several years, minus the Ubuntu part, and never had a problem with any version of turbostat with any kernel. This bug report is to request the deletion of the dependency check for Ubuntu. I am not saying it always has to be the latest version, but it should not be crippled by the dependency check. [1] https://marc.info/?l=linux-pm&m=156770359620861&w=2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1844201/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1817321] Re: installer does not support iSCSI iBFT
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, like other ones I have done already. -- 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/1817321 Title: installer does not support iSCSI iBFT Status in debian-installer package in Ubuntu: Fix Released Status in hw-detect package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in partman-iscsi package in Ubuntu: Fix Released Status in debian-installer source package in Bionic: Fix Released Status in hw-detect source package in Bionic: Fix Released Status in linux source package in Bionic: Fix Released Status in partman-iscsi source package in Bionic: Fix Released Status in debian-installer source package in Cosmic: Fix Released Status in hw-detect source package in Cosmic: Fix Released Status in linux source package in Cosmic: Fix Released Status in partman-iscsi source package in Cosmic: Fix Released Status in debian-installer source package in Disco: Fix Released Status in hw-detect source package in Disco: Fix Released Status in linux source package in Disco: Fix Released Status in partman-iscsi source package in Disco: Fix Released Status in debian-installer source package in Eoan: Fix Released Status in hw-detect source package in Eoan: Fix Released Status in linux source package in Eoan: Fix Released Status in partman-iscsi source package in Eoan: Fix Released Bug description: [Impact] * It's not possible to access iBFT (iSCSI Boot Firmware Table) information (settings for network interface, initiator, and target) in the installer because the 'iscsi_ibft' module is not present in udeb packages. * Even if it was, the installer does not handle iBFT information at all, thus any settings are ignored, and iSCSI-related configuration has to be done manually or with workarounds. * This impacts user-experience and automatic installation on systems and deployments which actually do provide the iBFT feature and information, but cannot use it practically. * With proper iBFT support in the installer (kernel module in udeb package and automatic iSCSI-related configuration) users will be able to rely on iBFT to install/deploy Ubuntu on their servers and datacenters. * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb, and configure network/iSCSI according to iBFT information in disk-detect. This is done in disk-detect so that the iSCSI LUNs are detected as disks (useful in case of no other disks in the system so the installer doesn't complain nor wait too long) and that any partman-related preseed options are not required and may be still available for the user. [Test Case] * linux package / kernel module in udeb: $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko Check the module loads in the installer environment. See comment with example for disco. * d-i/hw-detect/partman-iscsi package: See comments 11, 12, 13. [Regression Potential] * linux package: low, the kernel module is not loaded by default, and only checks whether iBFT information is present in firmware, then exposes that in sysfs in read-only mode. * d-i/hw-detect/partman-iscsi: - d-i: kernel version update to include iscsi_ibft module, based on kernel released to -updates plus one week monitoring bug reports -- it should be OK. Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64 on baremetal -- see comment 11. - hw-detect: low, the changes are enabled by a preseed option. see comment 12. - partman-iscsi: low, simple changes, plus one fix that has been tested in detail, and falls back to previous behavior if it fails. see comment 13. [Other Info] * This has been verified both by the developer with a simple iSCSI iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE) and by an user with system/firmware that supports iBFT for iSCSI. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1830961] Re: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]
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 mainline upstream git branch. Earlier today, a kernel 5.3-rc1 merge request was issued by the kbuild team [1]. Once that branch has been "pulled" into the upstream mainline, the Ubuntu mainline daily compiles should start working the next day. In about 8 days there will be kernel 5.3-rc1, which should have the patch. [1] https://www.spinics.net/lists/linux-kbuild/msg22526.html Other references: https://kernel.ubuntu.com/~kernel-ppa/mainline/daily/ https://www.spinics.net/lists/linux-kbuild/msg22298.html https://patchwork.kernel.org/patch/11037379/ -- 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/1830961 Title: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect- branch’ and ‘-fcf-protection’ are not compatible] Status in gcc-9 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in nvidia-graphics-drivers-430 package in Ubuntu: Fix Released Status in virtualbox package in Ubuntu: Won't Fix Status in xtables-addons package in Ubuntu: Won't Fix Bug description: Compiling kernels & kernel modules fails due to these errors: ./include/linux/compiler.h:193:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible (This happens with any kernel modules.) This appears to be due to the changes in 9.1.0-3ubuntu1 enabling -fcf- protection by default on 19.10's gcc-9. Switching to gcc-8 allows compilation to proceed. WORKAROUND: sudo ln -fs gcc-8 /usr/bin/gcc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836373] Re: Mainline builds for 5.1 and 5.2 failing for amd64 and i386
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 Ubuntu: Confirmed Bug description: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2/BUILD.LOG.amd64 /home/kernel/COD/linux/include/linux/compiler.h: In function '__read_once_size': /home/kernel/COD/linux/include/linux/compiler.h:193:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible The build has multiple errors saying '-mindirect-branch' and '-fcf- protection' are not compatible. This currently affects the 5.2 kernel build and the 5.1.17 kernel build. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836373/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1830961] Re: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]
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 --git a/Makefile b/Makefile index 3e4868a6498b..d8ccc47215be 100644 --- a/Makefile +++ b/Makefile @@ -630,8 +630,8 @@ ifdef CONFIG_FUNCTION_TRACER CC_FLAGS_FTRACE := -pg endif -RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern -mindirect-branch-register -RETPOLINE_VDSO_CFLAGS_GCC := -mindirect-branch=thunk-inline -mindirect-branch-register +RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern -mindirect-branch-register -fcf-protection=none +RETPOLINE_VDSO_CFLAGS_GCC := -mindirect-branch=thunk-inline -mindirect-branch-register -fcf-protection=none RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk RETPOLINE_VDSO_CFLAGS_CLANG := -mretpoline RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call cc-option,$(RETPOLINE_CFLAGS_CLANG))) -- 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/1830961 Title: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect- branch’ and ‘-fcf-protection’ are not compatible] Status in gcc-9 package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-430 package in Ubuntu: Fix Committed Status in virtualbox package in Ubuntu: Confirmed Status in xtables-addons package in Ubuntu: New Bug description: Compiling kernels & kernel modules fails due to these errors: ./include/linux/compiler.h:193:1: error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible (This happens with any kernel modules.) This appears to be due to the changes in 9.1.0-3ubuntu1 enabling -fcf- protection by default on 19.10's gcc-9. Switching to gcc-8 allows compilation to proceed. WORKAROUND: sudo ln -fs gcc-8 /usr/bin/gcc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794230] Re: failed to load kdump kernel
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 notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/1794230 Title: failed to load kdump kernel Status in kexec-tools package in Ubuntu: Confirmed Bug description: Steps: 1) In VMWare ESXi create VM with OS Ubuntu 18.04.1 LTS. 2) In Ubuntu compiled and installed Xen 4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1 3) Next installed kexec-tools 2.0.16 and kdump-tools 1.6.3-2 4) In /etc/default/grub.d/kdump-tools.cfg change crashkernel value to 512M 5) update-grub 6) reboot After reboot i try check status: sudo service kdump-tools status And get: ● kdump-tools.service - Kernel crash dump capture service Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor preset: enabled) Active: active (exited) since Tue 2018-09-25 05:06:10 UTC; 34s ago Process: 1046 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS) Main PID: 1046 (code=exited, status=0/SUCCESS) сен 25 05:06:09 ptms-all-qa7 systemd[1]: Starting Kernel crash dump capture service... сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: Starting kdump-tools: * Creating symlink /var/lib/kdump/vmlinuz сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: * Creating symlink /var/lib/kdump/initrd.img сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: Memory for crashkernel is not reserved сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: Please reserve memory by passing"crashkernel=X@Y" parameter to kernel сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: Then try to loading kdump kernel сен 25 05:06:09 ptms-all-qa7 kdump-tools[1046]: * failed to load kdump kernel сен 25 05:06:10 ptms-all-qa7 kdump-tools[1347]: failed to load kdump kernel сен 25 05:06:10 ptms-all-qa7 systemd[1]: Started Kernel crash dump capture service. Log says "Memory for crashkernel is not reserved", but if run: sudo cat /proc/iomem | grep Crash I get: 1800-37ff : Crash kernel What to do? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1794230/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1768121] Re: Mainline Kernel since 4.16.4 has postinstall script error
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 subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1768121 Title: Mainline Kernel since 4.16.4 has postinstall script error Status in linux package in Ubuntu: Confirmed Bug description: Hello, I don't know who does the packaging for the Mainline Kernel(http://kernel.ubuntu.com/~kernel-ppa/mainline/), but it has been erroring out in packaging and also for the packages in x64/32 that have made it, there are post install script errors within the packaging which disallow installation of the kernel. Tested on Ubuntu 16.04. Selecting previously unselected package linux-headers-4.16.6-041606. (Reading database ... 392264 files and directories currently installed.) Preparing to unpack linux-headers-4.16.6-041606_4.16.6-041606.201804300418_all.deb ... Unpacking linux-headers-4.16.6-041606 (4.16.6-041606.201804300418) ... Selecting previously unselected package linux-headers-4.16.6-041606-generic. Preparing to unpack linux-headers-4.16.6-041606-generic_4.16.6-041606.201804300418_amd64.deb ... Unpacking linux-headers-4.16.6-041606-generic (4.16.6-041606.201804300418) ... Selecting previously unselected package linux-image-unsigned-4.16.6-041606-generic. Preparing to unpack linux-image-unsigned-4.16.6-041606-generic_4.16.6-041606.201804300418_amd64.deb ... Unpacking linux-image-unsigned-4.16.6-041606-generic (4.16.6-041606.201804300418) ... Selecting previously unselected package linux-modules-4.16.6-041606-generic. Preparing to unpack linux-modules-4.16.6-041606-generic_4.16.6-041606.201804300418_amd64.deb ... Unpacking linux-modules-4.16.6-041606-generic (4.16.6-041606.201804300418) ... Setting up linux-headers-4.16.6-041606 (4.16.6-041606.201804300418) ... dpkg: dependency problems prevent configuration of linux-headers-4.16.6-041606-generic: linux-headers-4.16.6-041606-generic depends on libssl1.1 (>= 1.1.0); however: Package libssl1.1 is not installed. dpkg: error processing package linux-headers-4.16.6-041606-generic (--install): dependency problems - leaving unconfigured Setting up linux-modules-4.16.6-041606-generic (4.16.6-041606.201804300418) ... Setting up linux-image-unsigned-4.16.6-041606-generic (4.16.6-041606.201804300418) ... /var/lib/dpkg/info/linux-image-unsigned-4.16.6-041606-generic.postinst: 50: /var/lib/dpkg/info/linux-image-unsigned-4.16.6-041606-generic.postinst: linux-update-symlinks: not found dpkg: error processing package linux-image-unsigned-4.16.6-041606-generic (--install): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: linux-headers-4.16.6-041606-generic linux-image-unsigned-4.16.6-041606-generic What's new in 4.16.6 is the libssl1.1 dependency, as it just errored out with a half installed kernel and that post-installation script error you see above. Please let whoever packages these kernels know that is't been dead stick post 4.16.3. Thanks. HH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1768121/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1649905] Re: On boot excessive number of kworker threads are running
@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/1649905 Title: On boot excessive number of kworker threads are running Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Status in linux source package in Zesty: Fix Released Bug description: [SRU REQUEST, Yakkety] Ubuntu Yakkety 4.8 kernels have an excessive amount of kworker threads running, this is especially noticeable on boot, one can easily have > 1000 kworker threads on a 4 CPU box. Bisected this down to: commit 81ae6d03952c1bfb96e1a716809bd65e7cd14360 Author: Vladimir Davydov Date: Thu May 19 17:10:34 2016 -0700 mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink() [FIX] The synchronize_sched calls seem to create all these excessive kworker threads. This is fixed with upstream commit: commit 89e364db71fb5e7fc8d93228152abfa67daf35fa Author: Vladimir Davydov Date: Mon Dec 12 16:41:32 2016 -0800 slub: move synchronize_sched out of slab_mutex on shrink synchronize_sched() is a heavy operation and calling it per each cache owned by a memory cgroup being destroyed may take quite some time. What is worse, it's currently called under the slab_mutex, stalling all works doing cache creation/destruction. Actually, there isn't much point in calling synchronize_sched() for each cache - it's enough to call it just once - after setting cpu_partial for all caches and before shrinking them. This way, we can also move it out of the slab_mutex, which we have to hold for iterating over the slab cache list. [TEST CASE] Without the fix, boot a Yakkety and count the number of kthreads: ps -ef | grep kworker | wc -l 1034 With the fix, boot count the number kthreads and it will be dramatically less: ps -ef | grep kworker | wc -l 32 Since this touches the slub allocator and cgroups too, I have regression tested this against the kernel-team autotest regression tests to sanity check this fix. All seems OK. Note: this only affects kernels from 4.7-rc1 through to 4.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649905/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 869017] Re: Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)
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 enables screenblanking, concealing crashdumps (DPMS is not used) Status in kbd package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in kbd source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Status in kbd package in Debian: Fix Released Bug description: James Rice of Jump Networks noticed that there is a screen-blanker enabled on Ubuntu Server. James notes that this blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that the crash output is invisible which is unhelpful on a server (virtual or otherwise). Ideally the screen should (at a minimum) be turned on and unblanked at the point of an OOPs/crash being printed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1677491] Re: System freeze
@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 my issue, which we are not sure is the same as
yours or not, these are the related commits:
3fe87967c536e828bf1ea14b3ec3827d1101152e mm: convert remove_migration_pte() to
use page_vma_mapped_walk()
4b0ece6fa0167b22c004ff69e137dc94ee2e469e mm: migrate: fix
remove_migration_pte() for ksm pages
ace71a19cec5eb430207c3269d8a2683f0574306 mm: introduce page_vma_mapped_walk()
d75450ff40df0199bf13dfb19f435519ff947138 mm: fix page_vma_mapped_walk() for ksm
pages
Because these events are so rare, I would suggest trying kernel 4.11-rc6
for an extended time.
--
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/1677491
Title:
System freeze
Status in linux package in Ubuntu:
Confirmed
Bug description:
I'm getting a system freeze, consisting of all applications slowing
down and stopping to respond. This starts happening after some hours
of normal functioning of the system. A reboot recovers the system
until the next freeze. It doesn't seem that any application is
exhausting the memory. Here is an excerpt of my syslog, there are some
messages about the kernel and that's why I file this bug against the
kernel:
Mar 30 06:48:25 walter kernel: [67016.893820] RIP: 0033:0x7f70ba6dc246
Mar 30 06:48:25 walter kernel: [67016.893821] RSP: 002b:7f70a92e8d70
EFLAGS: 00010206
Mar 30 06:48:25 walter kernel: [67016.893822] RAX: 7f709cafffe8 RBX:
7f709ca00c20 RCX: 00018de8
Mar 30 06:48:25 walter kernel: [67016.893823] RDX: 0637 RSI:
RDI: 7f70a92e8da0
Mar 30 06:48:25 walter kernel: [67016.893824] RBP: 7f709ca0 R08:
R09: 00442c30
Mar 30 06:48:25 walter kernel: [67016.893825] R10: 002cbc87c178d3be R11:
7f70a92e8df0 R12: 7f70a92e8da0
Mar 30 06:48:25 walter kernel: [67016.893826] R13: 0001 R14:
7f70a3561c80 R15: 7f70b389
Mar 30 06:48:25 walter kernel: [67016.893827] Code: c0 74 e6 4d 85 c9 c6 07
01 74 30 41 c7 41 08 01 00 00 00 e9 52 ff ff ff 83 fa 01 0f 84 b0 fe ff ff 8b
07 84 c0 74 08 f3 90 8b 07 <84> c0 75 f8 b8 01 00 00 00 66 89 07 5d c3 f3 90 4c
8b 09 4d 85
Mar 30 06:48:35 walter fetchmail[3089]: getaddrinfo("imap.gmail.com","imaps")
error: Name or service not known
Mar 30 06:48:35 walter fetchmail[3089]: IMAP connection to imap.gmail.com
failed: Resource temporarily unavailable
Mar 30 06:48:35 walter fetchmail[3089]: Query status=2 (SOCKET)
Mar 30 06:48:53 walter kernel: [67044.895723] NMI watchdog: BUG: soft lockup
- CPU#3 stuck for 22s! [JS Helper:19669]
Mar 30 06:48:53 walter kernel: [67044.895724] Modules linked in: xt_CHECKSUM
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c
pci_stub xt_tcpudp bridge stp llc iptable_filter vboxpci(OE) vboxnetadp(OE)
vboxnetflt(OE) vboxdrv(OE) snd_hrtimer usblp binfmt_misc nls_iso8859_1
snd_usb_audio snd_usbmidi_lib intel_rapl sb_edac edac_core gspca_zc3xx
gspca_main v4l2_common videodev media snd_hda_codec_realtek input_leds
x86_pkg_temp_thermal snd_hda_codec
_hdmi snd_hda_codec_generic intel_powerclamp snd_hda_intel coretemp
snd_hda_codec snd_hda_core snd_hwdep kvm_intel snd_pcm kvm irqbypass
snd_seq_midi snd_seq_midi_event crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc aesni_intel snd_rawmidi snd_seq aes_x86_64 crypto_simd
glue_helper dcdbas snd_seq_device
Mar 30 06:48:53 walter kernel: [67044.895757] snd_timer cryptd snd
intel_cstate soundcore dell_smm_hwmon intel_rapl_perf shpchp mei_me mei lpc_ich
mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs xor
raid6_pq amdgpu hid_generic usbhid hid ums_cypress uas usb_storage amdkfd
amd_iommu_v2 radeon i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect
e1000e sysimgblt fb_sys_fops drm ptp ahci pps_core pata_acpi libahci wmi fjes
Mar 30 06:48:53 walter kernel: [67044.895775] CPU: 3 PID: 19669 Comm: JS
Helper Tainted: G DOEL 4.10.0-14-generic #16-Ubuntu
Mar 30 06:48:53 walter kernel: [67044.895776] Hardware name: Dell Inc.
Precision Tower 7810/0GWHMW, BIOS A07 04/14/2015
Mar 30 06:48:53 walter kernel: [67044.895777] task: 9fcab54ac380
task.stack: baf56602c000
Mar 30 06:48:53 walter kernel: [67044.895780] RIP:
0010:native_queued_spin_lock_slowpath+0x17b/0x1a0
Mar 30 06:48:53 walter kernel: [67044.895781] RSP: :baf56602fd48
EFLAGS: 0202 ORIG_RAX: ff10
Mar 30 06:48:53 walter kernel: [67044.895783] RAX: 0101 RBX:
eb799edbe070 RCX: 0001
Mar 30 06:48:53 walt
[Kernel-packages] [Bug 1671287] Re: I'm not working with SGI, JFS and QNX4.
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 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. Status in Linux: Unknown Status in linux package in Ubuntu: Incomplete Bug description: I'm not working with SGI, JFS and QNX4. dmesg: [ 3466.560076] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 3466.580617] JFS: nTxBlock = 8192, nTxLock = 65536 [...] [ 3466.635004] QNX4 filesystem 0.2.3 registered. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: linux-image-4.10.0-11-generic 4.10.0-11.13 ProcVersionSignature: Ubuntu 4.10.0-11.13-generic 4.10.1 Uname: Linux 4.10.0-11-generic x86_64 ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: caravena 2094 F...m pulseaudio /dev/snd/controlC0: caravena 2094 F pulseaudio CurrentDesktop: GNOME Date: Wed Mar 8 21:36:15 2017 HibernationDevice: RESUME=UUID=360bd2d2-4f44-4311-86d6-4781ac81ee87 InstallationDate: Installed on 2015-07-26 (591 days ago) InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150723) MachineType: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-11-generic root=UUID=4f4435ca-b877-47a5-9065-3dd624c0514e ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.10.0-11-generic N/A linux-backports-modules-4.10.0-11-generic N/A linux-firmware 1.163 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2013 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: P14AAJ dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: SAMSUNG_NP1234567890 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: FAB1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP14AAJ:bd04/15/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn530U3C/530U4C:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1: dmi.product.name: 530U3C/530U4C dmi.product.version: 0.1 dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1671287/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1671287] Re: I'm not working with SGI, JFS and QNX4.
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. Status in Linux: Unknown Status in linux package in Ubuntu: Incomplete Bug description: I'm not working with SGI, JFS and QNX4. dmesg: [ 3466.560076] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 3466.580617] JFS: nTxBlock = 8192, nTxLock = 65536 [...] [ 3466.635004] QNX4 filesystem 0.2.3 registered. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: linux-image-4.10.0-11-generic 4.10.0-11.13 ProcVersionSignature: Ubuntu 4.10.0-11.13-generic 4.10.1 Uname: Linux 4.10.0-11-generic x86_64 ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: caravena 2094 F...m pulseaudio /dev/snd/controlC0: caravena 2094 F pulseaudio CurrentDesktop: GNOME Date: Wed Mar 8 21:36:15 2017 HibernationDevice: RESUME=UUID=360bd2d2-4f44-4311-86d6-4781ac81ee87 InstallationDate: Installed on 2015-07-26 (591 days ago) InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150723) MachineType: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-11-generic root=UUID=4f4435ca-b877-47a5-9065-3dd624c0514e ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.10.0-11-generic N/A linux-backports-modules-4.10.0-11-generic N/A linux-firmware 1.163 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2013 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: P14AAJ dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: SAMSUNG_NP1234567890 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: FAB1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP14AAJ:bd04/15/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn530U3C/530U4C:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1: dmi.product.name: 530U3C/530U4C dmi.product.version: 0.1 dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1671287/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1671287] Re: I'm not working with SGI, JFS and QNX4.
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 few 4.11 rcs). Apr 4 12:54:09 s15 kernel: [46768.740976] SGI XFS with ACLs, security attributes, realtime, no debug enabled Apr 4 12:54:09 s15 kernel: [46768.757610] JFS: nTxBlock = 8192, nTxLock = 65536 Apr 4 12:54:09 s15 kernel: [46768.797629] ntfs: driver 2.1.32 [Flags: R/O MODULE]. Apr 4 12:54:09 s15 kernel: [46768.850974] QNX4 filesystem 0.2.3 registered. -- 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. Status in Linux: Unknown Status in linux package in Ubuntu: Incomplete Bug description: I'm not working with SGI, JFS and QNX4. dmesg: [ 3466.560076] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 3466.580617] JFS: nTxBlock = 8192, nTxLock = 65536 [...] [ 3466.635004] QNX4 filesystem 0.2.3 registered. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: linux-image-4.10.0-11-generic 4.10.0-11.13 ProcVersionSignature: Ubuntu 4.10.0-11.13-generic 4.10.1 Uname: Linux 4.10.0-11-generic x86_64 ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: caravena 2094 F...m pulseaudio /dev/snd/controlC0: caravena 2094 F pulseaudio CurrentDesktop: GNOME Date: Wed Mar 8 21:36:15 2017 HibernationDevice: RESUME=UUID=360bd2d2-4f44-4311-86d6-4781ac81ee87 InstallationDate: Installed on 2015-07-26 (591 days ago) InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150723) MachineType: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-11-generic root=UUID=4f4435ca-b877-47a5-9065-3dd624c0514e ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.10.0-11-generic N/A linux-backports-modules-4.10.0-11-generic N/A linux-firmware 1.163 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2013 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: P14AAJ dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: SAMSUNG_NP1234567890 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: FAB1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP14AAJ:bd04/15/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn530U3C/530U4C:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1: dmi.product.name: 530U3C/530U4C dmi.product.version: 0.1 dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1671287/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
@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 is not resolved quite yet, even though that is the status). If your issue always occurs and you are not using the proper Dell AC adapter, then that is why. Otherwise, I don't know. Try the acpi_cpufreq CPU frequency scaling driver instead. Also have a look at: https://bugzilla.kernel.org/show_bug.cgi?id=189861 ** Bug watch added: Linux Kernel Bug Tracker #90041 http://bugzilla.kernel.org/show_bug.cgi?id=90041 ** Bug watch added: Linux Kernel Bug Tracker #189861 http://bugzilla.kernel.org/show_bug.cgi?id=189861 -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.00% apache2 [unknown] [k] | + 10.01% 0.04% swapper [kernel.kallsyms] [k] tcp_v4_do_rcv Expanding in a few of those, you'll see: | - 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry |- 55.04% cpu_startup_entry | - 52.98% call_cpuidle | + 52.93% cpuidle_enter | + 0.00% ret_from_intr |0.00% cpuidle_enter_state |0.00% irq_entries_start | + 1.14% cpuidle_select | + 0.47% schedule_preempt_disabled |
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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. > but unless you can suggest a patch to try or a setting to change I am > probably just going to disable pstate on the GRUB command line and be done > with it Well, a lot of people do just that, but then also wonder why issues don't get solved. Issues don't get solved if people don't investigate. Myself, and without any proof, I suspect thermald is your root issue. Have a look at this bug: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1656528 By the way, a cool trick for some of the stuff you were listing above is to do this instead: root@s15:/sys/devices/system/cpu/cpu0/cpufreq# grep . * affected_cpus:0 cpuinfo_cur_freq:1599768 cpuinfo_max_freq:380 cpuinfo_min_freq:160 cpuinfo_transition_latency:4294967295 related_cpus:0 scaling_available_governors:performance powersave scaling_cur_freq:1599768 scaling_driver:intel_pstate scaling_governor:powersave scaling_max_freq:380 scaling_min_freq:160 scaling_setspeed: -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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 model? What is your kernel version? And does your issue persist with the latest mainline kernel, 4.10-rc6 (http://kernel.ubuntu.com/~kernel- ppa/mainline/v4.10-rc6/)? -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1649905] Re: On boot excessive number of kworker threads are running
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 Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1649905 Title: On boot excessive number of kworker threads are running Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Status in linux source package in Zesty: Fix Released Bug description: [SRU REQUEST, Yakkety] Ubuntu Yakkety 4.8 kernels have an excessive amount of kworker threads running, this is especially noticeable on boot, one can easily have > 1000 kworker threads on a 4 CPU box. Bisected this down to: commit 81ae6d03952c1bfb96e1a716809bd65e7cd14360 Author: Vladimir Davydov Date: Thu May 19 17:10:34 2016 -0700 mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink() [FIX] The synchronize_sched calls seem to create all these excessive kworker threads. This is fixed with upstream commit: commit 89e364db71fb5e7fc8d93228152abfa67daf35fa Author: Vladimir Davydov Date: Mon Dec 12 16:41:32 2016 -0800 slub: move synchronize_sched out of slab_mutex on shrink synchronize_sched() is a heavy operation and calling it per each cache owned by a memory cgroup being destroyed may take quite some time. What is worse, it's currently called under the slab_mutex, stalling all works doing cache creation/destruction. Actually, there isn't much point in calling synchronize_sched() for each cache - it's enough to call it just once - after setting cpu_partial for all caches and before shrinking them. This way, we can also move it out of the slab_mutex, which we have to hold for iterating over the slab cache list. [TEST CASE] Without the fix, boot a Yakkety and count the number of kthreads: ps -ef | grep kworker | wc -l 1034 With the fix, boot count the number kthreads and it will be dramatically less: ps -ef | grep kworker | wc -l 32 Since this touches the slub allocator and cgroups too, I have regression tested this against the kernel-team autotest regression tests to sanity check this fix. All seems OK. Note: this only affects kernels from 4.7-rc1 through to 4.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649905/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1649905] Re: On boot excessive number of kworker threads are running
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 are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1649905 Title: On boot excessive number of kworker threads are running Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Released Bug description: [SRU REQUEST, Yakkety] Ubuntu Yakkety 4.8 kernels have an excessive amount of kworker threads running, this is especially noticeable on boot, one can easily have > 1000 kworker threads on a 4 CPU box. Bisected this down to: commit 81ae6d03952c1bfb96e1a716809bd65e7cd14360 Author: Vladimir Davydov Date: Thu May 19 17:10:34 2016 -0700 mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink() [FIX] The synchronize_sched calls seem to create all these excessive kworker threads. This is fixed with upstream commit: commit 89e364db71fb5e7fc8d93228152abfa67daf35fa Author: Vladimir Davydov Date: Mon Dec 12 16:41:32 2016 -0800 slub: move synchronize_sched out of slab_mutex on shrink synchronize_sched() is a heavy operation and calling it per each cache owned by a memory cgroup being destroyed may take quite some time. What is worse, it's currently called under the slab_mutex, stalling all works doing cache creation/destruction. Actually, there isn't much point in calling synchronize_sched() for each cache - it's enough to call it just once - after setting cpu_partial for all caches and before shrinking them. This way, we can also move it out of the slab_mutex, which we have to hold for iterating over the slab cache list. [TEST CASE] Without the fix, boot a Yakkety and count the number of kthreads: ps -ef | grep kworker | wc -l 1034 With the fix, boot count the number kthreads and it will be dramatically less: ps -ef | grep kworker | wc -l 32 Since this touches the slub allocator and cgroups too, I have regression tested this against the kernel-team autotest regression tests to sanity check this fix. All seems OK. Note: this only affects kernels from 4.7-rc1 through to 4.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649905/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1649905] Re: On boot excessive number of kworker threads are running
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 watch added: Linux Kernel Bug Tracker #172991 http://bugzilla.kernel.org/show_bug.cgi?id=172991 -- 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/1649905 Title: On boot excessive number of kworker threads are running Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: In Progress Status in linux source package in Zesty: Fix Released Bug description: [SRU REQUEST, Yakkety] Ubuntu Yakkety 4.8 kernels have an excessive amount of kworker threads running, this is especially noticeable on boot, one can easily have > 1000 kworker threads on a 4 CPU box. Bisected this down to: commit 81ae6d03952c1bfb96e1a716809bd65e7cd14360 Author: Vladimir Davydov Date: Thu May 19 17:10:34 2016 -0700 mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink() [FIX] The synchronize_sched calls seem to create all these excessive kworker threads. This is fixed with upstream commit: commit 89e364db71fb5e7fc8d93228152abfa67daf35fa Author: Vladimir Davydov Date: Mon Dec 12 16:41:32 2016 -0800 slub: move synchronize_sched out of slab_mutex on shrink synchronize_sched() is a heavy operation and calling it per each cache owned by a memory cgroup being destroyed may take quite some time. What is worse, it's currently called under the slab_mutex, stalling all works doing cache creation/destruction. Actually, there isn't much point in calling synchronize_sched() for each cache - it's enough to call it just once - after setting cpu_partial for all caches and before shrinking them. This way, we can also move it out of the slab_mutex, which we have to hold for iterating over the slab cache list. [TEST CASE] Without the fix, boot a Yakkety and count the number of kthreads: ps -ef | grep kworker | wc -l 1034 With the fix, boot count the number kthreads and it will be dramatically less: ps -ef | grep kworker | wc -l 32 Since this touches the slub allocator and cgroups too, I have regression tested this against the kernel-team autotest regression tests to sanity check this fix. All seems OK. Note: this only affects kernels from 4.7-rc1 through to 4.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649905/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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 is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
> 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 testing) for both SLAB and SLUB, and I think (but am not sure) they have been flagged to eventually be backported to stable. I do not think any of the patches have made it into the current release candidate kernel (currently 4.9-rc2) yet. References: https://patchwork.kernel.org/patch/9359269/ https://patchwork.kernel.org/patch/9359271/ https://patchwork.kernel.org/patch/9363679/ -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
> 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 SLUB are fixed, then the decision to use SLAB or SLUB should be re-evaluated. One of Colin's original questions: "why was it [CONFIG_SLAB] changed for Yakkety?" also still needs an answer. -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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. ** Bug watch added: Linux Kernel Bug Tracker #172991 http://bugzilla.kernel.org/show_bug.cgi?id=172991 ** Bug watch added: Linux Kernel Bug Tracker #172981 http://bugzilla.kernel.org/show_bug.cgi?id=172981 -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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 commit that causes the remaining SLUB issue is: 81ae6d03952c1bfb96e1a716809bd65e7cd14360 "mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink()" It turns out that they just so happen to be adjacent commits in the tree. I will attempt to make e-mails for upstream, but it'll take me awhile. (Anyone willing to review before I send them?) -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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 bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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 test Laptop, however it is fairly easy to detect on my 16.04 server. When using "SLAB" it is trivial to detect on either computer. A bisection is going to take: "Bisecting: 5788 revisions left to test after this (roughly 13 steps)" Which I can only get to on about Tuesday or Wednesday. -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
>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 kworker threads, however it is rather difficult. -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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): $ scripts/diffconfig .config .config-4.8.0-040800rc7-generic -HAVE_ALIGNED_STRUCT_PAGE y -SLUB_CPU_PARTIAL y -SLUB_DEBUG y -SLUB_DEBUG_ON n -SLUB_STATS n DEBUG_INFO n -> y SLAB n -> y SLAB_FREELIST_RANDOM n -> y SLUB y -> n +DEBUG_INFO_DWARF4 n +DEBUG_INFO_REDUCED n +DEBUG_INFO_SPLIT n +DEBUG_SLAB n +GDB_SCRIPTS n -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Committed Status in linux source package in Yakkety: Fix Committed Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1626564] Re: 4.8 regression: SLAB is being used instead of SLUB
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 change to test. This attachment has some tools I made to very very simply show the issue. If I look at linux/Documentation/workqueue.txt and do: echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event and: cat /sys/kernel/debug/tracing/trace_pipe > out.txt with the issue, I get somwhere between 10,000 and 20,000 occurances of memcg_kmem_cache_create_func in the file (using my simple test method). Without the issue, I get 21, and an overall file size about 50 times smaller, for otherwise similar conditions. i.e. with the issue this stuff seems to go nuts. ** Attachment added: "Some tools to simply show the issue" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+attachment/4746294/+files/bla.txt -- 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/1626564 Title: 4.8 regression: SLAB is being used instead of SLUB Status in linux package in Ubuntu: Fix Committed Status in linux source package in Yakkety: Fix Committed Bug description: We're seeing hundreds of kernel worker threads being spawned with some actions, for example, after booting the desktop and hutting the brightness keys causes this. On investigation, this occurs when CONFIG_SLAB is being used. 1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of CONFIG_SLAB (why was it changed for Yakkety?) 2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker threads 3 CONFIG_SLUB seems more performant on the boot too over SLAB. Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial configs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
@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" saw a > considerable drop. What do you mean by "high load"? And when you say "saw a considerable drop", does that mean in wakeups per second or load? Note that you should observe a significant difference in load average on a server between powersave and performance mode, and that actually indicates things are working as they should be. For the SpecPower simulator test I posted above, I'll add some more data for the 0.5X and X lines: 0.5X, where Performance used 31.7% more package power: Powersave: Busy%: 12.58% (load average = 1.01) Bzy MHz: 1651 Performance: Busy%: 5.04% (load average = 0.40) Bzy MHz: 3686 X, where Performance used 42.1% more package power: Powersave: Busy%: 23.66% (load average = 1.89) Bzy MHz: 1798 Performance: Busy%: 10.56% (load average = 0.84) Bzy MHz: 3681 Isn't energy consumption what really matters, as long as performance doesn't suffer too much? What I would like to see for your servers is the results from: sudo turbostat -J -S --debug sleep 300 For the intel_pstate CPU frequency scaling driver and the powersave and performance scaling governors with your work flow. -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Committed Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.0
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
@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 overheads, I used the /proc/timer_stats method. I also did the test over 300 seconds, so as to dilute influence from the command itself. Kernel: 4.8.0-040800rc5-generic intel_pstate, "idle" system: powersave: 14722 events, 49.073 events / second performance: 14964 events, 49.879 events / second intel_pstate: extra "idle" system: powersave: 6381 total events, 21.269 events / second performance: 6788 events, 22.626 events / second Which kernel are you using? There was a flurry of high wakeups activity in June, but I thought it all got resolved. Note that there was a slight increase in wakeups with the recent change to a utilization based algorithm, but that was good thing because it solved a very long standing issue whereby the CPU frequency might not increase under high load for periodic workflows that just so happened to be idle on jiffy boundaries. You mention "on some workloads". Could you be more specific? i.e. so that I can attempt to recreate your scenario on my computer. My script: $ cat ./set_cpu_timer_stats_2 #! /bin/bash # Take a 300 second time sample # A long time is needed to amortize/dilute the effect of the command itself. # Reset the counters echo "0" > /proc/timer_stats echo "1" > /proc/timer_stats # Now let the sample time elapse sleep 300 # Now observe the timer counters cat /proc/timer_stats # And turn off timer stats. echo "0" > /proc/timer_stats What does "extra idle" mean?: $ cat set_cpu_turn_off_services #! /bin/bash # Turn off some services to try to get "idle" to be more "idle" sudo systemctl stop mysql.service sudo systemctl stop apache2.service sudo systemctl stop nmbd.service sudo systemctl stop smbd.service sudo systemctl stop cron.service sudo systemctl stop winbind.service sudo systemctl stop apt-daily.timer Recent wakeups thread: http://marc.info/?t=14661775703&r=1&w=2 -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Committed Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
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 574914536 22841 38475 51757 64425 77000 81733 3.839.6915.23 25.65 34.50 42.95 51.33 54.49 0.7%31.7% 42.1% 32.0% 12.7% 5.3%0.5%0.0% -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.00% apache2 [unknown] [k] | + 10.01% 0.04% swapper [kernel.kallsyms] [k] tcp_v4_do_rcv Expanding in a few of those, you'll see: | - 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry |- 55.04% cpu_startup_entry | - 52.98% call_cpuidle | + 52.93% cpuidle_enter | + 0.00% ret_from_intr |0.00% cpuidle_enter_state |0.00% irq_entries_start | + 1.14% cpuidle_select | + 0.47% schedule_preempt_disabled | 0.10% rcu_idle_enter | 0.09% rcu_idle_exit | + 0.05% ret_from_intr | + 0.05% tick_nohz_idle_enter | + 0.04% arch_cpu_idle_enter | 0.02% cpuidle_enter | 0.02% tick_check_broadcast_expired | + 0.01% cpuidle_reflect | 0.01% menu_reflec
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
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 watts, 1500 Seconds test run time. X ~= 18.2% on a real SpecPower. 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 574914536 22841 38475 51757 64425 77000 81733 3.839.6915.23 25.65 34.50 42.95 51.33 54.49 0.7%31.7% 42.1% 32.0% 12.7% 5.3%0.5%0.0% Note: A real SpecPower test-bed tends to get less dramatic results than my simulator. -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.00% apache2 [unknown] [k] | + 10.01% 0.04% swapper [kernel.kallsyms] [k] tcp_v4_do_rcv Expanding in a few of those, you'll see: | - 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry |- 55.04% cpu_startup_entry | - 52.98% call_cpuidle | + 52.93% cpuidle_enter | + 0.00% ret_from_intr |0.00% cpuidle_enter_state |0.00% irq_ent
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
>> 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 pretty much the only thing that I work on, and for a few years now, and through 3 maintainers. Why would Intel expend so much effort on powersave mode, if it were better to merely set performance mode and forget about it? The objective with powersave mode is best energy/ performance tradeoff. There are still issues, yes. For example whenever clock modulation becomes involved. Also, there can be a tendency to incorrectly drive up the CPU frequency. There is work in progress that should address these issues (see: http://askubuntu.com/questions/812530 /cpu-frequency-scaling-not-working-as-intended-on-vanilla- ubuntu-16-04/812721#812721 and the reference links therein.) I'll try to come back, maybe this weekend, with some energy comparison numbers. -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.00% apache2 [unknown] [k] | + 10.01% 0.04% swapper [kernel.kallsyms] [k] tcp_v4_do_rcv Expanding in a few of those, you'll see: | - 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry |- 55.04% cpu_startup_entry | - 52.98% call_cpuidle |
[Kernel-packages] [Bug 1579278] Re: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate
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 frequency scaling driver is NOT the same as "powersave" with the acpi-cpufreq CPU frequency scaling driver. The preferred governor with the intel_pstate driver is powersave. I'm saying that this: # more modern processors that support intel_pstate behave worse with # ondemand/powersave and should use performance if [ `cat /sys/devices/system/cpu/cpu$FIRSTCPU/cpufreq/scaling_driver` = intel_pstate ]; then echo 'CPU supports intel_pstate, keeping "performance"' exit 0 fi is incorrect. -- 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/1579278 Title: Keep powersave CPU frequency scaling governor for CPUs that support intel_pstate Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in sysvinit package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in systemd source package in Xenial: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: Hi, 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" saw a considerable drop. Perf report using the following commands: | perf record -g -a sleep 10 | perf report | Samples: 287K of event 'cycles:pp', Event count (approx.): 124776998906 | Children Self Command Shared Object Symbol | + 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry | + 53.51% 0.00% swapper [kernel.kallsyms] [k] start_secondary | + 53.02% 0.08% swapper [kernel.kallsyms] [k] call_cpuidle | + 52.94% 0.02% swapper [kernel.kallsyms] [k] cpuidle_enter | + 31.81% 0.67% swapper [kernel.kallsyms] [k] cpuidle_enter_state | + 29.59% 0.12% swapper [kernel.kallsyms] [k] acpi_idle_enter | + 29.45% 0.05% swapper [kernel.kallsyms] [k] acpi_idle_do_entry | + 29.43%29.43% swapper [kernel.kallsyms] [k] acpi_processor_ffh_cstate_enter | + 20.51% 0.04% swapper [kernel.kallsyms] [k] ret_from_intr | + 20.47% 0.12% swapper [kernel.kallsyms] [k] do_IRQ | + 19.30% 0.07% swapper [kernel.kallsyms] [k] irq_exit | + 19.18% 0.07% apache2 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath | + 18.80% 0.17% swapper [kernel.kallsyms] [k] __do_softirq | + 16.45% 0.11% swapper [kernel.kallsyms] [k] net_rx_action | + 16.25% 0.43% swapper [kernel.kallsyms] [k] be_poll | + 14.74% 0.21% swapper [kernel.kallsyms] [k] be_process_rx | + 13.61% 0.07% swapper [kernel.kallsyms] [k] napi_gro_frags | + 12.58% 0.04% swapper [kernel.kallsyms] [k] netif_receive_skb_internal | + 12.48% 0.03% swapper [kernel.kallsyms] [k] __netif_receive_skb | + 12.42% 0.24% swapper [kernel.kallsyms] [k] __netif_receive_skb_core | + 12.41% 0.00% apache2 [unknown] [k] 0x7f27983b5028 | + 12.41% 0.00% apache2 [unknown] [k] 0x7f2798369028 | + 11.49% 0.16% swapper [kernel.kallsyms] [k] ip_rcv | + 11.29% 0.09% swapper [kernel.kallsyms] [k] ip_rcv_finish | + 10.77% 0.05% swapper [kernel.kallsyms] [k] ip_local_deliver | + 10.70% 0.06% swapper [kernel.kallsyms] [k] ip_local_deliver_finish | + 10.55% 0.22% swapper [kernel.kallsyms] [k] tcp_v4_rcv | + 10.10% 0.00% apache2 [unknown] [k] | + 10.01% 0.04% swapper [kernel.kallsyms] [k] tcp_v4_do_rcv Expanding in a few of those, you'll see: | - 55.24% 0.20% swapper [kernel.kallsyms] [k] cpu_startup_entry |- 55.04% cpu_startup_entry | - 52.98% call_cpuidle | + 52.93% cpuidle_enter | + 0.00% ret_from_intr |0.00% cpuidle_enter_state |0.00% irq_entries_start | + 1.14% cpuidle_select | + 0.47% schedule_preempt_disabled | 0.10% rcu_idle_enter
[Kernel-packages] [Bug 1504584]
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 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: Confirmed Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
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.launchpad.net/bugs/1504584 Title: As of kernel 4.3-rc1 system will not stay in S3 suspend Status in Linux: Confirmed Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1534647] Re: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)
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 Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1534647 Title: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Bug description: 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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/sound/pci/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1534647] Re: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)
> 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: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Bug description: 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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/sound/pci/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1534647] Re: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)
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 Title: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64) Status in linux package in Ubuntu: Confirmed Bug description: 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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/sound/pci/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1534647] Re: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)
** 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 commit message does mention collateral damage: "In effect, this precludes devices that can only DMA from - memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. + The commit message does mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". + Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. - If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: + If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes - Trident 4D-Wave DX/NX; SiS 7018. + Trident 4D-Wave DX/NX; SiS 7018. - References: linux/mm/Kconfig; linux/mm/Kconfig + References: linux/mm/Kconfig; linux/sound/pci/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. -- 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: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64) Status in linux package in Ubuntu: New Bug description: 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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/sound/pci/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1534647] [NEW] Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)
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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/mm/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. ** Affects: linux (Ubuntu) Importance: Undecided Status: 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/1534647 Title: Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64) Status in linux package in Ubuntu: New Bug description: 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 mention collateral damage: "In effect, this precludes devices that can only DMA from memory addresses below 16MB". Indeed we already have a complaint about a sound card that doesn't work as of kernel 4.4-rc8. If CONFIG_ZONE_DEVICE is enabled, then CONFIG_ZONE_DMA is forced to disabled, which in turn forces these devices, all are sound cards, and their derivative devices, to be disabled: Avance Logic ALS300/ALS300+ ALi M5451 PCI Audio Controller Aztech AZF3328 / PCI168 Emu10k1 (SB Live!, Audigy, E-mu APS) Emu10k1X (Dell OEM Version) ESS ES1938/1946/1969 (Solo-1) ESS ES1968/1978 (Maestro-1/2/2E) ICEnsemble ICE1712 (Envy24) ESS Allegro/Maestro3 S3 SonicVibes Trident 4D-Wave DX/NX; SiS 7018. References: linux/mm/Kconfig; linux/mm/Kconfig One test done (suggested by apw on IRC) was to remove the dependency of ZONE_DEVICE on !ZONE_DMA, but that causes: "#error ZONES_SHIFT -- too many zones configured adjust calculation", as apw predicted. In a mindless way, I tried to allow more zones in linux/include/linux/page-flags-layout.h, but that caused a bunch of "shifting by too many bits type errors. Anyway it seems that MAX_NR_ZONES is, at least partially, hard coded to 4 in some array definitions and such. Please do not ask me to do "apport-collect" for this bug report as it is not needed, nor relevant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
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: Confirmed Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
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. The system is idle is both cases: 0.03% busy. -- 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: Confirmed Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
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 Title: As of kernel 4.3-rc1 system will not stay in S3 suspend Status in Linux: Incomplete Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 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 stack, including userspace. [ 399.518686] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 399.518687] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 399.518687] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 399.518687] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 399.518699] [drm:i915_reset_and_wakeup] resetting chip [ 399.518724] i915 :00:02.0: GEM idle failed, resume might fail [ 399.518737] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 399.518739] dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -11 [ 399.518741] PM: Device :00:02.0 failed to suspend async: error -11 [ 399.518804] PM: Some devices failed to suspend, or early wake event detected an edited /sys/class/drm/card0/error will be attached in a moment. -- 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: Incomplete Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
(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 check failed. -- 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: Incomplete Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584]
(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 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: Incomplete Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584] Re: As of kernel 4.3-rc1 system will not stay in S3 suspend
** 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 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: Unknown Status in linux package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1497520] Re: Slow performance after resuming from/on battery (CPUs do not scale above 800MHz) with intel_pstate
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 normal minimum.
One way, would be to do:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
160
160
160
160
160
160
160
160
and you can see that on my computer ( Intel(R) Core(TM) i7-2600K CPU @
3.40GHz ), the minimum pstate is 16.
I'm not sure yet if our issues are related, but on my computer, I also
am seeing odd stuff on resume from suspend (I didn't used to), but my
CPU frequencies are not stuck low, but rather never go below pstate 24,
even though the driver is asking for lower. I also get the same lack of
restoring the proper governor on all the CPUs except CPU 0 (and note
that for an S3 suspend CPU 0 is the one that never goes off line).
Example (no load):
pstate being asked for:
# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16
pstate that I am getting:
# rdmsr --bitfield 15:8 -d -a 0x198
24
24
24
24
24
24
24
24
CPU freqs:
# grep MHz /proc/cpuinfo
cpu MHz : 2400.054
cpu MHz : 2399.921
cpu MHz : 2399.921
cpu MHz : 2399.921
cpu MHz : 2399.789
cpu MHz : 2399.789
cpu MHz : 2399.921
cpu MHz : 2399.921
--
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/1497520
Title:
Slow performance after resuming from/on battery (CPUs do not scale
above 800MHz) with intel_pstate
Status in linux package in Ubuntu:
Incomplete
Bug description:
I have noticed slow performance after resuming from STR on battery.
I can not trigger this always, but it seems to be related to
suspending and resuming while on battery.
The CPU scaling governors look like this then:
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
performance
performance
performance
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
intel_pstate
intel_pstate
intel_pstate
intel_pstate
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
320
320
320
320
When watching the current CPU frequencies, it can be seen that they
don't go above 80 ('watch grep \"cpu MHz\" /proc/cpuinfo').
I cannot see why they are limited to 80.
It looks like https://bugzilla.kernel.org/show_bug.cgi?id=61241, but
/sys/devices/system/cpu/intel_pstate/max_perf_pct is at 100.
Just writing the same setting for cpu0 again fixes it, and all CPUs
will be scaled above 800MHz again:
% echo powersave | sudo tee
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-28-generic 3.19.0-28.30
ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5
Uname: Linux 3.19.0-28-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.4
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Sep 19 10:39:02 2015
HibernationDevice: RESUME=UUID=d39463f5-889e-42ba-a729-f3f442f0c8dd
InstallationDate: Installed on 2012-05-28 (1208 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64
(20120425)
MachineType: LENOVO 42992PG
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-28-generic
root=/dev/mapper/vg0-rootlv ro quiet splash
RelatedPackageVersions:
linux-restricted-modules-3.19.0-28-generic N/A
linux-backports-modules-3.19.0-28-generic N/A
linux-firmware 1.143.3
SourcePackage: linux
UpgradeStatus: Upgraded to vivid on 2015-05-14 (127 days ago)
dmi.bios.date: 05/14/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET70WW (1.40 )
dmi.board.asset.tag: Not Available
dmi.board.name: 42992PG
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias:
dmi:bvnLENOVO:bvr8DET70WW(1.40):bd05/14/2015:svnLENOVO:pn42992PG:pvrThinkPadX220Tablet:rvnLENOVO:rn42992PG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 42992PG
dmi.product.version: ThinkPad X220 Tablet
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497520/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584] Re: As of kernel 4.3-rc1 system will not stay in S3 suspend
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 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 package in Ubuntu: Triaged Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1504584] [NEW] As of kernel 4.3-rc1 system will not stay in S3 suspend
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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter ** Affects: linux (Ubuntu) Importance: Undecided Status: 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/1504584 Title: As of kernel 4.3-rc1 system will not stay in S3 suspend Status in linux package in Ubuntu: New Bug description: 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 S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1477171] Re: Enable intel_pstate by default on Trusty EC2 AMIs
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. Regardless of what other tools say, what does turbostat report for CPU frequencies when using the acpi-cpufreq frequency scaling driver? -- 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/1477171 Title: Enable intel_pstate by default on Trusty EC2 AMIs Status in linux package in Ubuntu: In Progress Bug description: Please can the intel_pstate driver be enabled by default on the Ubuntu EC2 AMIs. On instances with support for C-states and P-States [1] there is a notable performance impact and lack of support for higher clock frequencies available due to the use of the acpi-cpufreq driver. For example on a c4.8xlarge the default frequency is limited to 2.9GHz when 3.2GHz is supported by the chip [2]. Some additional analysis is available here [3] and re-enabling it by default has been discussed [4] but this request is specifically for the EC2 AMIs. [1] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html [2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/c4-instances.html [3] http://www.deplication.net/2015/07/c-states-and-p-states-with-ubuntu-1404.html [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647 AMI: ami-47a23a30 (eu-west-1) $ lsb_release -d Description:Ubuntu 14.04.2 LTS $ uname -a Linux ip-172-31-8-218 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Default configuration (c4.8xl): $ sudo cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1.20 GHz - 2.90 GHz available frequency steps: 2.90 GHz, 2.90 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.40 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 1.20 GHz and 2.90 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 2.90 GHz:70.40%, 2.90 GHz:0.00%, 2.80 GHz:0.00%, 2.70 GHz:0.00%, 2.50 GHz:0.00%, 2.40 GHz:0.00%, 2.30 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.90 GHz:0.00%, 1.80 GHz:0.00%, 1.70 GHz:0.00%, 1.60 GHz:0.09%, 1.40 GHz:0.00%, 1.30 GHz:0.00%, 1.20 GHz:29.51% (5) boost state support: Supported: yes Active: yes With intel_pstate enabled (c4.8xl): $ sudo cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 0.97 ms. hardware limits: 1.20 GHz - 3.50 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 1.20 GHz and 3.50 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 3.20 GHz (asserted by call to hardware). boost state support: Supported: yes Active: yes --- AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Aug 12 17:19 seq crw-rw 1 root audio 116, 33 Aug 12 17:19 timer AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: [Errno 2] No such file or directory CurrentDmesg: [39221.196411] init: plymouth-upstart-bridge main process ended, respawning DistroRelease: Ubuntu 14.04 Ec2AMI: ami-47a23a30 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1b Ec2InstanceType: c4.8xlarge Ec2Kernel: unavailable Ec2Ramdisk: unavailable IwConfig: Error: [Errno 2] No such file or directory Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Xen HVM domU Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-61-generic root=UUID=877c5daf-9427-49e3-8656-437c3f30fc84 ro console=tty1 console=ttyS0 P
[Kernel-packages] [Bug 1497520] Re: Slow performance after resuming from/on battery (CPUs do not scale above 800MHz)
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 separate
the issues and they tend to cross contaminate these bug reports.
See also:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/comments/5
--
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/1497520
Title:
Slow performance after resuming from/on battery (CPUs do not scale
above 800MHz)
Status in linux package in Ubuntu:
Confirmed
Bug description:
I have noticed slow performance after resuming from STR on battery.
I can not trigger this always, but it seems to be related to
suspending and resuming while on battery.
The CPU scaling governors look like this then:
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
performance
performance
performance
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
intel_pstate
intel_pstate
intel_pstate
intel_pstate
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
320
320
320
320
When watching the current CPU frequencies, it can be seen that they
don't go above 80 ('watch grep \"cpu MHz\" /proc/cpuinfo').
I cannot see why they are limited to 80.
It looks like https://bugzilla.kernel.org/show_bug.cgi?id=61241, but
/sys/devices/system/cpu/intel_pstate/max_perf_pct is at 100.
Just writing the same setting for cpu0 again fixes it, and all CPUs
will be scaled above 800MHz again:
% echo powersave | sudo tee
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-28-generic 3.19.0-28.30
ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5
Uname: Linux 3.19.0-28-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.4
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Sep 19 10:39:02 2015
HibernationDevice: RESUME=UUID=d39463f5-889e-42ba-a729-f3f442f0c8dd
InstallationDate: Installed on 2012-05-28 (1208 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64
(20120425)
MachineType: LENOVO 42992PG
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-28-generic
root=/dev/mapper/vg0-rootlv ro quiet splash
RelatedPackageVersions:
linux-restricted-modules-3.19.0-28-generic N/A
linux-backports-modules-3.19.0-28-generic N/A
linux-firmware 1.143.3
SourcePackage: linux
UpgradeStatus: Upgraded to vivid on 2015-05-14 (127 days ago)
dmi.bios.date: 05/14/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET70WW (1.40 )
dmi.board.asset.tag: Not Available
dmi.board.name: 42992PG
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias:
dmi:bvnLENOVO:bvr8DET70WW(1.40):bd05/14/2015:svnLENOVO:pn42992PG:pvrThinkPadX220Tablet:rvnLENOVO:rn42992PG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 42992PG
dmi.product.version: ThinkPad X220 Tablet
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497520/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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:03:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux The results were the same. -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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 process on CPU 7 I get: doug@s15:~/temp$ grep MHz /proc/cpuinfo cpu MHz : 3699.757 cpu MHz : 3627.640 cpu MHz : 3684.351 cpu MHz : 3800.429 cpu MHz : 3524.710 cpu MHz : 3522.187 cpu MHz : 3540.250 cpu MHz : 3799.898 Then if I set an upper limit: echo "75" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct I get: doug@s15:~/temp$ grep MHz /proc/cpuinfo cpu MHz : 2799.953 cpu MHz : 2799.953 cpu MHz : 2799.953 cpu MHz : 2799.953 cpu MHz : 2853.078 cpu MHz : 2799.953 cpu MHz : 2799.953 cpu MHz : 2799.953 as expected. As a sanity check, my CPU prints a time message occasionally, so we would expect it to have a bigger gap between prints now: doug@s15:~/c$ taskset -c 7 ./test1 Elapsed:174.06 s. Delta:174.06 s. Ave (10): 17.41 s. user cpu: 173.88 s. sys cpu: 0.06 s. Elapsed:348.04 s. Delta:173.98 s. Ave (10): 34.80 s. user cpu: 347.74 s. sys cpu: 0.06 s. Elapsed:557.31 s. Delta:209.27 s. Ave (10): 55.73 s. user cpu: 556.88 s. sys cpu: 0.06 s. Elapsed:792.06 s. Delta:234.75 s. Ave (10): 79.21 s. user cpu: 791.47 s. sys cpu: 0.07 s. 174 / 235 = 74% -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.la
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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 tee /sys/devices/system/cpu/intel_pstate/max_perf_pct (If I was in performance mode and not powersave mode, then I would set the min_perf_pct to 75 also, but I myself I wouldn't be in performance mode for this situation.) -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend
When a user is using the intel_pstate driver in performance mode, then yes, prior to Kernel 4.2RC1 the CPU frequency will be typically be stuck after resume from suspend. This is not a pm-ultils issue (which is how I stumbled across this bug report). To test that the issue is fixed on kernel 4.2, 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 Date: Mon Jun 1 21:12:34 2015 -0700 intel_pstate: Force setting target pstate when required -- 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/1484587 Title: CPU frequency management fails to re-engage on resume from suspend Status in linux package in Ubuntu: Confirmed Status in pm-utils package in Ubuntu: Confirmed Bug description: Behavior: CPU frequency management fails to re-engage on resume from suspend. On resume, the CPUs are stuck around a single frequency (usually a low idle frequency). I use indicator-cpufreq for manual governor control. On resume, indicator-cpufreq indicates the low frequency state in its live cpu performance display in the icon. However, in its governor menu, it still shows as in use whichever governor was selected before suspend, even though that governor is not actually or properly controlling the CPU state. Upon manually switching to the unused governor in indicator-cpufreq, this behavior resolves, and the newly-chosen governor begins performing its duties. I can then immediately switch back to the desired (pre-suspend) governor with no issues. PM logs appear to show a successful resume of cpu frequency management, even though the modules did not actually gain effective control of the processor frequencies. Expected behavior: On resume, the CPU frequencies should continue being managed as they were before suspend without the need for manual user input. Also, in the event that they do not, an error/warning should appear -- if not to the user, then in the pm suspend/resume logs. Other information that may or may not be relevant: On this system, the "powersave" governor is always automatically chosen at startup, although not until a minute or so after session login. The choice of an alternate governor "performance" from indicator-cpufreq is not persistent across reboots. Further, if I manually toggle the governors at the beginning of my first session after boot, and I settle on "performance", some automated script will force it back to "powersave" at the usual time about a minute after login. To use the "performance" governor, I must select it after waiting an interval following login, and I must always switch to powersave and back to performance after each resume from suspend. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: linux-image-3.19.0-25-generic 3.19.0-25.26 ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2 Uname: Linux 3.19.0-25-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adam 3887 F pulseaudio /dev/snd/controlC1: adam 3887 F pulseaudio CurrentDesktop: Unity Date: Thu Aug 13 11:41:27 2015 InstallationDate: Installed on 2014-08-10 (368 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) MachineType: Hewlett-Packard HP ENVY 15 x360 PC ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.19.0-25-generic N/A linux-backports-modules-3.19.0-25-generic N/A linux-firmware 1.143.3 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/19/2015 dmi.bios.vendor: Insyde dmi.bios.version: F.26 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 22D6 dmi.board.vendor: Hewlett-Packard dmi.board.version: 89.23 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.name: HP ENVY 15 x360 PC dmi.product.version: 0974100022405F0420180 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions --
[Kernel-packages] [Bug 1188647] Re: Please change intel_pstate default to disable
@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 that is still on hold. See: http://permalink.gmane.org/gmane.linux.power-management.general/58958 The basic control algorithms of the current version of the intel_pstate driver have been stable for quite sometime now (even though I still have concerns). I do not know what changes had not previously been backported to kernel 3.13, nor what issues people were having, so am unable to comment further. -- 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 change intel_pstate default to disable Status in linux package in Ubuntu: Fix Released Bug description: 3.9 introduced a new default governor on SandyBridge CPUs called INTEL_PSTATE which, when built in and enabled (the default), removes all other governors (like our usual default, ondemand). 3.10 extended this to Ivybridge generation CPUs. In theory, this isn't an awful thing, as the new Intel pstate governor should be higher performance and give better power savings. In theory. In practice, it drives my CPUs to max frequency nearly constantly, spins my fans like mad and, somehow, does all of this while also eating enough CPU time in kernel threads to make my machine choppy, unresponsive, and unable to do simple things like play videos when I get off work. Therefore, I propose that we, for now, toggle intel_pstate to disable by default (I am using intel_pstate=disable on my command line right now, with great success), so it's still built in, and people can play with it, but it's off by default. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.9.0-4-generic 3.9.0-4.9 ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4 Uname: Linux 3.9.0-4-generic x86_64 ApportVersion: 2.10.2-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adconrad 2574 F pulseaudio CurrentDmesg: [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1 [ 36.086916] br0: port 1(eth0) entered forwarding state Date: Fri Jun 7 08:48:56 2013 HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c InstallationDate: Installed on 2012-12-09 (179 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209) MachineType: LENOVO 4173LPB MarkForUpload: True ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.9.0-4-generic N/A linux-backports-modules-3.9.0-4-generic N/A linux-firmware 1.109 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 8CET55WW (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 4173LPB dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr8CET55WW(1.35):bd09/13/2012:svnLENOVO:pn4173LPB:pvrThinkPadT420s:rvnLENOVO:rn4173LPB:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 4173LPB dmi.product.version: ThinkPad T420s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1462822] Re: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be
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 Ubuntu. https://bugs.launchpad.net/bugs/1462822 Title: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be Status in linux package in Ubuntu: Fix Released Bug description: 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/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. By the way, I compiled 4.1RC6 changing from "#CONFIG_DEVMEM is not set" to "CONFIG_DEVMEM=y" myself and now dmidecode works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1462822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1462822] Re: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be
** 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 dmidecode does not work. I think that, in general, we want dmidecode to work. I found this: https://lists.ubuntu.com/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. - By the way, I compiled 4.1RC6 with CONFIG_DEVMEM=y and now dmidecode - works fine. + By the way, I compiled 4.1RC6 changing from "#CONFIG_DEVMEM is not set" + to "CONFIG_DEVMEM=y" myself and now dmidecode works fine. -- 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/1462822 Title: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be Status in linux package in Ubuntu: Confirmed Bug description: 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/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. By the way, I compiled 4.1RC6 changing from "#CONFIG_DEVMEM is not set" to "CONFIG_DEVMEM=y" myself and now dmidecode works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1462822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1462822] Re: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be
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/1462822 Title: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be Status in linux package in Ubuntu: New Bug description: 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/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. By the way, I compiled 4.1RC6 with CONFIG_DEVMEM=y and now dmidecode works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1462822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1462822] [NEW] Kernel configuration parameter CONFIG_DEVMEM is not set, it should be
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/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. By the way, I compiled 4.1RC6 with CONFIG_DEVMEM=y and now dmidecode works fine. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Andy Whitcroft (apw) Status: Incomplete ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Andy Whitcroft (apw) -- 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/1462822 Title: Kernel configuration parameter CONFIG_DEVMEM is not set, it should be Status in linux package in Ubuntu: Incomplete Bug description: 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/archives/kernel-team/2015-May/057250.html, and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. (And yes, I am talking mainline kernels here, which I know are not supported, but I am just trying to help.) Is there a reason to have it not set? On IRC apw asked me to enter this bug report and to assign it to him. By the way, I compiled 4.1RC6 with CONFIG_DEVMEM=y and now dmidecode works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1462822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1452460] Re: Turbo mode on i7 is not enabled upon resume
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 notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1452460 Title: Turbo mode on i7 is not enabled upon resume Status in linux package in Ubuntu: Incomplete Bug description: Turbo mode is not enabled upon resume from suspend. To enable I must issue: ``echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo`` I would expect that Turbo was re-enabled by default from resume. I created a script in /usr/lib/pm-utils/sleep.d/ to issue the above commands, but clearly that mechanism is depreciated. I am reporting this bug against systemd as I assume that it is managing the running of startup and resume scripts. A quick hack solution would be appreciated in the short term. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu4 Uname: Linux 4.0.0-04rc7-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Thu May 7 09:11:12 2015 InstallationDate: Installed on 2015-04-14 (22 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Beta amd64 (20150326) MachineType: Acer Aspire S7-392 ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.0.0-04rc7-generic root=UUID=57b63ba3-bc33-40b5-931f-8654d6c5cab4 ro rootflags=subvol=@ noprompt persistent quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/20/2014 dmi.bios.vendor: Insyde Corp. dmi.bios.version: V2.12 dmi.board.asset.tag: No Asset Tag dmi.board.name: Storm2 dmi.board.vendor: Acer dmi.board.version: V2.12 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V2.12 dmi.modalias: dmi:bvnInsydeCorp.:bvrV2.12:bd05/20/2014:svnAcer:pnAspireS7-392:pvrV2.12:rvnAcer:rnStorm2:rvrV2.12:cvnAcer:ct10:cvrV2.12: dmi.product.name: Aspire S7-392 dmi.product.version: V2.12 dmi.sys.vendor: Acer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452460/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1421793] Re: intel_pstate is always reported to be set to 'performance'
*** 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 sysvinit: default cpufreq governor to powersave for intel-pstate driver -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-lts-utopic in Ubuntu. https://bugs.launchpad.net/bugs/1421793 Title: intel_pstate is always reported to be set to 'performance' Status in sysvinit: New Status in linux-lts-utopic package in Ubuntu: New Bug description: as in - cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver intel_pstate cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance performance performance performance performance performance performance cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 240 2400187 2400093 2394468 2397281 240 2400093 2401125 In 15.04 it is reported at performance at login, then switches to powersave after a min. or so ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: linux-image-3.16.0-30-generic 3.16.0-30.40~14.04.1 [modified: boot/vmlinuz-3.16.0-30-generic] ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 CurrentDesktop: Unity Date: Fri Feb 13 14:13:57 2015 InstallationDate: Installed on 2015-02-08 (5 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150203.2) SourcePackage: linux-lts-utopic UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/sysvinit/+bug/1421793/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1421793] Re: intel_pstate is always reported to be set to 'performance'
*** 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 member of Kernel Packages, which is subscribed to linux-lts-utopic in Ubuntu. https://bugs.launchpad.net/bugs/1421793 Title: intel_pstate is always reported to be set to 'performance' Status in sysvinit: New Status in linux-lts-utopic package in Ubuntu: New Bug description: as in - cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver intel_pstate cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance performance performance performance performance performance performance cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 240 2400187 2400093 2394468 2397281 240 2400093 2401125 In 15.04 it is reported at performance at login, then switches to powersave after a min. or so ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: linux-image-3.16.0-30-generic 3.16.0-30.40~14.04.1 [modified: boot/vmlinuz-3.16.0-30-generic] ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 CurrentDesktop: Unity Date: Fri Feb 13 14:13:57 2015 InstallationDate: Installed on 2015-02-08 (5 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150203.2) SourcePackage: linux-lts-utopic UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/sysvinit/+bug/1421793/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1413149] Re: rtsx_usb_ms: system load immediately climbs, and stays above 1.00
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 to check the status of upstream patch requests? (by the way, I asked these same questions on IRC, but it was suggest by apw that this bug report submission was the preferred way to proceed.) Reference: http://irclogs.ubuntu.com/2015/01/20/%23ubuntu- kernel.html#t16:28 -- 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/1413149 Title: rtsx_usb_ms: system load immediately climbs, and stays above 1.00 Status in linux package in Ubuntu: In Progress Status in linux source package in Utopic: In Progress Status in linux package in Debian: Fix Released Bug description: SRU Justification: [Impact] Users of devices that use the rtsx_usb_ms module will experience false load values due to an issue in this driver. [Test Case] Boot computer and monitor load levels. [Fix] This patch by Ben Hutchings: https://lkml.org/lkml/2014/11/5/905 Has been applied to Debian/3.16, and has been posted upstream. -- I'm running 64 bit ubuntu 14.10 on an Asus N550JK-DB74T laptop. When I startup Ubuntu the system load climbs to 1.00 within a minute, and it never goes below 1.00 again, despite my processor being idle. This behavior occurs in all the newer kernels I installed from http://kernel.ubuntu.com/~kernel-ppa/mainline/ but when I installed the kernel from ubuntu 14.04, as well when I ran the ubuntu 14.04 from a usb the load average behaved normally, so the bug must have started in either kernel 3.15 or 3.16. When I posted this to ubuntu forums, a very helpful person able to point me to this bug report: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=765717 and to this submitted patch https://lkml.org/lkml/2014/11/5/905 . When I applied that patch to kernel 3.16 my issue was solved. However it doesn't seem that this patch has been has been merged into the kernel, even though it was submitted well in time for the 3.19 merge window. I was advised to file this bug report in the meantime. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: linux-image-3.16.0-29-generic 3.16.0-29.39 ProcVersionSignature: Ubuntu 3.16.0-29.39-generic 3.16.7-ckt2 Uname: Linux 3.16.0-29-generic x86_64 ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: dave 2338 F pulseaudio /dev/snd/controlC0: dave 2338 F pulseaudio CurrentDesktop: Unity Date: Wed Jan 21 05:14:38 2015 InstallationDate: Installed on 2014-12-30 (22 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) MachineType: ASUSTeK COMPUTER INC. N550JK ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-29-generic.efi.signed root=UUID=b5b33d3f-e01a-4d2b-824f-8883fbfed316 ro quiet splash acpi_osi= vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.16.0-29-generic N/A linux-backports-modules-3.16.0-29-generic N/A linux-firmware 1.138.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/26/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: N550JK.208 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: N550JK dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN550JK.208:bd09/26/2014:svnASUSTeKCOMPUTERINC.:pnN550JK:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnN550JK:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: N550JK dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413149/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1397061] Re: CONFIG_SCSI_MQ_DEFAULT default changed preventing use of IO schedulers
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 of 73 seconds, and a simple "ls -l" command that never did finish in over 1/2 an hour. With blk-mq disabled, while the system still gets sluggish under extreme disk IO load, no single task experiences such horrendous neglect. I even several occurrences of this: Nov 28 08:12:28 s15 kernel: [42812.544892] INFO: task master:2225 blocked for more than 120 seconds. Nov 28 08:12:28 s15 kernel: [42812.544934] Not tainted 3.18.0-rc6-250 #173 Nov 28 08:12:28 s15 kernel: [42812.544961] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. With blk-mq disabled, and under the same extreme disk IO load, the worst disk seek time is about 1 second. -- 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/1397061 Title: CONFIG_SCSI_MQ_DEFAULT default changed preventing use of IO schedulers Status in linux package in Ubuntu: Fix Committed Bug description: In kernel 3.18RC1 this kernel config parameter is: # CONFIG_SCSI_MQ_DEFAULT is not set In kernel 3.18RC2 and beyond, the kernel config parameter is: CONFIG_SCSI_MQ_DEFAULT=y This results in loss of the ability to set the IO scheduler via /sys/block/sda/queue/scheduler. Now we get: doug@s15:~$ cat /sys/block/sda/queue/scheduler none Where we are used to getting: doug@s15:~/temp2$ cat /sys/block/sda/queue/scheduler noop [deadline] cfq From the add a CONFIG_SCSI_MQ_DEFAULT option commit message: > Add a Kconfig option to enable the blk-mq path for SCSI by default > to ease testing and deployment in setups that know they benefit > from blk-mq. How do we know that all systems benifit from blk-mq? It seems complicated to have to re-compile the kernel to get the other IO scheduler options back. Why isn't this option done similar to the others? I.E. doug@s15:~/temp2$ cat /sys/block/sda/queue/scheduler noop [deadline] cfq blk-mq (and I realize that is actually an upstream question.) By the way, my system does seem to benefit from blk-mq, I just didn't understand why I couldn't observe and change the IO scheduler anymore, and so isolated the change. Experimental data: Random seeks in a large file: blk-mq: 104 seeks per second average deadline: 74 seeks per second average cfq: 74 seeks per second average noop: 74 seeks per second average Kernel compile: deadline: 23 minutes 37.4 seconds blk-mq: 23 minutes 35.4 seconds Note 1: Please do not ask for all of my apport stuff, it is not needed for this bug report. Note 2: on IRC "apw" asked me to enter this bug report To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1397061/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
