[Kernel-packages] [Bug 2064508] Re: re-enable Ubuntu FAN in the Noble kernel
Test result with the patch set applied (ubuntu_fan_smoke_test): 11:48:05 INFO | Writing results to /home/ubuntu/autotest/client/results/default 11:48:05 INFO | START timestamp=1714564085localtime=May 01 11:48:05 11:48:05 INFO | START ubuntu_fan_smoke_test.setup ubuntu_fan_smoke_test.setup timeout=1200timestamp=1714564085 localtime=May 01 11:48:05 11:48:07 INFO | GOODubuntu_fan_smoke_test.setup ubuntu_fan_smoke_test.setup timestamp=1714564087localtime=May 01 11:48:07 completed successfully 11:48:07 INFO | END GOODubuntu_fan_smoke_test.setup ubuntu_fan_smoke_test.setup timestamp=1714564087localtime=May 01 11:48:07 11:48:07 INFO | START ubuntu_fan_smoke_test.fan-smoke-test ubuntu_fan_smoke_test.fan-smoke-testtimeout=1800timestamp=1714564087 localtime=May 01 11:48:07 11:51:46 INFO | Testing Fan Networking (pre-0.13.0 API) 11:51:46 INFO | docker pull --platform linux/amd64 ubuntu: PASSED 11:51:46 INFO | enable disable fan test: PASSED 11:51:46 INFO | fanctl show test: PASSED 11:51:46 INFO | fanctl check bridge config test: PASSED 11:51:46 INFO | fanatic docker test(--dns=192.168.122.1): PASSED 11:51:47 INFO | GOODubuntu_fan_smoke_test.fan-smoke-test ubuntu_fan_smoke_test.fan-smoke-testtimestamp=1714564307localtime=May 01 11:51:47 completed successfully 11:51:47 INFO | END GOODubuntu_fan_smoke_test.fan-smoke-test ubuntu_fan_smoke_test.fan-smoke-testtimestamp=1714564307localtime=May 01 11:51:47 11:51:47 INFO | END GOODtimestamp=1714564307 localtime=May 01 11:51:47 11:51:47 INFO | Report successfully generated at /home/ubuntu/autotest/client/results/default/job_report.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2064508 Title: re-enable Ubuntu FAN in the Noble kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] In LP: #2063298, we have opted to deprecate Ubuntu FAN support because of the maintenance overhead and the possibility of regressions / conflicts with the new networking eBPF APIs in kernels >= 6.8. However, we cannot disable this feature in HWE/backport kernels, so it seems safer to adjust the Ubuntu FAN kernel patch set to ensure proper co-existence with the updated vxlan policy requirements in newer 6.8 kernels. The re-introduction of Ubuntu FAN should be considered as a temporary measure, aimed at facilitating a smooth transition during its deprecation without disrupting existing users (specifically Juju), and enabling the backporting of 6.8 kernels to older releases. The main plan is still to deprecate Ubuntu FAN in newer releases. [Test case] Rely on the specific Ubuntu FAN regression test to validate the proper kernel support of this feature: https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client- tests/tree/ubuntu_fan_smoke_test?h=autotest3 [Fix] Re-apply the Ubuntu FAN patch set to the latest Noble kernel 6.8 and integrate the IFLA_VXLAN_FAN_MAP attribute type in vxlan_policy to satisfy the strict length validation check. [Regression potential] We may experience regressions with eBPF vxlan capabilities and potentially specific use cases of the Ubuntu FAN technology (Juju installations). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064508/+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 2064508] Re: re-enable Ubuntu FAN in the Noble kernel
Patch set to re-enable Ubuntu FAN in the 6.8 Noble kernel: https://lists.ubuntu.com/archives/kernel-team/2024-May/150684.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2064508 Title: re-enable Ubuntu FAN in the Noble kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] In LP: #2063298, we have opted to deprecate Ubuntu FAN support because of the maintenance overhead and the possibility of regressions / conflicts with the new networking eBPF APIs in kernels >= 6.8. However, we cannot disable this feature in HWE/backport kernels, so it seems safer to adjust the Ubuntu FAN kernel patch set to ensure proper co-existence with the updated vxlan policy requirements in newer 6.8 kernels. The re-introduction of Ubuntu FAN should be considered as a temporary measure, aimed at facilitating a smooth transition during its deprecation without disrupting existing users (specifically Juju), and enabling the backporting of 6.8 kernels to older releases. The main plan is still to deprecate Ubuntu FAN in newer releases. [Test case] Rely on the specific Ubuntu FAN regression test to validate the proper kernel support of this feature: https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client- tests/tree/ubuntu_fan_smoke_test?h=autotest3 [Fix] Re-apply the Ubuntu FAN patch set to the latest Noble kernel 6.8 and integrate the IFLA_VXLAN_FAN_MAP attribute type in vxlan_policy to satisfy the strict length validation check. [Regression potential] We may experience regressions with eBPF vxlan capabilities and potentially specific use cases of the Ubuntu FAN technology (Juju installations). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064508/+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 2064508] [NEW] re-enable Ubuntu FAN in the Noble kernel
Public bug reported: [Impact] In LP: #2063298, we have opted to deprecate Ubuntu FAN support because of the maintenance overhead and the possibility of regressions / conflicts with the new networking eBPF APIs in kernels >= 6.8. However, we cannot disable this feature in HWE/backport kernels, so it seems safer to adjust the Ubuntu FAN kernel patch set to ensure proper co-existence with the updated vxlan policy requirements in newer 6.8 kernels. The re-introduction of Ubuntu FAN should be considered as a temporary measure, aimed at facilitating a smooth transition during its deprecation without disrupting existing users (specifically Juju), and enabling the backporting of 6.8 kernels to older releases. The main plan is still to deprecate Ubuntu FAN in newer releases. [Test case] Rely on the specific Ubuntu FAN regression test to validate the proper kernel support of this feature: https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client- tests/tree/ubuntu_fan_smoke_test?h=autotest3 [Fix] Re-apply the Ubuntu FAN patch set to the latest Noble kernel 6.8 and integrate the IFLA_VXLAN_FAN_MAP attribute type in vxlan_policy to satisfy the strict length validation check. [Regression potential] We may experience regressions with eBPF vxlan capabilities and potentially specific use cases of the Ubuntu FAN technology (Juju installations). ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) 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/2064508 Title: re-enable Ubuntu FAN in the Noble kernel Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] In LP: #2063298, we have opted to deprecate Ubuntu FAN support because of the maintenance overhead and the possibility of regressions / conflicts with the new networking eBPF APIs in kernels >= 6.8. However, we cannot disable this feature in HWE/backport kernels, so it seems safer to adjust the Ubuntu FAN kernel patch set to ensure proper co-existence with the updated vxlan policy requirements in newer 6.8 kernels. The re-introduction of Ubuntu FAN should be considered as a temporary measure, aimed at facilitating a smooth transition during its deprecation without disrupting existing users (specifically Juju), and enabling the backporting of 6.8 kernels to older releases. The main plan is still to deprecate Ubuntu FAN in newer releases. [Test case] Rely on the specific Ubuntu FAN regression test to validate the proper kernel support of this feature: https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client- tests/tree/ubuntu_fan_smoke_test?h=autotest3 [Fix] Re-apply the Ubuntu FAN patch set to the latest Noble kernel 6.8 and integrate the IFLA_VXLAN_FAN_MAP attribute type in vxlan_policy to satisfy the strict length validation check. [Regression potential] We may experience regressions with eBPF vxlan capabilities and potentially specific use cases of the Ubuntu FAN technology (Juju installations). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064508/+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 2051672] Re: Backport iproute2 6.8.0 to noble
Thanks @dannf for updating the bug! The SRU description looks good to me and everything seems reasonable, same with the plan. I'll keep monitoring this tracker and we'll proceed once oracular will be open. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/2051672 Title: Backport iproute2 6.8.0 to noble Status in iproute2 package in Ubuntu: Incomplete Bug description: [Impact] Several networking features introduced in the upstream 6.2->6.8 kernels are not accessible to noble users because noble lacks the corresponding iproute2 update. This includes support for new hardware features such as per-VF offload settings (see bug 2060969), but many others that you can see in the attached changelogs. Normally iproute2 is updated during the devel cycle to align with the kernel version, but it was missed this cycle and discovered too late for an FFe. We request an exception from the SRU team to do this as an SRU. This includes dropping the Ubuntu Fan patches, which adds features to iproute2 that no longer work since noble's kernels no longer support Ubuntu Fan. [Test Case] We'll run the 6.8 kernel self tests, which make use of a number of iproute2 features (see comment #17). NVIDIA's networking organization (Mellanox) has offered to put this through their QA process (details TBD). The upstream test suite will also run in the autopkgtests, though that suite is fairly stale. [What Could Go Wrong] Users who may be running noble userspace with a non-noble kernel that supports Ubuntu Fan would lose support for configuring it. If the SRU team considers this to be a regression we should avoid, then we can add the Ubuntu Fan patches back. iproute2 6.8 upstream retains backwards compatibility with earlier releases (see comment #17). There are no commits with a Fixes: annotation since the v6.8.0 tag was applied upstream. iproute2 is obviously a key package, and any upstream version bump carries risk. This includes the possibility of breaking networking for users of an Ubuntu LTS release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+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 2045503] Re: provide a sched-ext enabled kernel for the 24.10 release
** Summary changed: - apply sched-ext patch set to linux-unstable + provide a sched-ext enabled kernel for the 24.10 release ** Also affects: linux (Ubuntu Oracular) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu Noble) -- 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/2045503 Title: provide a sched-ext enabled kernel for the 24.10 release Status in linux package in Ubuntu: New Status in linux source package in Oracular: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. Targeting linux-unstable only for now is probably a good compromise to allow users to start some experiments, collect feedbacks, help the upstream community to find and fix bugs and at the same time avoid to introduce too much maintenance burden on us. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests and custom scheduler implementations are available in tools/sched_ext or in https://github.com/sched-ext/scx. [Fix] Apply this patch set as SAUCE to linux-unstable: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ On top of the patch set we want to apply also the following patches (still as SAUCE): - UBUNTU: SAUCE: sched_ext: use proper atomic operator for scx.ops_state (extra fix to properly build sched-ext on armhf) - UBUNTU: SAUCE: sched-ext: taint kernel when a custom scheduler is loaded (set TAINT_OOT_MODULE in /proc/sys/kernel/tainted to easily determine when a custom scheduler has been used, that can be useful for bug reports: we can easily detect when a custom scheduler has been used and treat the bug report accordingly) - UBUNTU: [Config] enable sched_ext in annotations (enable sched-ext in the config across all the supported architectures) Soon there will be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux-unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045503/+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 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
Hello, any progress on this? Now that ubuntu-fan is officially deprecated in Noble can we simply sync iproute2 with Debian? Is there any pending activity / requirement that are preventing this? Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/2051672 Title: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) Status in iproute2 package in Ubuntu: Incomplete Bug description: iproute2 upstream produces releases coinciding with upstream kernel releases to support the latest kernel features. Noble's iproute2 is still back at v6.1 even though it will use the v6.8 kernel. This means we provide no userspace interface for newer features - some of which are noted by a networking hardware partner in bug 2060969. Ubuntu's iproute2 has diverged from Debian's to add support for Ubuntu FAN. Noble has dropped kernel support for Ubuntu FAN, so those are no longer needed, and we could now just do a merge. We could also port the FAN patches forward if we can identify a need (see the original description of this bug to a link to such a port), but I have not done any testing with that. I have built Debian's iproute2 in a noble ppa at ppa:dannf/test and smoke tested it on an amd64 virtual machine: ubuntu@cortez-vm-0:~$ sudo dpkg -i iproute2_6.8.0-1~24.04.1_amd64.deb (Reading database ... 83134 files and directories currently installed.) Preparing to unpack iproute2_6.8.0-1~24.04.1_amd64.deb ... Unpacking iproute2 (6.8.0-1~24.04.1) over (6.1.0-1ubuntu6) ... dpkg: warning: unable to delete old directory '/etc/iproute2/rt_tables.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/iproute2/rt_protos.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/iproute2': Directory not empty Setting up iproute2 (6.8.0-1~24.04.1) ... Removing obsolete conffile /etc/iproute2/group ... Removing obsolete conffile /etc/iproute2/rt_realms ... Removing obsolete conffile /etc/iproute2/rt_scopes ... Removing obsolete conffile /etc/iproute2/rt_tables ... Removing obsolete conffile /etc/iproute2/rt_tables.d/README ... Removing obsolete conffile /etc/iproute2/rt_protos.d/README ... Removing obsolete conffile /etc/iproute2/rt_protos ... Removing obsolete conffile /etc/iproute2/rt_dsfield ... Removing obsolete conffile /etc/iproute2/nl_protos ... Removing obsolete conffile /etc/iproute2/ematch_map ... Removing obsolete conffile /etc/iproute2/bpf_pinning ... Processing triggers for man-db (2.12.0-4build1) ... The system rebooted fine. The ip command seems to behave normally. Since the upstream test suite only appears to run at autopkgtest time, I triggered a run in my PPA, and it passed: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-test/noble/amd64/i/iproute2/20240412_210819_97417@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+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 2058752] Re: ath11k high jitter and packet loss when operating in 802.11ax mode
unfortunately the problem is not actually gone in noble. I have upgraded to the beta and are having significant but intermittent problems. On 6.8.0-31-generic I get periods of normal traffic mixed with 100% packet loss for some seconds. This looks as follows: 64 bytes from 192.168.16.77: icmp_seq=2622 ttl=64 time=2.47 ms 64 bytes from 192.168.16.77: icmp_seq=2623 ttl=64 time=2.80 ms 64 bytes from 192.168.16.77: icmp_seq=2624 ttl=64 time=2.77 ms >From 192.168.16.231 icmp_seq=2637 Destination Host Unreachable >From 192.168.16.231 icmp_seq=2638 Destination Host Unreachable >From 192.168.16.231 icmp_seq=2639 Destination Host Unreachable >From 192.168.16.231 icmp_seq=2640 Destination Host Unreachable >From 192.168.16.231 icmp_seq=2644 Destination Host Unreachable >From 192.168.16.231 icmp_seq=2645 Destination Host Unreachable 64 bytes from 192.168.16.77: icmp_seq=2646 ttl=64 time=162 ms 64 bytes from 192.168.16.77: icmp_seq=2647 ttl=64 time=1.95 ms 64 bytes from 192.168.16.77: icmp_seq=2648 ttl=64 time=44.3 ms 64 bytes from 192.168.16.77: icmp_seq=2649 ttl=64 time=143 ms 64 bytes from 192.168.16.77: icmp_seq=2650 ttl=64 time=2.37 ms 64 bytes from 192.168.16.77: icmp_seq=2651 ttl=64 time=151 ms 64 bytes from 192.168.16.77: icmp_seq=2652 ttl=64 time=2.69 ms 64 bytes from 192.168.16.77: icmp_seq=2653 ttl=64 time=6.66 ms 64 bytes from 192.168.16.77: icmp_seq=2654 ttl=64 time=47.2 ms 64 bytes from 192.168.16.77: icmp_seq=2655 ttl=64 time=40.1 ms 64 bytes from 192.168.16.77: icmp_seq=2656 ttl=64 time=44.9 ms 64 bytes from 192.168.16.77: icmp_seq=2657 ttl=64 time=1583 ms 64 bytes from 192.168.16.77: icmp_seq=2658 ttl=64 time=560 ms 64 bytes from 192.168.16.77: icmp_seq=2659 ttl=64 time=1506 ms 64 bytes from 192.168.16.77: icmp_seq=2660 ttl=64 time=457 ms 64 bytes from 192.168.16.77: icmp_seq=2661 ttl=64 time=809 ms 64 bytes from 192.168.16.77: icmp_seq=2662 ttl=64 time=3014 ms 64 bytes from 192.168.16.77: icmp_seq=2663 ttl=64 time=2005 ms 64 bytes from 192.168.16.77: icmp_seq=2664 ttl=64 time=982 ms 64 bytes from 192.168.16.77: icmp_seq=2665 ttl=64 time=2.47 ms 64 bytes from 192.168.16.77: icmp_seq=2666 ttl=64 time=2471 ms 64 bytes from 192.168.16.77: icmp_seq=2667 ttl=64 time=1464 ms 64 bytes from 192.168.16.77: icmp_seq=2668 ttl=64 time=440 ms 64 bytes from 192.168.16.77: icmp_seq=2669 ttl=64 time=54.2 ms 64 bytes from 192.168.16.77: icmp_seq=2670 ttl=64 time=2.35 ms If I find some time I'll try rerunning the same test from windows. -- 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/2058752 Title: ath11k high jitter and packet loss when operating in 802.11ax mode Status in linux package in Ubuntu: New Bug description: On 6.5.0-26-generic, my QCNFA765 cannot really operate in 802.11ax mode. I have a Thinkpad P16s Gen 2 with a (soldered, sadly) QCNFA765 card, which uses the ath11k driver. I also have a Ruckus R650 AP, which supports wifi6. Connecting the two and pinging the AP yields the following: ``` 64 bytes from 192.168.16.77: icmp_seq=45 ttl=64 time=22.4 ms 64 bytes from 192.168.16.77: icmp_seq=46 ttl=64 time=29.6 ms 64 bytes from 192.168.16.77: icmp_seq=47 ttl=64 time=26.8 ms 64 bytes from 192.168.16.77: icmp_seq=48 ttl=64 time=2174 ms 64 bytes from 192.168.16.77: icmp_seq=49 ttl=64 time=1158 ms 64 bytes from 192.168.16.77: icmp_seq=50 ttl=64 time=130 ms 64 bytes from 192.168.16.77: icmp_seq=51 ttl=64 time=503 ms 64 bytes from 192.168.16.77: icmp_seq=54 ttl=64 time=1832 ms 64 bytes from 192.168.16.77: icmp_seq=55 ttl=64 time=808 ms 64 bytes from 192.168.16.77: icmp_seq=56 ttl=64 time=9.32 ms 64 bytes from 192.168.16.77: icmp_seq=57 ttl=64 time=2.11 ms 64 bytes from 192.168.16.77: icmp_seq=58 ttl=64 time=25.6 ms 64 bytes from 192.168.16.77: icmp_seq=59 ttl=64 time=30.9 ms 64 bytes from 192.168.16.77: icmp_seq=60 ttl=64 time=95.6 ms ^C --- 192.168.16.77 ping statistics --- 60 packets transmitted, 55 received, 8.3% packet loss, time 59273ms rtt min/avg/max/mdev = 2.105/275.084/2344.792/560.334 ms, pipe 3 ``` Those periodic bursts of >1s latency make some webpages fail to load and videochats unusable. No interference is present in my channel of choice. Nothing interesting is printed in dmesg while the above occurs. The above does not happen if: * I disable wifi 6 in the AP * I ping a wifi 5 AP (I also have an older R710, which is a 802.11ac AP) * I ping the R650 in wifi 6 mode from a AX210 on kernel 6.2 * I ping the R650 from a completely different OS and device (e.g. Android) I'll test with a 24.04 daily image next. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: linux-image-6.5.0-26-generic 6.5.0-26.26 ProcVersionSignature: Ubuntu 6.5.0-26.26-generic 6.5.13 Uname: Linux 6.5.0-26-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult:
[Kernel-packages] [Bug 2063298] [NEW] deprecate ubuntu-fan in Noble
Public bug reported: [Impact] In order to provide ubuntu-fan we need to maintain additional kernel SAUCE patches that are currently conflicting with upstream code, potentially breaking networking eBPF APIs. To prevent such incompatibility the whole patch set requires a major redesign. However, after investigations and a detailed assessment we have not found any relevant real-world use-case that still requuires ubuntu-fan, as most of its features are now available in the upstream kernel and user-space tools, using alternative solutions. Moreover, maintaining ubuntu-fan is also slowing down / preventing the development of other packages (see for example LP: #2051672). Therefore, we are proposing to deprecate ubuntu-fan starting with noble. [Test case] We have ubuntu-fan test cases in our regression testing suite. Such tests are expected to fail with the noble kernel, so we can hint/disable them in Noble. [Fix] Drop (do not apply) the ubuntu-fan SAUCE patch set from the Ubuntu kernel. [Regression potential] There are still some existing tools/systems that may still rely on ubuntu-fan, so we may experience regressions when such systems are moving to noble. However, the potential of breaking eBPF networking has a much higher impact, so we can probably workaround any potential ubuntu-fan regression using alternative upstream solutions. ** Affects: iproute2 (Ubuntu) Importance: Undecided Status: New ** Affects: iproute2 (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: iproute2 (Ubuntu Noble) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/2063298 Title: deprecate ubuntu-fan in Noble Status in iproute2 package in Ubuntu: New Status in iproute2 source package in Noble: New Bug description: [Impact] In order to provide ubuntu-fan we need to maintain additional kernel SAUCE patches that are currently conflicting with upstream code, potentially breaking networking eBPF APIs. To prevent such incompatibility the whole patch set requires a major redesign. However, after investigations and a detailed assessment we have not found any relevant real-world use-case that still requuires ubuntu- fan, as most of its features are now available in the upstream kernel and user-space tools, using alternative solutions. Moreover, maintaining ubuntu-fan is also slowing down / preventing the development of other packages (see for example LP: #2051672). Therefore, we are proposing to deprecate ubuntu-fan starting with noble. [Test case] We have ubuntu-fan test cases in our regression testing suite. Such tests are expected to fail with the noble kernel, so we can hint/disable them in Noble. [Fix] Drop (do not apply) the ubuntu-fan SAUCE patch set from the Ubuntu kernel. [Regression potential] There are still some existing tools/systems that may still rely on ubuntu-fan, so we may experience regressions when such systems are moving to noble. However, the potential of breaking eBPF networking has a much higher impact, so we can probably workaround any potential ubuntu-fan regression using alternative upstream solutions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2063298/+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 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
According to the information that I collected (asking around, investigating, etc.), it seems that there are no critical users of ubuntu-fan. Moreover, considering the impact of the ubuntu-fan kernel patches (that would require a major refactoring to avoid breaking the network eBPF ABI), we decided to proceed with the plan to deprecate this feature in all the noble kernels. Therefore, all the user-space components that rely on such feature can follow the same plan and drop their corresponding ubuntu-fan support (iproute2 included). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/2051672 Title: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) Status in iproute2 package in Ubuntu: Confirmed Bug description: iproute2 upstream produces releases coinciding with upstream kernel releases to support the latest kernel features. Noble's iproute2 is still back at v6.1 even though it will use the v6.8 kernel. This means we provide no userspace interface for newer features - some of which are noted by a networking hardware partner in bug 2060969. Ubuntu's iproute2 has diverged from Debian's to add support for Ubuntu FAN. Noble has dropped kernel support for Ubuntu FAN, so those are no longer needed, and we could now just do a merge. We could also port the FAN patches forward if we can identify a need (see the original description of this bug to a link to such a port), but I have not done any testing with that. I have built Debian's iproute2 in a noble ppa at ppa:dannf/test and smoke tested it on an amd64 virtual machine: ubuntu@cortez-vm-0:~$ sudo dpkg -i iproute2_6.8.0-1~24.04.1_amd64.deb (Reading database ... 83134 files and directories currently installed.) Preparing to unpack iproute2_6.8.0-1~24.04.1_amd64.deb ... Unpacking iproute2 (6.8.0-1~24.04.1) over (6.1.0-1ubuntu6) ... dpkg: warning: unable to delete old directory '/etc/iproute2/rt_tables.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/iproute2/rt_protos.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/iproute2': Directory not empty Setting up iproute2 (6.8.0-1~24.04.1) ... Removing obsolete conffile /etc/iproute2/group ... Removing obsolete conffile /etc/iproute2/rt_realms ... Removing obsolete conffile /etc/iproute2/rt_scopes ... Removing obsolete conffile /etc/iproute2/rt_tables ... Removing obsolete conffile /etc/iproute2/rt_tables.d/README ... Removing obsolete conffile /etc/iproute2/rt_protos.d/README ... Removing obsolete conffile /etc/iproute2/rt_protos ... Removing obsolete conffile /etc/iproute2/rt_dsfield ... Removing obsolete conffile /etc/iproute2/nl_protos ... Removing obsolete conffile /etc/iproute2/ematch_map ... Removing obsolete conffile /etc/iproute2/bpf_pinning ... Processing triggers for man-db (2.12.0-4build1) ... The system rebooted fine. The ip command seems to behave normally. Since the upstream test suite only appears to run at autopkgtest time, I triggered a run in my PPA, and it passed: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-test/noble/amd64/i/iproute2/20240412_210819_97417@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+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 2060909] Re: Apply mitigations for the native BHI hardware vulnerabilty
** Description changed:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious application
to influence indirect branch prediction in kernel by poisoning the
branch history. eIBRS isolates indirect branch targets in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between modes
when eIBRS is enabled, the BHB itself is not isolated between modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't require
unprivileged eBPF.
See also:
https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
- proper software sequence will be deployed at VMexit.
+ proper software sequence will be executed at VMexit.
+
+ NOTE: we may get these changes via stable update in 6.8, when that
+ happens we can drop this backport and apply the patch set like any other
+ regular stable update.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
--
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/2060909
Title:
Apply mitigations for the native BHI hardware vulnerabilty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious
application to influence indirect branch prediction in kernel by
poisoning the branch history. eIBRS isolates indirect branch targets
in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between
modes when eIBRS is enabled, the BHB itself is not isolated between
modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't
require unprivileged eBPF.
See also:
https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be executed at VMexit.
NOTE: we may get these changes via stable update in 6.8, when that
happens we can drop this backport and apply the patch set like any
other regular stable update.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060909/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help :
[Kernel-packages] [Bug 2060909] Re: Apply mitigations for the native BHI hardware vulnerabilty
** Summary changed:
- Backport mitigations for the native BHI hardware vulnerabilty
+ Apply mitigations for the native BHI hardware vulnerabilty
--
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/2060909
Title:
Apply mitigations for the native BHI hardware vulnerabilty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious
application to influence indirect branch prediction in kernel by
poisoning the branch history. eIBRS isolates indirect branch targets
in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between
modes when eIBRS is enabled, the BHB itself is not isolated between
modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't
require unprivileged eBPF.
See also:
https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be executed at VMexit.
NOTE: we may get these changes via stable update in 6.8, when that
happens we can drop this backport and apply the patch set like any
other regular stable update.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060909/+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 2060909] Re: Backport mitigations for the native BHI hardware vulnerabilty
** Changed in: linux (Ubuntu Noble)
Status: New => Fix Committed
** Description changed:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious application
to influence indirect branch prediction in kernel by poisoning the
branch history. eIBRS isolates indirect branch targets in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between modes
when eIBRS is enabled, the BHB itself is not isolated between modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't require
unprivileged eBPF.
+ See also:
+ https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject
+
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
- 2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
- ed2e8d49b54d ("KVM: x86: Add BHI_NO")
- 95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
- ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
- be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
- 0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
- 7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
- 1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
- 0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
+ 2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
+ ed2e8d49b54d ("KVM: x86: Add BHI_NO")
+ 95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
+ ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
+ be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
+ 0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
+ 7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
+ 1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
+ 0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be deployed at VMexit.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
--
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/2060909
Title:
Backport mitigations for the native BHI hardware vulnerabilty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious
application to influence indirect branch prediction in kernel by
poisoning the branch history. eIBRS isolates indirect branch targets
in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between
modes when eIBRS is enabled, the BHB itself is not isolated between
modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't
require unprivileged eBPF.
See also:
https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be deployed at VMexit.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
To
[Kernel-packages] [Bug 2060909] [NEW] Backport mitigations for the native BHI hardware vulnerabilty
Public bug reported:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious application
to influence indirect branch prediction in kernel by poisoning the
branch history. eIBRS isolates indirect branch targets in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between modes
when eIBRS is enabled, the BHB itself is not isolated between modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't require
unprivileged eBPF.
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be deployed at VMexit.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Committed
** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: Fix Committed
** Also affects: linux (Ubuntu Noble)
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/2060909
Title:
Backport mitigations for the native BHI hardware vulnerabilty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
[Impact]
Branch History Injection (BHI) attacks may allow a malicious
application to influence indirect branch prediction in kernel by
poisoning the branch history. eIBRS isolates indirect branch targets
in ring0.
The BHB can still influence the choice of indirect branch predictor
entry, and although branch predictor entries are isolated between
modes when eIBRS is enabled, the BHB itself is not isolated between
modes.
Previously the only known real-world BHB attack vector was via
unprivileged eBPF. Further research has found attacks that don't
require unprivileged eBPF.
[Test case]
https://www.vusec.net/projects/native-bhi/
[Fix]
Backport from upstream the merge that introduces spectre_bhi= boot
option to control BHI mitigation:
2bb69f5fc721 ("Merge tag 'nativebhi' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
ed2e8d49b54d ("KVM: x86: Add BHI_NO")
95a6ccbdc719 ("x86/bhi: Mitigate KVM by default")
ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
be482ff95009 ("x86/bhi: Enumerate Branch History Injection (BHI) bug")
0f4a837615ff ("x86/bhi: Define SPEC_CTRL_BHI_DIS_S")
7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall
entry")
1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system
calls")
0cd01ac5dcb1 ("x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs
file")
Also set spectre_bhi=auto by default, that will rely on the BHI_DIS_S
hardware control if it's available on the system CPUs, otherwise a
proper software sequence will be deployed at VMexit.
[Regression potential]
We may experience performance regressions with this new mitigation
enabled, especially in VMs and CPUs that don't have the BHI hardware
support capability (due to the extra software sequence executed at
VMexit).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060909/+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 2055805] Re: touchpad not working with kernel 6.8
@tijs thanks for testing it! If 6.8.0-19 is working I assume that also the latest kernel in release (6.8.0-22.22) is also working. If that's the case I think we can close this for now. -- 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/2055805 Title: touchpad not working with kernel 6.8 Status in linux package in Ubuntu: Confirmed Bug description: After the standard update procedure and installation of a new version of the kernel, the touchpad on the MacBook Pro 13 - 2014 stopped working. Even the mouse cursor does not appear on the screen. If you select the old kernel version 6.6 in the bootloader options, then everything works correctly Ubuntu 24.04 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-headers-6.8.0-11-generic 6.8.0-11.11 ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3 Uname: Linux 6.6.0-14-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Mar 3 11:11:43 2024 InstallationDate: Installed on 2023-11-06 (118 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: Apple Inc. MacBookPro11,1 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-6.6.0-14-generic root=UUID=2075733d-58de-4836-9c71-04dd00378200 ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.6.0-14-generic N/A linux-backports-modules-6.6.0-14-generic N/A linux-firmware20240202.git36777504-0ubuntu1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/17/2020 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 430.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-189A3D4F975D5FFC dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,1 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-189A3D4F975D5FFC dmi.modalias: dmi:bvnAppleInc.:bvr430.0.0.0.0:bd12/17/2020:br0.1:svnAppleInc.:pnMacBookPro11,1:pvr1.0:rvnAppleInc.:rnMac-189A3D4F975D5FFC:rvrMacBookPro11,1:cvnAppleInc.:ct10:cvrMac-189A3D4F975D5FFC:skuSystemSKU#: dmi.product.family: Mac dmi.product.name: MacBookPro11,1 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055805/+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 2058830] Re: vp9 hw decode broken on modern AMD apus, needs amdgpu update
Any news? Pulling firmware from upstream is enough to solve this issue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/2058830 Title: vp9 hw decode broken on modern AMD apus, needs amdgpu update Status in Linux Firmware: Fix Released Status in linux-firmware package in Ubuntu: Fix Released Status in linux-firmware source package in Jammy: Confirmed Status in linux-firmware source package in Mantic: Confirmed Status in linux-firmware source package in Noble: Fix Released Bug description: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8044 [EDIT: fixed link] Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. To manage notifications about this bug go to: https://bugs.launchpad.net/linux-firmware/+bug/2058830/+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 2060130] Re: [SPR][EMR][GNR] TDX: efi: TD Measurement support for kernel cmdline/initrd sections from EFI stub
Applied all the listed commits to noble/linux, including also:
9c55461040a9 ("x86/efistub: Remap kernel text read-only before dropping
NX attribute")
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Noble)
Status: New => Fix Committed
--
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/2060130
Title:
[SPR][EMR][GNR] TDX: efi: TD Measurement support for kernel
cmdline/initrd sections from EFI stub
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
This is a public version of https://bugs.launchpad.net/bugs/2058835
[Description]
When a TD is created, during the boot process, steps like loading the
firmware, bootloader, kernel image, etc are measured and stored in RTMR
registers to support the trusted boot model. After boot, this measured value is
used to validate the integrity of the boot process.
During the direct boot process, bootloader is responsible for
measuring the kernel image before loading the kernel. But if the
kernel is loaded from EFI bootstub, the related measurements needs to
be owned by the EFI bootstub. This support needs to be added to Linux
EFI boot stub code.
Also, as per the following discussion, the kernel command line or
initrd section measurements also needs be owned by the EFI bootsub.
https://edk2.groups.io/g/devel/topic/93737108?p=Created%2C%2C%2C20%2C2%2C0%2C0%3A%3A%2C%2C%2C0%2C0%2C0%2C93737108
[Fix]
Cherry pick cleanly:
d228814b1913 efi/libstub: Add get_event_log() support for CC platforms
ac93cbfc2a2c efi/libstub: Measure into CC protocol if TCG2 protocol is
absent
0bbe5b0ea97a efi/libstub: Add Confidential Computing (CC) measurement
typedefs
7a1381e8313f efi/tpm: Use symbolic GUID name from spec for final events
table
3e0b0f880e9e efi/libstub: Use TPM event typedefs from the TCG PC Client
spec
External Links:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70ef654469b371d0a71bcf967fa3dcbca05d4b25
Those are all merged into upstream.
[Test Plan]
Build/sign/boot with secure boot enabled.
[Where problems could occur]
At boot time, as this is modifying the efi libstub. Could be impacting
secure boot.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060130/+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 2059080] Re: Add Real-time Linux Analysis tool (rtla) to linux-tools
** Changed in: linux (Ubuntu Noble) Status: New => Fix Committed -- 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/2059080 Title: Add Real-time Linux Analysis tool (rtla) to linux-tools Status in linux package in Ubuntu: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: [Impact] The **rtla** is a meta-tool that includes a set of commands that aims to analyze the real-time properties of Linux. Considering the latest "low-latency" capabilities acquired by the generic kernel and also considering the recent trend in Ubuntu to focus on performance and observability (see for example https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame- pointers-by-default), it makes sense to provide more tools that can help to analyze timing/responsive performance, such as rtla. [Test case] Simple rtla usage to measure the timer irq / timer thread latency: $ sudo rtla timerlat [Fix] Enable the build of the rtla binary during the kernel build and ship it with linux-tools. [Regression potential] The only potential regression is an increased amount of size in the linux-tools package, due to the extra binary. However, the binary itself is really small, the kernel already has all the required capabilities enabled and we don't need to introduce any additional user-space dependency, therefore such extra space is expected to be minimal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059080/+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 2046040] Re: enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble
Changing the state to Won't fix, because of LP: #2059762. ** Changed in: linux (Ubuntu Noble) Status: Fix Released => Won't Fix -- 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/2046040 Title: enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble Status in linux package in Ubuntu: Fix Released Status in linux source package in Noble: Won't Fix Bug description: [Impact] Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. Linux 6.7 introduced the TDX support for the host to run confidential VMs (TDX guests). [Test case] We should probably define with Intel a proper test case to test this feature, since it requires special hardware/firmware support. [Fix] Enable CONFIG_INTEL_TDX_HOST in our generic kernel. [Regression potential] The TDX host support may introduce potential performance regressions, so we should probably do some performance evaluation with vs without CONFIG_INTEL_TDX_HOST enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2046040/+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 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
If the issue is fixed without the extra patch, I think we can ignore it, it was probably a false positive from UBSAN. Let's keep an eye on it and if it shows up again in the future we can do a test with my additional patch. Thanks for update! -- 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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job for default target initrd.target. Machine Type = P10 LPAR Contact Information = Kowshik Jois B S kowshik.j...@in.ibm.com ---Steps to Reproduce--- 1. reboot the system 2. Once the system is booted back, look at dmesg ---uname output--- Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 ppc64le ppc64le ppc64le
[Kernel-packages] [Bug 2059762] [NEW] CONFIG_INTEL_TDX_HOST conflicts with kexec in linux >= 6.8 for noble
Public bug reported:
[Impact]
CONFIG_INTEL_TDX_HOST depends on !KEXEC_CORE in the latest 6.8 kernel.
This was introduced by:
cb8eb06d50fc ("x86/virt/tdx: Disable TDX host support when kexec is
enabled")
We cannot regress kexec, therefore we need to disable
CONFIG_INTEL_TDX_HOST in the generic kernel, despite our attempt with
LP: #2046040.
[Fix]
Disable CONFIG_INTEL_TDX_HOST in the generic kernel, until upstream will
properly support this option with kexec.
[Regression potential]
The Intel host TDX feature won't be available in the generic kernel.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Committed
** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: Fix Committed
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Noble)
Status: New => Fix Committed
--
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/2059762
Title:
CONFIG_INTEL_TDX_HOST conflicts with kexec in linux >= 6.8 for noble
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Bug description:
[Impact]
CONFIG_INTEL_TDX_HOST depends on !KEXEC_CORE in the latest 6.8 kernel.
This was introduced by:
cb8eb06d50fc ("x86/virt/tdx: Disable TDX host support when kexec is
enabled")
We cannot regress kexec, therefore we need to disable
CONFIG_INTEL_TDX_HOST in the generic kernel, despite our attempt with
LP: #2046040.
[Fix]
Disable CONFIG_INTEL_TDX_HOST in the generic kernel, until upstream
will properly support this option with kexec.
[Regression potential]
The Intel host TDX feature won't be available in the generic kernel.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059762/+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 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
Looking at the code this issue seems to be introduced by `UBUNTU: SAUCE:
modpost: support arbitrary symbol length in modversion` and the UBSAN
warning tells us that accessing vers->name[0] could be an out-of-bounds
access.
The struct modversion_info contains a flexibile array (name), that is
correctly defined as the last member of the struct, and its size is
allocated dynamically at runtime, so I would expect that vars->name[0]
is always allocated, unless vars is not initialized properly or there's
an empty name.
So, my guess is that UBSAN isn't really happy about the flexible array
and this is just a false positive.
However, to be 100% sure that we are not actually doing and out-of-bound
access and prevent the warning, we could apply something like the
following on top of our SAUCE patch:
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 195714fc6e22..1f5960e25758 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -350,6 +350,8 @@ static void dedotify_versions(struct modversion_info *vers,
struct modversion_info *end = (void *)vers + size;
for (; vers < end && vers->next; vers = (void *)vers + vers->next) {
+ if (size <= offsetof(struct modversion_info, name))
+ continue;
if (vers->name[0] == '.') {
memmove(vers->name, vers->name+1, strlen(vers->name));
}
In this case even if (for any reason) vars->name[] is an empty string we can
prevent the out-of-bound access and make UBSAN happy.
Opinions?
--
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/2059237
Title:
[Ubuntu-24.04] "array-index-out-of-bounds" error is observed after
every reboot
Status in The Ubuntu-power-systems project:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
== Comment:- Kowshik Jois B S ==
---Problem Description---
Below trace messges are observed in dmesg after every reboot.
[0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2)
[0.475750] Freeing unused kernel image (initmem) memory: 8832K
[0.507388] Checked W+X mappings: passed, no W+X pages found
[0.507400] Run /init as init process
[0.507403] with arguments:
[0.507404] /init
[0.507405] with environment:
[0.507406] HOME=/
[0.507407] TERM=linux
[0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic
[0.511892] [ cut here ]
[0.511904] UBSAN: array-index-out-of-bounds in
/build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17
[0.511909] index 0 is out of range for type 'char [*]'
[0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic
#11-Ubuntu
[0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06
of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries
[0.511921] Call Trace:
[0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4
(unreliable)
[0.511931] [c6683650] [c0c7bc58]
__ubsan_handle_out_of_bounds+0xc4/0x12c
[0.511938] [c6683700] [c005d2a8]
module_frob_arch_sections+0x4ec/0x8d0
[0.511943] [c66837e0] [c02b98cc]
layout_and_allocate.isra.0+0x38/0x2a8
[0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0
[0.511953] [c6683990] [c02baca8]
init_module_from_file+0xb4/0x14c
[0.511958] [c6683a70] [c02baf70]
sys_finit_module+0x230/0x48c
[0.511963] [c6683b80] [c0033248]
system_call_exception+0xe8/0x240
[0.511967] [c6683e50] [c000d15c]
system_call_vectored_common+0x15c/0x2ec
[0.511972] --- interrupt: 3000 at 0x7879b903b8a8
[0.511977] NIP: 7879b903b8a8 LR: CTR:
[0.511980] REGS: c6683e80 TRAP: 3000 Not tainted
(6.8.0-11-generic)
[0.511984] MSR: 8000f033 CR:
48222428 XER:
[0.511993] IRQMASK: 0
GPR00: 0161 7fffd683b580 7879b9166d00
0004
GPR04: 7879b8e0c160 0004 0010
0004
GPR08: 0001
GPR12: 7879b99d3a00 2000
0002
GPR16: 1b5c7d7453e0
7fffd683ba68
GPR20: 1b5c82154ae0
1b5c82142360
GPR24: 7879b957f7b0 1b5c82154ae0
1b5c82142160
GPR28: 7879b8e0c160 0002 1b5c82154ae0
1b5c82142380
[0.512029] NIP
[Kernel-packages] [Bug 2059080] [NEW] Add Real-time Linux Analysis tool (rtla) to linux-tools
Public bug reported: [Impact] The **rtla** is a meta-tool that includes a set of commands that aims to analyze the real-time properties of Linux. Considering the latest "low-latency" capabilities acquired by the generic kernel and also considering the recent trend in Ubuntu to focus on performance and observability (see for example https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame- pointers-by-default), it makes sense to provide more tools that can help to analyze timing/responsive performance, such as rtla. [Test case] Simple rtla usage to measure the timer irq / timer thread latency: $ sudo rtla timerlat [Fix] Enable the build of the rtla binary during the kernel build and ship it with linux-tools. [Regression potential] The only potential regression is an increased amount of size in the linux-tools package, due to the extra binary. However, the binary itself is really small, the kernel already has all the required capabilities enabled and we don't need to introduce any additional user-space dependency, therefore such extra space is expected to be minimal. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) 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/2059080 Title: Add Real-time Linux Analysis tool (rtla) to linux-tools Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] The **rtla** is a meta-tool that includes a set of commands that aims to analyze the real-time properties of Linux. Considering the latest "low-latency" capabilities acquired by the generic kernel and also considering the recent trend in Ubuntu to focus on performance and observability (see for example https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame- pointers-by-default), it makes sense to provide more tools that can help to analyze timing/responsive performance, such as rtla. [Test case] Simple rtla usage to measure the timer irq / timer thread latency: $ sudo rtla timerlat [Fix] Enable the build of the rtla binary during the kernel build and ship it with linux-tools. [Regression potential] The only potential regression is an increased amount of size in the linux-tools package, due to the extra binary. However, the binary itself is really small, the kernel already has all the required capabilities enabled and we don't need to introduce any additional user-space dependency, therefore such extra space is expected to be minimal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059080/+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 2058830] Re: vp9 hw decode broken on modern AMD apus, needs amdgpu update
** Description changed: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: - https://gitlab.com/kernel-firmware/linux- - firmware/-/commit/977332782302476e1c863b09b840f463d0378807 + https://gitlab.freedesktop.org/mesa/mesa/-/issues/8044 + + [EDIT: fixed link] Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/2058830 Title: vp9 hw decode broken on modern AMD apus, needs amdgpu update Status in linux-firmware package in Ubuntu: New Bug description: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8044 [EDIT: fixed link] Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2058830/+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 2058830] Re: vp9 hw decode broken on modern AMD apus, needs amdgpu update
** Summary changed: - vp9 hw decode broke on modern AMD apus, needs amdgpu update + vp9 hw decode broken on modern AMD apus, needs amdgpu update ** Description changed: - Current version of amdgpu in linux-firmware shipped with ubuntu 22.04 - (jammy) and ubuntu 23.10 (mantic) create various problems when decoding - VP9 content with the iGPU on modern AMD mobile processor (rembrant and - phoenix, i.e. 6xxxU/H, 7x40U/H and 7735U/H processor). + Current version of amdgpu binaries in linux-firmware shipped with ubuntu + 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when + decoding VP9 content with the iGPU on modern AMD mobile processor + (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7735U/H processor). The issue has been reported and solved upstream: https://gitlab.com/kernel-firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. ** Description changed: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor - (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7735U/H processor). + (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.com/kernel-firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/2058830 Title: vp9 hw decode broken on modern AMD apus, needs amdgpu update Status in linux-firmware package in Ubuntu: New Bug description: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.com/kernel-firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2058830/+subscriptions -- Mailing list:
[Kernel-packages] [Bug 2058830] [NEW] vp9 hw decode broken on modern AMD apus, needs amdgpu update
Public bug reported: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.com/kernel-firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. ** Affects: linux-firmware (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/2058830 Title: vp9 hw decode broken on modern AMD apus, needs amdgpu update Status in linux-firmware package in Ubuntu: New Bug description: Current version of amdgpu binaries in linux-firmware shipped with ubuntu 22.04 (jammy) and ubuntu 23.10 (mantic) create various problems when decoding VP9 content with the iGPU on modern AMD mobile processor (rembrant and phoenix, i.e. 6xxxU/H, 7x40U/H and 7x35U/H processor). The issue has been reported and solved upstream: https://gitlab.com/kernel-firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Solution dates to the end of February: https://gitlab.com/kernel- firmware/linux- firmware/-/commit/977332782302476e1c863b09b840f463d0378807 Ubuntu 24.04 already ships the updated binaries and should not be affected. Steps to reproduce: * on an affected system play a VP9 video with hardware decoding Additional links: * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=977332782302476e1c863b09b840f463d0378807 * https://bugzilla.redhat.com/show_bug.cgi?id=2267714 * https://www.phoronix.com/news/AMDGPU-Firmware-Fixes-VP9 Workaround: * download the amdgpu folder from upstream linux-firmware repos * compress each file with zstd * copy into /lib/firmware/amdgpu * regenerate the initrd I'm currently running ubuntu 23.10 (mantic) with binaries from upstream and the issue is solved. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2058830/+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 2058752] Re: ath11k high jitter and packet loss when operating in 802.11ax mode
Well, that was a pleasant surprise! On 6.8.0-11 the problem seems to be
completely gone. I guess I'll be upgrading to Noble as soon as possible.
--
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/2058752
Title:
ath11k high jitter and packet loss when operating in 802.11ax mode
Status in linux package in Ubuntu:
New
Bug description:
On 6.5.0-26-generic, my QCNFA765 cannot really operate in 802.11ax
mode.
I have a Thinkpad P16s Gen 2 with a (soldered, sadly) QCNFA765 card, which
uses the ath11k driver.
I also have a Ruckus R650 AP, which supports wifi6.
Connecting the two and pinging the AP yields the following:
```
64 bytes from 192.168.16.77: icmp_seq=45 ttl=64 time=22.4 ms
64 bytes from 192.168.16.77: icmp_seq=46 ttl=64 time=29.6 ms
64 bytes from 192.168.16.77: icmp_seq=47 ttl=64 time=26.8 ms
64 bytes from 192.168.16.77: icmp_seq=48 ttl=64 time=2174 ms
64 bytes from 192.168.16.77: icmp_seq=49 ttl=64 time=1158 ms
64 bytes from 192.168.16.77: icmp_seq=50 ttl=64 time=130 ms
64 bytes from 192.168.16.77: icmp_seq=51 ttl=64 time=503 ms
64 bytes from 192.168.16.77: icmp_seq=54 ttl=64 time=1832 ms
64 bytes from 192.168.16.77: icmp_seq=55 ttl=64 time=808 ms
64 bytes from 192.168.16.77: icmp_seq=56 ttl=64 time=9.32 ms
64 bytes from 192.168.16.77: icmp_seq=57 ttl=64 time=2.11 ms
64 bytes from 192.168.16.77: icmp_seq=58 ttl=64 time=25.6 ms
64 bytes from 192.168.16.77: icmp_seq=59 ttl=64 time=30.9 ms
64 bytes from 192.168.16.77: icmp_seq=60 ttl=64 time=95.6 ms
^C
--- 192.168.16.77 ping statistics ---
60 packets transmitted, 55 received, 8.3% packet loss, time 59273ms
rtt min/avg/max/mdev = 2.105/275.084/2344.792/560.334 ms, pipe 3
```
Those periodic bursts of >1s latency make some webpages fail to load
and videochats unusable.
No interference is present in my channel of choice.
Nothing interesting is printed in dmesg while the above occurs.
The above does not happen if:
* I disable wifi 6 in the AP
* I ping a wifi 5 AP (I also have an older R710, which is a 802.11ac AP)
* I ping the R650 in wifi 6 mode from a AX210 on kernel 6.2
* I ping the R650 from a completely different OS and device (e.g. Android)
I'll test with a 24.04 daily image next.
ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: linux-image-6.5.0-26-generic 6.5.0-26.26
ProcVersionSignature: Ubuntu 6.5.0-26.26-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 21 16:58:07 2024
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: root=zfs:zroot/ROOT/ubuntu quiet loglevel=4
rtc_cmos.use_acpi_alarm=1 spl.spl_hostid=0x4605c990
RelatedPackageVersions:
linux-restricted-modules-6.5.0-26-generic N/A
linux-backports-modules-6.5.0-26-generic N/A
linux-firmware20230919.git3672ccab-0ubuntu2.9
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/15/2024
dmi.bios.release: 1.18
dmi.bios.vendor: LENOVO
dmi.bios.version: R2FET38W (1.18 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21K9001NUS
dmi.board.vendor: LENOVO
dmi.board.version: SDK0T76530 WIN
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.11
dmi.modalias:
dmi:bvnLENOVO:bvrR2FET38W(1.18):bd01/15/2024:br1.18:efr1.11:svnLENOVO:pn21K9001NUS:pvrThinkPadP16sGen2:rvnLENOVO:rn21K9001NUS:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21K9_BU_Think_FM_ThinkPadP16sGen2:
dmi.product.family: ThinkPad P16s Gen 2
dmi.product.name: 21K9001NUS
dmi.product.sku: LENOVO_MT_21K9_BU_Think_FM_ThinkPad P16s Gen 2
dmi.product.version: ThinkPad P16s Gen 2
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2058752/+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 2051560] Re: Provide python perf module
** Changed in: linux (Ubuntu) Status: New => Fix Committed -- 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/2051560 Title: Provide python perf module Status in linux package in Ubuntu: Fix Committed Bug description: [Impact] We need to provide the python perf module, because some applications (such as tuned) require it. This module is implemented inside perf, provided by the kernel. At the moment we provide a distinct perf for each kernel installed in the system. There is really no reason to do that, because perf is both backward and forward compatible, but this is a different issue and we are not going to solve it in this context and it will be addressed in a separate bug. For now, to solve this specific issue, we need to enable the python module when we build perf (as part of the kernel build) and ship the library inside the linux-tools- package. However, this brings a new problem, because we need to install the module in a standard python path (so that python applications can be able to use it in a regular way), but we need to support multiple installed versions and add some logic to transparently select the right one when a generic user-space python application uses `import perf`. For this reason we need to provide a python wrapper module that is imported via a regular `import perf` and it transparently loads the actual python perf module, based on the kernel that is currently running. [Test case] Install linux-tools- and run the following simple test case: $ python -c 'import perf; [print(c) for c in perf.cpu_map()]' [Fix] - Enable the python perf module build during the regular kernel build - Provide a virtual `perf` python module wrapper in linux-tools-common [Regression potential] We are adding a new python module to linux-tools (that is something new, we don't ship any other python module), but we are not changing anything that is already provided, so the only regression that can happen is an increased size of the linux-tools package. [Original bug report] The tuned package has some plugins which rely on the perf python module [1], and right now they are not working because we do not have the perf python module available in Ubuntu. Initially, this was reported in this other bug [2], but it seems the scope of that bug is bigger than what we (Server) need for tuned. So filing this new bug as requested by the Kernel team to provide just the python module. For reference, in Fedora it's shipped in the bin:python3-perf package: [root@f39 ~]# rpm -ql python3-perf /usr/lib/.build-id /usr/lib/.build-id/80 /usr/lib/.build-id/80/9022196f598cb3327545c2d497b1d9fdf55630 /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/PKG-INFO /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/SOURCES.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/dependency_links.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/top_level.txt /usr/lib64/python3.12/site-packages/perf.cpython-312-x86_64-linux-gnu.so /usr/share/licenses/python3-perf /usr/share/licenses/python3-perf/COPYING Built from their kernel-tools package[3]. [1] https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/2051290 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1613393 [3] https://src.fedoraproject.org/rpms/kernel-tools/blob/rawhide/f/kernel-tools.spec#_148 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2051560/+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 2051560] Re: Provide python perf module
Patch sent to the kernel team mailing list for review: https://lists.ubuntu.com/archives/kernel-team/2024-March/149751.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2051560 Title: Provide python perf module Status in linux package in Ubuntu: New Bug description: [Impact] We need to provide the python perf module, because some applications (such as tuned) require it. This module is implemented inside perf, provided by the kernel. At the moment we provide a distinct perf for each kernel installed in the system. There is really no reason to do that, because perf is both backward and forward compatible, but this is a different issue and we are not going to solve it in this context and it will be addressed in a separate bug. For now, to solve this specific issue, we need to enable the python module when we build perf (as part of the kernel build) and ship the library inside the linux-tools- package. However, this brings a new problem, because we need to install the module in a standard python path (so that python applications can be able to use it in a regular way), but we need to support multiple installed versions and add some logic to transparently select the right one when a generic user-space python application uses `import perf`. For this reason we need to provide a python wrapper module that is imported via a regular `import perf` and it transparently loads the actual python perf module, based on the kernel that is currently running. [Test case] Install linux-tools- and run the following simple test case: $ python -c 'import perf; [print(c) for c in perf.cpu_map()]' [Fix] - Enable the python perf module build during the regular kernel build - Provide a virtual `perf` python module wrapper in linux-tools-common [Regression potential] We are adding a new python module to linux-tools (that is something new, we don't ship any other python module), but we are not changing anything that is already provided, so the only regression that can happen is an increased size of the linux-tools package. [Original bug report] The tuned package has some plugins which rely on the perf python module [1], and right now they are not working because we do not have the perf python module available in Ubuntu. Initially, this was reported in this other bug [2], but it seems the scope of that bug is bigger than what we (Server) need for tuned. So filing this new bug as requested by the Kernel team to provide just the python module. For reference, in Fedora it's shipped in the bin:python3-perf package: [root@f39 ~]# rpm -ql python3-perf /usr/lib/.build-id /usr/lib/.build-id/80 /usr/lib/.build-id/80/9022196f598cb3327545c2d497b1d9fdf55630 /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/PKG-INFO /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/SOURCES.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/dependency_links.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/top_level.txt /usr/lib64/python3.12/site-packages/perf.cpython-312-x86_64-linux-gnu.so /usr/share/licenses/python3-perf /usr/share/licenses/python3-perf/COPYING Built from their kernel-tools package[3]. [1] https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/2051290 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1613393 [3] https://src.fedoraproject.org/rpms/kernel-tools/blob/rawhide/f/kernel-tools.spec#_148 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2051560/+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 2058752] [NEW] ath11k high jitter and packet loss when operating in 802.11ax mode
Public bug reported:
On 6.5.0-26-generic, my QCNFA765 cannot really operate in 802.11ax mode.
I have a Thinkpad P16s Gen 2 with a (soldered, sadly) QCNFA765 card, which uses
the ath11k driver.
I also have a Ruckus R650 AP, which supports wifi6.
Connecting the two and pinging the AP yields the following:
```
64 bytes from 192.168.16.77: icmp_seq=45 ttl=64 time=22.4 ms
64 bytes from 192.168.16.77: icmp_seq=46 ttl=64 time=29.6 ms
64 bytes from 192.168.16.77: icmp_seq=47 ttl=64 time=26.8 ms
64 bytes from 192.168.16.77: icmp_seq=48 ttl=64 time=2174 ms
64 bytes from 192.168.16.77: icmp_seq=49 ttl=64 time=1158 ms
64 bytes from 192.168.16.77: icmp_seq=50 ttl=64 time=130 ms
64 bytes from 192.168.16.77: icmp_seq=51 ttl=64 time=503 ms
64 bytes from 192.168.16.77: icmp_seq=54 ttl=64 time=1832 ms
64 bytes from 192.168.16.77: icmp_seq=55 ttl=64 time=808 ms
64 bytes from 192.168.16.77: icmp_seq=56 ttl=64 time=9.32 ms
64 bytes from 192.168.16.77: icmp_seq=57 ttl=64 time=2.11 ms
64 bytes from 192.168.16.77: icmp_seq=58 ttl=64 time=25.6 ms
64 bytes from 192.168.16.77: icmp_seq=59 ttl=64 time=30.9 ms
64 bytes from 192.168.16.77: icmp_seq=60 ttl=64 time=95.6 ms
^C
--- 192.168.16.77 ping statistics ---
60 packets transmitted, 55 received, 8.3% packet loss, time 59273ms
rtt min/avg/max/mdev = 2.105/275.084/2344.792/560.334 ms, pipe 3
```
Those periodic bursts of >1s latency make some webpages fail to load and
videochats unusable.
No interference is present in my channel of choice.
Nothing interesting is printed in dmesg while the above occurs.
The above does not happen if:
* I disable wifi 6 in the AP
* I ping a wifi 5 AP (I also have an older R710, which is a 802.11ac AP)
* I ping the R650 in wifi 6 mode from a AX210 on kernel 6.2
* I ping the R650 from a completely different OS and device (e.g. Android)
I'll test with a 24.04 daily image next.
ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: linux-image-6.5.0-26-generic 6.5.0-26.26
ProcVersionSignature: Ubuntu 6.5.0-26.26-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 21 16:58:07 2024
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: root=zfs:zroot/ROOT/ubuntu quiet loglevel=4
rtc_cmos.use_acpi_alarm=1 spl.spl_hostid=0x4605c990
RelatedPackageVersions:
linux-restricted-modules-6.5.0-26-generic N/A
linux-backports-modules-6.5.0-26-generic N/A
linux-firmware20230919.git3672ccab-0ubuntu2.9
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/15/2024
dmi.bios.release: 1.18
dmi.bios.vendor: LENOVO
dmi.bios.version: R2FET38W (1.18 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21K9001NUS
dmi.board.vendor: LENOVO
dmi.board.version: SDK0T76530 WIN
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.11
dmi.modalias:
dmi:bvnLENOVO:bvrR2FET38W(1.18):bd01/15/2024:br1.18:efr1.11:svnLENOVO:pn21K9001NUS:pvrThinkPadP16sGen2:rvnLENOVO:rn21K9001NUS:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21K9_BU_Think_FM_ThinkPadP16sGen2:
dmi.product.family: ThinkPad P16s Gen 2
dmi.product.name: 21K9001NUS
dmi.product.sku: LENOVO_MT_21K9_BU_Think_FM_ThinkPad P16s Gen 2
dmi.product.version: ThinkPad P16s Gen 2
dmi.sys.vendor: LENOVO
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug mantic wayland-session
--
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/2058752
Title:
ath11k high jitter and packet loss when operating in 802.11ax mode
Status in linux package in Ubuntu:
New
Bug description:
On 6.5.0-26-generic, my QCNFA765 cannot really operate in 802.11ax
mode.
I have a Thinkpad P16s Gen 2 with a (soldered, sadly) QCNFA765 card, which
uses the ath11k driver.
I also have a Ruckus R650 AP, which supports wifi6.
Connecting the two and pinging the AP yields the following:
```
64 bytes from 192.168.16.77: icmp_seq=45 ttl=64 time=22.4 ms
64 bytes from 192.168.16.77: icmp_seq=46 ttl=64 time=29.6 ms
64 bytes from 192.168.16.77: icmp_seq=47 ttl=64 time=26.8 ms
64 bytes from 192.168.16.77: icmp_seq=48 ttl=64 time=2174 ms
64 bytes from 192.168.16.77: icmp_seq=49 ttl=64 time=1158 ms
64 bytes from 192.168.16.77: icmp_seq=50 ttl=64 time=130 ms
64 bytes from 192.168.16.77: icmp_seq=51 ttl=64 time=503 ms
64 bytes from 192.168.16.77: icmp_seq=54 ttl=64 time=1832 ms
64 bytes from 192.168.16.77: icmp_seq=55 ttl=64 time=808 ms
64 bytes from 192.168.16.77: icmp_seq=56 ttl=64 time=9.32 ms
64 bytes from 192.168.16.77: icmp_seq=57 ttl=64 time=2.11 ms
64 bytes from 192.168.16.77: icmp_seq=58 ttl=64 time=25.6 ms
64
[Kernel-packages] [Bug 2051560] Re: Provide python perf module
** Description changed: + [Impact] + + We need to provide the python perf module, because some applications + (such as tuned) require it. + + This module is implemented inside perf, provided by the kernel. + + At the moment we provide a distinct perf for each kernel installed in + the system. There is really no reason to do that, because perf is both + backward and forward compatible, but this is a different issue and we + are not going to solve it in this context and it will be addressed in a + separate bug. + + For now, to solve this specific issue, we need to enable the python + module when we build perf (as part of the kernel build) and ship the + library inside the linux-tools- package. + + However, this brings a new problem, because we need to install the + module in a standard python path (so that python applications can be + able to use it in a regular way), but we need to support multiple + installed versions and add some logic to transparently select the right + one when a generic user-space python application uses `import perf`. + + For this reason we need to provide a python wrapper module that is + imported via a regular `import perf` and it transparently loads the + actual python perf module, based on the kernel that is currently + running. + + [Test case] + + Install linux-tools- and run the following simple test + case: + + $ python -c 'import perf; [print(c) for c in perf.cpu_map()]' + + [Fix] + + - Enable the python perf module build during the regular kernel build + - Provide a virtual `perf` python module wrapper in linux-tools-common + + [Regression potential] + + We are adding a new python module to linux-tools (that is something new, + we don't ship any other python module), but we are not changing anything + that is already provided, so the only regression that can happen is an + increased size of the linux-tools package. + + [Original bug report] + The tuned package has some plugins which rely on the perf python module [1], and right now they are not working because we do not have the perf python module available in Ubuntu. Initially, this was reported in this other bug [2], but it seems the scope of that bug is bigger than what we (Server) need for tuned. So filing this new bug as requested by the Kernel team to provide just the python module. For reference, in Fedora it's shipped in the bin:python3-perf package: [root@f39 ~]# rpm -ql python3-perf /usr/lib/.build-id /usr/lib/.build-id/80 /usr/lib/.build-id/80/9022196f598cb3327545c2d497b1d9fdf55630 /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/PKG-INFO /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/SOURCES.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/dependency_links.txt /usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/top_level.txt /usr/lib64/python3.12/site-packages/perf.cpython-312-x86_64-linux-gnu.so /usr/share/licenses/python3-perf /usr/share/licenses/python3-perf/COPYING Built from their kernel-tools package[3]. - [1] https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/2051290 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1613393 [3] https://src.fedoraproject.org/rpms/kernel-tools/blob/rawhide/f/kernel-tools.spec#_148 -- 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/2051560 Title: Provide python perf module Status in linux package in Ubuntu: New Bug description: [Impact] We need to provide the python perf module, because some applications (such as tuned) require it. This module is implemented inside perf, provided by the kernel. At the moment we provide a distinct perf for each kernel installed in the system. There is really no reason to do that, because perf is both backward and forward compatible, but this is a different issue and we are not going to solve it in this context and it will be addressed in a separate bug. For now, to solve this specific issue, we need to enable the python module when we build perf (as part of the kernel build) and ship the library inside the linux-tools- package. However, this brings a new problem, because we need to install the module in a standard python path (so that python applications can be able to use it in a regular way), but we need to support multiple installed versions and add some logic to transparently select the right one when a generic user-space python application uses `import perf`. For this reason we need to provide a python wrapper module that is imported via a regular `import perf` and it transparently loads the actual python perf module, based on the kernel that is currently running. [Test case] Install linux-tools- and run the following simple test case: $ python -c 'import perf;
[Kernel-packages] [Bug 2058191] Re: Getting SIGSEGV and SIGILL in many programs
Unfortunately those traces don't say much without the debugging symbols. If it happens also with the mainline kernel we should see similar bugs reported upstream, that's why I'm not very convinced about this being a kernel issue. More likely a library issue, considering that it happens with different applications (or interactions between kernel and a particular library). You mention that the last kernel that was working was like a 6.5? There's a huge delta between 6.5 and 6.8. Maybe we could try to restrict this range a bit more... At https://kernel.ubuntu.com/mainline/ you can find the debs of pretty much all the mainline kernel versions, maybe you could also test some kernels between 6.5 and 6.8 (assuming you can easily reproduce the problem), in order to restrict the range of changes and have a better idea where to look. Thanks! -- 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/2058191 Title: Getting SIGSEGV and SIGILL in many programs Status in Ubuntu: New Status in linux package in Ubuntu: New Bug description: Okay, recently I upgraded to 24.04. I'm getting some SIGSEGV and SIGILLs from time to time. Sometimes the entire computer freezes and i can't even turn down unless i hold the power button for 5 secs. I tought it could be the kernel version, so I upgraded from Ubuntu's 6.8.0-11.11+1 to mainline 6.8.1. However, it didn't fix. Here are some softwares i got SIGSEGV or SIGILLs: - code-insiders (vscode) - brave (Brave browser) - bun (node.js alternative) - node.js I know i should upload more logs, but I didn't find the errors in syslog or journalctl. $ lsb_release -rd - No LSB modules are available. Description: Ubuntu Noble Numbat (development branch) Release: 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2058191/+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 2058191] Re: Getting SIGSEGV and SIGILL in many programs
Hm... honestly this looks more like a user-space / brave issue than a kernel issue. Do you get similar SIGSEGV with other apps? -- 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/2058191 Title: Getting SIGSEGV and SIGILL in many programs Status in Ubuntu: New Status in linux package in Ubuntu: New Bug description: Okay, recently I upgraded to 24.04. I'm getting some SIGSEGV and SIGILLs from time to time. Sometimes the entire computer freezes and i can't even turn down unless i hold the power button for 5 secs. I tought it could be the kernel version, so I upgraded from Ubuntu's 6.8.0-11.11+1 to mainline 6.8.1. However, it didn't fix. Here are some softwares i got SIGSEGV or SIGILLs: - code-insiders (vscode) - brave (Brave browser) - bun (node.js alternative) - node.js I know i should upload more logs, but I didn't find the errors in syslog or journalctl. $ lsb_release -rd - No LSB modules are available. Description: Ubuntu Noble Numbat (development branch) Release: 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2058191/+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 2058191] Re: Getting SIGSEGV and SIGILL in many programs
Can you give it a try also with the latest upstream 6.8 (available here https://kernel.ubuntu.com/mainline/v6.8.1/). This should help to verify if it's an upstream issue or a specific issue with the Ubuntu kernel. Thanks! -- 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/2058191 Title: Getting SIGSEGV and SIGILL in many programs Status in Ubuntu: New Status in linux package in Ubuntu: New Bug description: Okay, recently I upgraded to 24.04. I'm getting some SIGSEGV and SIGILLs from time to time. Sometimes the entire computer freezes and i can't even turn down unless i hold the power button for 5 secs. I tought it could be the kernel version, so I upgraded from Ubuntu's 6.8.0-11.11+1 to mainline 6.8.1. However, it didn't fix. Here are some softwares i got SIGSEGV or SIGILLs: - code-insiders (vscode) - brave (Brave browser) - bun (node.js alternative) - node.js I know i should upload more logs, but I didn't find the errors in syslog or journalctl. $ lsb_release -rd - No LSB modules are available. Description: Ubuntu Noble Numbat (development branch) Release: 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2058191/+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 2055805] Re: touchpad not working with kernel 6.8
@tijs not exactly that kernel, but a kernel that has all the fixes that are included in 6.8.1. :) If you are willing to do one more test to confirm that everything is fine in the next candidate kernel for 24.04, you could try with 6.8.0-20.20 from this ppa: https://launchpad.net/~canonical-kernel- team/+archive/ubuntu/bootstrap -- 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/2055805 Title: touchpad not working with kernel 6.8 Status in linux package in Ubuntu: Confirmed Bug description: After the standard update procedure and installation of a new version of the kernel, the touchpad on the MacBook Pro 13 - 2014 stopped working. Even the mouse cursor does not appear on the screen. If you select the old kernel version 6.6 in the bootloader options, then everything works correctly Ubuntu 24.04 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-headers-6.8.0-11-generic 6.8.0-11.11 ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3 Uname: Linux 6.6.0-14-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Mar 3 11:11:43 2024 InstallationDate: Installed on 2023-11-06 (118 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: Apple Inc. MacBookPro11,1 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-6.6.0-14-generic root=UUID=2075733d-58de-4836-9c71-04dd00378200 ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.6.0-14-generic N/A linux-backports-modules-6.6.0-14-generic N/A linux-firmware20240202.git36777504-0ubuntu1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/17/2020 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 430.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-189A3D4F975D5FFC dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,1 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-189A3D4F975D5FFC dmi.modalias: dmi:bvnAppleInc.:bvr430.0.0.0.0:bd12/17/2020:br0.1:svnAppleInc.:pnMacBookPro11,1:pvr1.0:rvnAppleInc.:rnMac-189A3D4F975D5FFC:rvrMacBookPro11,1:cvnAppleInc.:ct10:cvrMac-189A3D4F975D5FFC:skuSystemSKU#: dmi.product.family: Mac dmi.product.name: MacBookPro11,1 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055805/+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 2055805] Re: touchpad not working with kernel 6.8
I don't have the hardware at the moment. It'd be great if you could do a test with the latest mainline build, so that we can better understand if it's an upstream issue or something specific with the Ubuntu kernel (or maybe a kernel .config issue): https://kernel.ubuntu.com/mainline/v6.8.1/ Thanks! -- 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/2055805 Title: touchpad not working with kernel 6.8 Status in linux package in Ubuntu: Confirmed Bug description: After the standard update procedure and installation of a new version of the kernel, the touchpad on the MacBook Pro 13 - 2014 stopped working. Even the mouse cursor does not appear on the screen. If you select the old kernel version 6.6 in the bootloader options, then everything works correctly Ubuntu 24.04 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-headers-6.8.0-11-generic 6.8.0-11.11 ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3 Uname: Linux 6.6.0-14-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Mar 3 11:11:43 2024 InstallationDate: Installed on 2023-11-06 (118 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: Apple Inc. MacBookPro11,1 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-6.6.0-14-generic root=UUID=2075733d-58de-4836-9c71-04dd00378200 ro rootflags=subvol=@ quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.6.0-14-generic N/A linux-backports-modules-6.6.0-14-generic N/A linux-firmware20240202.git36777504-0ubuntu1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/17/2020 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 430.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-189A3D4F975D5FFC dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,1 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-189A3D4F975D5FFC dmi.modalias: dmi:bvnAppleInc.:bvr430.0.0.0.0:bd12/17/2020:br0.1:svnAppleInc.:pnMacBookPro11,1:pvr1.0:rvnAppleInc.:rnMac-189A3D4F975D5FFC:rvrMacBookPro11,1:cvnAppleInc.:ct10:cvrMac-189A3D4F975D5FFC:skuSystemSKU#: dmi.product.family: Mac dmi.product.name: MacBookPro11,1 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055805/+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 2058191] Re: Getting SIGSEGV and SIGILL in many programs
The message `mce: [Hardware Error]: Machine check events logged` really seems to indicate a potential hardware malfunction. Can you double check if this is happening only with the latest 6.8? Do you see anything similar in dmesg with other kernels? -- 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/2058191 Title: Getting SIGSEGV and SIGILL in many programs Status in Ubuntu: New Status in linux package in Ubuntu: New Bug description: Okay, recently I upgraded to 24.04. I'm getting some SIGSEGV and SIGILLs from time to time. Sometimes the entire computer freezes and i can't even turn down unless i hold the power button for 5 secs. I tought it could be the kernel version, so I upgraded from Ubuntu's 6.8.0-11.11+1 to mainline 6.8.1. However, it didn't fix. Here are some softwares i got SIGSEGV or SIGILLs: - code-insiders (vscode) - brave (Brave browser) - bun (node.js alternative) - node.js I know i should upload more logs, but I didn't find the errors in syslog or journalctl. $ lsb_release -rd - No LSB modules are available. Description: Ubuntu Noble Numbat (development branch) Release: 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2058191/+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 2058165] Re: System freeze on copy large files on usb
Can you elaborate more on the freeze part? Does the system completely freezes and it never recovers or is it a temporary freeze (until the copy completes)? How much RAM do you have in your system? Can you check if the following helps to mitigate the problem? $ echo $((32 * 1024 * 1024)) | sudo tee /proc/sys/vm/dirty_bytes $ echo $((16 * 1024 * 1024)) | sudo tee /proc/sys/vm/dirty_background_bytes Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-meta-lowlatency in Ubuntu. https://bugs.launchpad.net/bugs/2058165 Title: System freeze on copy large files on usb Status in linux-meta-lowlatency package in Ubuntu: New Bug description: Everytime i create/copy/move a large file >15GB on a usb the system freezes ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-lowlatency 6.8.0-7.7.1 ProcVersionSignature: Ubuntu 6.8.0-7.7.1-lowlatency 6.8.0-rc3 Uname: Linux 6.8.0-7-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Sun Mar 17 18:55:31 2024 InstallationDate: Installed on 2024-03-10 (7 days ago) InstallationMedia: Ubuntu-Studio 24.04 LTS "Noble Numbat" - Daily amd64 (20240308) SourcePackage: linux-meta-lowlatency UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lowlatency/+bug/2058165/+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 2056616] Re: left-over ceph debugging printks
** Changed in: linux (Ubuntu Noble) Status: In Progress => Fix Committed -- 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/2056616 Title: left-over ceph debugging printks Status in linux package in Ubuntu: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: Hello, a pal recently mentioned some debugging printk statements in our kernels, eg: evict_inodes inode d69da69b, i_count = 1, was skipped! https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037214 has some additional details. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2041613 looks like an effort to remove it? This apparently hasn't been finished yet, and it's in the middle of a big run of actual real work, so it might not be super-easy to just yank this out, it might also justify a larger look at the surrounding context. In noble master-next: https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/noble/commit/fs/inode.c?h=master- next=603b74b4176fdf6ab2fb83306136947296e7aeb4 Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056616/+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
** Changed in: linux (Ubuntu Noble) Status: New => Fix Committed -- 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: Fix Committed Status in linux source package in Noble: Fix Committed 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 package that would set the proper options in the kernel boot command line (GRUB, or similar). [Test case] There are plenty of benchmarks that
[Kernel-packages] [Bug 2056126] Re: hwmon: (coretemp) Fix core count limitation
** Changed in: linux (Ubuntu Noble) Status: New => Fix Committed -- 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/2056126 Title: hwmon: (coretemp) Fix core count limitation Status in linux package in Ubuntu: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: [Impact] In linux 6.8 the coretemp driver supports at most 128 cores per package. Cores higher than 128 will lose their core temperature information. There is an upstream patch set that allows to support more than 128 cores per package, but it's applied to linux-next for now and it's scheduled for 6.9. We should apply the patch set to the Noble 6.8 kernel, so that we can properly support systems with a large amount of cores per package. [Test case] Read temperature info from /sys/class/hwmon on a system with > 128 cores per package (that means we don't have a proper test case to verify the fix at the moment). [Fix] Apply the following commits (from linux-next): 18cb15e9c108 hwmon: (coretemp) Use dynamic allocated memory for core temp_data f0a5f46b0100 hwmon: (coretemp) Remove redundant temp_data->is_pkg_data 16a29729c00c hwmon: (coretemp) Split package temp_data and core temp_data b48fddda2b30 hwmon: (coretemp) Abstract core_temp helpers a30f3dc6e9bf hwmon: (coretemp) Remove redundant pdata->cpu_map[] e416450cb080 hwmon: (coretemp) Replace sensor_device_attribute with device_attribute 46ee134971bb hwmon: (coretemp) Remove unnecessary dependency of array index 9f360b22929c hwmon: (coretemp) Introduce enum for attr index [Regression potential] We may experience hwmon-related regressions, either systems reading incorrect temperature information or even bugs/crashes when accessing data from /sys/class/hwmon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056126/+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 2056126] [NEW] hwmon: (coretemp) Fix core count limitation
Public bug reported: [Impact] In linux 6.8 the coretemp driver supports at most 128 cores per package. Cores higher than 128 will lose their core temperature information. There is an upstream patch set that allows to support more than 128 cores per package, but it's applied to linux-next for now and it's scheduled for 6.9. We should apply the patch set to the Noble 6.8 kernel, so that we can properly support systems with a large amount of cores per package. [Test case] Read temperature info from /sys/class/hwmon on a system with > 128 cores per package (that means we don't have a proper test case to verify the fix at the moment). [Fix] Apply the following commits (from linux-next): 18cb15e9c108 hwmon: (coretemp) Use dynamic allocated memory for core temp_data f0a5f46b0100 hwmon: (coretemp) Remove redundant temp_data->is_pkg_data 16a29729c00c hwmon: (coretemp) Split package temp_data and core temp_data b48fddda2b30 hwmon: (coretemp) Abstract core_temp helpers a30f3dc6e9bf hwmon: (coretemp) Remove redundant pdata->cpu_map[] e416450cb080 hwmon: (coretemp) Replace sensor_device_attribute with device_attribute 46ee134971bb hwmon: (coretemp) Remove unnecessary dependency of array index 9f360b22929c hwmon: (coretemp) Introduce enum for attr index [Regression potential] We may experience hwmon-related regressions, either systems reading incorrect temperature information or even bugs/crashes when accessing data from /sys/class/hwmon. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) 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/2056126 Title: hwmon: (coretemp) Fix core count limitation Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] In linux 6.8 the coretemp driver supports at most 128 cores per package. Cores higher than 128 will lose their core temperature information. There is an upstream patch set that allows to support more than 128 cores per package, but it's applied to linux-next for now and it's scheduled for 6.9. We should apply the patch set to the Noble 6.8 kernel, so that we can properly support systems with a large amount of cores per package. [Test case] Read temperature info from /sys/class/hwmon on a system with > 128 cores per package (that means we don't have a proper test case to verify the fix at the moment). [Fix] Apply the following commits (from linux-next): 18cb15e9c108 hwmon: (coretemp) Use dynamic allocated memory for core temp_data f0a5f46b0100 hwmon: (coretemp) Remove redundant temp_data->is_pkg_data 16a29729c00c hwmon: (coretemp) Split package temp_data and core temp_data b48fddda2b30 hwmon: (coretemp) Abstract core_temp helpers a30f3dc6e9bf hwmon: (coretemp) Remove redundant pdata->cpu_map[] e416450cb080 hwmon: (coretemp) Replace sensor_device_attribute with device_attribute 46ee134971bb hwmon: (coretemp) Remove unnecessary dependency of array index 9f360b22929c hwmon: (coretemp) Introduce enum for attr index [Regression potential] We may experience hwmon-related regressions, either systems reading incorrect temperature information or even bugs/crashes when accessing data from /sys/class/hwmon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056126/+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 2055310] Re: dmesg spammed by virtui-fs and 9pnet-virtio messages
I haven't been able to reproduce this on my PC yet... Looking at the error, especially the virtio-fs part, I'm wondering if you're missing virtiofsd in your host. Can you try to `apt install virtiofsd` (if you don't have it installed 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/2055310 Title: dmesg spammed by virtui-fs and 9pnet-virtio messages Status in linux package in Ubuntu: New Bug description: Ubuntu noble, as of 28 Feb 2024, on amd64, s390x, ppc64, seeing kernel messages after boot (running instances in a VM using virt-manager) uname -a Linux noble-amd64-efi 6.6.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:27:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux [ 30.638354] virtio-fs: tag not found [ 30.642316] 9pnet_virtio: no channels available for device config [ 35.897615] virtio-fs: tag not found [ 35.901568] 9pnet_virtio: no channels available for device config [ 41.141860] virtio-fs: tag not found [ 41.145513] 9pnet_virtio: no channels available for device config [ 46.382040] virtio-fs: tag not found [ 46.386141] 9pnet_virtio: no channels available for device config [ 51.632229] virtio-fs: tag not found [ 51.635727] 9pnet_virtio: no channels available for device config These are annoying when logging in via the console. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055310/+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 1951440] Re: Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
** Changed in: linux (Ubuntu Noble)
Status: New => Fix Committed
--
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/1951440
Title:
Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Jammy:
Invalid
Status in linux source package in Noble:
Fix Committed
Bug description:
Starting with the following commit, upstream kernel is enabling Intel
IOMMU related options by default:
792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by
default")
We should follow upstream direction enabling
CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON.
A downside is that this change may introduce boot regressions on old
systems (especially those with buggy firmware).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1951440/+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 2049390] Re: Please change CONFIG_CONSOLE_LOGLEVEL_QUIET to 3
For the general use case I think that reducing the verbosity makes sense. About our testing, I think we're not booting kernels with "quiet", and if we do we should definitely drop it from the kernel boot options. -- 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/2049390 Title: Please change CONFIG_CONSOLE_LOGLEVEL_QUIET to 3 Status in linux package in Ubuntu: Confirmed Bug description: The Ubuntu Desktop boot isn't flickerfree today as reported on bug #1970069 , one of the reason is that kernel error messages are often being logged and not filtered out by our default loglevel (one example with usb messages on https://launchpadlibrarian.net/598152686/20220422_014058.jpg) Fedora is using CONFIG_CONSOLE_LOGLEVEL_QUIET=3 (instead of 4 which is the default), they change it 5 years ago (https://src.fedoraproject.org/rpms/kernel/c/838818e5), the rational is in the commit message that added the configuration option to the kernel > This for example will allow distros which want quiet to really mean quiet to set > CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity then KERN_ERR (CRIT, ALERT, EMERG) > get printed, avoiding an endless game of whack-a-mole silencing harmless error messages. ' Could we also get the default change to 3 in Ubuntu? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049390/+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 2055310] Re: dmesg spammed by virtui-fs and 9pnet-virtio messages
I don't see these messages with the latest Noble using the kernel from the proposed pocket (6.8.0-11-generic). Can you also give it a try (if you can)? Hopefully we'll be able to promote a 6.8 in release soon, we are currently blocked by a glibc regression (that doesn't seem to be a kernel regression). If we can unblock/hint this one (hopefully this week, or worst case next week) we'll have a new 6.8 in release. -- 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/2055310 Title: dmesg spammed by virtui-fs and 9pnet-virtio messages Status in linux package in Ubuntu: New Bug description: Ubuntu noble, as of 28 Feb 2024, on amd64, s390x, ppc64, seeing kernel messages after boot (running instances in a VM using virt-manager) uname -a Linux noble-amd64-efi 6.6.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:27:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux [ 30.638354] virtio-fs: tag not found [ 30.642316] 9pnet_virtio: no channels available for device config [ 35.897615] virtio-fs: tag not found [ 35.901568] 9pnet_virtio: no channels available for device config [ 41.141860] virtio-fs: tag not found [ 41.145513] 9pnet_virtio: no channels available for device config [ 46.382040] virtio-fs: tag not found [ 46.386141] 9pnet_virtio: no channels available for device config [ 51.632229] virtio-fs: tag not found [ 51.635727] 9pnet_virtio: no channels available for device config These are annoying when logging in via the console. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055310/+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 1951440] Re: Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON on jammy 5.15
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: Fix Released
** Summary changed:
- Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON on jammy 5.15
+ Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
** Changed in: linux (Ubuntu Jammy)
Status: Fix Released => Invalid
** Changed in: linux (Ubuntu Noble)
Status: Fix Released => 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/1951440
Title:
Enable CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
Status in linux package in Ubuntu:
New
Status in linux source package in Jammy:
Invalid
Status in linux source package in Noble:
New
Bug description:
Starting with the following commit, upstream kernel is enabling Intel
IOMMU related options by default:
792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by
default")
We should follow upstream direction enabling
CONFIG_INTEL_IOMMU_DEFAULT_ON and
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON.
A downside is that this change may introduce boot regressions on old
systems (especially those with buggy firmware).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1951440/+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
@turner basically any type of I/O workload can benefit from the HZ=1000 change, I haven't posted any test result, because in the scope of this proposal I wanted to focus mainly at the regression potential for CPU- intensive workloads and the benefits in terms of power consumption (this one as a positive side effect). I will also post some numbers to better highlight the benefits of the low latency features. -- 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
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
More tests and results available here: https://discourse.ubuntu.com/t/enable-low-latency-features-in-the- generic-ubuntu-kernel-for-24-04/42255 -- 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 package that would set the proper options in the kernel boot command line (GRUB, or similar).
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
@andysem yes that is also another possibility. The idea is to do a lot of tests and if we find that there's a remote possibility to introduce significant performance regressions in certain cases we can still keep HZ=250, but definitely go with the other options. -- 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"
[Kernel-packages] [Bug 2051733] Re: Specifying nohz_full disables CPU frequency scaling
@dsmythies IIUC this happens also with a mainline kernel, right? Not just the Ubuntu lowlatency one. -- 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
@andysem correct, without `nohz_full` specified at boot CONFIG_NO_HZ_FULL has no effect, except for the little extra overhead that it's adding to the tick handler (there is still some overhead with this option enabled, even if it's not used). That's why I'd like to measure the time spent in some of the tick callbacks (using bpftrace) with generic vs lowlatency, to have a better understanding of this extra overhead. Then, yes, repeating the tests disabling the ticks on some CPUs (booting with nohz_full) would be another interesting metric. -- 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
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
@colin-king noticed, I just left a thank you message in the article. I'll still do the tests, but it's nice to see that someone else is contributing to this! Another thing that I'd like to measure is to bpftrace the time spent in the tick handler before and after these changes applied, because we call the tick handler more often with HZ=1000, so it'd be nice to see how much is the distribution of such overhead. And another cool thing that I've been told is that HZ=1000 can actually help in terms of power consumption, because apparently the CPUs have more chances to enter the idle states more quickly. This is also something that I'd like to measure. -- 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,
[Kernel-packages] [Bug 2051533] [NEW] Noble update: v6.7.2 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.7.2 upstream stable release from git://git.kernel.org/ Linux 6.7.2 Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"" arm64: dts: armada-3720-turris-mox: set irq type for RTC Revert "KEYS: encrypted: Add check for strsep" i2c: s3c24xx: fix transferring more than one message in polling mode i2c: s3c24xx: fix read transfers in polling mode ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes mlxsw: spectrum_router: Register netdevice notifier before nexthop mlxsw: spectrum_acl_tcam: Fix stack corruption mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure loop: fix the the direct I/O support check when used on top of block devices ethtool: netlink: Add missing ethnl_ops_begin/complete arm64/ptrace: Don't flush ZA/ZT storage when writing ZA via ptrace kdb: Fix a potential buffer overflow in kdb_local() io_uring: adjust defer tw counting ipvs: avoid stat macros calls from preemptible context netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description netfilter: nf_tables: skip dead set elements in netlink dump netfilter: nf_tables: do not allow mismatch field size and set key length netfilter: bridge: replace physindev with physinif in nf_bridge_info netfilter: propagate net to nf_bridge_get_physindev netfilter: nf_queue: remove excess nf_bridge variable netfilter: nfnetlink_log: use proper helper for fetching physinif netfilter: nft_limit: do not ignore unsupported flags netfilter: nf_tables: reject invalid set policy net: netdevsim: don't try to destroy PHC on VFs mptcp: relax check on MPC passive fallback LoongArch: BPF: Prevent out-of-bounds memory access net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probe bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls selftests: bonding: Change script interpreter drm/amdgpu: fall back to INPUT power for AVG power via INFO IOCTL drm/amdkfd: fixes for HMM mem allocation gpiolib: Fix scope-based gpio_device refcounting ASoC: SOF: ipc4-loader: remove the CPC check warnings gpio: mlxbf3: add an error code check in mlxbf3_gpio_probe dt-bindings: gpio: xilinx: Fix node address in gpio net: ravb: Fix dma_addr_t truncation in error case net: tls, fix WARNIING in __sk_msg_free bpf: Avoid iter->offset making backward progress in bpf_iter_udp bpf: iter_udp: Retry with a larger batch size without going back to the previous bucket net: netdev_queue: netdev_txq_completed_mb(): fix wake condition net: add more sanity check in virtio_net_hdr_to_skb() erofs: fix inconsistent per-file compression format udp: annotate data-races around up->pending net: stmmac: Fix ethool link settings ops for integrated PCS block: ensure we hold a queue reference when using queue limits mptcp: refine opt_mp_capable determination mptcp: use OPTION_MPTCP_MPJ_SYN in subflow_check_req() mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() mptcp: strict validation before using mp_opt->hmac mptcp: mptcp_parse_option() fix for MPTCPOPT_MP_JOIN ALSA: hda: Properly setup HDMI stream net: phy: micrel: populate .soft_reset for KSZ9131 net: micrel: Fix PTP frame parsing for lan8841 ALSA: aloop: Introduce a function to get if access is interleaved mode amt: do not use overwrapped cb area net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames octeontx2-af: CN10KB: Fix FIFO length calculation for RPM2 rxrpc: Fix use of Don't Fragment flag net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events net: qualcomm: rmnet: fix global oob in rmnet_policy s390/pci: fix max size calculation in zpci_memcpy_toio() ASoC: mediatek: sof-common: Add NULL check for normal_link string PCI: mediatek-gen3: Fix translation window size calculation apparmor: Fix memory leak in unpack_profile() PCI: keystone: Fix race condition when initializing PHYs nvmet-tcp: Fix the H2C expected PDU len calculation PCI: xilinx-xdma: Fix error code in xilinx_pl_dma_pcie_init_irq_domain() PCI: xilinx-xdma: Fix uninitialized symbols in xilinx_pl_dma_pcie_setup_irq() nvme: trace: avoid memcpy overflow warning nvmet: re-fix tracing strncpy() warning hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume spi: coldfire-qspi: Remove an erroneous clk_disable_unprepare() from the remove function cxl/port: Fix missing target list
[Kernel-packages] [Bug 1965303] Re: Migrate from fbdev drivers to simpledrm and DRM fbdev emulation layer
** Also affects: linux (Ubuntu Noble) Importance: Undecided Assignee: Timo Aaltonen (tjaalton) Status: Confirmed ** Also affects: nvidia-graphics-drivers-470 (Ubuntu Noble) Importance: Undecided Status: 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/1965303 Title: Migrate from fbdev drivers to simpledrm and DRM fbdev emulation layer Status in gdm: Fix Released Status in linux package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-470 package in Ubuntu: Fix Released Status in linux source package in Jammy: Won't Fix Status in nvidia-graphics-drivers-470 source package in Jammy: Fix Released Status in linux source package in Lunar: Won't Fix Status in nvidia-graphics-drivers-470 source package in Lunar: Fix Released Status in linux source package in Mantic: Won't Fix Status in nvidia-graphics-drivers-470 source package in Mantic: Fix Released Status in linux source package in Noble: Confirmed Status in nvidia-graphics-drivers-470 source package in Noble: Fix Released Status in linux package in Fedora: Fix Released Bug description: [ Impact ] The fbdev subsystem has been deprecated for a long time. We should drop it in favour of using simpledrm with fbdev emulation layer. This requires Kernel config changes: FB_EFI=n FB_VESA=n fbcon will still require FB to be available, but will use the fbdev emulation layer [ Test Plan ] * Ensure that systems currently relying on fbdev (and therefore only allowing Xorg logins) such as some virtual machine types, boot with working Wayland support. [ Where Problems could occur ] * When this stack is enabled, it changes boot timing such that some drivers may take a longer time to boot and GDM may hang in a black screen (bug 2039757). * Race conditions could be exposed to DE environments * Software that expects to find DRM device at /dev/dri/card0 may have a problem. * Some older versions of NVIDIA driver might not work properly. [ Other Info ] * Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2022385 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1965303/+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
@colin-king thanks! Any suggestion in particular? I was thinking to lmbench, netperf and fio. -- 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 package that would set the proper options in the kernel boot command line (GRUB, or similar). [Test case] There are plenty of benchmarks
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
@dsmythies thank you so much for sharing the results of your tests, really useful info! I'm planning to do more tests setting the performance governor, I've been doing my initial tests only with the default Ubuntu settings, that means with the "Balanced" power mode enabled (that I think it's using intel p-states), so that may have affected my results. I'm also curious to measure the power consumption of 250 vs 1000, since I expect to see a little extra power consumption with HZ=1000. But then I also want to enable the lazy RCU (boot with `rcu_nocbs=all rcutree.enable_rcu_lazy=1`) and see how much power we can save vs the impact on performance. Overall, the point that I want to prove is that, yes, we may have small regressions here and there, but with these changes in place we can provide a huge flexibility for users, that will able to tune their system for improved responsiveness, CPU throughput, or power consumption, all using the default stock kernel. -- 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-
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
** Description changed: [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 analisys 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, simply by tuning run-time and boot-time options. + efficient (therefore more "generic"), simply by tuning run-time and + boot-time options. - Once these changes are applied we will be able to deprecate the - lowlatency kernel, saving engineering time and also reducing power + 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 package that would set the proper options in the kernel boot command line (GRUB, or similar). [Test case] There are plenty of benchmarks that can prove the validity of each one of the setting mentioned above, providing huge benefits in terms of system responsive. However, our main goal here is to
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
** Description changed: [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 analisys 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, simply by tuning run-time and boot-time options. + + 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 package that would set the proper options in the kernel boot + command line (GRUB, or similar). + [Test case] - There are plenty of micro-benchmarks to prove the validity of each one - of the config mentioned above, in terms of system responsive. + There are plenty of benchmarks that can prove the validity of each one + of the setting mentioned above, providing huge benefits in terms of + system responsive. However, our main goal here is to mitigate as much as possible the risk - of regression for CPU-intensive applications, so the test case
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
** Description changed: [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 analisys 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 (can provide 5~10% + 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) + 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.). - - Other latency-related options: - - - CONFIG_LATENCYTOP=y: we should definitely support latencytop in the - generic kernel, considering that we are shipping the user-space package [Test case] There are plenty of micro-benchmarks to prove the validity of each one of the config mentioned above, in terms of system responsive. However, our main goal here is to mitigate as much as possible the risk of regression for CPU-intensive applications, so the test case should be focused on this particular aspect. We also have the opportunity to test these changes using the lowlatency kernel, therefore a reasonable test plan could be defined as following. Test case (a CPU-intensive stress test) - stress-ng --matrix $(getconf _NPROCESSORS_ONLN) --timeout 5m --metrics-brief Metrics: - measure the bogo ops printed to stdout (not a great metric for real- world
[Kernel-packages] [Bug 2051342] Re: Enable lowlatency settings in the generic kernel
** Description changed: [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 analisys 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 (can 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) - 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.). Moreover, it is worth - noticing that pretty much all the other major Linux distributions are - also using CONFIG_HZ0=1000. + (gaming, live conferencing, multimedia, etc.). + + Other latency-related options: + + - CONFIG_LATENCYTOP=y: we should definitely support latencytop in the + generic kernel, considering that we are shipping the user-space package [Test case] There are plenty of micro-benchmarks to prove the validity of each one of the config mentioned above, in terms of system responsive. However, our main goal here is to mitigate as much as possible the risk of regression for CPU-intensive applications, so the test case should be focused on this particular aspect. We also have the opportunity to test these changes using the lowlatency kernel, therefore a reasonable test plan could be defined as following. Test case (a CPU-intensive stress test) - stress-ng --matrix $(getconf _NPROCESSORS_ONLN) --timeout 5m --metrics-brief Metrics: - measure the bogo ops printed to stdout (not a great metric for real- world applications, but in this case they
[Kernel-packages] [Bug 2051342] [NEW] Enable lowlatency settings in the generic kernel
Public bug reported: [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 analisys 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 (can 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) - 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.). Moreover, it is worth noticing that pretty much all the other major Linux distributions are also using CONFIG_HZ0=1000. [Test case] There are plenty of micro-benchmarks to prove the validity of each one of the config mentioned above, in terms of system responsive. However, our main goal here is to mitigate as much as possible the risk of regression for CPU-intensive applications, so the test case should be focused on this particular aspect. We also have the opportunity to test these changes using the lowlatency kernel, therefore a reasonable test plan could be defined as following. Test case (a CPU-intensive stress test) - stress-ng --matrix $(getconf _NPROCESSORS_ONLN) --timeout 5m --metrics-brief Metrics: - measure the bogo ops printed to stdout (not a great metric for real- world applications, but in this case they can show the impact of the addditional kernel jitter introduced by the different CONFIG_HZ) Perform multiple runs of the stress test, both on amd64 and arm64. Repeat the test also with CONFIG_NO_HZ_FULL. If NO_HZ_FULL can provide better results than the CONFIG_HZ=250 case, we can safely switch to CONFIG_HZ=1000, since we have the possibility to provide a boot-time option to improve CPU-intensive workloads and get better
[Kernel-packages] [Bug 2045503] Re: apply sched-ext patch set to linux-unstable
** Also affects: linux (Ubuntu Noble) 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/2045503 Title: apply sched-ext patch set to linux-unstable Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. Targeting linux-unstable only for now is probably a good compromise to allow users to start some experiments, collect feedbacks, help the upstream community to find and fix bugs and at the same time avoid to introduce too much maintenance burden on us. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests and custom scheduler implementations are available in tools/sched_ext or in https://github.com/sched-ext/scx. [Fix] Apply this patch set as SAUCE to linux-unstable: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ On top of the patch set we want to apply also the following patches (still as SAUCE): - UBUNTU: SAUCE: sched_ext: use proper atomic operator for scx.ops_state (extra fix to properly build sched-ext on armhf) - UBUNTU: SAUCE: sched-ext: taint kernel when a custom scheduler is loaded (set TAINT_OOT_MODULE in /proc/sys/kernel/tainted to easily determine when a custom scheduler has been used, that can be useful for bug reports: we can easily detect when a custom scheduler has been used and treat the bug report accordingly) - UBUNTU: [Config] enable sched_ext in annotations (enable sched-ext in the config across all the supported architectures) Soon there will be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux-unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045503/+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 2046040] Re: enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble
** Changed in: linux (Ubuntu Noble) Status: New => Fix Committed -- 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/2046040 Title: enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble Status in linux package in Ubuntu: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: [Impact] Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. Linux 6.7 introduced the TDX support for the host to run confidential VMs (TDX guests). [Test case] We should probably define with Intel a proper test case to test this feature, since it requires special hardware/firmware support. [Fix] Enable CONFIG_INTEL_TDX_HOST in our generic kernel. [Regression potential] The TDX host support may introduce potential performance regressions, so we should probably do some performance evaluation with vs without CONFIG_INTEL_TDX_HOST enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2046040/+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 2051245] [NEW] Noble update: v6.7.1 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.7.1 upstream stable release from git://git.kernel.org/ f2fs: explicitly null-terminate the xattr list ALSA: hda/realtek: Add quirks for Dell models ALSA: hda: cs35l41: Support additional Dell models without _DSD ALSA: hda: cs35l41: Prevent firmware load if SPI speed too low ALSA: hda: Add driver properties for cs35l41 for Lenovo Legion Slim 7 Gen 8 serie ALSA: hda/realtek: enable SND_PCI_QUIRK for Lenovo Legion Slim 7 Gen 8 (2023) serie ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxx ALSA: hda: cs35l41: Support more HP models without _DSD ACPI: resource: Add another DMI match for the TongFang GMxXGxx bus: moxtet: Mark the irq as shared bus: moxtet: Add spi device table drm/amd/display: Pass pwrseq inst for backlight and ABM ksmbd: don't allow O_TRUNC open on read-only share ksmbd: free ppace array on error in parse_dacl Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" binder: use EPOLLERR from eventpoll.h binder: fix use-after-free in shinker's callback binder: fix trivial typo of binder_free_buf_locked() binder: fix comment on binder_alloc_new_buf() return value uio: Fix use-after-free in uio_open parport: parport_serial: Add Brainboxes BAR details parport: parport_serial: Add Brainboxes device IDs and geometry leds: ledtrig-tty: Free allocated ttyname buffer on deactivate PCI: Add ACS quirk for more Zhaoxin Root Ports coresight: etm4x: Fix width of CCITMIN field scripts/decode_stacktrace.sh: optionally use LLVM utilities docs: kernel_feat.py: fix potential command injection mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval Linux 6.7.1 ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: Confirmed ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: Confirmed ** Description changed: + SRU Justification - SRU Justification + Impact: + The upstream process for stable tree updates is quite similar + in scope to the Ubuntu SRU process, e.g., each patch has to + demonstrably fix a bug, and each patch is vetted by upstream + by originating either directly from a mainline/stable Linux tree or + a minimally backported form of that patch. The following upstream + stable patches should be included in the Ubuntu kernel: - Impact: -The upstream process for stable tree updates is quite similar -in scope to the Ubuntu SRU process, e.g., each patch has to -demonstrably fix a bug, and each patch is vetted by upstream -by originating either directly from a mainline/stable Linux tree or -a minimally backported form of that patch. The following upstream -stable patches should be included in the Ubuntu kernel: + v6.7.1 upstream stable release + from git://git.kernel.org/ -v6.7.1 upstream stable release -from git://git.kernel.org/ + f2fs: explicitly null-terminate the xattr list + ALSA: hda/realtek: Add quirks for Dell models + ALSA: hda: cs35l41: Support additional Dell models without _DSD + ALSA: hda: cs35l41: Prevent firmware load if SPI speed too low + ALSA: hda: Add driver properties for cs35l41 for Lenovo Legion Slim 7 Gen 8 serie + ALSA: hda/realtek: enable SND_PCI_QUIRK for Lenovo Legion Slim 7 Gen 8 (2023) serie + ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxx + ALSA: hda: cs35l41: Support more HP models without _DSD + ACPI: resource: Add another DMI match for the TongFang GMxXGxx + bus: moxtet: Mark the irq as shared + bus: moxtet: Add spi device table + drm/amd/display: Pass pwrseq inst for backlight and ABM + ksmbd: don't allow O_TRUNC open on read-only share + ksmbd: free ppace array on error in parse_dacl + Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" + binder: use EPOLLERR from eventpoll.h + binder: fix use-after-free in shinker's callback + binder: fix trivial typo of binder_free_buf_locked() + binder: fix comment on binder_alloc_new_buf() return value + uio: Fix use-after-free in uio_open + parport: parport_serial: Add Brainboxes BAR details + parport: parport_serial: Add Brainboxes device IDs and geometry + leds: ledtrig-tty: Free allocated ttyname buffer on deactivate + PCI: Add ACS quirk for more Zhaoxin Root Ports +
[Kernel-packages] [Bug 2028253] Re: update apparmor and LSM stacking patch set
** Also affects: linux (Ubuntu Noble) Importance: Critical Status: 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/2028253 Title: update apparmor and LSM stacking patch set Status in linux package in Ubuntu: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: [Impact] Provide an updated patch set for apparmor / LSM stacking with all the custom features that we need in the Ubuntu kernel. This patch set is required to provide the proper confinement with snaps and other Ubuntu-specific security features. [Fix] Apply the latest updated patch set from: https://gitlab.com/jjohansen/apparmor-kernel [Test case] Run the apparmor test case suite. [Regression potential] This patch set introduces significant non-upstream changes to the security layer, so we may expect generic regressions in the kernel, especially running applications that are stressing the security layer (such as systemd, snapd, lxd, etc.). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028253/+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 2049603] Re: nvidia-dkms-535 FTBS on noble with the latest 6.7 kernel on arm64
The same problem happens also with nvidia-dkms-545 (still on arm64
only).
** Also affects: nvidia-graphics-drivers-545 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-535 in Ubuntu.
https://bugs.launchpad.net/bugs/2049603
Title:
nvidia-dkms-535 FTBS on noble with the latest 6.7 kernel on arm64
Status in nvidia-graphics-drivers-535 package in Ubuntu:
New
Status in nvidia-graphics-drivers-545 package in Ubuntu:
New
Status in nvidia-graphics-drivers-535 source package in Noble:
New
Status in nvidia-graphics-drivers-545 source package in Noble:
New
Bug description:
[Impact]
It looks like nvidia-dkms-535 is using a symbol that became GPL-only
in the latest 6.7 kernel, causing the following build error:
# MODPOST <>/build/nvidia/535.146.02/build/Module.symvers
scripts/mod/modpost -M -m -a -o
<>/build/nvidia/535.146.02/build/Module.symvers -T
<>/build/nvidia/535.146.02/build/modules.order -i Module.symvers -e
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'screen_info'
This change was introduced by: b8466fe82b79 ("efi: move screen_info
into efi init code")
This happens only on arm64, where the symbol is defined.
[Fix]
Avoid using screen_info in the nvidia-dkms-535 driver.
[Regression potential]
We may disable certain features in the 535 driver, or even have an
unusable driver, unless a proper workaround/solution is provided.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-535/+bug/2049603/+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 2049603] [NEW] nvidia-dkms-535 FTBS on noble with the latest 6.7 kernel on arm64
Public bug reported:
[Impact]
It looks like nvidia-dkms-535 is using a symbol that became GPL-only in
the latest 6.7 kernel, causing the following build error:
# MODPOST <>/build/nvidia/535.146.02/build/Module.symvers
scripts/mod/modpost -M -m -a -o
<>/build/nvidia/535.146.02/build/Module.symvers -T
<>/build/nvidia/535.146.02/build/modules.order -i Module.symvers -e
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'screen_info'
This change was introduced by: b8466fe82b79 ("efi: move screen_info into
efi init code")
This happens only on arm64, where the symbol is defined.
[Fix]
Avoid using screen_info in the nvidia-dkms-535 driver.
[Regression potential]
We may disable certain features in the 535 driver, or even have an
unusable driver, unless a proper workaround/solution is provided.
** Affects: nvidia-graphics-drivers-535 (Ubuntu)
Importance: Undecided
Status: New
** Affects: nvidia-graphics-drivers-535 (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: nvidia-graphics-drivers-535 (Ubuntu Noble)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-535 in Ubuntu.
https://bugs.launchpad.net/bugs/2049603
Title:
nvidia-dkms-535 FTBS on noble with the latest 6.7 kernel on arm64
Status in nvidia-graphics-drivers-535 package in Ubuntu:
New
Status in nvidia-graphics-drivers-535 source package in Noble:
New
Bug description:
[Impact]
It looks like nvidia-dkms-535 is using a symbol that became GPL-only
in the latest 6.7 kernel, causing the following build error:
# MODPOST <>/build/nvidia/535.146.02/build/Module.symvers
scripts/mod/modpost -M -m -a -o
<>/build/nvidia/535.146.02/build/Module.symvers -T
<>/build/nvidia/535.146.02/build/modules.order -i Module.symvers -e
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'screen_info'
This change was introduced by: b8466fe82b79 ("efi: move screen_info
into efi init code")
This happens only on arm64, where the symbol is defined.
[Fix]
Avoid using screen_info in the nvidia-dkms-535 driver.
[Regression potential]
We may disable certain features in the 535 driver, or even have an
unusable driver, unless a proper workaround/solution is provided.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-535/+bug/2049603/+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 2048758] [NEW] nvidia-dkms-535-server-open FTBS with the latest 6.7 kernel in noble
Public bug reported:
[Impact]
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:90:26: error:
implicit declaration of function ‘crypto_tfm_ctx_aligned’; did you mean
‘crypto_tfm_ctx_align’? [-Werror=implicit-function-declaration]
90 | char *src_ipad = crypto_tfm_ctx_aligned(_tfm->base);
| ^~
| crypto_tfm_ctx_align
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:90:26: warning:
initialization of ‘char *’ from ‘int’ makes pointer from integer without a cast
[-Wint-conversion]
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:91:26: warning:
initialization of ‘char *’ from ‘int’ makes pointer from integer without a cast
[-Wint-conversion]
91 | char *dst_ipad = crypto_tfm_ctx_aligned(_tfm->base);
| ^~
cc1: some warnings being treated as errors
[Test case]
$ sudo apt install nvidia-dkms-535-server-open
[Fix]
Upstream commit acd7799574e5 ("crypto: shash - remove
crypto_shash_ctx_aligned()") removed crypto_tfm_ctx_aligned() that is
used by the open variant of the driver.
Re-introduce this function (as a static inline) directly in the driver
(like the original one):
static inline void *crypto_tfm_ctx_aligned(struct crypto_tfm *tfm)
{
return crypto_tfm_ctx_align(tfm, crypto_tfm_alg_alignmask(tfm) + 1);
}
This should fix the build error, since crypto_tfm_ctx_align() is still
available in the kernel ABI.
[Regression potential]
We may experience graphics regressions in systems that are using the
open variant of the 535-server nvidia driver, especially with any 6.7
kernel.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: nvidia-dkms-535-server-open 535.129.03-0ubuntu1
ProcVersionSignature: User Name 6.7.0-5.5-generic 6.7.0-rc8
Uname: Linux 6.7.0-5-generic x86_64
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: unknown
CloudArchitecture: x86_64
CloudBuildName: server
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSerial: 20240101
CloudSubPlatform: config-disk (/dev/vdb)
Date: Tue Jan 9 08:54:19 2024
ProcEnviron:
LANG=C.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=
SourcePackage: nvidia-graphics-drivers-535-server
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: nvidia-graphics-drivers-535-server (Ubuntu)
Importance: Undecided
Status: New
** Affects: nvidia-graphics-drivers-535-server (Ubuntu Noble)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug cloud-image noble
** Also affects: nvidia-graphics-drivers-535-server (Ubuntu Noble)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-535-server in
Ubuntu.
https://bugs.launchpad.net/bugs/2048758
Title:
nvidia-dkms-535-server-open FTBS with the latest 6.7 kernel in noble
Status in nvidia-graphics-drivers-535-server package in Ubuntu:
New
Status in nvidia-graphics-drivers-535-server source package in Noble:
New
Bug description:
[Impact]
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:90:26: error:
implicit declaration of function ‘crypto_tfm_ctx_aligned’; did you mean
‘crypto_tfm_ctx_align’? [-Werror=implicit-function-declaration]
90 | char *src_ipad = crypto_tfm_ctx_aligned(_tfm->base);
| ^~
| crypto_tfm_ctx_align
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:90:26: warning:
initialization of ‘char *’ from ‘int’ makes pointer from integer without a cast
[-Wint-conversion]
/var/lib/dkms/nvidia/535.129.03/build/nvidia/libspdm_shash.c:91:26: warning:
initialization of ‘char *’ from ‘int’ makes pointer from integer without a cast
[-Wint-conversion]
91 | char *dst_ipad = crypto_tfm_ctx_aligned(_tfm->base);
| ^~
cc1: some warnings being treated as errors
[Test case]
$ sudo apt install nvidia-dkms-535-server-open
[Fix]
Upstream commit acd7799574e5 ("crypto: shash - remove
crypto_shash_ctx_aligned()") removed crypto_tfm_ctx_aligned() that is
used by the open variant of the driver.
Re-introduce this function (as a static inline) directly in the driver
(like the original one):
static inline void *crypto_tfm_ctx_aligned(struct crypto_tfm *tfm)
{
return crypto_tfm_ctx_align(tfm, crypto_tfm_alg_alignmask(tfm) + 1);
}
This should fix the build error, since crypto_tfm_ctx_align() is still
available in the kernel ABI.
[Regression potential]
We may experience graphics regressions in systems that are using the
open variant of the 535-server nvidia driver, especially with any 6.7
kernel.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
[Kernel-packages] [Bug 2046040] [NEW] enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble
Public bug reported: [Impact] Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. Linux 6.7 introduced the TDX support for the host to run confidential VMs (TDX guests). [Test case] We should probably define with Intel a proper test case to test this feature, since it requires special hardware/firmware support. [Fix] Enable CONFIG_INTEL_TDX_HOST in our generic kernel. [Regression potential] The TDX host support may introduce potential performance regressions, so we should probably do some performance evaluation with vs without CONFIG_INTEL_TDX_HOST enabled. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Package changed: linux-lowlatency (Ubuntu) => linux (Ubuntu) ** Also affects: linux (Ubuntu Noble) 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/2046040 Title: enable CONFIG_INTEL_TDX_HOST in linux >= 6.7 for noble Status in linux package in Ubuntu: New Status in linux source package in Noble: New Bug description: [Impact] Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. Linux 6.7 introduced the TDX support for the host to run confidential VMs (TDX guests). [Test case] We should probably define with Intel a proper test case to test this feature, since it requires special hardware/firmware support. [Fix] Enable CONFIG_INTEL_TDX_HOST in our generic kernel. [Regression potential] The TDX host support may introduce potential performance regressions, so we should probably do some performance evaluation with vs without CONFIG_INTEL_TDX_HOST enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2046040/+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 2045503] Re: apply sched-ext patch set to linux-unstable
** Description changed: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. Targeting linux-unstable only for now is probably a good compromise to allow users to start some experiments, collect feedbacks, help the upstream community to find and fix bugs and at the same time avoid to introduce too much maintenance burden on us. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests and custom scheduler implementations are available in tools/sched_ext or in https://github.com/sched-ext/scx. [Fix] Apply this patch set as SAUCE to linux-unstable: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ + On top of the patch set we want to apply also the following patches + (still as SAUCE): + + - UBUNTU: SAUCE: sched_ext: use proper atomic operator for scx.ops_state +(extra fix to properly build sched-ext on armhf) + + - UBUNTU: SAUCE: sched-ext: taint kernel when a custom scheduler is loaded +(set TAINT_OOT_MODULE in /proc/sys/kernel/tainted to easily determine when a custom scheduler has been used, that can be useful for bug reports: we can easily detect when a custom scheduler has been used and treat the bug report accordingly) + + - UBUNTU: [Config] enable sched_ext in annotations +(enable sched-ext in the config across all the supported architectures) + Soon there will be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux- unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). -- 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/2045503 Title: apply sched-ext patch set to linux-unstable Status in linux package in Ubuntu: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the
[Kernel-packages] [Bug 2045503] Re: apply sched-ext patch set to linux-unstable
** Description changed: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. + Targeting linux-unstable only for now is probably a good compromise to + allow users to start some experiments, collect feedbacks, help the + upstream community to find and fix bugs and at the same time avoid to + introduce too much maintenance burden on us. + [Test case] Basic test cases for this feature are provided by the sched-ext patch - set. Tests are available in tools/sched_ext. + set. Tests and custom scheduler implementations are available in + tools/sched_ext or in https://github.com/sched-ext/scx. [Fix] - Apply this patch set as SAUCE: + Apply this patch set as SAUCE to linux-unstable: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ - Soon there'll be a branch against any kernel that we need here (we will only need 6.7 for now): + Soon there will be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux- unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). -- 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/2045503 Title: apply sched-ext patch set to linux-unstable Status in linux package in Ubuntu: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can
[Kernel-packages] [Bug 2045503] [NEW] apply sched-ext patch set to linux-unstable
Public bug reported: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests are available in tools/sched_ext. [Fix] Apply this patch set as SAUCE: https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/ Soon there'll be a branch against any kernel that we need here (we will only need 6.7 for now): https://github.com/sched-ext/sched_ext [Regression potential] This feature is not going to be merged upstream in the near future, some upstream maintainers are worried that giving the possibility to inject in the kernel a custom scheduler can introduce performance regressions that are hard to track down. For this reason we should apply this feature only to linux-unstable for now, making sure that the patch is unapplied or reverted when linux- unstable becomes linux. In the meantime we can also figure out a reasonable way to determine when a custom scheduler is used (i.e., taint the kernel?) to easily determine when any potential performance regression may have been introduced by a custom sched-ext scheduler. From a maintenance perspective, having this patch set applied may also be problematic (potential conflicts) when we apply new stable updates. However, the upstream maintainers of sched-ext have expressed interest to help us maintaining the patch set against the target kernel(s) that we need. And targeting linux-unstable only can definitely mitigate the maintenance problem a lot (since we won't have the urgency to apply critical security fixes to linux-unstable). ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Summary changed: - apply sched-ext patch set to inux-unstable + apply sched-ext patch set to linux-unstable -- 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/2045503 Title: apply sched-ext patch set to linux-unstable Status in linux package in Ubuntu: New Bug description: [Impact] sched-ext is a new scheduling class introduced in the Linux kernel that provides a mechanism to implement scheduling policies as eBPF programs (https://lwn.net/Articles/922405/). Such programs can also be connected to user-space counterparts to defer scheduling decisions to regular user-space processes. The idea of "pluggable" schedulers is not new, it was initially proposed in 2004 (https://lwn.net/Articles/109458/), but at that time it was strongly rejected, to prioritize the creation of a single generic scheduler (one to rule them all), that ended up being the “completely fair scheduler” (CFS). However, with BPF and the sched-ext scheduling class, we now have the possibility to easily and quickly implement and test scheduling policies, making the “pluggable” approach an effective tool for easy experimentation. The ability to implement custom scheduling policies via BPF greatly lowers the difficulty of testing new scheduling ideas (much easier than changing CFS or replacing it with a different scheduler). With this feature researchers or developers can test their own scheduler in a safe way, without even needing to reboot the system. Shipping this feature in the Ubuntu kernel can provide a significant benefit to researchers and companies that want to experiment (or ship) their own scheduling policy, implemented as an eBPF/user-space program. [Test case] Basic test cases for this feature are provided by the sched-ext patch set. Tests are available in tools/sched_ext. [Fix] Apply this patch set as SAUCE:
[Kernel-packages] [Bug 2045492] [NEW] make lazy RCU a boot time option
Public bug reported: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't want to risk performance regressions. [Test case] In this context providing a single test case is not relevant. After applying the fix any performance benchmark can be used to evaluate if lazy RCU feature should be enabled at boot time or not (according to the specific context where the lowlatency kernel is going to be used/deployed). [Fix] Apply this patch to the *generic* kernel: https://lore.kernel.org/lkml/20231203011252.233748-1-qyou...@layalina.io/T/#u We want to apply this to the generic kernel, not just lowlatency, because in this way *all* derivatives will have the possibility to get this feature, in case some of them want to enable lazy RCUs (even generic itself). Then make sure that lowlatency (or any other kernel with CONFIG_RCU_LAZY=y) also has CONFIG_RCU_LAZY_DEFAULT_OFF not set (so that the previous behavior is not changed). [Regression potential] We may receive reports of small performance regressions vs power consumption regressions, depending on the rcutree.enable_rcu_lazy command line option that is used. In such case we should suggest the user to test both with lazy RCU disabled or enabled. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-lowlatency (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Affects: linux-lowlatency (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-lowlatency (Ubuntu Noble) Importance: Undecided Status: New ** Description changed: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't want to risk performance regressions. [Test case] In this context providing a single test case is not relevant. After applying the fix any performance benchmark can be used to evaluate if lazy RCU feature should be enabled at boot time or not (according to the specific context where the lowlatency kernel is going to be used/deployed). [Fix] Apply this patch to the *generic* kernel: https://lore.kernel.org/lkml/20231203011252.233748-1-qyou...@layalina.io/T/#u We want to apply this to the generic kernel, not just lowlatency, because in this way *all* derivatives will have the possibility to get this feature, in case some of them want to enable lazy RCUs (even generic itself). + Then make sure that lowlatency (or any other kernel with + CONFIG_RCU_LAZY=y) also has CONFIG_RCU_LAZY_DEFAULT_OFF not set (so that + the previous behavior is not changed). + [Regression potential] We may receive reports of small performance regressions vs power consumption regressions, depending on the rcutree.enable_rcu_lazy command line option that is used. In such case we should suggest the user to test both with lazy RCU disabled or enabled. ** Also 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-lowlatency in Ubuntu. https://bugs.launchpad.net/bugs/2045492 Title: make lazy RCU a boot time option Status in linux package in Ubuntu: New Status in linux-lowlatency package in Ubuntu: New Status in linux source package in Noble: New Status in linux-lowlatency source package in Noble: New Bug description: [Impact] With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the lowlatency kernel to improve power consumption, but this option can potentially introduce performance regressions in some cases, due to the fact that RCU callbacks are now batched and flushed all at once after a timed delay. It would be definitely safer to have a way to enable/disable lazy RCUs at boot time. In this way we could provide a simple kernel command line option that can be used in all those cases where the lowlatency kernel is required, but we don't
[Kernel-packages] [Bug 2038522] Re: disable shiftfs
shiftfs has been correctly disabled in 6.5.0-14: $ uname -r 6.5.0-14-generic $ sudo modprobe shiftfs modprobe: FATAL: Module shiftfs not found in directory /lib/modules/6.5.0-14-generic -- 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/2038522 Title: disable shiftfs Status in linux package in Ubuntu: Triaged Status in linux source package in Mantic: Fix Committed Bug description: [Impact] Now that all the filesystems that we officially support have the idmapped mounts capability we can get rid of shiftfs. The benefit of this change is that we don't have to maintain an out- of-tree filesystem anymore and we can completely rely on upstream features. [Test case] lxd was the main user of shiftfs to compensate the lack of idmapped mounts capability of certain filesystems, such as zfs / ceph, but now in mantic also these two filesystem received the support for idmapped mounts (support for zfs was introduced in 2.2.0~rc3 and for ceph see LP: #2032959). The lxd team provided a positive feedback, testing the latest 6.5 Mantic kernel across all the supported filesystems with shiftfs disabled. [Fix] Disable shiftfs in the kernel config and enable unsafe idmapped mounts by default (default=on). [Regression potential] The support for idmapped mounts for the ceph filesystem is not applied upstream yet, so we may experience regressions in systems that are using this filesystem. Moreover disabling shiftfs may trigger failures in our testing (testing shiftfs capabilities will obviously fail) or break any other user-space application that is relying on shiftfs (however to our knowledge lxd was the only "official" user or shiftfs; for this reason we may also see potential regressions in lxd). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038522/+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 2038522] Re: disable shiftfs
** Tags removed: verification-needed-mantic-linux ** Tags added: verification-done-mantic -- 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/2038522 Title: disable shiftfs Status in linux package in Ubuntu: Triaged Status in linux source package in Mantic: Fix Committed Bug description: [Impact] Now that all the filesystems that we officially support have the idmapped mounts capability we can get rid of shiftfs. The benefit of this change is that we don't have to maintain an out- of-tree filesystem anymore and we can completely rely on upstream features. [Test case] lxd was the main user of shiftfs to compensate the lack of idmapped mounts capability of certain filesystems, such as zfs / ceph, but now in mantic also these two filesystem received the support for idmapped mounts (support for zfs was introduced in 2.2.0~rc3 and for ceph see LP: #2032959). The lxd team provided a positive feedback, testing the latest 6.5 Mantic kernel across all the supported filesystems with shiftfs disabled. [Fix] Disable shiftfs in the kernel config and enable unsafe idmapped mounts by default (default=on). [Regression potential] The support for idmapped mounts for the ceph filesystem is not applied upstream yet, so we may experience regressions in systems that are using this filesystem. Moreover disabling shiftfs may trigger failures in our testing (testing shiftfs capabilities will obviously fail) or break any other user-space application that is relying on shiftfs (however to our knowledge lxd was the only "official" user or shiftfs; for this reason we may also see potential regressions in lxd). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038522/+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 2038611] Re: drop all references to is_rust_module.sh in kernels >= 6.5
This is still failing in mantic, "something" in our kernel cranking
process re-added the chmod command in debian.master/reconstruct for
is_rust_module.sh, this needs further investigation.
** Tags removed: verification-needed-mantic-linux
** Tags added: verification-failed-mantic
--
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/2038611
Title:
drop all references to is_rust_module.sh in kernels >= 6.5
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Mantic:
Fix Committed
Bug description:
[Impact]
The script tools/is_rust_module.sh has been dropped by this commit:
079c66bbe2f8 ("UBUNTU: SAUCE: btf, scripts: rust: drop
is_rust_module.sh")
And upstream as well (in 6.6):
41bdc6decda0 ("btf, scripts: rust: drop is_rust_module.sh")
But we still have a reference of it in debian.master/reconstruct and
that generates the following warning during the build:
chmod: cannot access 'scripts/is_rust_module.sh': No such file or
directory
[Fix]
Drop the reference to is_rust_module.sh from reconstruct to prevent
unnecessary warnings during the build.
[Test case]
The following command ran from the kernel source directory is enough
to trigger the warning:
$ fakeroot debian/rules clean
[Regression potential]
This change is affecting only our packaging. The change is trivial but
it might affect our kernel build process in case of regressions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038611/+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 2017413] Re: Dell XPS 13 Plus 9320 touchpad is not recognized
lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 uname -r 6.1.0-1025-oem sudo dmidecode -s bios-version 2.5.0 Touchpad firmware: 2023.06.05.519, A03 https://www.dell.com/support/home/it-it/drivers/driversdetails?driverid=twdxv=ubt22=xps-13-9320-laptop Update-ath8124_tributo-82023-06-05-519-RDP2-E1 When I resume the computer after it suspended, the touchpad is not anymore functional: I can move the pointer a round, but I can't click. The touchpad sometimes becomes functional by itself by waiting for some time. If I reboot the computer, the touchpad is always functional. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2017413 Title: Dell XPS 13 Plus 9320 touchpad is not recognized Status in linux-signed-hwe-5.19 package in Ubuntu: Confirmed Bug description: lsb_release -rd Description: Ubuntu 22.04.2 LTS Release: 22.04 uname -r 5.19.0-40-generic The touchpad (VEN_04F3:00 04F3:31D1) stops working intermittently when resumed from hibernate or after a reboot. In most cases, it seems that the kernel fails to recognize it. Issue also appears with older kernels all the way up to v5.15. During boot, the following error appears: i2c_hid_acpi i2c-VEN_04F3:00 failed to reset device: -61 Dell touchpad firmware has been updated to the latest version 2023.04.03.423, A02 (as of 23-04-2023, issue still persists): https://www.dell.com/support/home/en-uk/drivers/driversdetails?driverid=yd0v6=ubt22=xps-13-9320-laptop Dell BIOS has been updated to the latest version 2.1.0 (as of 23-04-2023, issue still persists): https://www.dell.com/support/home/en-uk/drivers/driversdetails?driverid=mh38g=ubt22=xps-13-9320-laptop Switching from Wayland to X11 also has no effect. Also adding the following to grub does not help: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0 i8042.nopnp=1 pci=nocrs" Device info has been added as an attachment. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-40-generic 5.19.0-40.41~22.04.1 ProcVersionSignature: Ubuntu 5.19.0-40.41~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Apr 23 11:02:54 2023 InstallationDate: Installed on 2023-04-22 (0 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) SourcePackage: linux-signed-hwe-5.19 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.19/+bug/2017413/+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 2039010] [NEW] revert support for arbitrary symbol length in modversion in hwe kernels
Public bug reported: The following patch may break user-space, providing an actual ABI change: UBUNTU: SAUCE: modpost: support arbitrary symbol length in modversion This is not critical for new releases (also considering that the potential breakage is unlikely to happen, unless some tools/scripts/apps are inspecting modules' internals - likely only kmod tools, that are ok with this change), but for LTS releases it is just safer to prevent adding this change. Keep in mind that this patch is required to enable Rust support in the generic kernel, but it is not required for hwe kernels, because we do not enable Rust support for them. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) 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/2039010 Title: revert support for arbitrary symbol length in modversion in hwe kernels Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Bug description: The following patch may break user-space, providing an actual ABI change: UBUNTU: SAUCE: modpost: support arbitrary symbol length in modversion This is not critical for new releases (also considering that the potential breakage is unlikely to happen, unless some tools/scripts/apps are inspecting modules' internals - likely only kmod tools, that are ok with this change), but for LTS releases it is just safer to prevent adding this change. Keep in mind that this patch is required to enable Rust support in the generic kernel, but it is not required for hwe kernels, because we do not enable Rust support for them. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039010/+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 2039009] [NEW] do not ship ZSTD compressed modules in jammy/hwe-6.5 kernels
Public bug reported: Providing zstd compressed modules may break user-space scripts/tools/binaries that are relying on the .ko naming schema. The kernel can still support ZSTD compressed modules (via CONFIG_MODULE_COMPRESS_ZSTD), but our shipped kernel modules will be just regular .ko files. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) 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/2039009 Title: do not ship ZSTD compressed modules in jammy/hwe-6.5 kernels Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Bug description: Providing zstd compressed modules may break user-space scripts/tools/binaries that are relying on the .ko naming schema. The kernel can still support ZSTD compressed modules (via CONFIG_MODULE_COMPRESS_ZSTD), but our shipped kernel modules will be just regular .ko files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039009/+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 2038611] Re: drop all references to is_rust_module.sh in kernels >= 6.5
** Also affects: linux (Ubuntu Mantic)
Importance: Undecided
Status: Incomplete
--
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/2038611
Title:
drop all references to is_rust_module.sh in kernels >= 6.5
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Mantic:
Incomplete
Bug description:
[Impact]
The script tools/is_rust_module.sh has been dropped by this commit:
079c66bbe2f8 ("UBUNTU: SAUCE: btf, scripts: rust: drop
is_rust_module.sh")
And upstream as well (in 6.6):
41bdc6decda0 ("btf, scripts: rust: drop is_rust_module.sh")
But we still have a reference of it in debian.master/reconstruct and
that generates the following warning during the build:
chmod: cannot access 'scripts/is_rust_module.sh': No such file or
directory
[Fix]
Drop the reference to is_rust_module.sh from reconstruct to prevent
unnecessary warnings during the build.
[Test case]
The following command ran from the kernel source directory is enough
to trigger the warning:
$ fakeroot debian/rules clean
[Regression potential]
This change is affecting only our packaging. The change is trivial but
it might affect our kernel build process in case of regressions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038611/+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 2038611] [NEW] drop all references to is_rust_module.sh in kernels >= 6.5
Public bug reported:
[Impact]
The script tools/is_rust_module.sh has been dropped by this commit:
079c66bbe2f8 ("UBUNTU: SAUCE: btf, scripts: rust: drop
is_rust_module.sh")
And upstream as well (in 6.6):
41bdc6decda0 ("btf, scripts: rust: drop is_rust_module.sh")
But we still have a reference of it in debian.master/reconstruct and
that generates the following warning during the build:
chmod: cannot access 'scripts/is_rust_module.sh': No such file or
directory
[Fix]
Drop the reference to is_rust_module.sh from reconstruct to prevent
unnecessary warnings during the build.
[Test case]
The following command ran from the kernel source directory is enough to
trigger the warning:
$ fakeroot debian/rules clean
[Regression potential]
This change is affecting only our packaging. The change is trivial but
it might affect our kernel build process in case of regressions.
** Affects: linux (Ubuntu)
Importance: Medium
Status: Incomplete
** Affects: linux (Ubuntu Mantic)
Importance: Medium
Status: Incomplete
--
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/2038611
Title:
drop all references to is_rust_module.sh in kernels >= 6.5
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Mantic:
Incomplete
Bug description:
[Impact]
The script tools/is_rust_module.sh has been dropped by this commit:
079c66bbe2f8 ("UBUNTU: SAUCE: btf, scripts: rust: drop
is_rust_module.sh")
And upstream as well (in 6.6):
41bdc6decda0 ("btf, scripts: rust: drop is_rust_module.sh")
But we still have a reference of it in debian.master/reconstruct and
that generates the following warning during the build:
chmod: cannot access 'scripts/is_rust_module.sh': No such file or
directory
[Fix]
Drop the reference to is_rust_module.sh from reconstruct to prevent
unnecessary warnings during the build.
[Test case]
The following command ran from the kernel source directory is enough
to trigger the warning:
$ fakeroot debian/rules clean
[Regression potential]
This change is affecting only our packaging. The change is trivial but
it might affect our kernel build process in case of regressions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038611/+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 2038522] [NEW] disable shiftfs
Public bug reported: [Impact] Now that all the filesystems that we officially support have the idmapped mounts capability we can get rid of shiftfs. The benefit of this change is that we don't have to maintain an out-of- tree filesystem anymore and we can completely rely on upstream features. [Test case] lxd was the main user of shiftfs to compensate the lack of idmapped mounts capability of certain filesystems, such as zfs / ceph, but now in mantic also these two filesystem received the support for idmapped mounts (support for zfs was introduced in 2.2.0~rc3 and for ceph see LP: #2032959). The lxd team provided a positive feedback, testing the latest 6.5 Mantic kernel across all the supported filesystems with shiftfs disabled. [Fix] Disable shiftfs in the kernel config and enable unsafe idmapped mounts by default (default=on). [Regression potential] The support for idmapped mounts for the ceph filesystem is not applied upstream yet, so we may experience regressions in systems that are using this filesystem. Moreover disabling shiftfs may trigger failures in our testing (testing shiftfs capabilities will obviously fail) or break any other user-space application that is relying on shiftfs (however to our knowledge lxd was the only "official" user or shiftfs; for this reason we may also see potential regressions in lxd). ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) 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/2038522 Title: disable shiftfs Status in linux package in Ubuntu: New Status in linux source package in Mantic: New Bug description: [Impact] Now that all the filesystems that we officially support have the idmapped mounts capability we can get rid of shiftfs. The benefit of this change is that we don't have to maintain an out- of-tree filesystem anymore and we can completely rely on upstream features. [Test case] lxd was the main user of shiftfs to compensate the lack of idmapped mounts capability of certain filesystems, such as zfs / ceph, but now in mantic also these two filesystem received the support for idmapped mounts (support for zfs was introduced in 2.2.0~rc3 and for ceph see LP: #2032959). The lxd team provided a positive feedback, testing the latest 6.5 Mantic kernel across all the supported filesystems with shiftfs disabled. [Fix] Disable shiftfs in the kernel config and enable unsafe idmapped mounts by default (default=on). [Regression potential] The support for idmapped mounts for the ceph filesystem is not applied upstream yet, so we may experience regressions in systems that are using this filesystem. Moreover disabling shiftfs may trigger failures in our testing (testing shiftfs capabilities will obviously fail) or break any other user-space application that is relying on shiftfs (however to our knowledge lxd was the only "official" user or shiftfs; for this reason we may also see potential regressions in lxd). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038522/+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 2038437] Re: mantic:linux ubuntu_qrt_kernel_security.KernelSecurityTest.test_082_stack_guard_kernel: Could not find a suitable kernel module to test
Patch in attach (against qa-regression-testing) allows to fix this issue. ** Patch added: "0001-scripts-test-kernel-security.py-support-zstd-compres.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038437/+attachment/5706797/+files/0001-scripts-test-kernel-security.py-support-zstd-compres.patch -- 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/2038437 Title: mantic:linux ubuntu_qrt_kernel_security.KernelSecurityTest.test_082_stack_guard_kernel: Could not find a suitable kernel module to test Status in linux package in Ubuntu: Triaged Status in linux source package in Mantic: Triaged Bug description: Running the ubuntu_qrt_kernel_security suite as part of the linux (selftest) suite produces the following error: stdout: Running test: './test-kernel-security.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-7.7 (Ubuntu 6.5.0-7.7-generic 6.5.3)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') stderr: test_082_stack_guard_kernel (__main__.KernelSecurityTest.test_082_stack_guard_kernel) Kernel stack guard ... FAIL == FAIL: test_082_stack_guard_kernel (__main__.KernelSecurityTest.test_082_stack_guard_kernel) Kernel stack guard -- Traceback (most recent call last): File "/tmp/autopkgtest.Si3gP4/build.moT/src/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/./test-kernel-security.py", line 758, in test_082_stack_guard_kernel self.assertTrue(module, 'Could not find a suitable kernel module to test') AssertionError: '' is not true : Could not find a suitable kernel module to test There is no clear indication which module(s) are attempted but probably those got renamed or this is due to compressing the modules resulting in different filename extensions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2038437/+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 2035588] [NEW] Mantic update: v6.5.3 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.5.3 upstream stable release from git://git.kernel.org/ Linux 6.5.3 drm/amd/display: Block optimize on consecutive FAMS enables revert "memfd: improve userspace warnings for missing exec-related flags". memfd: improve userspace warnings for missing exec-related flags memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2 selftests/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED mm/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED serial: sc16is7xx: fix regression with GPIO configuration serial: sc16is7xx: remove obsolete out_thread label Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED Bluetooth: msft: Extended monitor tracking by address filter media: ipu3-cio2: allow ipu_bridge to be a module again perf/x86/uncore: Correct the number of CHAs on EMR x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld x86/sgx: Break up long non-preemptible delays in sgx_vepc_release() x86/smp: Don't send INIT to non-present and non-booted CPUs USB: core: Fix oversight in SuperSpeed initialization of: property: fw_devlink: Add a devlink for panel followers cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug crypto: stm32 - fix MDMAT condition crypto: stm32 - fix loop iterating through scatterlist for DMA HID: logitech-hidpp: rework one more time the retries attempts s390/dasd: fix string length handling s390/ipl: add missing secure/has_secure file to ipl type 'unknown' s390/dcssblk: fix kernel crash with list_add corruption RISC-V: Add ptrace support for vectors iov_iter: Fix iov_iter_extract_pages() with zero-sized entries regulator: dt-bindings: qcom,rpm: fix pattern for children arm64: sdei: abort running SDEI handlers during crash pstore/ram: Check start of empty przs during init mmc: renesas_sdhi: register irqs before registering controller platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFER crypto: af_alg - Decrement struct key.usage in alg_set_by_key_serial() x86/MCE: Always save CS register on AMD Zen IF Poison errors fsverity: skip PKCS#7 parser when keyring is empty net: handle ARPHRD_PPP in dev_is_mac_header_xmit() X.509: if signature is unsupported skip validation r8169: fix ASPM-related issues on a number of systems with NIC version from RTL8168h x86/sev: Make enc_dec_hypercall() accept a size instead of npages dccp: Fix out of bounds access in DCCP error handler dlm: fix plock lookup when using multiple lockspaces bpf: Fix issue in verifying allow_ptr_leaks drm/amd/display: Add smu write msg id fail retry process misc: fastrpc: Pass proper scm arguments for static process init parisc: Fix /proc/cpuinfo output for lscpu procfs: block chmod on /proc/thread-self/comm block: don't add or resize partition on the disk with GENHD_FL_NO_PART block: fix pin count management when merging same-page segments Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset" ntb: Fix calculation ntb_transport_tx_free_entry() ntb: Clean up tx tail index on link down ntb: Drop packets when qp link is down dt-bindings: PCI: qcom: Fix SDX65 compatible PCI/PM: Only read PCI_PM_CTRL register when available PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation PCI: Free released resource after coalescing scsi: mpt3sas: Perform additional retries if doorbell read returns 0 Revert "scsi: qla2xxx: Fix buffer overrun" media: nxp: Fix wrong return pointer check in mxc_isi_crossbar_init() media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts media: dvb: symbol fixup for dvb_attach() selftests/landlock: Fix a resource leak ALSA: hda/cirrus: Fix broken audio on hardware with two CS42L42 codecs. ALSA: seq: Fix snd_seq_expand_var_event() call to user-space ALSA: usb-audio: Fix potential memory leaks at error path for UMP open arm64: csum: Fix OoB access in IP checksum code for negative lengths io_uring: Don't set affinity on a dying sqpoll thread i3c: master: svc: fix probe failure when no i3c device exist powerpc/ftrace: Fix dropping weak symbols with older toolchains powercap: intel_rapl: Fix invalid setting of Power Limit 4 LoongArch: mm: Add p?d_leaf() definitions xtensa: PMU: fix base address for the newer hardware drm/amd/display: register edp_backlight_control() for DCN301 backlight/lv5207lp: Compare against struct fb_info.device backlight/bd6107: Compare against struct fb_info.device backlight/gpio_backlight: Compare against struct fb_info.device io_uring: break out of iowq iopoll on
[Kernel-packages] [Bug 2035583] [NEW] Mantic update: v6.5.2 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.5.2 upstream stable release from git://git.kernel.org/ Linux 6.5.2 pinctrl: amd: Don't show `Invalid config param` errors usb: typec: tcpci: clear the fault status bit nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse tracing: Zero the pipe cpumask on alloc to avoid spurious -EBUSY dt-bindings: sc16is7xx: Add property to change GPIO function tcpm: Avoid soft reset when partner does not support get_status fsi: master-ast-cf: Add MODULE_FIRMWARE macro firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probe serial: sc16is7xx: fix bug when first setting GPIO direction serial: sc16is7xx: fix broken port 0 uart init serial: qcom-geni: fix opp vote on shutdown wifi: ath11k: Cleanup mac80211 references on failure during tx_complete wifi: ath11k: Don't drop tx_status when peer cannot be found wifi: rtw88: usb: kill and free rx urbs on probe failure wifi: mt76: mt7921: fix skb leak by txs missing in AMSDU wifi: mt76: mt7921: do not support one stream on secondary antenna only staging: rtl8712: fix race condition HID: wacom: remove the battery when the EKR is off usb: chipidea: imx: improve logic if samsung,picophy-* parameter is 0 usb: dwc3: meson-g12a: do post init to fix broken usb after resumption ALSA: usb-audio: Fix init call orders for UAC1 USB: serial: option: add FOXCONN T99W368/T99W373 product USB: serial: option: add Quectel EM05G variant (0x030e) modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules rtc: ds1685: use EXPORT_SYMBOL_GPL for ds1685_rtc_poweroff net: enetc: use EXPORT_SYMBOL_GPL for enetc_phc_index mmc: au1xmmc: force non-modular build and remove symbol_get usage ARM: pxa: remove use of symbol_get() ksmbd: reduce descriptor size if remaining bytes is less than request size ksmbd: replace one-element array with flex-array member in struct smb2_ea_info ksmbd: fix slub overflow in ksmbd_decode_ntlmssp_auth_blob() ksmbd: fix wrong DataOffset validation of create context erofs: ensure that the post-EOF tails are all zeroed drm/amdgpu: correct vmhub index in GMC v10/11 ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: Confirmed ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: 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/2035583 Title: Mantic update: v6.5.2 upstream stable release Status in linux package in Ubuntu: Confirmed Status in linux source package in Mantic: Confirmed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.5.2 upstream stable release from git://git.kernel.org/ Linux 6.5.2 pinctrl: amd: Don't show `Invalid config param` errors usb: typec: tcpci: clear the fault status bit nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse tracing: Zero the pipe cpumask on alloc to avoid spurious -EBUSY dt-bindings: sc16is7xx: Add property to change GPIO function tcpm: Avoid soft reset when partner does not support get_status fsi: master-ast-cf: Add MODULE_FIRMWARE macro firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probe serial: sc16is7xx: fix bug when first setting GPIO direction serial: sc16is7xx: fix broken port 0 uart init serial: qcom-geni: fix opp vote on shutdown wifi: ath11k: Cleanup mac80211 references on failure during tx_complete wifi: ath11k: Don't drop tx_status when peer cannot be found wifi: rtw88: usb: kill and free rx urbs on probe failure wifi: mt76: mt7921: fix skb leak by txs missing in AMSDU wifi: mt76: mt7921: do not support one stream on secondary antenna only staging: rtl8712: fix race condition HID: wacom: remove the battery when the EKR is off usb: chipidea: imx: improve logic if samsung,picophy-*
[Kernel-packages] [Bug 2035581] [NEW] Mantic update: v6.5.1 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.5.1 upstream stable release from git://git.kernel.org/ ACPI: thermal: Drop nocrt parameter module: Expose module_init_layout_section() arm64: module: Use module_init_layout_section() to spot init sections ARM: module: Use module_init_layout_section() to spot init sections ipv6: remove hard coded limitation on ipv6_pinfo lockdep: fix static memory detection even more kallsyms: Fix kallsyms_selftest failure Linux 6.5.1 ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: Confirmed ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: Confirmed ** Description changed: + SRU Justification - SRU Justification + Impact: + The upstream process for stable tree updates is quite similar + in scope to the Ubuntu SRU process, e.g., each patch has to + demonstrably fix a bug, and each patch is vetted by upstream + by originating either directly from a mainline/stable Linux tree or + a minimally backported form of that patch. The following upstream + stable patches should be included in the Ubuntu kernel: - Impact: -The upstream process for stable tree updates is quite similar -in scope to the Ubuntu SRU process, e.g., each patch has to -demonstrably fix a bug, and each patch is vetted by upstream -by originating either directly from a mainline/stable Linux tree or -a minimally backported form of that patch. The following upstream -stable patches should be included in the Ubuntu kernel: + v6.5.1 upstream stable release + from git://git.kernel.org/ -v6.5.1 upstream stable release -from git://git.kernel.org/ + + ACPI: thermal: Drop nocrt parameter + module: Expose module_init_layout_section() + arm64: module: Use module_init_layout_section() to spot init sections + ARM: module: Use module_init_layout_section() to spot init sections + ipv6: remove hard coded limitation on ipv6_pinfo + lockdep: fix static memory detection even more + kallsyms: Fix kallsyms_selftest failure + Linux 6.5.1 -- 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/2035581 Title: Mantic update: v6.5.1 upstream stable release Status in linux package in Ubuntu: Confirmed Status in linux source package in Mantic: Confirmed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.5.1 upstream stable release from git://git.kernel.org/ ACPI: thermal: Drop nocrt parameter module: Expose module_init_layout_section() arm64: module: Use module_init_layout_section() to spot init sections ARM: module: Use module_init_layout_section() to spot init sections ipv6: remove hard coded limitation on ipv6_pinfo lockdep: fix static memory detection even more kallsyms: Fix kallsyms_selftest failure Linux 6.5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2035581/+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 2030525] Re: Installation support for SMARC RZ/G2L platform
** Changed in: linux (Ubuntu Mantic) Status: Confirmed => Fix Committed -- 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/2030525 Title: Installation support for SMARC RZ/G2L platform Status in linux package in Ubuntu: Fix Committed Status in linux source package in Focal: New Status in linux source package in Jammy: New Status in linux source package in Lunar: New Status in linux source package in Mantic: Fix Committed Bug description: Dear Maintainer The Ubuntu installation on Renesas RZ/G2L platform board is failing due to the following configuration: https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/tree/debian.master/config/annotations#n10339 The configuration CONFIG_RESET_RZG2L_USBPHY_CTRL=y is required to allow the installation on Renesas SMARC platform. Alternatively, the module "reset-rzg2l-usbphy-ctrl.ko" to be added in the inside installer initrd. This change is required on Lunar and Jammy versions as well. Please update once the changes merged to test them on Renesas SMARC RZ/G2L platform. Best Regards John To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2030525/+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 2034510] Re: spl fails to unregister sysctl entries
Attached debdiff seems to fix the bug (reproduced and tested in a local VM with the latest Mantic 6.5 kernel). ** Patch added: "spl-fix.debdiff" https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2034510/+attachment/5697900/+files/spl-fix.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2034510 Title: spl fails to unregister sysctl entries Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] On unload the spl module is not properly cleaning up the registered sysctl entries with kernel 6.5 in Mantic: 06:58 ubuntu@mantic$ sudo modprobe spl modprobe: ERROR: could not insert 'spl': Protocol driver not attached 06:58 ubuntu@mantic$ sudo dmesg | grep duplicate [ 152.587197] sysctl duplicate entry: /kernel/spl/kmem/slab_kvmem_total [Test case] Uninstall zfsutils-linux and try to `modprobe -r zfs; modprobe -r spl`, then `modprobe zfs` again and you should see the error (with a failure to load spl again). At this point it is possible to load spl again only after a reboot. [Fix] Properly cleanup all the registered sysctl entries when the spl module is unloaded. [Regression potential] We may experience regressions in systems that are using zfs with the 6.5 kernel. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: zfs-dkms 2.2.0~rc3-0ubuntu3 ProcVersionSignature: User Name 6.5.0-4.4-generic 6.5.0 Uname: Linux 6.5.0-4-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20230823 CloudSubPlatform: config-disk (/dev/vdb) Date: Wed Sep 6 07:06:33 2023 PackageArchitecture: all ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: zfs-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2034510/+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 2034510] Re: spl fails to unregister sysctl entries
Upstream pull request to fix this issue: https://github.com/openzfs/zfs/pull/15239 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2034510 Title: spl fails to unregister sysctl entries Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] On unload the spl module is not properly cleaning up the registered sysctl entries with kernel 6.5 in Mantic: 06:58 ubuntu@mantic$ sudo modprobe spl modprobe: ERROR: could not insert 'spl': Protocol driver not attached 06:58 ubuntu@mantic$ sudo dmesg | grep duplicate [ 152.587197] sysctl duplicate entry: /kernel/spl/kmem/slab_kvmem_total [Test case] Uninstall zfsutils-linux and try to `modprobe -r zfs; modprobe -r spl`, then `modprobe zfs` again and you should see the error (with a failure to load spl again). At this point it is possible to load spl again only after a reboot. [Fix] Properly cleanup all the registered sysctl entries when the spl module is unloaded. [Regression potential] We may experience regressions in systems that are using zfs with the 6.5 kernel. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: zfs-dkms 2.2.0~rc3-0ubuntu3 ProcVersionSignature: User Name 6.5.0-4.4-generic 6.5.0 Uname: Linux 6.5.0-4-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20230823 CloudSubPlatform: config-disk (/dev/vdb) Date: Wed Sep 6 07:06:33 2023 PackageArchitecture: all ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: zfs-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2034510/+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 2034510] [NEW] spl fails to unregister sysctl entries
Public bug reported: [Impact] On unload the spl module is not properly cleaning up the registered sysctl entries with kernel 6.5 in Mantic: 06:58 ubuntu@mantic$ sudo modprobe spl modprobe: ERROR: could not insert 'spl': Protocol driver not attached 06:58 ubuntu@mantic$ sudo dmesg | grep duplicate [ 152.587197] sysctl duplicate entry: /kernel/spl/kmem/slab_kvmem_total [Test case] Uninstall zfsutils-linux and try to `modprobe -r zfs; modprobe -r spl`, then `modprobe zfs` again and you should see the error (with a failure to load spl again). At this point it is possible to load spl again only after a reboot. [Fix] Properly cleanup all the registered sysctl entries when the spl module is unloaded. [Regression potential] We may experience regressions in systems that are using zfs with the 6.5 kernel. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: zfs-dkms 2.2.0~rc3-0ubuntu3 ProcVersionSignature: User Name 6.5.0-4.4-generic 6.5.0 Uname: Linux 6.5.0-4-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20230823 CloudSubPlatform: config-disk (/dev/vdb) Date: Wed Sep 6 07:06:33 2023 PackageArchitecture: all ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: zfs-linux UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New ** Affects: zfs-linux (Ubuntu Mantic) Importance: Undecided Status: New ** Tags: amd64 apport-bug cloud-image mantic third-party-packages ** Also affects: zfs-linux (Ubuntu Mantic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2034510 Title: spl fails to unregister sysctl entries Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] On unload the spl module is not properly cleaning up the registered sysctl entries with kernel 6.5 in Mantic: 06:58 ubuntu@mantic$ sudo modprobe spl modprobe: ERROR: could not insert 'spl': Protocol driver not attached 06:58 ubuntu@mantic$ sudo dmesg | grep duplicate [ 152.587197] sysctl duplicate entry: /kernel/spl/kmem/slab_kvmem_total [Test case] Uninstall zfsutils-linux and try to `modprobe -r zfs; modprobe -r spl`, then `modprobe zfs` again and you should see the error (with a failure to load spl again). At this point it is possible to load spl again only after a reboot. [Fix] Properly cleanup all the registered sysctl entries when the spl module is unloaded. [Regression potential] We may experience regressions in systems that are using zfs with the 6.5 kernel. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: zfs-dkms 2.2.0~rc3-0ubuntu3 ProcVersionSignature: User Name 6.5.0-4.4-generic 6.5.0 Uname: Linux 6.5.0-4-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20230823 CloudSubPlatform: config-disk (/dev/vdb) Date: Wed Sep 6 07:06:33 2023 PackageArchitecture: all ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: zfs-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2034510/+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 1930783] Re: integrity: Problem loading X.509 certificate
Also affects: Computer: Acer Nitro 515 Ubuntu version: Ubuntu 22.04.2 LTS Kernel: linux-image-5.19.0-35-generic -- 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/1930783 Title: integrity: Problem loading X.509 certificate Status in linux package in Ubuntu: Confirmed Bug description: Following error shows on Acer machines while booting when UEFI boot is enabled. integrity: Problem loading X.509 certificate -65 The issue is discussed at https://bugzilla.opensuse.org/show_bug.cgi?id=1129471 and a patch is available at https://lkml.org/lkml/2019/7/16/23. Seems like this patch is not included in Ubuntu as I'm still getting this error. I'm using Linux Mint 20, which is based on Ubuntu 20.04. This error comes while live booting Ubuntu 20.04 and Ubuntu 18.04 also. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1930783/+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 2033385] Re: zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic
Add LP bug reference to the changelog. ** Patch added: "zfs-fix-ubsan-warnings.debdiff" https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2033385/+attachment/5696048/+files/zfs-fix-ubsan-warnings.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2033385 Title: zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] When the zfs module is loaded we can see the following errors in dmesg with the latest 6.5 kernel in mantic: [ 10.730318] UBSAN: array-index-out-of-bounds in /build/mantic/debian/build/build-generic/___dkms/build/zfs/2.2.0~rc3/build/module/zfs/vdev_raidz_math_impl.h:1475:22 [ 10.734075] index 6 is out of range for type 'raidz_col_t [*]' [Test case] $ sudo apt install zfs-dkms [Fix] Apply this patch to properly support varlen arrays and prevent the UBSAN warnings: https://github.com/ckane/zfs/commit/095a435cd5129b25ebc1b090613b73059719bae5 [Regression potential] This change is limited to ZFS, so we may experience regressions in those systems that are using ZFS filesystems or zpool volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2033385/+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 2033385] Re: zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic
debdiff in attach fixes the UBSAN warnings with linux 6.5 on mantic. ** Patch added: "zfs-fix-ubsan-warnings.debdiff" https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2033385/+attachment/5696047/+files/zfs-fix-ubsan-warnings.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2033385 Title: zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] When the zfs module is loaded we can see the following errors in dmesg with the latest 6.5 kernel in mantic: [ 10.730318] UBSAN: array-index-out-of-bounds in /build/mantic/debian/build/build-generic/___dkms/build/zfs/2.2.0~rc3/build/module/zfs/vdev_raidz_math_impl.h:1475:22 [ 10.734075] index 6 is out of range for type 'raidz_col_t [*]' [Test case] $ sudo apt install zfs-dkms [Fix] Apply this patch to properly support varlen arrays and prevent the UBSAN warnings: https://github.com/ckane/zfs/commit/095a435cd5129b25ebc1b090613b73059719bae5 [Regression potential] This change is limited to ZFS, so we may experience regressions in those systems that are using ZFS filesystems or zpool volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2033385/+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 2033385] [NEW] zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic
Public bug reported: [Impact] When the zfs module is loaded we can see the following errors in dmesg with the latest 6.5 kernel in mantic: [ 10.730318] UBSAN: array-index-out-of-bounds in /build/mantic/debian/build/build-generic/___dkms/build/zfs/2.2.0~rc3/build/module/zfs/vdev_raidz_math_impl.h:1475:22 [ 10.734075] index 6 is out of range for type 'raidz_col_t [*]' [Test case] $ sudo apt install zfs-dkms [Fix] Apply this patch to properly support varlen arrays and prevent the UBSAN warnings: https://github.com/ckane/zfs/commit/095a435cd5129b25ebc1b090613b73059719bae5 [Regression potential] This change is limited to ZFS, so we may experience regressions in those systems that are using ZFS filesystems or zpool volumes. ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New ** Affects: zfs-linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu Mantic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/2033385 Title: zfs-dkms UBSAN array-out-of-bounds warning with kernel 6.5 on mantic Status in zfs-linux package in Ubuntu: New Status in zfs-linux source package in Mantic: New Bug description: [Impact] When the zfs module is loaded we can see the following errors in dmesg with the latest 6.5 kernel in mantic: [ 10.730318] UBSAN: array-index-out-of-bounds in /build/mantic/debian/build/build-generic/___dkms/build/zfs/2.2.0~rc3/build/module/zfs/vdev_raidz_math_impl.h:1475:22 [ 10.734075] index 6 is out of range for type 'raidz_col_t [*]' [Test case] $ sudo apt install zfs-dkms [Fix] Apply this patch to properly support varlen arrays and prevent the UBSAN warnings: https://github.com/ckane/zfs/commit/095a435cd5129b25ebc1b090613b73059719bae5 [Regression potential] This change is limited to ZFS, so we may experience regressions in those systems that are using ZFS filesystems or zpool volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2033385/+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 2028253] Re: update apparmor and LSM stacking patch set
** Changed in: linux (Ubuntu Mantic) Status: Confirmed => Fix Committed -- 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/2028253 Title: update apparmor and LSM stacking patch set Status in linux package in Ubuntu: Fix Committed Status in linux source package in Mantic: Fix Committed Bug description: [Impact] Provide an updated patch set for apparmor / LSM stacking with all the custom features that we need in the Ubuntu kernel. This patch set is required to provide the proper confinement with snaps and other Ubuntu-specific security features. [Fix] Apply the latest updated patch set from: https://gitlab.com/jjohansen/apparmor-kernel [Test case] Run the apparmor test case suite. [Regression potential] This patch set introduces significant non-upstream changes to the security layer, so we may expect generic regressions in the kernel, especially running applications that are stressing the security layer (such as systemd, snapd, lxd, etc.). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028253/+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 2028791] [NEW] Mantic update: v6.4.6 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.6 upstream stable release from git://git.kernel.org/ Linux 6.4.6 x86/cpu/amd: Add a Zenbleed fix x86/cpu/amd: Move the errata checking functionality up ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: Confirmed ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: 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/2028791 Title: Mantic update: v6.4.6 upstream stable release Status in linux package in Ubuntu: Confirmed Status in linux source package in Mantic: Confirmed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.6 upstream stable release from git://git.kernel.org/ Linux 6.4.6 x86/cpu/amd: Add a Zenbleed fix x86/cpu/amd: Move the errata checking functionality up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028791/+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 2028790] [NEW] Mantic update: v6.4.5 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.5 upstream stable release from git://git.kernel.org/ Linux 6.4.5 net/ncsi: change from ndo_set_mac_address to dev_set_mac_address net/ncsi: make one oem_gma function for all mfr id drm/atomic: Fix potential use-after-free in nonblocking commits Revert "drm/amd: Disable PSR-SU on Parade 0803 TCON" MIPS: kvm: Fix build error with KVM_MIPS_DEBUG_COP0_COUNTERS enabled net: dsa: ocelot: unlock on error in vsc9959_qos_port_tas_set() scsi: qla2xxx: Fix end of loop test scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue scsi: qla2xxx: Pointer may be dereferenced scsi: qla2xxx: Correct the index of array scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport() scsi: qla2xxx: Fix potential NULL pointer dereference scsi: qla2xxx: Fix buffer overrun scsi: qla2xxx: Avoid fcport pointer dereference scsi: qla2xxx: Array index may go out of bound scsi: qla2xxx: Fix mem access after free scsi: qla2xxx: Wait for io return on terminate rport scsi: qla2xxx: Fix hang in task management scsi: qla2xxx: Fix task management cmd fail due to unavailable resource scsi: qla2xxx: Fix task management cmd failure scsi: qla2xxx: Multi-que support for TMF tracing/user_events: Fix struct arg size match check tracing/probes: Fix to record 0-length data_loc in fetch_store_string*() if fails Revert "tracing: Add "(fault)" name injection to kernel probes" tracing/probes: Fix to update dynamic data counter if fetcharg uses it tracing/probes: Fix not to count error code to total length tracing/probes: Fix to avoid double count of the string length on the array smb: client: Fix -Wstringop-overflow issues selftests: mptcp: pm_nl_ctl: fix 32-bit support selftests: mptcp: depend on SYN_COOKIES selftests: mptcp: userspace_pm: report errors with 'remove' tests selftests: mptcp: userspace_pm: use correct server port selftests: mptcp: sockopt: return error if wrong mark selftests: mptcp: connect: fail if nft supposed to work selftests: mptcp: sockopt: use 'iptables-legacy' if available mptcp: ensure subflow is unhashed before cleaning the backlog mptcp: do not rely on implicit state check in mptcp_listen() tracing: Fix null pointer dereference in tracing_err_log_open() fprobe: Ensure running fprobe_exit_handler() finished before calling rethook_free() fprobe: Release rethook after the ftrace_ops is unregistered accel/ivpu: Clear specific interrupt status bits on C0 accel/ivpu: Fix VPU register access in irq disable pwm: meson: fix handling of period/duty if greater than UINT_MAX pwm: meson: modify and simplify calculation in meson_pwm_get_state PM: QoS: Restore support for default value on frequency QoS perf/x86: Fix lockdep warning in for_each_sibling_event() on SPR xtensa: ISS: fix call to split_if_spec cifs: if deferred close is disabled then close files immediately drm/amd/pm: conditionally disable pcie lane/speed switching for SMU13 drm/amd/pm: share the code around SMU13 pcie parameters update ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() ring-buffer: Fix deadloop issue on reading trace_pipe net: ena: fix shift-out-of-bounds in exponential backoff regmap-irq: Fix out-of-bounds access when allocating config buffers perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() samples: ftrace: Save required argument registers in sample trampolines nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices tracing: Fix memory leak of iter->temp when reading trace_pipe tracing/histograms: Add histograms to hist_vars if they have referenced variables dm: verity-loadpin: Add NULL pointer check for 'bdev' parameter s390/decompressor: fix misaligned symbol build error bus: ixp4xx: fix IXP4XX_EXP_T1_MASK Revert "8250: add support for ASIX devices with a FIFO bug" media: uapi: Fix [GS]_ROUTING ACTIVE flag value soundwire: qcom: fix storing port config out-of-bounds opp: Fix use-after-free in lazy_opp_tables after probe deferral meson saradc: fix clock divider mask length xhci: Show ZHAOXIN xHCI root hub speed correctly xhci: Fix TRB prefetch issue of ZHAOXIN hosts xhci: Fix resume issue of some ZHAOXIN hosts arm64: errata: Mitigate Ampere1 erratum AC03_CPU_38 at stage-2 nfp: clean mc addresses in application firmware when closing port ceph: don't let check_caps skip sending responses for revoke msgs ceph: fix blindly expanding the readahead windows ceph: add a dedicated private data for netfs rreq libceph: harden msgr2.1 frame segment length checks firmware: stratix10-svc: Fix a
[Kernel-packages] [Bug 2028253] [NEW] update apparmor and LSM stacking patch set
Public bug reported: [Impact] Provide an updated patch set for apparmor / LSM stacking with all the custom features that we need in the Ubuntu kernel. This patch set is required to provide the proper confinement with snaps and other Ubuntu-specific security features. [Fix] Apply the latest updated patch set from: https://gitlab.com/jjohansen/apparmor-kernel [Test case] Run the apparmor test case suite. [Regression potential] This patch set introduces significant non-upstream changes to the security layer, so we may expect generic regressions in the kernel, especially running applications that are stressing the security layer (such as systemd, snapd, lxd, etc.). ** Affects: linux (Ubuntu) Importance: Critical Status: Confirmed ** Affects: linux (Ubuntu Mantic) Importance: Critical Status: Confirmed ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Mantic) Status: New => Confirmed ** Changed in: linux (Ubuntu Mantic) Importance: Undecided => Critical ** Description changed: [Impact] Provide an updated patch set for apparmor / LSM stacking with all the custom features that we need in the Ubuntu kernel. + This patch set is required to provide the proper confinement with snaps + and other Ubuntu-specific security features. + [Fix] Apply the latest updated patch set from: - https://gitlab.com/jjohansen/apparmor-kernel + https://gitlab.com/jjohansen/apparmor-kernel [Test case] Run the apparmor test case suite. [Regression potential] This patch set introduces significant non-upstream changes to the security layer, so we may expect generic regressions in the kernel, especially running applications that are stressing the security layer (such as systemd, snapd, lxd, etc.). -- 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/2028253 Title: update apparmor and LSM stacking patch set Status in linux package in Ubuntu: Confirmed Status in linux source package in Mantic: Confirmed Bug description: [Impact] Provide an updated patch set for apparmor / LSM stacking with all the custom features that we need in the Ubuntu kernel. This patch set is required to provide the proper confinement with snaps and other Ubuntu-specific security features. [Fix] Apply the latest updated patch set from: https://gitlab.com/jjohansen/apparmor-kernel [Test case] Run the apparmor test case suite. [Regression potential] This patch set introduces significant non-upstream changes to the security layer, so we may expect generic regressions in the kernel, especially running applications that are stressing the security layer (such as systemd, snapd, lxd, etc.). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028253/+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 2028251] [NEW] Mantic update: v6.4.4 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.4 upstream stable release from git://git.kernel.org/ Linux 6.4.4 sh: hd64461: Handle virq offset for offchip IRQ base and HD64461 IRQ sh: mach-dreamcast: Handle virq offset in cascaded IRQ demux sh: mach-highlander: Handle virq offset in cascaded IRL demux sh: mach-r2d: Handle virq offset in cascaded IRL demux block/partition: fix signedness issue for Amiga partitions io_uring: Use io_schedule* in cqring wait tty: serial: fsl_lpuart: add earlycon for imx8ulp platform wireguard: netlink: send staged packets when setting initial private key wireguard: queueing: use saner cpu selection wrapping netfilter: nf_tables: prevent OOB access in nft_byteorder_eval netfilter: nf_tables: do not ignore genmask when looking up chain by id netfilter: conntrack: Avoid nf_ct_helper_hash uses after free drm/amdgpu: check RAS irq existence for VCN/JPEG drm/amd/pm: add abnormal fan detection for smu 13.0.0 drm/amdgpu/sdma4: set align mask to 255 drm/amd/pm: revise the ASPM settings for thunderbolt attached scenario drm/amdgpu: Skip mark offset for high priority rings drm/amdgpu: make sure that BOs have a backing store drm/amdgpu: make sure BOs are locked in amdgpu_vm_get_memory LoongArch: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation ovl: fix null pointer dereference in ovl_get_acl_rcu() ovl: let helper ovl_i_path_real() return the realinode ovl: fix null pointer dereference in ovl_permission() kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS kbuild: Add KBUILD_CPPFLAGS to as-option invocation kbuild: Add CLANG_FLAGS to as-instr powerpc/vdso: Include CLANG_FLAGS explicitly in ldflags-y mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation Input: ads7846 - fix pointer cast warning fs: no need to check source md/raid1-10: fix casting from randomized structure in raid1_submit_write() Input: ads7846 - Fix usage of match data blktrace: use inline function for blk_trace_remove() while blktrace is disabled leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename ARM: orion5x: fix d2net gpio initialization ARM: dts: qcom: ipq4019: fix broken NAND controller properties override ARM: dts: qcom: msm8660: Fix regulator node names regulator: tps65219: Fix matching interrupts for their regulators ASoC: mediatek: mt8173: Fix snd_soc_component_initialize error path ASoC: mediatek: mt8173: Fix irq error path btrfs: do not BUG_ON() on tree mod log failure at __btrfs_cow_block() btrfs: fix extent buffer leak after tree mod log failure at split_node() btrfs: add missing error handling when logging operation while COWing extent buffer btrfs: fix race when deleting quota root from the dirty cow roots list btrfs: reinsert BGs failed to reclaim btrfs: add block-group tree to lockdep classes btrfs: bail out reclaim process if filesystem is read-only btrfs: delete unused BGs while reclaiming BGs btrfs: warn on invalid slot in tree mod log rewind btrfs: insert tree mod log move in push_node_left btrfs: fix dirty_metadata_bytes for redirtied buffers btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile ipvs: increase ip_vs_conn_tab_bits range for 64BIT usb: typec: ucsi: Mark dGPUs as DEVICE scope fs: Lock moved directories fs: Establish locking order for unrelated directories Revert "udf: Protect rename against modification of moved directory" Revert "f2fs: fix potential corruption when moving a directory" ext4: Remove ext4 locking of moved directory fs: avoid empty option when generating legacy mount string jffs2: reduce stack usage in jffs2_build_xattr_subsystem() nfsd: use vfs setgid helper shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs mm/damon/ops-common: atomically test and clear young on ptes and pmds autofs: use flexible array in ioctl structure integrity: Fix possible multiple allocation in integrity_inode_get() um: Use HOST_DIR for mrproper watch_queue: prevent dangling pipe pointer bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent bcache: Remove unnecessary NULL point check in node allocations bcache: fixup btree_cache_wait list damage wifi: mt76: mt7921e: fix init command fail with enabled device wifi: cfg80211: fix receiving mesh packets without RFC1042 header wifi: ath10k: Serialize wake_tx_queue ops wifi: cfg80211: fix regulatory disconnect for non-MLO mmc: sdhci: fix DMA configure compatibility issue when 64bit DMA mode is used. mmc: mmci: Set PROBE_PREFER_ASYNCHRONOUS mmc: core: disable TRIM on Micron MTFC4GACAJCN-1M mmc: core: disable TRIM on Kingston EMMC04G-M627
[Kernel-packages] [Bug 2028250] [NEW] Mantic update: v6.4.3 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.3 upstream stable release from git://git.kernel.org/ Linux 6.4.3 fork: lock VMAs of the parent process when forking bootmem: remove the vmemmap pages from kmemleak in free_bootmem_page mm: call arch_swap_restore() from do_swap_page() mm: lock newly mapped VMA with corrected ordering mm: lock newly mapped VMA which can be modified after it becomes visible mm: lock a vma before stack expansion ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Mantic) Importance: Undecided Status: Confirmed ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: 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/2028250 Title: Mantic update: v6.4.3 upstream stable release Status in linux package in Ubuntu: Confirmed Status in linux source package in Mantic: Confirmed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v6.4.3 upstream stable release from git://git.kernel.org/ Linux 6.4.3 fork: lock VMAs of the parent process when forking bootmem: remove the vmemmap pages from kmemleak in free_bootmem_page mm: call arch_swap_restore() from do_swap_page() mm: lock newly mapped VMA with corrected ordering mm: lock newly mapped VMA which can be modified after it becomes visible mm: lock a vma before stack expansion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028250/+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
