[Kernel-packages] [Bug 2051672] Re: Backport iproute2 6.8.0 to noble
Hi Andrea - since this is now a stable release update, I *think* the
next steps should be:
1) Edit this bug to use the SRU Template
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
(now done)
Since your team owns this package, please review that and let me know if you
have any concerns with that text.
2) Wait for 24.10 ('oracular') to open for devel and forcesync iproute2
w/ Debian
(https://wiki.ubuntu.com/StableReleaseUpdates#Development_Release_Fixed_First).
3) Upload the SRU, and wait for feedback from the sru team. If approved,
we'll need to run the tests in the [Test Case] section and make sure
there are no regressions from 6.1.
--
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 2051672] Re: Backport iproute2 6.8.0 to noble
** Description changed: - 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. + [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. - 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. + 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. - I have built Debian's iproute2 in a noble ppa at ppa:dannf/test and - smoke tested it on an amd64 virtual machine: + [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. - 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) ... + [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. - The system rebooted fine. The ip command seems to behave normally. + 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. - 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 + 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. -- 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
[Kernel-packages] [Bug 2051672] Re: Backport iproute2 6.8.0 to noble
** Summary changed: - [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) + Backport iproute2 6.8.0 to noble -- 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: 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
Re: [Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
On Mon, Apr 22, 2024 at 11:07:54AM -, Matthieu Baerts wrote: > > I don't think we can justify dropping FAN support in an SRU, so let's > add that port back in. > > Even if it will not be used in Ubuntu 24.04, I'm happy to drop it if the stable release team would accept it. Here's the policy: https://wiki.ubuntu.com/StableReleaseUpdates However, I don't see how we can argue that dropping FAN support is *not* a regression, even if the kernel we ship does not support it. > and dropping these patches would stop the diversion with Debian? That's not a goal of our SRU process. We can always realign with Debian during the next devel cycle. > > @matttbe - is there any documentation about upstream compatibility > > guarantees and regression testing done that you're aware of, or any tests > > that we could run beyond those in our autopkgtests? > > @dannf: IPRoute2 is following the kernel development, and it is not > supposed to break the compatibility with older kernel versions (also > because the kernel's user API is not supposed to break). > > There is a test suite included in the source code, but it looks like it > is not tested when building the .deb package, check the 'debian/rules' > file: > > override_dh_auto_test: > # upstream test suite needs root and leaves machine unclean, skip > it The package does seem to include this in its autopkgtests (debian/tests/testsuite.sh), so I think we have that coverage. > > I never used it, (and it looks like it is not often updated), but IPRoute2 > (ip, tc, ss, etc.) is also heavily used in the kernel selftests: > > $ git grep -cw -e ip -e tc -e ss -- tools/testing/selftests/ | wc -l > 635 > > Maybe these tests are already being validated when building a new kernel for > Ubuntu? That's another way to validate IPRoute2. Thanks for the pointer! -dann > Other than that, Debian is using IPRoute2 versions > 6.1 for a long time > now. > -- 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] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
Thank Utkarsh. Yeah, we just dropped the ball on not getting this done sooner. I'd like to see if we can make the case for SRU'ing 6.8 in, so let's convert the bug to that. I don't think we can justify dropping FAN support in an SRU, so let's add that port back in. We'll need to make a convincing case to the SRU team that the risk of regression is minimal. Our partners at NVIDIA/Mellanox have offered to put this release through their testing. I'll see if they can provide details on what their tests will cover. @matttbe - is there any documentation about upstream compatibility guarantees and regression testing done that you're aware of, or any tests that we could run beyond those in our autopkgtests? -- 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 2060969] Re: UB 24.04: update uproute2 package
*** This bug is a duplicate of bug 2051672 *** https://bugs.launchpad.net/bugs/2051672 Amir - we're working on this in bug 2051672, and I subscribed you to it. I have prepared a build of iproute2 6.8 for noble in a PPA: https://launchpad.net/~dannf/+archive/ubuntu/test If there is some testing you can do with it to help validate it, that would be appreciated. Please update bug 2051672 with any results. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060969 Title: UB 24.04: update uproute2 package Status in linux package in Ubuntu: New Bug description: This ticket is an FR to update iproute2 package from 6.1.0 to latest upstream version. This updated is needed to support latest mlx5 driver features. Missing support examples 1) related feature: ipsec packet offload (iproute v6.7): https://lore.kernel.org/netdev/20231003180557.GC51282@unreal/T/ 994e80e9 devlink: Support setting port function ipsec_packet cap 27fd1bfa devlink: Support setting port function ipsec_crypto cap kernel https://www.spinics.net/lists/netdev/msg932050.html 2) related feature: live migration (iproute2 v6.2.0) https://lore.kernel.org/netdev/2022125849.510284-5-sh...@nvidia.com/T/ e036c36 devlink: Add documentation for roce and migratable port function attributes 32168d8a devlink: Support setting port function migratable cap bb2eea91 devlink: Support setting port function roce cap To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060969/+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)
** Description changed: 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 + 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 ** Changed in: iproute2 (Ubuntu) Milestone: ubuntu-24.04-beta => ubuntu-24.04 -- 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 ...
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Description changed: - A few versions have been released and Ubuntu Noble still has the 6.1 - version (6.1.0-1ubuntu2) from one year ago. Could it be possible to - import the latest version from Debian unstable fixing a bunch of issues - and supporting features from more recent kernels? + 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. - Please note that Ubuntu Noble 24.04 will probably be shipped with the - v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 - kernel, so missing the ones added to earlier versions. Switching to the - v6.7 now should ease the upgrade to the v6.8 later. + 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. - [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- - the-24-04-noble-numbat-release/41958 + I have built Debian's iproute2 in a noble ppa at ppa:dannf/test and + smoke tested it on an amd64 virtual machine: - Upstream ChangeLog: + 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) ... - - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ - - (Previous changelog: - https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 - ) - - ChangeLog from Debian: - - iproute2 (6.8.0-1) unstable; urgency=medium - - [ Ceppo ] - * Update Italian po-debconf translation (Closes: #1063002) - - [ Luca Boccassi ] - * Add build dependency on libnsl-dev (Closes: #1065214) - * Switch to pkgconf - * Update upstream source from tag 'upstream/6.8.0' - * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged - upstream - * Drop iproute2-doc package - * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream - - -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + - - iproute2 (6.7.0-2) unstable; urgency=medium - - * Backport fix for 'ss' output - - -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + - - iproute2 (6.7.0-1) unstable; urgency=medium - - * Add Italian debconf translation (Closes: #1056582) - * Update upstream source from tag 'upstream/6.7.0' - * Bump copyright year ranges in d/copyright - * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, - merged upstream - * Default config files moved from /usr/lib to /usr/share - - -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + - - iproute2 (6.6.0-1) unstable; urgency=medium - - * Update upstream source from tag 'upstream/6.6.0' - * Backport patch to fix configuration installation - * Remove handling of qt_atm.so, dropped upstream - - -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + - - iproute2 (6.5.0-5) unstable; urgency=medium - - * Use
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
Thanks Matthieu. I spoke to the kernel team and I think they will handle the update. I'm just trying to help unblock them by getting this reviewed/agreed by our release team ahead of time. -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.7 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763789/+files/6.7-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.8 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763790/+files/6.8-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.6 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763788/+files/6.6-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.5 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763787/+files/6.5-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.4 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763786/+files/6.4-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
It seems like this bug should now be a FFe (see https://wiki.ubuntu.com/FreezeExceptionProcess) - so converting... -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable; urgency=medium * Drop obsolete
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.2 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763784/+files/6.2-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Attachment added: "Upstream 6.3 changelog" https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2051672/+attachment/5763785/+files/6.3-changes.txt -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40 +0100 iproute2 (6.3.0-1) unstable;
[Kernel-packages] [Bug 2051672] Re: [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main)
** Summary changed: - Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) + [FFe] Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) -- 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: A few versions have been released and Ubuntu Noble still has the 6.1 version (6.1.0-1ubuntu2) from one year ago. Could it be possible to import the latest version from Debian unstable fixing a bunch of issues and supporting features from more recent kernels? Please note that Ubuntu Noble 24.04 will probably be shipped with the v6.8 kernel [1]. IPRoute v6.1 supports features added up to the v6.1 kernel, so missing the ones added to earlier versions. Switching to the v6.7 now should ease the upgrade to the v6.8 later. [1] https://discourse.ubuntu.com/t/introducing-kernel-6-8-for- the-24-04-noble-numbat-release/41958 Upstream ChangeLog: - 6.2: https://lore.kernel.org/netdev/20230220105811.674bd304@hermes.local/ - 6.3: https://lore.kernel.org/netdev/20230427090253.7a92616b@hermes.local/ - 6.4: https://lore.kernel.org/netdev/20230626093137.2f302acc@hermes.local/ - 6.5: https://lore.kernel.org/netdev/20230906093918.394a1b1d@hermes.local/ - 6.6: https://lore.kernel.org/netdev/20231106090325.07092c87@hermes.local/ - 6.7: https://lore.kernel.org/netdev/20240108094709.050e22bc@hermes.local/ - 6.8: https://lore.kernel.org/netdev/20240311094432.16bf9516@hermes.local/ (Previous changelog: https://lore.kernel.org/netdev/?q=s%3A%22%5BANNOUNCE%5D+iproute2%22+AND+NOT+s%3A%22Re%3A%22 ) ChangeLog from Debian: iproute2 (6.8.0-1) unstable; urgency=medium [ Ceppo ] * Update Italian po-debconf translation (Closes: #1063002) [ Luca Boccassi ] * Add build dependency on libnsl-dev (Closes: #1065214) * Switch to pkgconf * Update upstream source from tag 'upstream/6.8.0' * Drop 0002-ss-show-extra-info-when-processes-is-not-used.patch, merged upstream * Drop iproute2-doc package * Drop tc/m_xt.so and tc/m_ipt.so, removed upstream -- Luca Boccassi <> Tue, 12 Mar 2024 14:02:38 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output -- Luca Boccassi <> Mon, 22 Jan 2024 12:24:29 + iproute2 (6.7.0-1) unstable; urgency=medium * Add Italian debconf translation (Closes: #1056582) * Update upstream source from tag 'upstream/6.7.0' * Bump copyright year ranges in d/copyright * Drop 0002-Revert-Makefile-ensure-CONF_USR_DIR-honours-the-libd.patch, merged upstream * Default config files moved from /usr/lib to /usr/share -- Luca Boccassi <> Fri, 12 Jan 2024 21:47:59 + iproute2 (6.6.0-1) unstable; urgency=medium * Update upstream source from tag 'upstream/6.6.0' * Backport patch to fix configuration installation * Remove handling of qt_atm.so, dropped upstream -- Luca Boccassi <> Sun, 05 Nov 2023 22:46:20 + iproute2 (6.5.0-5) unstable; urgency=medium * Use dh-sequence-movetousr -- Luca Boccassi <> Tue, 24 Oct 2023 15:24:01 +0100 iproute2 (6.5.0-4) unstable; urgency=medium * postinst: handle legacy config files only when upgrading from previous versions that shipped them * postinst: ensure that locally modified legacy config files are preserved as overrides on upgrade (Closes: #1051577) * Note configuration files location changes in NEWS -- Luca Boccassi <> Sat, 16 Sep 2023 18:58:51 +0100 iproute2 (6.5.0-3) unstable; urgency=medium * Remove further leftovers as part of upstream's move of config to /usr (Closes: #1051577) -- Luca Boccassi <> Mon, 11 Sep 2023 09:42:12 +0100 iproute2 (6.5.0-2) unstable; urgency=medium * Add maintscript to remove conffiles that upstream has moved to /usr (Closes: #1051577) -- Luca Boccassi <> Sun, 10 Sep 2023 21:28:28 +0100 iproute2 (6.5.0-1) unstable; urgency=medium [ Luca Boccassi ] * Use wildcard for Lintian overrides [ Peter Kvillegård ] * Add Swedish translation of debconf messages (Closes: #1050442) [ Luca Boccassi ] * Update upstream source from tag 'upstream/6.5.0' * Use cap_bpf instead of cap_sys_admin for ip vrf-exec * Package-provided config files are now shipped in /usr/iproute2 instead of /etc/iproute2 -- Luca Boccassi <> Sat, 09 Sep 2023 16:32:54 +0100 iproute2 (6.4.0-1) unstable; urgency=medium * Fix patch header Forwarded field * Enable ELF metadata stamping * Update upstream source from tag 'upstream/6.4.0' * Update Lintian overrides -- Luca Boccassi <> Fri, 30 Jun 2023 12:16:40
[Kernel-packages] [Bug 2060969] Re: UB 24.04: update uproute2 package
*** This bug is a duplicate of bug 2051672 *** https://bugs.launchpad.net/bugs/2051672 ** This bug has been marked a duplicate of bug 2051672 Merge iproute2 with the latest Debian version: 6.8.0-1 from testing/unstable (main) -- 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/2060969 Title: UB 24.04: update uproute2 package Status in linux package in Ubuntu: New Bug description: This ticket is an FR to update iproute2 package from 6.1.0 to latest upstream version. This updated is needed to support latest mlx5 driver features. Missing support examples 1) related feature: ipsec packet offload (iproute v6.7): https://lore.kernel.org/netdev/20231003180557.GC51282@unreal/T/ 994e80e9 devlink: Support setting port function ipsec_packet cap 27fd1bfa devlink: Support setting port function ipsec_crypto cap kernel https://www.spinics.net/lists/netdev/msg932050.html 2) related feature: live migration (iproute2 v6.2.0) https://lore.kernel.org/netdev/2022125849.510284-5-sh...@nvidia.com/T/ e036c36 devlink: Add documentation for roce and migratable port function attributes 32168d8a devlink: Support setting port function migratable cap bb2eea91 devlink: Support setting port function roce cap To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060969/+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 2058557] Re: Kernel panic during checkbox stress_ng_test on Grace running noble 6.8 (arm64+largemem) kernel
** Changed in: linux (Ubuntu) Assignee: Jose Ogando Justo (joseogando) => Mitchell Augustin (mitchellaugustin) ** Changed in: linux (Ubuntu) Status: Fix Committed => In Progress -- 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/2058557 Title: Kernel panic during checkbox stress_ng_test on Grace running noble 6.8 (arm64+largemem) kernel Status in linux package in Ubuntu: In Progress Bug description: A kernel oops and panic occurred during 22.04 SoC certification on Gunyolk (Grace/Grace) with 6.8 kernel, arm64+largemem variant Steps to reproduce: Run (as root) the following commands: add-apt-repository -y ppa:checkbox-dev/stable apt-add-repository -y ppa:firmware-testing-team/ppa-fwts-stable apt update apt install -y canonical-certification-server /usr/lib/checkbox-provider-base/bin/stress_ng_test.py disk --device dm-0 --base-time 240 stress_ng_test caused a kernel panic after about 5 minutes. I have attached dmesg output from my reproducer to this report. Initially, this was identified via a panic during the above test, which was running as part of a run of certify-soc-22.04. Attached is a tarball containing: - apport.linux-image-6.8.0-11-generic-64k.kzsondji.apport: The output of `ubuntu-bug linux` on the machine (after reboot) - reproduced-dmesg.202403201942: The dmesg output captured by kdump when I reproduced my original issue by running only the single stress_ng_test.py command above (not the entire cert suite) - original-dmesg.txt: The dmesg output I captured when the stress_ng_test originally failed during the full cert suite run To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2058557/+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 2059316] Re: backport arm64 THP improvements from 6.9
I've build-tested on all architectures in this PPA: https://launchpad.net/~dannf/+archive/ubuntu/mthp/+packages I manually tested on a few systems, timing a full kernel build w/ the Ubuntu config in a tmpfs (both to stress the system, and look for performance differences). - ppc64el / Power9 - no performance difference - x86 - AMD EPYC/Naples - 11% improvement - Ampere AltraMax (-generic) - 19% improvement ** Description changed: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP - https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html + https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: - https://lwn.net/Articles/962330/ + https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. + + It has been reported that this can have a *10x* improvement for certain + GPU workloads on ARM: + + https://lwn.net/Articles/954094/ -- 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/2059316 Title: backport arm64 THP improvements from 6.9 Status in linux package in Ubuntu: In Progress Bug description: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. It has been reported that this can have a *10x* improvement for certain GPU workloads on ARM: https://lwn.net/Articles/954094/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059316/+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 2059316] Re: backport arm64 THP improvements from 6.9
** Changed in: linux (Ubuntu) Status: New => In Progress -- 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/2059316 Title: backport arm64 THP improvements from 6.9 Status in linux package in Ubuntu: In Progress Bug description: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059316/+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 2059316] Re: backport arm64 THP improvements from 6.9
** Changed in: linux (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) -- 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/2059316 Title: backport arm64 THP improvements from 6.9 Status in linux package in Ubuntu: New Bug description: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059316/+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 2059316] [NEW] backport arm64 THP improvements from 6.9
Public bug reported: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2059316 Title: backport arm64 THP improvements from 6.9 Status in linux package in Ubuntu: New Bug description: Initial support for multi-size THP landed upstream in v6.8. In the 6.9 merge window, 2 other series have landed that show significant performance improvements on arm64 mm/memory: optimize fork() with PTE-mapped THP https://lkml.iu.edu/hypermail/linux/kernel/2401.3/02766.html Transparent Contiguous PTEs for User Mappings: https://lwn.net/Articles/962330/ On an Ampere AltraMax system w/ 4K page size, kernel builds in a tmpfs are reduced from 6m30s to 5m17s, a ~19% improvement. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059316/+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 2055082] Re: IB peer memory feature regressed in 6.5
= Verification = $ cat /proc/version Linux version 6.5.0-27-generic (buildd@lcy02-amd64-059) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 ubuntu@ubuntu:~/autotest-client-tests/ubuntu_performance_gpudirect_rdma/nvidia-peermem-test$ ./nvidia-peermem-test.sh -m peermem Repository: 'Types: deb URIs: https://ppa.launchpadcontent.net/canonical-nvidia/perftest+cuda/ubuntu/ Suites: mantic Components: main ' Description: Used internal for kernel regression testing More info: https://launchpad.net/~canonical-nvidia/+archive/ubuntu/perftest+cuda Adding repository. Found existing deb entry in /etc/apt/sources.list.d/canonical-nvidia-ubuntu-perftest_cuda-mantic.sources Hit:1 http://archive.ubuntu.com/ubuntu mantic InRelease Hit:2 http://archive.ubuntu.com/ubuntu mantic-updates InRelease Hit:3 http://archive.ubuntu.com/ubuntu mantic-security InRelease Hit:4 http://archive.ubuntu.com/ubuntu mantic-backports InRelease Hit:5 http://archive.ubuntu.com/ubuntu mantic-proposed InRelease Hit:6 https://ppa.launchpadcontent.net/canonical-nvidia/perftest+cuda/ubuntu mantic InRelease Hit:7 https://ppa.launchpadcontent.net/dannf/dannf/ubuntu mantic InRelease Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done perftest is already the newest version (24.01.0+0.38-1+perftest+cuda.1~ubuntu23.10.1). 0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded. Reading package lists... Done Building dependency tree... Done Reading state information... Done opensm is already the newest version (3.3.23-2). 0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded. --use_cuda= Use CUDA specific device for GPUDirect RDMA testing Perftest doesn't supports CUDA tests with inline messages: inline size set to 0 * Waiting for client to connect... * Perftest doesn't supports CUDA tests with inline messages: inline size set to 0 initializing CUDA initializing CUDA Listing all CUDA devices in system: CUDA device 0: PCIe address is 07:00 CUDA device 1: PCIe address is 0F:00 CUDA device 2: PCIe address is 47:00 CUDA device 3: PCIe address is 4E:00 CUDA device 4: PCIe address is 87:00 CUDA device 5: PCIe address is 90:00 CUDA device 6: PCIe address is B7:00 CUDA device 7: PCIe address is BD:00 Picking device No. 1 [pid = 15582, dev = 1] device name = [NVIDIA A100-SXM4-40GB] creating CUDA Ctx Listing all CUDA devices in system: CUDA device 0: PCIe address is 07:00 CUDA device 1: PCIe address is 0F:00 CUDA device 2: PCIe address is 47:00 CUDA device 3: PCIe address is 4E:00 CUDA device 4: PCIe address is 87:00 CUDA device 5: PCIe address is 90:00 CUDA device 6: PCIe address is B7:00 CUDA device 7: PCIe address is BD:00 Picking device No. 0 [pid = 15576, dev = 0] device name = [NVIDIA A100-SXM4-40GB] creating CUDA Ctx making it the current CUDA Ctx cuMemAlloc() of a 16777216 bytes GPU buffer allocated GPU buffer address at 7c014600 pointer=0x7c014600 --- RDMA_Write BW Test Dual-port : OFF Device : mlx5_6 Number of qps : 1Transport type : IB Connection type : RC Using SRQ : OFF PCIe relax order: ON making it the current CUDA Ctx cuMemAlloc() of a 16777216 bytes GPU buffer allocated GPU buffer address at 7a08b400 pointer=0x7a08b400 --- RDMA_Write BW Test Dual-port : OFF Device : mlx5_2 Number of qps : 1Transport type : IB Connection type : RC Using SRQ : OFF PCIe relax order: ON ibv_wr* API : ON TX depth: 128 CQ Moderation : 100 Mtu : 4096[B] Link type : IB Max inline data : 0[B] rdma_cm QPs : OFF Data ex. method : Ethernet --- ibv_wr* API : ON CQ Moderation : 100 Mtu : 4096[B] Link type : IB Max inline data : 0[B] rdma_cm QPs : OFF Data ex. method : Ethernet --- local address: LID 0x01 QPN 0x0029 PSN 0x6763b2 RKey 0x180eef VAddr 0x007a08b480 local address: LID 0x02 QPN 0x36ef PSN 0x149b7b RKey 0x180efd VAddr 0x007c014680 remote address: LID 0x02 QPN 0x36ef PSN 0x149b7b RKey 0x180efd VAddr 0x007c014680 --- #bytes #iterationsBW peak[MB/sec]BW average[MB/sec] MsgRate[Mpps] remote address: LID 0x01 QPN 0x0029 PSN 0x6763b2 RKey 0x180eef VAddr 0x007a08b480
[Kernel-packages] [Bug 1804481] Re: SecureBoot support for arm64
** Changed in: shim-signed (Ubuntu Cosmic) Status: Triaged => Won't Fix ** Changed in: shim-signed (Ubuntu Bionic) Status: Triaged => Fix Released ** Changed in: linux-signed (Ubuntu Cosmic) Status: Triaged => Won't Fix ** Changed in: linux-meta (Ubuntu Cosmic) Status: Triaged => Won't Fix ** Changed in: linux (Ubuntu Cosmic) Status: Triaged => Won't Fix ** Changed in: linux-signed (Ubuntu Bionic) Status: Triaged => Won't Fix ** Changed in: linux (Ubuntu Bionic) Status: Triaged => Won't Fix ** Changed in: linux-meta (Ubuntu Bionic) Status: Triaged => Won't Fix ** Changed in: linux-signed-hwe-edge (Ubuntu) Status: New => Fix Released ** Changed in: linux-meta (Ubuntu) Status: In Progress => 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/1804481 Title: SecureBoot support for arm64 Status in linux package in Ubuntu: Fix Released Status in linux-meta package in Ubuntu: Fix Released Status in linux-signed package in Ubuntu: Fix Released Status in linux-signed-hwe package in Ubuntu: Invalid Status in linux-signed-hwe-edge package in Ubuntu: Fix Released Status in shim package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in linux-meta source package in Bionic: Won't Fix Status in linux-signed source package in Bionic: Won't Fix Status in linux-signed-hwe source package in Bionic: Fix Released Status in linux-signed-hwe-edge source package in Bionic: Fix Released Status in shim source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Fix Released Status in linux source package in Cosmic: Won't Fix Status in linux-meta source package in Cosmic: Won't Fix Status in linux-signed source package in Cosmic: Won't Fix Status in linux-signed-hwe source package in Cosmic: Invalid Status in linux-signed-hwe-edge source package in Cosmic: Invalid Status in shim source package in Cosmic: Fix Released Status in shim-signed source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-meta source package in Disco: Won't Fix Status in linux-signed source package in Disco: Fix Released Status in linux-signed-hwe source package in Disco: Invalid Status in linux-signed-hwe-edge source package in Disco: Invalid Status in shim source package in Disco: Fix Released Status in shim-signed source package in Disco: Fix Released Bug description: [Impact] Ubuntu does not currently support SecureBoot for UEFI systems on arm64 platforms. [Test Case] See: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing [Fix] - Introduce shim-signed for arm64 - Introduce grub-signed for arm64 - Produce signed linux kernels [Regression Risk] We're enabling new signed packages - regressions would most likely fall into packaging issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804481/+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 2055082] [NEW] IB peer memory feature regressed in 6.5
Public bug reported: [Impact] The GPU Direct over Infiniband feature of NVIDIA GPUs no longer works on jammy/hwe kernels that have migrated to 6.5 *except* for the -nvidia kernel, which pulled in support via bug 2049537. We have carried this patch since 5.4 (see bug 1923104). We do not plan to carry this patch into 6.8 or later - we are working on a deprecation post for that to give users some time to migrate. [Test Case] https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client-tests/tree/ubuntu_performance_gpudirect_rdma ** Affects: linux (Ubuntu) Importance: Undecided Status: Won't Fix ** Affects: linux (Ubuntu Mantic) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Won't Fix ** Changed in: linux (Ubuntu Mantic) Status: New => In Progress ** Changed in: linux (Ubuntu Mantic) Assignee: (unassigned) => dann frazier (dannf) -- 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/2055082 Title: IB peer memory feature regressed in 6.5 Status in linux package in Ubuntu: Won't Fix Status in linux source package in Mantic: In Progress Bug description: [Impact] The GPU Direct over Infiniband feature of NVIDIA GPUs no longer works on jammy/hwe kernels that have migrated to 6.5 *except* for the -nvidia kernel, which pulled in support via bug 2049537. We have carried this patch since 5.4 (see bug 1923104). We do not plan to carry this patch into 6.8 or later - we are working on a deprecation post for that to give users some time to migrate. [Test Case] https://git.launchpad.net/~canonical-kernel-team/+git/autotest-client-tests/tree/ubuntu_performance_gpudirect_rdma To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055082/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
I'm glad to hear you are seeing an improvement! The current implementation is still racy as mentioned in Comment #22. I did a search of the logs I downloaded, and I believe this one shows that the mount_partition() race isn't just theoretical: https://autopkgtest.ubuntu.com/results/autopkgtest- mantic/mantic/amd64/l/livecd-rootfs/20230928_132941_a6800@/log.gz So my suggestion is that we: 1) wait for systemd 255.3 to be merged in noble to fix the issue w/ `udevadm lock` 2) convert livecd-rootfs to use udevadm lock in noble, addressing the remaining known races. 3) backport `udevadm lock` to jammy (likely as a low-priority SRU) 4) backport the`udevadm lock` support to livecd-rootfs I realize that'll take some time, so if you want to SRU the partial fix as a stop-gap, feel free. -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Status in linux source package in Jammy: New Status in livecd-rootfs source package in Jammy: New Status in util-linux source package in Jammy: New Status in linux source package in Mantic: New Status in livecd-rootfs source package in Mantic: New Status in util-linux source package in Mantic: New Status in linux source package in Noble: New Status in livecd-rootfs source package in Noble: Fix Released Status in util-linux source package in Noble: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2052663] Re: fabric-manager-535 setup fails during install on Grace/Hopper arm64 system running noble
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: nvidia-graphics-drivers-535-server (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2052663
Title:
fabric-manager-535 setup fails during install on Grace/Hopper arm64
system running noble
Status in fabric-manager-535 package in Ubuntu:
New
Status in linux package in Ubuntu:
New
Status in nvidia-graphics-drivers-535-server package in Ubuntu:
New
Bug description:
This error occurs on both the standard and largemem variants of the latest
Noble server build of Ubuntu:
Ubuntu Noble Numbat (development branch) (GNU/Linux 6.6.0-14-generic-64k
aarch64) (iso link:
https://cdimage.ubuntu.com/ubuntu-server/daily-live/20240207.1/noble-live-server-arm64+largemem.iso)
Ubuntu Noble Numbat (development branch) (GNU/Linux 6.6.0-14-generic aarch64)
(iso link:
https://cdimage.ubuntu.com/ubuntu-server/daily-live/20240207/noble-live-server-arm64.iso)
CPU/GPU: Nvidia Grace/Hopper
lsb_release -rd:
No LSB modules are available.
Description: Ubuntu Noble Numbat (development branch)
Release: 24.04
Kernel versions affected:
GNU/Linux 6.6.0-14-generic-64k aarch64
GNU/Linux 6.6.0-14-generic aarch64
Package version: nvidia-fabricmanager-535 (535.154.05-0ubuntu1 arm64)
Expected behavior: Package starts as expected during post-install
setup steps
Actual behavior:
On our grace/hopper system running noble, when installing
nvidia-fabricmanager-535, the installation froze at 60% twice, along with all
ssh processes. I am also unable to ssh back into the system after this happens.
This is the last output I see from my installer shell:
+ apt install -y nvidia-fabricmanager-535
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
nvidia-fabricmanager-535
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 1795 kB of archives.
After this operation, 8679 kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports noble/multiverse arm64
nvidia-fabricmanager-535 arm64 535.154.05-0ubuntu1 [1795 kB]
Fetched 1795 kB in 1s (2439 kB/s)
Selecting previously unselected package nvidia-fabricmanager-535.
(Reading database ... 103745 files and directories currently installed.)
Preparing to unpack
.../nvidia-fabricmanager-535_535.154.05-0ubuntu1_arm64.deb ...
Unpacking nvidia-fabricmanager-535 (535.154.05-0ubuntu1) ...
Setting up nvidia-fabricmanager-535 (535.154.05-0ubuntu1) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/nvidia-fabricmanager.service →
/lib/systemd/system/nvidia-fabricmanager.service.
Progress: [ 60%]
[#...]
This does not appear to cause a panic/reboot, as I can still interact with
the console, and it even appears that the apt process is still running in ps
aux (although it doesn't seem to progress). However, I observe the following
output in the console that I believe may be related:
[ 1453.814597] watchdog: BUG: soft lockup - CPU#16 stuck for 670s!
[(udev-worker):33269]
[ 1477.814602] watchdog: BUG: soft lockup - CPU#16 stuck for 693s!
[(udev-worker):33269]
[ 1501.814606] watchdog: BUG: soft lockup - CPU#16 stuck for 715s!
[(udev-worker):33269]
[ 1525.814611] watchdog: BUG: soft lockup - CPU#16 stuck for 738s!
[(udev-worker):33269]
[ 1579.666718] rcu: INFO: rcu_preempt detected expedited stalls on
CPUs/tasks: { 17-...D } 240893 ji
ffies s: 653 root: 0x2/.
[ 1579.678114] rcu: blocking rcu_node structures (internal RCU debug):
l=1:15-29:0x4/.
[ 1597.814625] watchdog: BUG: soft lockup - CPU#16 stuck for 805s!
[(udev-worker):33269]
[ 1621.814630] watchdog: BUG: soft lockup - CPU#16 stuck for 827s!
[(udev-worker):33269]
[ 1630.562655] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 1630.568973] rcu: 17-...0: (1 GPs behind) idle=2444/1/0x4000
softirq=13696/13700 f
qs=126842
[ 1630.578665] rcu:hardirqs softirqs csw/system
[ 1630.584381] rcu:number:0 00
[ 1630.590109] rcu: cputime:0 00 ==>
1110384(ms)
[ 1630.597458] rcu: (detected by 20, t=285099 jiffies, g=74061, q=113266
ncpus=72)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fabric-manager-535/+bug/2052663/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
While the above MP is now merged, I still see additional potential races in the code. For example, anything calling mount_partition() for the first partition, and also maybe bug 2030771. I don't see a good way to solve that w/o `udevadm lock` because these functions don't currently know what the full block device - and I don't think we want to implement that logic ourselves. I suggest we move from flock to `udevadm lock` once it is available in noble. If that proves to be stable, then perhaps we consider backporting that to jammy's systemd. -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Status in linux source package in Jammy: New Status in livecd-rootfs source package in Jammy: New Status in util-linux source package in Jammy: New Status in linux source package in Mantic: New Status in livecd-rootfs source package in Mantic: New Status in util-linux source package in Mantic: New Status in linux source package in Noble: New Status in livecd-rootfs source package in Noble: Fix Released Status in util-linux source package in Noble: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
** Also affects: util-linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: util-linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Noble) Importance: Undecided Status: Fix Released ** 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Status in linux source package in Jammy: New Status in livecd-rootfs source package in Jammy: New Status in util-linux source package in Jammy: New Status in linux source package in Mantic: New Status in livecd-rootfs source package in Mantic: New Status in util-linux source package in Mantic: New Status in linux source package in Noble: New Status in livecd-rootfs source package in Noble: Fix Released Status in util-linux source package in Noble: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2043059] Re: Installation errors out when installing in a chroot
** Attachment added: "jammy: verification steps 4-6" https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2043059/+attachment/5744328/+files/jammy.log ** Tags removed: verification-needed verification-needed-jammy verification-needed-mantic ** Tags added: verification-done verification-done-jammy verification-done-mantic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Fix Released Status in linux-nvidia package in Ubuntu: Invalid Status in kdump-tools source package in Jammy: Fix Committed Status in linux-nvidia source package in Jammy: Invalid Status in kdump-tools source package in Mantic: Fix Committed Status in linux-nvidia source package in Mantic: Invalid Status in kdump-tools source package in Noble: Fix Released Status in linux-nvidia source package in Noble: Invalid Bug description: [Impact] When installing in a chroot environment, the kdump-tools kernel hook will fail. This breaks certain OS image creation tools, such as BCM (which I assume is NVIDIA Base Command Manager from context). While BCM's image generation tool requires some additional tweaks to consume this, the proposed fix is necessary, and should be sufficient for other tools that use chroots. [Test Plan] 1) debootstrap a chroot environment for the target Ubuntu release 2) Install kdump-tools within that environment 3) Install a kernel package and make sure it succeeds. 4) do the same steps in a virtual machine, but with `ischroot` symlinked to /dev/true at install time. This should simulate a system that was just installed with an image prepared as above. 5) Then restore ischroot, and reboot. 6) Confirm the systemd service does generate an initramfs at boot, and 7) that a crash dump can be triggered afterwords. [Where Problems Could Occur] The solution we implemented in noble was simply to detect a chroot environment with ischroot, and disable initramfs generation. The systemd service will detect that an initrd is missing, and generate one on first boot. A source of potential problems is if that does not happen for some reason, resulting in a kdump-tools service failure on first boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
** Attachment added: "mantic: verification steps 4-6" https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2043059/+attachment/5744327/+files/mantic.log -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Fix Released Status in linux-nvidia package in Ubuntu: Invalid Status in kdump-tools source package in Jammy: Fix Committed Status in linux-nvidia source package in Jammy: Invalid Status in kdump-tools source package in Mantic: Fix Committed Status in linux-nvidia source package in Mantic: Invalid Status in kdump-tools source package in Noble: Fix Released Status in linux-nvidia source package in Noble: Invalid Bug description: [Impact] When installing in a chroot environment, the kdump-tools kernel hook will fail. This breaks certain OS image creation tools, such as BCM (which I assume is NVIDIA Base Command Manager from context). While BCM's image generation tool requires some additional tweaks to consume this, the proposed fix is necessary, and should be sufficient for other tools that use chroots. [Test Plan] 1) debootstrap a chroot environment for the target Ubuntu release 2) Install kdump-tools within that environment 3) Install a kernel package and make sure it succeeds. 4) do the same steps in a virtual machine, but with `ischroot` symlinked to /dev/true at install time. This should simulate a system that was just installed with an image prepared as above. 5) Then restore ischroot, and reboot. 6) Confirm the systemd service does generate an initramfs at boot, and 7) that a crash dump can be triggered afterwords. [Where Problems Could Occur] The solution we implemented in noble was simply to detect a chroot environment with ischroot, and disable initramfs generation. The systemd service will detect that an initrd is missing, and generate one on first boot. A source of potential problems is if that does not happen for some reason, resulting in a kdump-tools service failure on first boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
# verification steps 1-3: installation in a chroot
I set up 2 chroots - one w/ the normal sources.list, the other w/
proposed enabled, and did a side by side install test.
$ for chroot in mantic mantic-proposed jammy jammy-proposed; do sudo chroot
$chroot apt list kdump-tools; done
Listing... Done
kdump-tools/mantic,now 1:1.8.1ubuntu1 amd64 [installed]
Listing... Done
kdump-tools/mantic-proposed,now 1:1.8.1ubuntu1.1 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it
Listing... Done
kdump-tools/jammy-updates,now 1:1.6.10ubuntu2.1 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it
Listing... Done
kdump-tools/jammy-proposed,now 1:1.6.10ubuntu2.2 amd64 [installed]
N: There are 2 additional versions. Please use the '-a' switch to see them.
## mantic
### first w/ only updates enabled
dannf@lakitu:~$ sudo chroot mantic-proposed apt install kdump-tools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
kdump-tools is already the newest version (1:1.8.1ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 40 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
Setting up linux-image-6.5.0-15-generic (6.5.0-15.15) ...
Processing triggers for linux-image-6.5.0-15-generic (6.5.0-15.15) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.5.0-15-generic
/etc/kernel/postinst.d/kdump-tools:
kdump-tools: Generating /var/lib/kdump/initrd.img-6.5.0-15-generic
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /var/lib/kdump/initramfs-tools
Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /var/lib/kdump/initrd.img-6.5.0-15-generic with 1.
run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1
dpkg: error processing package linux-image-6.5.0-15-generic (--configure):
installed linux-image-6.5.0-15-generic package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-6.5.0-15-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)
### and now w/ proposed
$ sudo chroot mantic-proposed apt install kdump-tools -t mantic-proposed
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be upgraded:
kdump-tools
1 upgraded, 0 newly installed, 0 to remove and 50 not upgraded.
1 not fully installed or removed.
Need to get 30.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu mantic-proposed/main amd64
kdump-tools amd64 1:1.8.1ubuntu1.1 [30.8 kB]
Fetched 30.8 kB in 0s (1216 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Preconfiguring packages ...
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 46941 files and directories currently installed.)
Preparing to unpack .../kdump-tools_1%3a1.8.1ubuntu1.1_amd64.deb ...
Unpacking kdump-tools (1:1.8.1ubuntu1.1) over (1:1.8.1ubuntu1) ...
Setting up linux-image-6.5.0-15-generic (6.5.0-15.15) ...
Setting up kdump-tools (1:1.8.1ubuntu1.1) ...
Installing new version of config file /etc/kernel/postinst.d/kdump-tools ...
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Running in chroot, ignoring request.
Processing triggers for initramfs-tools (0.142ubuntu15.1) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-15-generic
Processing triggers for linux-image-6.5.0-15-generic (6.5.0-15.15) ...
[Kernel-packages] [Bug 2006557] Re: Enable rdma-sniffer for libpcap
** Changed in: libpcap (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: libpcap (Ubuntu) Status: Triaged => In Progress -- 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/2006557 Title: Enable rdma-sniffer for libpcap Status in libpcap package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Lunar: Invalid Status in libpcap package in Debian: Won't Fix Bug description: Hi, The request is to build and configure stock package libpcap with rdma-sniffer enabled. We'd like users of rdma devices to be able to sniff on them using stock tcpdump. Currently when using default tcpdump It does not list rdma devices. $ tcpdump -D |grep -i rdma $ when using locally build tcpdump (with rdma enabled) $ cd $ ./tcpdump -D |grep -i rdma 24.rocep4s0 (RDMA sniffer) 25.rocep7s0f0 (RDMA sniffer) 26.rocep7s0f1 (RDMA sniffer) 27.rocep10s0f0 (RDMA sniffer) 28.rocep10s0f1 (RDMA sniffer) 29.rocep33s0f0 (RDMA sniffer) 30.rocep33s0f1 (RDMA sniffer) 31.rocep36s0f0 (RDMA sniffer) 32.ibp36s0f1 (RDMA sniffer) Locally build steps: clone sources: $ mkdir tcpdumpbuild $ cd tcpdumpbuild/ $ git clone https://github.com/the-tcpdump-group/tcpdump.git $ git clone https://github.com/the-tcpdump-group/libpcap.git install required packages (including rdma packages so libpcap is built with rdma enabled): $ apt install flex bison librdmacm-dev librdmacm1 rdma-core rdmacm-utils configure and build $ cd libpcap $ ./autogen.sh $ ./configure --enable-rdma=yes $ make cd ../tcpdump/ ./autogen.sh ./configure $ make now ./tcpdump -D can show rdma devices. Thanks ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/2006557/+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 2051942] Re: autopkgtest fails: EE Missing modules
** Also affects: linux-nvidia-tegra-igx (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux-nvidia-tegra (Ubuntu) ** No longer affects: linux-nvidia-tegra (Ubuntu Jammy) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia-tegra-igx in Ubuntu. https://bugs.launchpad.net/bugs/2051942 Title: autopkgtest fails: EE Missing modules Status in linux-nvidia-tegra-igx package in Ubuntu: New Status in linux-nvidia-tegra-igx source package in Jammy: New Bug description: From https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- jammy/jammy/arm64/l/linux-nvidia-tegra- igx/20240121_072109_094a7@/log.gz : 6243s dpkg-deb: building package 'linux-nvidia-tegra-igx-tools-5.15.0-1007' in '../linux-nvidia-tegra-igx-tools-5.15.0-1007_5.15.0-1007.7_arm64.deb'. 6253s Debug: module-check-nvidia-tegra-igx 6253s debian/scripts/module-check "nvidia-tegra-igx" \ 6253s "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/abi/arm64" "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/__abi.current/arm64" 6254s II: Checking modules for nvidia-tegra-igx... 6254s read 11 modules. 6254sreading new modules...read 7343 modules. 6254sreading old modules... 6254s MISS: ar1335_common 6254s MISS: arm64-ras 6254s MISS: bluedroid_pm 6254s MISS: bmi088 6254s MISS: cam_cdi_tsc [...] 6254s MISS: tegracam_log 6254s MISS: ti_fpdlink_dp_serializer 6254s MISS: tsecriscv 6254s MISS: ufs-tegra 6254s MISS: ufs-tegra-provision 6254s MISS: userspace_ivc_mempool 6254s MISS: virtual_i2c_mux 6254s MISS: watchdog-tegra-t18x 6254s MISS: wch 6254s NEW: pps-ktimer 6254s read 7498 modules : new(1) missing(154) 6254s EE: Missing modules 6254s make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia-tegra-igx] Error 1 6254s dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 6254s autopkgtest [07:05:29]: test rebuild: ---] 6259s autopkgtest [07:05:34]: test rebuild: - - - - - - - - - - results - - - - - - - - - - 6259s rebuild FAIL non-zero exit status 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-tegra-igx/+bug/2051942/+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 2043059] Re: Installation errors out when installing in a chroot
** Description changed: - Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ... - /etc/kernel/postinst.d/dkms: - * dkms: running auto installation service for kernel 5.15.0-1040-nvidia -...done. - /etc/kernel/postinst.d/initramfs-tools: - update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia - cryptsetup: WARNING: Couldn't determine root device - W: Couldn't identify type of root file system for fsck hook - cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory - /etc/kernel/postinst.d/kdump-tools: - kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia - mkinitramfs: failed to determine device for / - mkinitramfs: workaround is MODULES=most, check: - grep -r MODULES /var/lib/kdump/initramfs-tools + [Impact] + When installing in a chroot environment, the kdump-tools kernel hook will fail. This breaks certain OS image creation tools, such as BCM (which I assume is NVIDIA Base Command Manager from context). While BCM's image generation tool requires some additional tweaks to consume this, the proposed fix is necessary, and should be sufficient for other tools that use chroots. - Error please report bug on initramfs-tools - Include the output of 'mount' and 'cat /proc/mounts' - update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia with 1. - run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1 - dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure): - installed linux-image-5.15.0-1040-nvidia package post-installation script subprocess returned error exit status 1 - Errors were encountered while processing: - linux-image-5.15.0-1040-nvidia - E: Sub-process /usr/bin/dpkg returned an error code (1) + [Test Plan] + 1) debootstrap a chroot environment for the target Ubuntu release + 2) Install kdump-tools within that environment + 3) Install a kernel package and make sure it succeeds. + 4) do the same steps in a virtual machine, but with `ischroot` symlinked to /dev/true at install time. This should simulate a system that was just installed with an image prepared as above. + 5) Then restore ischroot, and reboot. + 6) Confirm the systemd service does generate an initramfs at boot, and + 7) that a crash dump can be triggered afterwords. + + [Where Problems Could Occur] + The solution we implemented in noble was simply to detect a chroot environment with ischroot, and disable initramfs generation. The systemd service will detect that an initrd is missing, and generate one on first boot. A source of potential problems is if that does not happen for some reason, resulting in a kdump-tools service failure on first boot. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Fix Released Status in linux-nvidia package in Ubuntu: Invalid Status in kdump-tools source package in Jammy: In Progress Status in linux-nvidia source package in Jammy: Invalid Status in kdump-tools source package in Mantic: In Progress Status in linux-nvidia source package in Mantic: Invalid Status in kdump-tools source package in Noble: Fix Released Status in linux-nvidia source package in Noble: Invalid Bug description: [Impact] When installing in a chroot environment, the kdump-tools kernel hook will fail. This breaks certain OS image creation tools, such as BCM (which I assume is NVIDIA Base Command Manager from context). While BCM's image generation tool requires some additional tweaks to consume this, the proposed fix is necessary, and should be sufficient for other tools that use chroots. [Test Plan] 1) debootstrap a chroot environment for the target Ubuntu release 2) Install kdump-tools within that environment 3) Install a kernel package and make sure it succeeds. 4) do the same steps in a virtual machine, but with `ischroot` symlinked to /dev/true at install time. This should simulate a system that was just installed with an image prepared as above. 5) Then restore ischroot, and reboot. 6) Confirm the systemd service does generate an initramfs at boot, and 7) that a crash dump can be triggered afterwords. [Where Problems Could Occur] The solution we implemented in noble was simply to detect a chroot environment with ischroot, and disable initramfs generation. The systemd service will detect that an initrd is missing, and generate one on first boot. A source of potential problems is if that does not happen for some reason, resulting in a kdump-tools service failure on first boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net
[Kernel-packages] [Bug 2043059] Re: Installation errors out when installing in a chroot
** Also affects: linux-nvidia (Ubuntu Noble) Importance: Undecided Status: Invalid ** Also affects: kdump-tools (Ubuntu Noble) Importance: Undecided Assignee: dann frazier (dannf) Status: Fix Released ** Also affects: linux-nvidia (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: kdump-tools (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux-nvidia (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: kdump-tools (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux-nvidia (Ubuntu Mantic) Status: New => Invalid ** Changed in: linux-nvidia (Ubuntu Jammy) Status: New => Invalid ** Changed in: kdump-tools (Ubuntu Mantic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: kdump-tools (Ubuntu Jammy) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: kdump-tools (Ubuntu Mantic) Status: New => In Progress ** Changed in: kdump-tools (Ubuntu Jammy) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. Matching subscriptions: Maintainer https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Fix Released Status in linux-nvidia package in Ubuntu: Invalid Status in kdump-tools source package in Jammy: In Progress Status in linux-nvidia source package in Jammy: Invalid Status in kdump-tools source package in Mantic: In Progress Status in linux-nvidia source package in Mantic: Invalid Status in kdump-tools source package in Noble: Fix Released Status in linux-nvidia source package in Noble: Invalid Bug description: Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 5.15.0-1040-nvidia ...done. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia cryptsetup: WARNING: Couldn't determine root device W: Couldn't identify type of root file system for fsck hook cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory /etc/kernel/postinst.d/kdump-tools: kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /var/lib/kdump/initramfs-tools Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia with 1. run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1 dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure): installed linux-image-5.15.0-1040-nvidia package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: linux-image-5.15.0-1040-nvidia E: Sub-process /usr/bin/dpkg returned an error code (1) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2051941] [NEW] autopkgtest fails: EE: Missing modules
Public bug reported: From https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- jammy/jammy/arm64/l/linux-nvidia-6.5/20240131_012859_fd7ca@/log.gz: 7141s dpkg-deb: building package 'linux-nvidia-6.5-tools-6.5.0-1011' in '../linux-nvidia-6.5-tools-6.5.0-1011_6.5.0-1011.11_arm64.deb'. 7150s Debug: module-check-nvidia 7150s debian/scripts/checks/module-check "nvidia" \ 7150s "/tmp/autopkgtest.99vLuG/build.vn7/src/debian.nvidia-6.5/abi/arm64" "/tmp/autopkgtest.99vLuG/build.vn7/src/debian.nvidia-6.5/__abi.current/arm64" 7150s II: Checking modules for nvidia... 7150s Reading modules to ignore...read 11 modules. 7150s Reading new modules...read 8037 modules. 7150s Reading old modules...read 8040 modules. 7150s II: Checking for modules changes... 7150s MISS : mstflint_access 7150s MISS : spl (ignored) 7150s MISS : zfs (ignored) 7150s EE: Missing modules 7150s make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia] Error 1 7150s dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 7150s autopkgtest [01:14:33]: test rebuild: ---] 7152s rebuild FAIL non-zero exit status 2 ** Affects: linux-nvidia-6.5 (Ubuntu) Importance: Undecided Status: New ** Affects: linux-nvidia-6.5 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-nvidia-6.5 (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051941 Title: autopkgtest fails: EE: Missing modules Status in linux-nvidia-6.5 package in Ubuntu: New Status in linux-nvidia-6.5 source package in Jammy: New Bug description: From https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- jammy/jammy/arm64/l/linux-nvidia-6.5/20240131_012859_fd7ca@/log.gz: 7141s dpkg-deb: building package 'linux-nvidia-6.5-tools-6.5.0-1011' in '../linux-nvidia-6.5-tools-6.5.0-1011_6.5.0-1011.11_arm64.deb'. 7150s Debug: module-check-nvidia 7150s debian/scripts/checks/module-check "nvidia" \ 7150s "/tmp/autopkgtest.99vLuG/build.vn7/src/debian.nvidia-6.5/abi/arm64" "/tmp/autopkgtest.99vLuG/build.vn7/src/debian.nvidia-6.5/__abi.current/arm64" 7150s II: Checking modules for nvidia... 7150s Reading modules to ignore...read 11 modules. 7150s Reading new modules...read 8037 modules. 7150s Reading old modules...read 8040 modules. 7150s II: Checking for modules changes... 7150s MISS : mstflint_access 7150s MISS : spl (ignored) 7150s MISS : zfs (ignored) 7150s EE: Missing modules 7150s make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia] Error 1 7150s dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 7150s autopkgtest [01:14:33]: test rebuild: ---] 7152s rebuild FAIL non-zero exit status 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.5/+bug/2051941/+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 2051942] [NEW] autopkgtest fails: EE Missing modules
Public bug reported: From https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- jammy/jammy/arm64/l/linux-nvidia-tegra-igx/20240121_072109_094a7@/log.gz : 6243s dpkg-deb: building package 'linux-nvidia-tegra-igx-tools-5.15.0-1007' in '../linux-nvidia-tegra-igx-tools-5.15.0-1007_5.15.0-1007.7_arm64.deb'. 6253s Debug: module-check-nvidia-tegra-igx 6253s debian/scripts/module-check "nvidia-tegra-igx" \ 6253s "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/abi/arm64" "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/__abi.current/arm64" 6254s II: Checking modules for nvidia-tegra-igx... 6254s read 11 modules. 6254sreading new modules...read 7343 modules. 6254sreading old modules... 6254s MISS: ar1335_common 6254s MISS: arm64-ras 6254s MISS: bluedroid_pm 6254s MISS: bmi088 6254s MISS: cam_cdi_tsc [...] 6254s MISS: tegracam_log 6254s MISS: ti_fpdlink_dp_serializer 6254s MISS: tsecriscv 6254s MISS: ufs-tegra 6254s MISS: ufs-tegra-provision 6254s MISS: userspace_ivc_mempool 6254s MISS: virtual_i2c_mux 6254s MISS: watchdog-tegra-t18x 6254s MISS: wch 6254s NEW: pps-ktimer 6254s read 7498 modules : new(1) missing(154) 6254s EE: Missing modules 6254s make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia-tegra-igx] Error 1 6254s dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 6254s autopkgtest [07:05:29]: test rebuild: ---] 6259s autopkgtest [07:05:34]: test rebuild: - - - - - - - - - - results - - - - - - - - - - 6259s rebuild FAIL non-zero exit status 2 ** Affects: linux-nvidia-tegra (Ubuntu) Importance: Undecided Status: New ** Affects: linux-nvidia-tegra (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-nvidia-tegra (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia-tegra in Ubuntu. https://bugs.launchpad.net/bugs/2051942 Title: autopkgtest fails: EE Missing modules Status in linux-nvidia-tegra package in Ubuntu: New Status in linux-nvidia-tegra source package in Jammy: New Bug description: From https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- jammy/jammy/arm64/l/linux-nvidia-tegra- igx/20240121_072109_094a7@/log.gz : 6243s dpkg-deb: building package 'linux-nvidia-tegra-igx-tools-5.15.0-1007' in '../linux-nvidia-tegra-igx-tools-5.15.0-1007_5.15.0-1007.7_arm64.deb'. 6253s Debug: module-check-nvidia-tegra-igx 6253s debian/scripts/module-check "nvidia-tegra-igx" \ 6253s "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/abi/arm64" "/tmp/autopkgtest.MfAsoT/build.Xbz/src/debian.nvidia-tegra-igx/__abi.current/arm64" 6254s II: Checking modules for nvidia-tegra-igx... 6254s read 11 modules. 6254sreading new modules...read 7343 modules. 6254sreading old modules... 6254s MISS: ar1335_common 6254s MISS: arm64-ras 6254s MISS: bluedroid_pm 6254s MISS: bmi088 6254s MISS: cam_cdi_tsc [...] 6254s MISS: tegracam_log 6254s MISS: ti_fpdlink_dp_serializer 6254s MISS: tsecriscv 6254s MISS: ufs-tegra 6254s MISS: ufs-tegra-provision 6254s MISS: userspace_ivc_mempool 6254s MISS: virtual_i2c_mux 6254s MISS: watchdog-tegra-t18x 6254s MISS: wch 6254s NEW: pps-ktimer 6254s read 7498 modules : new(1) missing(154) 6254s EE: Missing modules 6254s make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia-tegra-igx] Error 1 6254s dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 6254s autopkgtest [07:05:29]: test rebuild: ---] 6259s autopkgtest [07:05:34]: test rebuild: - - - - - - - - - - results - - - - - - - - - - 6259s rebuild FAIL non-zero exit status 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-tegra/+bug/2051942/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
The test passed w/ flock as well: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-loop/noble/amd64/l/livecd-rootfs/20240131_104633_df869@/log.gz 274 successful iterations before the timeout killed it. I've updated the MP: https://code.launchpad.net/~dannf/livecd-rootfs/+git/livecd-rootfs/+merge/459549 -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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
Re: [Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
On Tue, Jan 30, 2024 at 6:21 PM Michael Hudson-Doyle <2045...@bugs.launchpad.net> wrote: > > Oh wait, we've been through something very like this before > https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1834875. I suspect > a judicious application of flock may be the most correct solution > available. ACK - I'll switch over to flock and run another test. -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
I updated my livecd-rootfs PPA test package that runs this section of code in a loop to use this pattern, and it survived until the autopkgtest timeout - 304 iterations: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf- loop/noble/amd64/l/livecd-rootfs/20240128_061640_5c909@/log.gz ...when it previously was failing reliably within a few iterations. They `udevadm lock` fix is now in unstable, so the next sync should pull it in. However, I don't know that we really need any features of `udevadm lock` beyond the actual flock'ing of the device. We could presumably do that with `flock` for older releases. Or we could consider SRU'ing back the udevadm lock command to jammy as a low priority SRU. The way it was introduced looks very non-invasive: https://github.com/systemd/systemd/commit/8b12a516e9304f720e07eeec5d25c5b7f7104bc9 But I haven't gone through the bug fixes since to ensure it remained that way. -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
I was bothered by the fact that we only sometimes see the double partition rescan in dmesg. If udev always rescans the partitions of a full block devices, shouldn't we always see those messages twice? It turns out that udev doesn't rescan partitions just because a new block device appears. When it gets a uevent for a full block device, it registers an inotify watch on the device file for any process closing a file that was open in write mode. Presumably that process could've changed the partitions so, when that inotify event fires, it requests a partition rescan. In our case, losetup has opened /dev/loop0 in write mode. When it calls into the LOOP_CONFIGURE ioctl(), a uevent will fire for /dev/loop0. If udev processes that event and adds the inotify watch before losetup closes the device, then closing the device will trigger the inotify event and udev will rescan. I don't see a way to order operations to prevent this race. And I don't think we can "settle" our way out of it, because its not a uevent we're racing with, its the inotify event. But it looks like systemd may already have a solution for that: https://systemd.io/BLOCK_DEVICE_LOCKING/ I think as long as we run all of our commands that access the partition device files under `udevadm lock -d `, then systemd should not trigger a partition reread underneath us. Here's what I'm thinking: https://code.launchpad.net/~dannf/livecd-rootfs/+git/livecd- rootfs/+merge/459549 Of course, udevadm lock didn't exist until after jammy. And all versions that do have it, including the one in v255 in noble-proposed, are broken and need this patch backport: https://github.com/systemd/systemd/commit/ba340e2a75a0a16031fcb7efa05cfd250e859f17 -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
That kernel change doesn't fix the issue: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf- loop/noble/amd64/l/livecd-rootfs/20240125_203808_8b5c9@/log.gz Which actually didn't surprise me after thinking about it. systemd-udevd is going to ask for a partition reread when it gets the uevent for loop0 at some point - it doesn't matter if we hold it off until losetup's reread completes. There will always be a window where the partition device files disappear and reappear. Perhaps we just need a `udevadm wait $rootfs_dev_mapper --settle`. -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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
Re: [Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
On Tue, Jan 23, 2024 at 8:55 PM Michael Hudson-Doyle <2045...@bugs.launchpad.net> wrote: > > Amazing debugging Dann. Until we can get a kernel fix, what's the way > forward here? Run losetup without -P, run udevadm settle, run partprobe > on the device (then maybe run udevadm settle again??) That seems logical. I don't see the need for the 2nd udevadm settle - but I also don't see the harm. I've a test fix kernel building in a PPA. I think Łukasz mentioned that there's a way to have an autopkgtest run on a specific kernel? Can someone give me those steps? -dann -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2033418] Re: Ubuntu desktop does not appear on DGX Station A100 discrete GPU by default
We're checking to see if the system behaves the same with NVIDIA's
BaseOS. If it is, we'll probably move on and this can move to Won't Fix.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
https://bugs.launchpad.net/bugs/2033418
Title:
Ubuntu desktop does not appear on DGX Station A100 discrete GPU by
default
Status in linux-nvidia package in Ubuntu:
Incomplete
Status in nvidia-graphics-drivers-535 package in Ubuntu:
Incomplete
Status in nvidia-graphics-drivers-535-server package in Ubuntu:
Incomplete
Bug description:
The DGX Station A10 has various display options. The BMC provides an
emulated device (Aspeed controller), a physical BMC controller (NVIDIA
Quadro T1000 Mobile), and a discrete GPU card with 4 DisplayPort
outputs (A100 SXM4 80GB). See the user guide[*] for a diagram.
In a default Ubuntu Desktop 22.04 ('jammy') install, nothing appears
on the A100 DisplayPort output.
NVIDIA DGX OS - a derivative of Ubuntu - works around this by
installing a service that generates an xorg config file dynamically
based on the "OnBrd/Ext VGA Select" setting (aka "dmidecode -t 11").
I'll attach samples of those files here. Replacing the default Ubuntu
xorg.conf file with the sample xorg-nvidia.conf file on a default
Ubuntu Desktop install is confirmed to enable output.
[*] https://docs.nvidia.com/dgx/dgx-station-a100-user-guide/getting-
started-station-a100.html
(Note: split from bug 2031367)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2033418/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
** Summary changed: - livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble + livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble
I ran the above test: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dannf-test/jammy/amd64/l/livecd-rootfs/20240123_035147_6470b@/log.gz It does appear that systemd-udevd is trying to scan partitions at the same time as losetup: 1599s ++ losetup --show -f -P -v binary/boot/disk-uefi.ext4 1600s + loop_device=/dev/loop0 1600s + '[' '!' -b /dev/loop0 ']' 1600s + rootfs_dev_mapper=/dev/loop0p1 1600s + '[' '!' -b /dev/loop0p1 ']' 1600s + echo '/dev/loop0p1 is not a block device' 1600s /dev/loop0p1 is not a block device 1600s + echo '=== dmesg ===' 1600s === dmesg === 1600s + dmesg -c 1600s [ 986.014824] EXT4-fs (loop0p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. 1600s [ 992.684380] EXT4-fs (loop0p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. 1600s [ 1043.171603] loop0: detected capacity change from 0 to 4612096 1600s [ 1043.171924] loop0: p1 p14 p15 1600s [ 1043.190421] loop0: p1 p14 p15 1600s + cat /sys/kernel/debug/tracing/trace 1600s # tracer: function 1600s # 1600s # entries-in-buffer/entries-written: 2/2 #P:4 1600s # 1600s #_-=> irqs-off 1600s # / _=> need-resched 1600s # | / _---=> hardirq/softirq 1600s # || / _--=> preempt-depth 1600s # ||| / _-=> migrate-disable 1600s # / delay 1600s # TASK-PID CPU# | TIMESTAMP FUNCTION 1600s # | | | | | | 1600s losetup-50167 [002] . 1043.176845: bdev_disk_changed <-loop_reread_partitions 1600ssystemd-udevd-321 [000] . 1043.195003: bdev_disk_changed <-blkdev_get_whole 1600s + echo 0 1600s + ls -l /dev/loop0p1 1600s brw--- 1 root root 259, 3 Jan 23 03:51 /dev/loop0p1 1600s + exit 1 1600s + clean_loops Maybe we just need something like this? diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 48c530b83000e..52fda87f5d674 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1366,13 +1366,13 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, if (partscan) lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN; - /* enable and uncork uevent now that we are done */ - dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); - loop_global_unlock(lo, is_loop); if (partscan) loop_reread_partitions(lo); + /* enable and uncork uevent now that we are done */ + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); + if (!(mode & FMODE_EXCL)) bd_abort_claiming(bdev, loop_configure); -- 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/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble
I ran into this on jammy/amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-
jammy/jammy/amd64/l/livecd-rootfs/20240121_173406_e4f9a@/log.gz
I downloaded all of the amd64 failures and searched for this failure
pattern. These were the kernels that were running at the time:
"Linux 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023"
"Linux 6.2.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 14 12:34:02 UTC
2023"
"Linux 6.3.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Thu Jun 8 16:02:30 UTC
2023"
"Linux 6.5.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 7 01:35:40 UTC
2023"
"Linux 6.6.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:27:29 UTC
2023"
Here's the count of failures per image type:
12 017-disk-image-uefi.binary
3 018-disk-image.binary
3 020-kvm-image.binary
1 023-vagrant.binary
1 024-vagrant.binary
I can confirm that /dev/loop0p1 is created by devtmpfs. This surprised
me because I'd never actually need to know what devtmpfs was, and I saw
devices being created even though I had SIGSTOP'd systemd-udevd. But
watching udevadm monitor and forktrace output convinced me.
I had a theory that something was opening the first created partition before
all partitions were created. loop_reread_partitions() can fail without
returning an error to userspace:
https://elixir.bootlin.com/linux/v5.15.147/source/drivers/block/loop.c#L676
that could happen if bdev_disk_changed() aborts because it finds another
partition on the device is open:
https://elixir.bootlin.com/linux/v5.15.147/source/block/partitions/core.c#L662
But then we should see this in dmesg:
pr_warn("%s: partition scan of loop%d (%s) failed (rc=%d)\n"
I added dmesg calls to check that:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dannf-test/jammy/amd64/l/livecd-rootfs/20240122_161631_62ecd@/log.gz
.. but no such message appeared, so that's not it. But what *is*
interesting there is that it shows *2* partition scan lines:
1248s [ 990.855361] loop0: detected capacity change from 0 to 4612096
1248s [ 990.855628] loop0: p1 p14 p15
1248s [ 990.874241] loop0: p1 p14 p15
Previously we just saw 1:
1189s [ 932.268459] loop0: detected capacity change from 0 to 4612096
1189s [ 932.268715] loop0: p1 p14 p15
That only gets printed when bdev_disk_changed() is called. So do we have
2 racing callers?
One thing that seems off is that loop_configure() unsuppresses uevents
for the full device before the partition scan, but loop_change_fd()
waits until the partition scan is complete. Shouldn't they be following
the same pattern? I wonder if that could cause the following race:
[livecd-rootfs] losetup creates /dev/loop0
[livecd-rootfs] kernel sends uevent for /dev/loop0
[livecd-rootfs] /dev/loop0p* appear in devtmpfs
[udev] receives uevent for loop0
[udev] partprobe /dev/loop0
[livecd-rootfs] losetup exit(0)
[partprobe] /dev/loop0p* cleared
[livecd-rootfs] check for /dev/loop0p1 FAILS
[partprobe] /dev/loop0p* recreated
I tried checking for this using ftrace in a local jammy VM. I haven't been able
to reproduce this in a local VM, but I wanted to see what happens in a normal
losetup.. er... setup.
> First I used losetup to create the device:
root@dannf-livecd-rootfs-debug:/sys/kernel/debug/tracing# loopdev="$(losetup
--show -f -P -v /home/ubuntu/disk.img)"
root@dannf-livecd-rootfs-debug:/sys/kernel/debug/tracing# cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 1/1 #P:1
#
#_-=> irqs-off
# / _=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# / delay
# TASK-PID CPU# | TIMESTAMP FUNCTION
# | | | | | |
losetup-1996[000] . 657.573994: bdev_disk_changed
<-loop_reread_partitions
> Only the expected bdev_disk_change() call
> Then I remove the device:
root@dannf-livecd-rootfs-debug:/sys/kernel/debug/tracing# losetup -v -d $loopdev
root@dannf-livecd-rootfs-debug:/sys/kernel/debug/tracing# cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 3/3 #P:1
#
#_-=> irqs-off
# / _=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# / delay
# TASK-PID CPU# | TIMESTAMP FUNCTION
# | | | | | |
losetup-1996[000] . 657.573994: bdev_disk_changed
<-loop_reread_partitions
systemd-udevd-2524[000] . 680.555336: bdev_disk_changed
<-blkdev_get_whole
Re: [Kernel-packages] [Bug 2043059] Re: Installation errors out when installing in a chroot
On Fri, Dec 15, 2023 at 3:55 PM Sam Tannous <2043...@bugs.launchpad.net> wrote: > > You're correct. It can fail for other reasons. I don't think we could check > the errno, could we? It would be 1, "Operation not permitted". The exit code is not documented in the manpage, and it appears to exit 1 with other failure types: root@dannf-kdump-chroot:~# unshare -U true unshare: unshare failed: No space left on device root@dannf-kdump-chroot:~# echo $? 1 I also suspect this is not the only situation that could return -EPERM. > If not, I think we can live with the last suggestion. ACK. As you can see above, I've uploaded that change to noble, and will begin the SRU process back to jammy. -dann -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Fix Released Status in linux-nvidia package in Ubuntu: Invalid Bug description: Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 5.15.0-1040-nvidia ...done. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia cryptsetup: WARNING: Couldn't determine root device W: Couldn't identify type of root file system for fsck hook cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory /etc/kernel/postinst.d/kdump-tools: kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /var/lib/kdump/initramfs-tools Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia with 1. run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1 dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure): installed linux-image-5.15.0-1040-nvidia package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: linux-image-5.15.0-1040-nvidia E: Sub-process /usr/bin/dpkg returned an error code (1) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
Cool, thanks for testing Sam. Apologies for the missing ${SW_IMG}.
And thanks for the 'unshare -U true' suggestion. I gather your point is
that 'unshare -U' will fail in any chroot environment. I'm not an expert
on namespaces but, from what I can tell, that does seem to be true in
all modern kernels as you say. However, 'unshare -U' can fail for other
reasons too - say, if the admin set /proc/sys/user/max_user_namespaces
to 0, or when running a kernel with CONFIG_USER_NS=n. If we assume all
failures mean we are in a chroot, then we risk not configuring kdump in
such environments.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
https://bugs.launchpad.net/bugs/2043059
Title:
Installation errors out when installing in a chroot
Status in kdump-tools package in Ubuntu:
Triaged
Status in linux-nvidia package in Ubuntu:
Invalid
Bug description:
Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ...
/etc/kernel/postinst.d/dkms:
* dkms: running auto installation service for kernel 5.15.0-1040-nvidia
...done.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia
cryptsetup: WARNING: Couldn't determine root device
W: Couldn't identify type of root file system for fsck hook
cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory
/etc/kernel/postinst.d/kdump-tools:
kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /var/lib/kdump/initramfs-tools
Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia
with 1.
run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1
dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure):
installed linux-image-5.15.0-1040-nvidia package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-5.15.0-1040-nvidia
E: Sub-process /usr/bin/dpkg returned an error code (1)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
hey Sam,
I looked into ways to try to teach the chroot detection tools how to
detect a chroot in a new pid namespace (which is actually the problem,
not the mount namespace), but I didn't find a good solution there.
However, it occurs to me that you can simply override the answer:
ln -sf ../../bin/true ${SW_IMG}/usr/local/bin/ischroot
echo 'DPkg::Path "/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin";' >
/etc/apt/apt.conf.d/99-usr-local-dpkg-path
unshare -p -u -f --mount-proc="${SW_IMG}/proc" chroot "${SW_IMG}"
"${CHROOT_SCRIPT}"
EXIT_CODE=$?
rm ${SW_IMG}/etc/apt/apt.conf.d/99-usr-local-dpkg-path
rm ${SW_IMG}/usr/local/bin/ischroot
That would have the added benefit of solving the problem for
other/future packages as well.
If we were to update kdump-tools to detect a chroot as described in
comment #7 (test build in
https://launchpad.net/~dannf/+archive/ubuntu/lp2043059 ), could you
update your script to do the above?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-nvidia in Ubuntu.
https://bugs.launchpad.net/bugs/2043059
Title:
Installation errors out when installing in a chroot
Status in kdump-tools package in Ubuntu:
Triaged
Status in linux-nvidia package in Ubuntu:
Invalid
Bug description:
Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ...
/etc/kernel/postinst.d/dkms:
* dkms: running auto installation service for kernel 5.15.0-1040-nvidia
...done.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia
cryptsetup: WARNING: Couldn't determine root device
W: Couldn't identify type of root file system for fsck hook
cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory
/etc/kernel/postinst.d/kdump-tools:
kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /var/lib/kdump/initramfs-tools
Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia
with 1.
run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1
dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure):
installed linux-image-5.15.0-1040-nvidia package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-5.15.0-1040-nvidia
E: Sub-process /usr/bin/dpkg returned an error code (1)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
** Also affects: kdump-tools (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-nvidia (Ubuntu) Status: New => Invalid ** Changed in: kdump-tools (Ubuntu) Status: New => Triaged ** Changed in: kdump-tools (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kdump-tools in Ubuntu. Matching subscriptions: Maintainer https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in kdump-tools package in Ubuntu: Triaged Status in linux-nvidia package in Ubuntu: Invalid Bug description: Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 5.15.0-1040-nvidia ...done. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia cryptsetup: WARNING: Couldn't determine root device W: Couldn't identify type of root file system for fsck hook cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory /etc/kernel/postinst.d/kdump-tools: kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /var/lib/kdump/initramfs-tools Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia with 1. run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1 dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure): installed linux-image-5.15.0-1040-nvidia package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: linux-image-5.15.0-1040-nvidia E: Sub-process /usr/bin/dpkg returned an error code (1) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/2043059/+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 2043059] Re: Installation errors out when installing in a chroot
Thanks for providing that script Sam. Jamie has nailed the problem in Comment #2. A *seemingly* obvious solution is to add code to the /etc/kernel/postinst.d/kdump-tools hook that detects when it is running in a chroot, and if so, exits before trying to make an initramfs. When the real system boots, the kdump-tools should detect that no initramfs for the running kernel exists, and it can generate a proper one at that time. There are 2 tools in Debian/Ubuntu that packages use to detect if you are running in a chroot - `ischroot` and `systemd-detect-virt --chroot`. So I asked the team to test this out: https://salsa.debian.org/dannf/kdump-tools/-/commit/2b70360d6aeaa0874e2cbd917f39e3fcaa3f56be This seems to DTRT. But it appears not to work with your cm-chroot-sw- img script. That script fools both chroot detection tools. This is due to the use of `unshare --mount-proc`. I believe this is because that causes unshare to place everything in a new mount namespace, whereas these tools rely on pid 1's "/" being different than the chroot'd "/" to detect the chroot. If you'd be able to remove --mount-proc, then we can look into adding such code. An alternative option is to add a diversion for /etc/kernel/postinst.d/kdump-tools before installing packages in your chroot: $ sudo dpkg-divert --divert /etc/kernel/postinst.d/kdump-tools.disabled \ --rename /etc/kernel/postinst.d/kdump-tools run-parts won't exec hooks with a "." in the name, so this will prevent the hook from firing until the diversion is later removed. You can add this diversion whether or not kdump-tools is installed. If the diversion is in place, it will rename the file for you automatically when you do install kdump-tools. Once you are done installing packages, you can then remove the diversion to re-enable the hook: $ sudo dpkg-divert --rename --remove /etc/kernel/postinst.d/kdump-tools Removing 'local diversion of /etc/kernel/postinst.d/kdump-tools to /etc/kernel/postinst.d/kdump-tools.disabled' -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2043059 Title: Installation errors out when installing in a chroot Status in linux-nvidia package in Ubuntu: New Bug description: Processing triggers for linux-image-5.15.0-1040-nvidia (5.15.0-1040.40) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 5.15.0-1040-nvidia ...done. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.15.0-1040-nvidia cryptsetup: WARNING: Couldn't determine root device W: Couldn't identify type of root file system for fsck hook cp: cannot stat '/etc/iscsi/initiatorname.iscsi': No such file or directory /etc/kernel/postinst.d/kdump-tools: kdump-tools: Generating /var/lib/kdump/initrd.img-5.15.0-1040-nvidia mkinitramfs: failed to determine device for / mkinitramfs: workaround is MODULES=most, check: grep -r MODULES /var/lib/kdump/initramfs-tools Error please report bug on initramfs-tools Include the output of 'mount' and 'cat /proc/mounts' update-initramfs: failed for /var/lib/kdump/initrd.img-5.15.0-1040-nvidia with 1. run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1 dpkg: error processing package linux-image-5.15.0-1040-nvidia (--configure): installed linux-image-5.15.0-1040-nvidia package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: linux-image-5.15.0-1040-nvidia E: Sub-process /usr/bin/dpkg returned an error code (1) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2043059/+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 2042897] [NEW] Bump arm64's CONFIG_NR_CPUS to 512
Public bug reported: arm64 server platforms have been announced that will have more cores than the max of 256 that we currently support. For example, systems w/ 2 NVIDIA Grace chips, each of containing 2 nodes of 72 cores = 288. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) -- 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/2042897 Title: Bump arm64's CONFIG_NR_CPUS to 512 Status in linux package in Ubuntu: In Progress Bug description: arm64 server platforms have been announced that will have more cores than the max of 256 that we currently support. For example, systems w/ 2 NVIDIA Grace chips, each of containing 2 nodes of 72 cores = 288. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2042897/+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 1800562] Re: Remove obsolete "nousb" option in kdump command-line for newer kernels
** Also affects: kdump-tools (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: kdump-tools (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
Matching subscriptions: Maintainer
https://bugs.launchpad.net/bugs/1800562
Title:
Remove obsolete "nousb" option in kdump command-line for newer kernels
Status in makedumpfile package in Ubuntu:
Confirmed
Status in kdump-tools source package in Xenial:
New
Status in makedumpfile source package in Xenial:
Won't Fix
Status in kdump-tools source package in Bionic:
New
Status in makedumpfile source package in Bionic:
Confirmed
Status in kdump-tools source package in Eoan:
New
Status in makedumpfile source package in Eoan:
Won't Fix
Status in kdump-tools source package in Focal:
New
Status in makedumpfile source package in Focal:
Confirmed
Status in kdump-tools source package in Groovy:
New
Status in makedumpfile source package in Groovy:
Won't Fix
Bug description:
[Impact]
* Kdump command-line include an obsolete "nousb" parameter by default, which
can cause a misimpression: users will think they are not booting with USB, but
they are.
* Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case
the subsystem is built-in). This was changed by commit 097a9ea0e48
("usb: make "nousb" a clear module parameter").
* USB may be pretty essential in case for example kdump users need to
decrypt a disk under LUKS, and there's only an USB keyboard connected
to the system. Given the option is innocuous since Bionic, we should
just drop it to prevent confusion.
[Test Case]
1) Deploy a Disco VM e.g. with uvt-kvm
2) Install the kdump-tools package
3) Run `kdump-config test`and check for the 'nousb' parameter:
$ kdump-config test
...
kexec command to be used:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
[Regression Potential]
The regression potential is extremely low, since the "nousb" parameter
is not used since Bionic although is there. Any bugs we would have by
changing this are still valid by not removing the option - the
semantics with or without "nosub" is the same since from Bionic.
NOTICE we won't change Xenial, it can use kernel 4.4 which indeed
disables USB by taking the "nousb" parameter.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+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 2035123] Re: scripts/pahole-flags.sh needs upstream fix
** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-bluefield (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => Triaged ** Changed in: linux-bluefield (Ubuntu Jammy) Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2035123 Title: scripts/pahole-flags.sh needs upstream fix Status in linux package in Ubuntu: Incomplete Status in linux-bluefield package in Ubuntu: Triaged Status in linux source package in Jammy: Triaged Status in linux-bluefield source package in Jammy: Triaged Bug description: When doing a kernel make in our Jammy repo we notice the follow error being emitted: ./scripts/pahole-flags.sh: line 7: return: can only `return' from a function or sourced script It appears that while the Jammy baseline is 5.15.99 (as per the top-level Makefile) the file scripts/pahole-flags.sh is out of date with upstream 5.15.99 The upstream 5.15.99 version of scripts/pahole-flags.sh fixes this issue by making this change: 7c7 < return --- > exit 0 This seems like a simple fix, but not sure who should be fixing this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2035123/+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 2035123] Re: scripts/pahole-flags.sh needs upstream fix
It appears that Linus applied a fix for this directly in a merge commit: https://github.com/torvalds/linux/commits/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4 When the change with this bug was backported to stable, the fix was squashed. But we appear to have cherry-picked the version from mainline instead of the one from stable which had the bug. ** Changed in: linux-bluefield (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/2035123 Title: scripts/pahole-flags.sh needs upstream fix Status in linux-bluefield package in Ubuntu: Triaged Bug description: When doing a kernel make in our Jammy repo we notice the follow error being emitted: ./scripts/pahole-flags.sh: line 7: return: can only `return' from a function or sourced script It appears that while the Jammy baseline is 5.15.99 (as per the top-level Makefile) the file scripts/pahole-flags.sh is out of date with upstream 5.15.99 The upstream 5.15.99 version of scripts/pahole-flags.sh fixes this issue by making this change: 7c7 < return --- > exit 0 This seems like a simple fix, but not sure who should be fixing this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2035123/+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 2031367] Re: Archive races can cause nvidia driver / kernel version ABI mismatch
** Summary changed: - No video output from discrete GPU (DGX Station A100) + Archive races can cause nvidia driver / kernel version ABI mismatch ** Also affects: linux-restricted-modules (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/2031367 Title: Archive races can cause nvidia driver / kernel version ABI mismatch Status in Ubuntu: Confirmed Status in linux-restricted-modules package in Ubuntu: New Bug description: [Summary] after selecting ubuntu from bios boot menu, it lost video output from the discrete GPU * build-in VGA port works fine, can output the display to monitor and boot into OS only the discrete GPU has issue [Steps to reproduce] It is not currently reproducible but, at some point in the past, these steps resulted in the problem: 1. install 22.04 2. install linux-nvidia 3. install linux-modules-nvidia-535-server-nvidia [Actual result] linux-nvidia w/ a 1030 ABI got installed with a linux-modules-nvidia-535-server-nvidia with a 1029 ABI. [Additional information] CID: 202307-31886 SKU: DGX station A100 system-manufacturer: NVIDIA system-product-name: DGX Station A100 920-23487-2531-000 bios-version: L9.28C CPU: AMD EPYC 7742 64-Core Processor (128x) GPU: 01:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 SXM4 80GB] [10de:20b2] (rev a1) 46:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 41) 47:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 SXM4 80GB] [10de:20b2] (rev a1) 81:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 SXM4 80GB] [10de:20b2] (rev a1) c1:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb0] (rev a1) c2:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 SXM4 80GB] [10de:20b2] (rev a1) Nvidia Driver: 535.54.03 kernel-version: 5.15.0-1030-nvidia [Stage] Issue reported and logs collected at a later stage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2031367/+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 2026891] Re: linux-nvidia-6.2 on DGX servers: "WARNING: CPU: 0 PID: 0 at init/main.c:1065 start_kernel+0x4da/0x540"
** Changed in: linux-nvidia-6.2 (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia-6.2 in Ubuntu. https://bugs.launchpad.net/bugs/2026891 Title: linux-nvidia-6.2 on DGX servers: "WARNING: CPU: 0 PID: 0 at init/main.c:1065 start_kernel+0x4da/0x540" Status in linux-nvidia-6.2 package in Ubuntu: In Progress Bug description: We started testing the jammy/linux-nvidia-6.2 kernels on the nvidia servers (DGX-1/DGX-2/H100) and hit the following warning during boot: [7.690486] [ cut here ] [7.690487] Interrupts were enabled early [7.690490] WARNING: CPU: 0 PID: 0 at init/main.c:1065 start_kernel+0x4da/0x540 [7.690498] Modules linked in: [7.690501] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.2.0-1004-nvidia #4~22.04.1-Ubuntu [7.690504] Hardware name: NVIDIA NVIDIA DGX-2/NVIDIA DGX-2, BIOS 0.29 06/07/2021 [7.690505] RIP: 0010:start_kernel+0x4da/0x540 [7.690508] Code: ff 48 c7 c7 e8 26 f0 97 e8 b3 59 a8 fd 0f 0b e9 96 fd ff ff e8 a7 1d 04 00 e9 7c fe ff ff 48 c7 c7 18 27 f0 97 e8 96 59 a8 fd <0f> 0b e9 ed fd ff ff 48 c7 c7 b0 26 f0 97 e8 83 59 a8 fd 0f 0b ff [7.690510] RSP: :98803f08 EFLAGS: 00010246 [7.690512] RAX: RBX: RCX: [7.690513] RDX: RSI: RDI: [7.690514] RBP: 98803f20 R08: R09: [7.690515] R10: R11: R12: 00e0 [7.690516] R13: 5a1ccde0 R14: 5a1c7469 R15: 5a1d7ee0 [7.690518] FS: () GS:96490060() knlGS: [7.690520] CS: 0010 DS: ES: CR0: 80050033 [7.690521] CR2: 970bf000 CR3: 00ecd7810001 CR4: 000606f0 [7.690522] DR0: DR1: DR2: [7.690523] DR3: DR6: fffe0ff0 DR7: 0400 [7.690524] Call Trace: [7.690526] [7.690529] x86_64_start_kernel+0x102/0x180 [7.690536] secondary_startup_64_no_verify+0xe5/0xeb [7.690544] [7.690544] ---[ end trace ]--- I also see pretty much the same thing on some Ampere based arm64 servers: [0.000519] [ cut here ] [0.000521] Interrupts were enabled early [0.000525] WARNING: CPU: 0 PID: 0 at init/main.c:1065 start_kernel+0x3ac/0x514 [0.000531] Modules linked in: [0.000535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.2.0-1004-nvidia #4~22.04.1-Ubuntu [0.000538] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [0.000540] pc : start_kernel+0x3ac/0x514 [0.000543] lr : start_kernel+0x3ac/0x514 [0.000545] sp : dec5ff733e60 [0.000546] x29: dec5ff733e60 x28: 0819aa09baac x27: 403ffdd124e0 [0.000549] x26: bfdf3788 x25: 9b6fc000 x24: 001dba7b [0.000552] x23: 5ec57c98 x22: 0819ab2a x21: dec5ff749140 [0.000555] x20: dec5ff73d9c0 x19: dec5ffbe4000 x18: dec5ff74a1c8 [0.000558] x17: x16: x15: [0.000560] x14: x13: 0a796c7261652064 x12: 656c62616e652065 [0.000563] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : [0.000565] x8 : x7 : x6 : [0.000568] x5 : x4 : x3 : [0.000571] x2 : x1 : x0 : [0.000573] Call trace: [0.000574] start_kernel+0x3ac/0x514 [0.000577] __primary_switched+0xc0/0xc8 [0.000580] ---[ end trace ]--- The warning does not appear on an older thunderx2 server. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.2/+bug/2026891/+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 2025396] Re: kdump/kexec does not work when UEFI secureboot and kernel lockdown enabled
It seems like this would impact the generic kernel as well, in which case, it would be nice to fix it there and let the -bluefield kernel inherit it via rebase. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/2025396 Title: kdump/kexec does not work when UEFI secureboot and kernel lockdown enabled Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) We've found that for Jammy 5.15 and also 5.4.0-1049 kernel running on Bluefield, the kdump doesn't work when enabling secure boot[1]. * How to test Make sure kernel config: CONFIG_SECURITY_LOCKDOWN_LSM=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_IN_SECURE_BOOT=y The kdump kernel we use is actually signed correctly # file /boot/vmlinuz-5.15.0-1015-bluefield /boot/vmlinuz-5.15.0-1015-bluefield: gzip compressed data, was "vmlinuz-5.15.0 1015-bluefield.efi.signed", # kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: 0xcfe0 /boot/vmlinuz-5.4.0-1049-bluefield kdump initrd: /boot/initrd.img-5.4.0-1049-bluefield current state:Not ready to kdump kdump-tools.service - Kernel crash dump capture service Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2023-04-13 19:21:01 UTC; 4 days ago Process: 1975 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS) Main PID: 1975 (code=exited, status=0/SUCCESS) Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net systemd[1]: Starting Kernel crash dump capture serv> Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[1975]: Starting kdump-tools: Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * Creating symlink /var/lib/kdu> Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * Creating symlink /var/lib/kdu> Apr 13 19:21:01 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2525]: syscall kexec_file_load not avai> Apr 13 19:21:01 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * failed to load kdump kernel * Possible reason Currently, a problem faced by arm64 is if a kernel image is signed by a MOK key, loading it via the kexec_file_load() system call would be rejected with the error in dmesg "Lockdown: kexec: kexec of unsigned images is restricted; see man kernel_lockdown.7". I backported the two below [2]: 0d519cadf751 arm64: kexec_file: use more system keyrings to verify kernel image signature c903dae8941d kexec, KEYS: make the code in bzImage64_verify_sig generic However still kdump/kexec fails due to lockdown [ 353.298348] Lockdown: kexec: kexec of unsigned images is restricted; see man kernel_lockdown.7 [ 364.833004] audit: type=1400 audit(1686619435.331:16): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cri-containerd.apparmor.d" pid=15407 comm="apparmor_parser" If I disable kernel lockdown (CONFIG_SECURITY_LOCKDOWN_LSM=n), then kexec works ok. But this is not an acceptable workaround. * How to fix I got it working (secure boot + lockdown config enabled + kdump/kexec) using kernel v6.4 on bluefield, which means if we backport properly, mostly missing some arch/arm64/ patches, to BlueField 5.15 kernel, we can get it working. Reference 1. https://docs.nvidia.com/networking/display/BlueFieldDPUOSv392/UEFI%20Secure%20Boot 2. https://www.spinics.net/lists/arm-kernel/msg979554.html 3. https://mjg59.dreamwidth.org/50577.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2025396/+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 1921536] Re: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch
This bug is about installing on a system with a different version of binutils. I assumed that is what you are doing because that is what this bug is about. But based on your comment @khteh, I now assume that you are not hitting the problem I reported. Do you have a reason to believe your issue is caused by binutils, or are you just seeing this same error message? modprobe: ERROR: could not insert 'nvidia': Key was rejected by service binutils version differences is not the only reason you might see that error. You may be having an issue unrelated to this bug. One possibility is that the installation method you selected is trying to build its own version of the module, which is not signed by a trusted Canonical key. The fact that you have a make.log at all (as shown in comment #19) is a hint there. nvidia-driver-535 will try to install the prebuilt and signed modules where possible, but if it can't, it will revert to installing the "source" and building an unsigned one instead. If you have the nvidia-dkms-535 driver installed instead of linux-modules-nvidia-535-generic, then that may be what happened. If that is the case, you can try switching to the prebuilt/signed one by running: sudo apt install nvidia-driver-535 linux-modules-nvidia-535-generic sudo apt remove nvidia-dkms-535 # ^ That should only remove nvidia-dkms-535 I hope that fixes your system. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1921536 Title: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch Status in linux package in Ubuntu: Confirmed Status in linux-restricted-modules package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-525 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-535 package in Ubuntu: Confirmed Bug description: If a user does not have the same version of binutils installed as the one used to produce the nvidia module signature, the module generated at postinst maybe unloadable: modprobe: ERROR: could not insert 'nvidia': Key was rejected by service I ran into this when I tried to install the hirsute kernel/nvidia driver on a focal system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921536/+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 2025616] Re: kernel Firmware Bug: TSC ADJUST differs failures during suspend
I was curious why this wasn't a problem with focal/5.4. I took a look at the last cert run that used focal/5.4[*], and I see these errors in the logs as well. I then went back to the cert run that was used to award focal certification[**] and those errors do *not* appear there. So either this is an intermittent failure, or likely one of 3 things happened in the interim: - The test changed (or was introduced) - The kernel changed - The firmware changed The test does not appear to be new - I have not checked if it has changed. The kernel version between these runs changed from 5.4.0-37.41-generic to 5.4.0-121.137-generic. A change to this kernel code was introduced in between, in 5.4.0-100.113-generic: commit 7dcfa07b500834c75a4f5043a43f409a3f02bd5e Author: Feng Tang Date: Wed Nov 17 10:37:50 2021 +0800 x86/tsc: Add a timer to make sure TSC_adjust is always checked BugLink: https://bugs.launchpad.net/bugs/1956381 commit c7719e79347803b8e3b6b50da8c6db410a3012b5 upstream. That causes the code that *might* print this warning to run every 10 minutes, instead of when the CPU enters idle. But the log shows these messages appearing every 28-29 seconds, so this being the cause seems unlikely. As for the firmware, the dmidecode output is identical between these runs, which suggests the firmware has not changed. [*] https://certification.canonical.com/hardware/201711-25989/submission/269263/ [**] https://certification.canonical.com/hardware/201711-25989/submission/172650/ -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2025616 Title: kernel Firmware Bug: TSC ADJUST differs failures during suspend Status in linux-nvidia package in Ubuntu: New Bug description: [Summary] Discoverd kernel error message during suspend stress test test case id: power-management/suspend_30_cycles_with_reboots collected log ~~~ High failures: s3: 180 failures HIGH Kernel message: [38779.612837] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5266754042. Restoring (x 3) HIGH Kernel message: [38839.622411] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5295340520. Restoring (x 3) HIGH Kernel message: [38868.467564] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5270514862. Restoring (x 3) HIGH Kernel message: [38897.419897] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5275834616. Restoring (x 3) HIGH Kernel message: [38926.135900] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5249511520. Restoring (x 3) HIGH Kernel message: [38955.114760] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5252454094. Restoring (x 3) HIGH Kernel message: [38983.860142] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5270474360. Restoring (x 3) HIGH Kernel message: [39012.819868] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5264045578. Restoring (x 3) ~~~ [Failure rate] 1/1 [Additional information] CID: 201711-25989 SKU: DGX-1 Station system-manufacturer: NVIDIA system-product-name: DGX Station bios-version: 0406 CPU: Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz (40x) GPU: 07:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 08:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 0f:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) nvidia-driver-version: 525.105.17 kernel-version: 5.15.0-1028-nvidia [Stage] Issue reported and logs collected at a later stage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2025616/+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 2025616] Re: kernel Firmware Bug: TSC ADJUST differs failures during suspend
** Package changed: ubuntu => linux-nvidia (Ubuntu) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-nvidia in Ubuntu. https://bugs.launchpad.net/bugs/2025616 Title: kernel Firmware Bug: TSC ADJUST differs failures during suspend Status in linux-nvidia package in Ubuntu: New Bug description: [Summary] Discoverd kernel error message during suspend stress test test case id: power-management/suspend_30_cycles_with_reboots collected log ~~~ High failures: s3: 180 failures HIGH Kernel message: [38779.612837] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5266754042. Restoring (x 3) HIGH Kernel message: [38839.622411] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5295340520. Restoring (x 3) HIGH Kernel message: [38868.467564] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5270514862. Restoring (x 3) HIGH Kernel message: [38897.419897] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5275834616. Restoring (x 3) HIGH Kernel message: [38926.135900] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5249511520. Restoring (x 3) HIGH Kernel message: [38955.114760] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5252454094. Restoring (x 3) HIGH Kernel message: [38983.860142] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5270474360. Restoring (x 3) HIGH Kernel message: [39012.819868] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -5264045578. Restoring (x 3) ~~~ [Failure rate] 1/1 [Additional information] CID: 201711-25989 SKU: DGX-1 Station system-manufacturer: NVIDIA system-product-name: DGX Station bios-version: 0406 CPU: Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz (40x) GPU: 07:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 08:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) 0f:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1db2] (rev a1) nvidia-driver-version: 525.105.17 kernel-version: 5.15.0-1028-nvidia [Stage] Issue reported and logs collected at a later stage To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2025616/+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 1921536] Re: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch
Canonical has provided a signature for an exact set of bytes in the .ko file. The packaging needs to relink the object files into that exact set of bytes on the target system for the signature to match. The relinking is required for license compliance AIUI. binutils does the linking. If you use a different version of binutils, it may generate a different set of bytes that fails the signature check. Can you elaborate on what you think Ubuntu should be doing differently? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1921536 Title: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch Status in linux package in Ubuntu: Confirmed Status in linux-restricted-modules package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-525 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-535 package in Ubuntu: Confirmed Bug description: If a user does not have the same version of binutils installed as the one used to produce the nvidia module signature, the module generated at postinst maybe unloadable: modprobe: ERROR: could not insert 'nvidia': Key was rejected by service I ran into this when I tried to install the hirsute kernel/nvidia driver on a focal system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921536/+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 1996915] Re: megaraid_sas crash in ubuntu 22.04
*** This bug is a duplicate of bug 2008157 *** https://bugs.launchpad.net/bugs/2008157 ** This bug has been marked a duplicate of bug 2008157 [SRU][Ubuntu 22.04.1]: Observed "Array Index out of bounds" Call Trace multiple times on Ubuntu 22.04.1 OS during boot -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1996915 Title: megaraid_sas crash in ubuntu 22.04 Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: New Status in linux source package in Kinetic: New Bug description: crash message for dmesg UBSAN: array-index-out-of-bounds in /build/linux-JjvoxS/linux-5.15.0/drivers/scsi/megaraid/megaraid_sas_fp.c:151:32 index 2 is out of range for type 'MR_LD_SPAN_MAP [1]' CPU: 16 PID: 330 Comm: kworker/16:1H Not tainted 5.15.0-53-generic #59-Ubuntu Hardware name: GIGABYTE R282-Z91-00/MZ92-FS0-00, BIOS M10 11/23/2021 Workqueue: kblockd blk_mq_run_work_fn Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x49 __ubsan_handle_out_of_bounds.cold+0x44/0x49 MR_GetPhyParams+0x487/0x700 [megaraid_sas] MR_BuildRaidContext+0x71e/0xb50 [megaraid_sas] ? cpumask_next_and+0x24/0x30 ? update_sg_lb_stats+0x78/0x580 megasas_build_ldio_fusion+0x5b9/0x9a0 [megaraid_sas] megasas_build_io_fusion+0x412/0x450 [megaraid_sas] megasas_build_and_issue_cmd_fusion+0xa5/0x380 [megaraid_sas] megasas_queue_command+0x1c1/0x200 [megaraid_sas] ? ktime_get+0x46/0xc0 scsi_dispatch_cmd+0x96/0x200 scsi_queue_rq+0x2d5/0x690 blk_mq_dispatch_rq_list+0x13f/0x680 ? sbitmap_get+0x71/0xe0 __blk_mq_do_dispatch_sched+0xba/0x2e0 blk_mq_do_dispatch_sched+0x40/0x70 __blk_mq_sched_dispatch_requests+0x105/0x150 blk_mq_sched_dispatch_requests+0x35/0x70 __blk_mq_run_hw_queue+0x34/0xc0 blk_mq_run_work_fn+0x1f/0x30 process_one_work+0x22b/0x3d0 worker_thread+0x53/0x420 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1996915/+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 1996915] Re: megaraid_sas crash in ubuntu 22.04
** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) 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/1996915 Title: megaraid_sas crash in ubuntu 22.04 Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: New Status in linux source package in Kinetic: New Bug description: crash message for dmesg UBSAN: array-index-out-of-bounds in /build/linux-JjvoxS/linux-5.15.0/drivers/scsi/megaraid/megaraid_sas_fp.c:151:32 index 2 is out of range for type 'MR_LD_SPAN_MAP [1]' CPU: 16 PID: 330 Comm: kworker/16:1H Not tainted 5.15.0-53-generic #59-Ubuntu Hardware name: GIGABYTE R282-Z91-00/MZ92-FS0-00, BIOS M10 11/23/2021 Workqueue: kblockd blk_mq_run_work_fn Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x49 __ubsan_handle_out_of_bounds.cold+0x44/0x49 MR_GetPhyParams+0x487/0x700 [megaraid_sas] MR_BuildRaidContext+0x71e/0xb50 [megaraid_sas] ? cpumask_next_and+0x24/0x30 ? update_sg_lb_stats+0x78/0x580 megasas_build_ldio_fusion+0x5b9/0x9a0 [megaraid_sas] megasas_build_io_fusion+0x412/0x450 [megaraid_sas] megasas_build_and_issue_cmd_fusion+0xa5/0x380 [megaraid_sas] megasas_queue_command+0x1c1/0x200 [megaraid_sas] ? ktime_get+0x46/0xc0 scsi_dispatch_cmd+0x96/0x200 scsi_queue_rq+0x2d5/0x690 blk_mq_dispatch_rq_list+0x13f/0x680 ? sbitmap_get+0x71/0xe0 __blk_mq_do_dispatch_sched+0xba/0x2e0 blk_mq_do_dispatch_sched+0x40/0x70 __blk_mq_sched_dispatch_requests+0x105/0x150 blk_mq_sched_dispatch_requests+0x35/0x70 __blk_mq_run_hw_queue+0x34/0xc0 blk_mq_run_work_fn+0x1f/0x30 process_one_work+0x22b/0x3d0 worker_thread+0x53/0x420 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1996915/+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 2008824] Re: sched: cpumask: improve on cpumask_local_spread() locality
** Changed in: linux (Ubuntu) Status: Incomplete => In Progress -- 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/2008824 Title: sched: cpumask: improve on cpumask_local_spread() locality Status in linux package in Ubuntu: In Progress Bug description: A patch series landed upstream during the v6.3 merge window that shows impressive performance improvements in iperf3 multi-stream performance on NUMA based systems w/ Mellanox network controllers: https://www.spinics.net/lists/linux-rdma/msg115357.html It would be valuable to land those in lunar, allowing our LTS users to adopt them more quickly starting with the HWE kernel in 22.04.3. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2008824/+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 2008824] [NEW] sched: cpumask: improve on cpumask_local_spread() locality
Public bug reported: A patch series landed upstream during the v6.3 merge window that shows impressive performance improvements in iperf3 multi-stream performance on NUMA based systems w/ Mellanox network controllers: https://www.spinics.net/lists/linux-rdma/msg115357.html It would be valuable to land those in lunar, allowing our LTS users to adopt them more quickly starting with the HWE kernel in 22.04.3. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: dann frazier (dannf) Status: Incomplete ** Changed in: linux (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) -- 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/2008824 Title: sched: cpumask: improve on cpumask_local_spread() locality Status in linux package in Ubuntu: Incomplete Bug description: A patch series landed upstream during the v6.3 merge window that shows impressive performance improvements in iperf3 multi-stream performance on NUMA based systems w/ Mellanox network controllers: https://www.spinics.net/lists/linux-rdma/msg115357.html It would be valuable to land those in lunar, allowing our LTS users to adopt them more quickly starting with the HWE kernel in 22.04.3. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2008824/+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 2006397] Re: nft_lookup crash when running DDOS attack
This issue only impacts linux-bluefield/focal because it uniquely
included a backport of upstream commit 339706bc21c1 ("netfilter:
nft_lookup: update element stateful expression") from v5.7-rc1 without
these follow up fixes that also landed in upstream before v5.7 final:
24791b9aa1ab0 netfilter: nft_set_bitmap: initialize set element extension in
lookups
a26c1e49c8e97 netfilter: nf_tables: do not update stateful expressions if
lookup is inverted
It impacts all linux-bluefield/focal kernels since the initial version,
5.4.0-1001.2 and is resolved in 5.4.0-1058.64.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/2006397
Title:
nft_lookup crash when running DDOS attack
Status in linux-bluefield package in Ubuntu:
Invalid
Status in linux-bluefield source package in Focal:
Fix Committed
Bug description:
* Explain the bug
Running DDOS test on tcp port 22 will trigger kernel crash.
* Brief explanation of fixes
Do not update stateful expressions if lookup is inverted
* How to test
Configuration nftables with config file below:
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0
jump filter_ssh
}
chain filter_ssh {
tcp dport { 22 } ct state new accept
}
}
* {22}: {} is mandatory to repro
If we don’t add {}, nft_lookup_eval function is never called and kernel crush
isn’t reproduced.
Then apply nft by doing:
# nft -f temp_nftables.conf
Start hping3 from peer:
# hping3 -I {Host Device} -p 22 -d 52 {SmartNIC IP Address} --flood
DPU side will crash with kernel call trace without this fix.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2006397/+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 2006557] Re: Enable rdma-sniffer for libpcap
** Bug watch added: Debian Bug tracker #1030898 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030898 ** Also affects: libpcap (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030898 Importance: Unknown Status: Unknown ** No longer affects: libpcap (Ubuntu Bionic) ** No longer affects: linux (Ubuntu Bionic) ** No longer affects: linux (Ubuntu Focal) ** No longer affects: linux (Ubuntu Jammy) ** No longer affects: linux (Ubuntu Kinetic) -- 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/2006557 Title: Enable rdma-sniffer for libpcap Status in libpcap package in Ubuntu: New Status in linux package in Ubuntu: Invalid Status in libpcap source package in Focal: New Status in libpcap source package in Jammy: New Status in libpcap source package in Kinetic: New Status in libpcap source package in Lunar: New Status in linux source package in Lunar: Invalid Status in libpcap package in Debian: Unknown Bug description: Hi, The request is to build and configure stock package libpcap with rdma-sniffer enabled. We'd like users of rdma devices to be able to sniff on them using stock tcpdump. Currently when using default tcpdump It does not list rdma devices. $ tcpdump -D |grep -i rdma $ when using locally build tcpdump (with rdma enabled) $ cd $ ./tcpdump -D |grep -i rdma 24.rocep4s0 (RDMA sniffer) 25.rocep7s0f0 (RDMA sniffer) 26.rocep7s0f1 (RDMA sniffer) 27.rocep10s0f0 (RDMA sniffer) 28.rocep10s0f1 (RDMA sniffer) 29.rocep33s0f0 (RDMA sniffer) 30.rocep33s0f1 (RDMA sniffer) 31.rocep36s0f0 (RDMA sniffer) 32.ibp36s0f1 (RDMA sniffer) Locally build steps: clone sources: $ mkdir tcpdumpbuild $ cd tcpdumpbuild/ $ git clone https://github.com/the-tcpdump-group/tcpdump.git $ git clone https://github.com/the-tcpdump-group/libpcap.git install required packages (including rdma packages so libpcap is built with rdma enabled): $ apt install flex bison librdmacm-dev librdmacm1 rdma-core rdmacm-utils configure and build $ cd libpcap $ ./autogen.sh $ ./configure --enable-rdma=yes $ make cd ../tcpdump/ ./autogen.sh ./configure $ make now ./tcpdump -D can show rdma devices. Thanks ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/2006557/+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 2006557] Re: [focal, jammy]Enable rdma-sniffer for libpcap
** Also affects: libpcap (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Incomplete => Invalid ** Summary changed: - [focal, jammy]Enable rdma-sniffer for libpcap + Enable rdma-sniffer for libpcap ** Also affects: libpcap (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: libpcap (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: libpcap (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: libpcap (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libpcap (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: Invalid -- 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/2006557 Title: Enable rdma-sniffer for libpcap Status in libpcap package in Ubuntu: New Status in linux package in Ubuntu: Invalid Status in libpcap source package in Bionic: New Status in linux source package in Bionic: New Status in libpcap source package in Focal: New Status in linux source package in Focal: New Status in libpcap source package in Jammy: New Status in linux source package in Jammy: New Status in libpcap source package in Kinetic: New Status in linux source package in Kinetic: New Status in libpcap source package in Lunar: New Status in linux source package in Lunar: Invalid Bug description: Hi, The request is to build and configure stock package libpcap with rdma-sniffer enabled. We'd like users of rdma devices to be able to sniff on them using stock tcpdump. Currently when using default tcpdump It does not list rdma devices. $ tcpdump -D |grep -i rdma $ when using locally build tcpdump (with rdma enabled) $ cd $ ./tcpdump -D |grep -i rdma 24.rocep4s0 (RDMA sniffer) 25.rocep7s0f0 (RDMA sniffer) 26.rocep7s0f1 (RDMA sniffer) 27.rocep10s0f0 (RDMA sniffer) 28.rocep10s0f1 (RDMA sniffer) 29.rocep33s0f0 (RDMA sniffer) 30.rocep33s0f1 (RDMA sniffer) 31.rocep36s0f0 (RDMA sniffer) 32.ibp36s0f1 (RDMA sniffer) Locally build steps: clone sources: $ mkdir tcpdumpbuild $ cd tcpdumpbuild/ $ git clone https://github.com/the-tcpdump-group/tcpdump.git $ git clone https://github.com/the-tcpdump-group/libpcap.git install required packages (including rdma packages so libpcap is built with rdma enabled): $ apt install flex bison librdmacm-dev librdmacm1 rdma-core rdmacm-utils configure and build $ cd libpcap $ ./autogen.sh $ ./configure --enable-rdma=yes $ make cd ../tcpdump/ ./autogen.sh ./configure $ make now ./tcpdump -D can show rdma devices. Thanks ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/2006557/+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 2000257] Re: kdump fails on focal + linux-image-generic-hwe-20.04 kernel
>From the serial log, it looks to me like you don't have enough memory reserved. Try bumping up crashkernel=? You're not getting to the point of running makedumpfile so I don't see how it would be impacted. Its hard to say why jammy works for you and focal does not. I don't think we have a larger crashkernel= value by default. It is likely something more subtle like the initramfs in jammy consuming less memory. Note that once the memory issue is resolved, I suspect you'll hit bug 1970672. ** Changed in: makedumpfile (Ubuntu) Status: New => Triaged ** Changed in: linux-meta-hwe-5.15 (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/2000257 Title: kdump fails on focal + linux-image-generic-hwe-20.04 kernel Status in linux-meta-hwe-5.15 package in Ubuntu: Triaged Status in makedumpfile package in Ubuntu: Triaged Bug description: 1) $ lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 2) ubuntu@ubuntu:~$ apt-cache policy makedumpfile makedumpfile: Installed: 1:1.6.7-1ubuntu2.4 Candidate: 1:1.6.7-1ubuntu2.4 Version table: *** 1:1.6.7-1ubuntu2.4 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:1.6.7-1ubuntu2 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages ubuntu@ubuntu:~$ apt-cache policy kexec-tools kexec-tools: Installed: 1:2.0.18-1ubuntu1 Candidate: 1:2.0.18-1ubuntu1 Version table: *** 1:2.0.18-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status $ apt-cache policy linux-image-generic-hwe-20.04 linux-image-generic-hwe-20.04: Installed: 5.15.0.56.62~20.04.22 Candidate: 5.15.0.56.62~20.04.22 Version table: *** 5.15.0.56.62~20.04.22 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 5.4.0.26.32 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 3) crash dump of linux-image-generic-hwe-20.04 kernel to complete successfully 4) the kexec'ed kernel panics and fails to capture the kernel crash dump ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: kdump-tools 1:1.6.7-1ubuntu2.4 ProcVersionSignature: User Name 5.15.0-56.62~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-56-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Dec 21 15:02:20 2022 SourcePackage: makedumpfile UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-hwe-5.15/+bug/2000257/+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 1999082] Re: linux-modules-nvidia-510-server fails to install
What happened here is that we dropped the 510 driver in lrm 5.4.0-135.152+1, transitioning it to the 515 driver. It therefore did not produce a 5.4.0-135.152+1 version of linux-modules- nvidia-510-server-5.4.0-135-generic. Ubuntu always keeps the latest version of a binary package in the archive, even if the source that produced it has been superseded. Because of that, the 5.4.0-135.152 version of linux-modules-nvidia-510-server-5.4.0-135-generic is sticking around. 5.4.0-135.152 correctly had a strict versioned dep on a matching linux-signatures package, and that linux-signatures package was superseded by a new one. Superseded packages *are* dropped from the archive, so that dependency can no longer be met. TLDR; this is all normal (though not ideal) behavior, and this one is particularly confusing because we dropped (and transitioned) the 510 driver during a refresh of the drivers for a kernel that previously had a 510 driver. Lesson: Installing modules for anything other than the latest kernel update is not supported, even if those modules appear to still be available in the archive. ** Changed in: nvidia-graphics-drivers-510-server (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-510-server in Ubuntu. https://bugs.launchpad.net/bugs/1999082 Title: linux-modules-nvidia-510-server fails to install Status in nvidia-graphics-drivers-510-server package in Ubuntu: Won't Fix Bug description: $ sudo apt install linux-modules-nvidia-510-server-$(uname -r) Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-modules-nvidia-510-server-5.4.0-135-generic : Depends: linux-signatures-nvidia-5.4.0-135-generic (= 5.4.0-135.152) but 5.4.0-135.152+1 is to be installed Depends: nvidia-kernel-common-510-server (<= 510.85.02-1) but it is not going to be installed Depends: nvidia-kernel-common-510-server (>= 510.85.02) but it is not going to be installed E: Unable to correct problems, you have held broken packages. $ lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-510-server/+bug/1999082/+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 1982582] Re: [UBUNTU 22.04] Unable to install kdump-tools on 22.04 on s390x (LPAR nor z/VM guest)
** Also affects: kdump-tools (Ubuntu Lunar) Importance: High Status: In Progress ** Also affects: kdump-tools (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: kdump-tools (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kdump-tools in Ubuntu. Matching subscriptions: Maintainer https://bugs.launchpad.net/bugs/1982582 Title: [UBUNTU 22.04] Unable to install kdump-tools on 22.04 on s390x (LPAR nor z/VM guest) Status in Ubuntu on IBM z Systems: In Progress Status in kdump-tools package in Ubuntu: In Progress Status in kdump-tools source package in Jammy: New Status in kdump-tools source package in Kinetic: New Status in kdump-tools source package in Lunar: In Progress Bug description: Unable to install kdump-tools on 22.04 (Jammy) on s390x (LPAR nor z/VM guest) Errors were encountered while processing: kdump-tools needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Contact Information = Vanessa Baeza/vanessa.ba...@ibm.com ---uname output--- Linux ilzlnx15 5.15.0-41-generic #44-Ubuntu SMP Wed Jun 22 14:22:27 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- apt-get install kdump-tools or apt-get install linux-crashdump == Comment: #1 - Ruth Vanessa Baeza Elizalde - 2022-07-21 14:09:21 == == Comment: #6 - Steffen Maier - 2022-07-22 06:15:06 == (In reply to comment #1) > Created attachment 155027 [details] > sosreport-ilzlnx15-199072-2022-07-21-cpplakh [maier:~/docs/zfcp/issues/ilab/ltc199072-u2204-error-on-installing_kdump-tools/sosreport-ilzlnx15-199072-2022-07-21-cpplakh](0)$ cat sos_commands/kdump/kdump-config_show * /etc/default/kdump-tools: USE_KDUMP is not set or zero * no crashkernel= parameter in the kernel cmdline [maier:~/docs/zfcp/issues/ilab/ltc199072-u2204-error-on-installing_kdump-tools/sosreport-ilzlnx15-199072-2022-07-21-cpplakh](0)$ cat ./proc/cmdline root=/dev/disk/by-id/dm-uuid-LVM-pgDF7ojWA1Vra6LMB3aPVQt9xStlmQK2he2ApvXaEuUKbGUMrJf8Kv7yIs9yAZzH [maier:~/docs/zfcp/issues/ilab/ltc199072-u2204-error-on-installing_kdump-tools/sosreport-ilzlnx15-199072-2022-07-21-cpplakh](0)$ cat etc/zipl.conf # This has been modified by the MAAS curtin installer [defaultboot] default=ubuntu [ubuntu] target = /boot image = /boot/vmlinuz ramdisk = /boot/initrd.img parameters = root=/dev/disk/by-id/dm-uuid-LVM-pgDF7ojWA1Vra6LMB3aPVQt9xStlmQK2he2ApvXaEuUKbGUMrJf8Kv7yIs9yAZzH Looks like some preconditions for kdump are not fulfilled. [https://ubuntu.com/server/docs/kernel-crash-dump] Are those supposed to be created by the installation of kdump-tools or does that package require those pre-reqs to already be fulfilled to get installed? (I'm not familiar with kdump tooling on Ubuntu.) Vanessa, is this different from previous Ubuntu versions you deployed? (cf. bug 194306) FYI, there's also this known kdump bug 195646. While kdump is really nice, you could continue with just a working standalone dump for the time being in order not to jeopardize your schedules. (In reply to comment #0) > ---Problem Description--- > Unable to install kdump-tools on 22.04 (Jammy Jellyfish) on s390x (LPAR nor > zVM guest) > Errors were encountered while processing: > kdump-tools > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) Are there any more details on the error it faced? Copy from the terminal? (issued command and its output) [maier:~/docs/zfcp/issues/ilab/ltc199072-u2204-error-on-installing_kdump-tools/sosreport-ilzlnx15-199072-2022-07-21-cpplakh](0)$ fgrep kdump var/log/dpkg.log 465:2022-07-21 10:48:56 install kdump-tools:s390x 1:1.6.10ubuntu1 467:2022-07-21 10:48:56 status half-installed kdump-tools:s390x 1:1.6.10ubuntu1 468:2022-07-21 10:48:56 status unpacked kdump-tools:s390x 1:1.6.10ubuntu1 489:2022-07-21 10:49:05 configure kdump-tools:s390x 1:1.6.10ubuntu1 490:2022-07-21 10:49:05 status unpacked kdump-tools:s390x 1:1.6.10ubuntu1 491:2022-07-21 10:49:05 status half-configured kdump-tools:s390x 1:1.6.10ubuntu1 502:2022-07-21 10:54:06 configure kdump-tools:s390x 1:1.6.10ubuntu1 504:2022-07-21 10:54:06 status half-configured kdump-tools:s390x 1:1.6.10ubuntu1 509:2022-07-21 11:04:42 status half-configured kdump-tools:s390x 1:1.6.10ubuntu1 510:2022-07-21 11:04:43 remove kdump-tools:s390x 1:1.6.10ubuntu1 512:2022-07-21 11:04:43 status half-installed kdump-tools:s390x 1:1.6.10ubuntu1 514:2022-07-21 11:04:46 status config-files kdump-tools:s390x 1:1.6.10ubuntu1 523:2022-07-21 11:06:45 install kdump-tools:s390x 1:1.6.10ubuntu1 1:1.6.10ubuntu1 525:2022-07-21 11:06:45 status
[Kernel-packages] [Bug 1990294] Re: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..."
Thanks! OK, that shows that we've successfully booted the kernel, but it is having an issue bringing up a CPU. I've pasted the relevant snippet below. It isn't obvious to me if this is a kernel issue or some other platform issue. As a next step, I'd suggest attempting to reproduce w/ the latest mainline kernel (continuing w/ earlycon enabled). If the problem goes away, perhaps there's a mainline fix we can identify what "fixed" it. If the problem persists, we probably need to notify the vendor. [3.321372] arch_timer: Enabling local workaround for ARM erratum 1418040 [3.321394] CPU245: Booted secondary processor 0x0100310100 [0x413fd0c1] [8.536939] CPU246: failed to come online [8.550338] Detected PIPT I-cache on CPU246 [8.555817] CPU246: failed in unknown state : 0x0 [8.555987] GICv3: CPU246: found redistributor 10037 region 1:0x500100f0 [8.562727] [ cut here ] [8.562809] GICv3: CPU246: using allocated LPI pending table @0x08000268 [8.569364] Dying CPU not properly vacated! [ 16.668834] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:9215 sched_cpu_dying+0x1d0/0x2a0 [ 16.681496] Modules linked in: [ 16.684597] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-43-generic #46~20.04.1-Ubuntu [ 16.693010] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 16.700095] pc : sched_cpu_dying+0x1d0/0x2a0 [ 16.704432] lr : sched_cpu_dying+0x1d0/0x2a0 [ 16.708770] sp : 8881bbe0 [ 16.712132] x29: 8881bbe0 x28: cca930eada80 x27: [ 16.719390] x26: 7395107ce000 x25: 00f6 x24: 403e40ed6728 [ 16.726651] x23: cca930eb2618 x22: x21: 00f6 [ 16.733907] x20: cca930719100 x19: 403e40ee7100 x18: 0014 [ 16.741165] x17: 3836323030303830 x16: 3030303078304020 x15: 656c62617420676e [ 16.748425] x14: 69646e6570204950 x13: 3030303038363230 x12: 3030383030303030 [ 16.755683] x11: 78304020656c6261 x10: 7420676e69646e65 x9 : cca92e7e39a0 [ 16.762940] x8 : 6c6c6120676e6973 x7 : 205d393038323635 x6 : c000fffe [ 16.770198] x5 : 0017ffe8 x4 : x3 : 8881b8c8 [ 16.777457] x2 : x1 : x0 : [ 16.784717] Call trace: [ 16.787197] sched_cpu_dying+0x1d0/0x2a0 [ 16.791182] cpuhp_invoke_callback+0x14c/0x5a8 [ 16.795699] cpuhp_invoke_callback_range+0x5c/0xb8 [ 16.800568] _cpu_up+0x234/0x360 [ 16.803844] cpu_up+0xb8/0x110 [ 16.806945] bringup_nonboot_cpus+0x7c/0xb0 [ 16.811195] smp_init+0x3c/0x98 [ 16.814385] kernel_init_freeable+0x1a4/0x39c [ 16.818813] kernel_init+0x2c/0x158 [ 16.822359] ret_from_fork+0x10/0x20 [ 16.825992] ---[ end trace bb9ca924bc23dd10 ]--- [ 16.830685] CPU246 enqueued tasks (0 total): [ 16.835356] [ cut here ] [ 16.835431] GICv3: CPU246: found redistributor 10037 region 1:0x500100f0 [ 16.840045] Dying CPU not properly vacated! [ 16.847925] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:9215 sched_cpu_dying+0x1d0/0x2a -- 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/1990294 Title: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..." Status in grub2 package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Bug description: When kernel test rebooted onto the 5.15.0-43-generic HWE kernel, no output appeared on the console after the EFI stub: Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint A0 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint AD EFI stub: Booting Linux Kernel... EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1990294/+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 1990294] Re: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..."
Whether or not we can reproduce on other machines, I think we still need to try to diagnose what is going on with papat. I think there's a series of steps we can do to help diagnose that - I'd suggest starting w/ the "earlycon" test. -- 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/1990294 Title: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..." Status in grub2 package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Bug description: When kernel test rebooted onto the 5.15.0-43-generic HWE kernel, no output appeared on the console after the EFI stub: Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint A0 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint AD EFI stub: Booting Linux Kernel... EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1990294/+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
Re: [Kernel-packages] [Bug 1970672] Re: makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid pmd_pte."
On Wed, Sep 28, 2022 at 12:41 PM Kellen Renshaw
<1970...@bugs.launchpad.net> wrote:
>
> Thanks Dann!
>
> Oof, the links didn't make it from the draft document, fixed now.
>
> If I understand your previous comment correctly, a better variant of
> this testing procedure would be a regression testing checklist against a
> library (linked to in the page) of dump files and a single manual test
> of the kdump<>makedumpfile functionality?
As someone who in no way speaks for the SRU team, yes - that is what
I'd suggest.
-dann
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1970672
Title:
makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid
pmd_pte."
Status in makedumpfile package in Ubuntu:
Confirmed
Bug description:
[Impact]
* On Focal with an HWE (>=5.12) kernel, makedumpfile can sometimes fail with
"__vtop4_x86_64: Can't get a valid pmd_pte."
* makedumpfile falls back to cp for the dump, resulting in extremely
large vmcores. This can impact both collection and analysis due to
lack of space for the resulting vmcore.
* This is fixed in upstream commit present in versions 1.7.0 and 1.7.1:
https://github.com/makedumpfile/makedumpfile/commit/646456862df8926ba10dd7330abf3bf0f887e1b6
commit 646456862df8926ba10dd7330abf3bf0f887e1b6
Author: Kazuhito Hagio
Date: Wed May 26 14:31:26 2021 +0900
[PATCH] Increase SECTION_MAP_LAST_BIT to 5
* Required for kernel 5.12
Kernel commit 1f90a3477df3 ("mm: teach pfn_to_online_page() about
ZONE_DEVICE section collisions") added a section flag
(SECTION_TAINT_ZONE_DEVICE) and causes makedumpfile an error on
some machines like this:
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(e2bdc200) to physical
address.
readmem: type_addr: 0, addr:e2bdc200, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
Increase SECTION_MAP_LAST_BIT to 5 to fix this. The bit had not
been used until the change, so we can just increase the value.
Signed-off-by: Kazuhito Hagio
[Test Plan]
* Confirm that makedumpfile works as expected by triggering a kdump.
* Confirm that the patched makedumpfile works as expected on a system
known to experience the issue.
* Confirm that the patched makedumpfile is able to work with a cp-
generated known affected vmcore to compress it. The unpatched version
fails.
[Where problems could occur]
* This change could adversely affect the collection/compression of
vmcores during a kdump situation resulting in fallback to cp.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1970672/+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
Re: [Kernel-packages] [Bug 1970672] Re: makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid pmd_pte."
On Fri, Sep 23, 2022 at 11:15 AM Kellen Renshaw
<1970...@bugs.launchpad.net> wrote:
>
> I have put up a draft SRU exception page at
> https://wiki.ubuntu.com/MakedumpfileUpdates. Comments/edits are welcome.
> I am working on finding an appropriate place for test vmcores to be
> stored.
Awesome! Thanks for starting this. I made some edits already, but
here's some other things I'd recommend:
- Provide links under resources (it's a web page!)
- be more precise about what will be tested, ideally in a checklist
form. Make it clear enough that you could give the list to another
developer and they would run the same tests and get the same results.
- Testing other architectures should not be optional IMO. makedumpfile
has architecture specific knowledge. You could easily break one w/o
noticing on another.
- Mention the plan to filter a pool of saved dump files as a
regression test. That is key IMO.
- If you have the regression testing pool, I don't see any reason to
have to do the full kdump process everywhere. Just do that once (one
kernel, one arch) to make sure the kdump-tools<->makedumpfile
interface has been preserved. Testing the full crash dump process is
painful, but makedumpfile really is just used as a filter, and we can
test that easily.
-dann
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1970672
Title:
makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid
pmd_pte."
Status in makedumpfile package in Ubuntu:
Confirmed
Bug description:
[Impact]
* On Focal with an HWE (>=5.12) kernel, makedumpfile can sometimes fail with
"__vtop4_x86_64: Can't get a valid pmd_pte."
* makedumpfile falls back to cp for the dump, resulting in extremely
large vmcores. This can impact both collection and analysis due to
lack of space for the resulting vmcore.
* This is fixed in upstream commit present in versions 1.7.0 and 1.7.1:
https://github.com/makedumpfile/makedumpfile/commit/646456862df8926ba10dd7330abf3bf0f887e1b6
commit 646456862df8926ba10dd7330abf3bf0f887e1b6
Author: Kazuhito Hagio
Date: Wed May 26 14:31:26 2021 +0900
[PATCH] Increase SECTION_MAP_LAST_BIT to 5
* Required for kernel 5.12
Kernel commit 1f90a3477df3 ("mm: teach pfn_to_online_page() about
ZONE_DEVICE section collisions") added a section flag
(SECTION_TAINT_ZONE_DEVICE) and causes makedumpfile an error on
some machines like this:
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(e2bdc200) to physical
address.
readmem: type_addr: 0, addr:e2bdc200, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
Increase SECTION_MAP_LAST_BIT to 5 to fix this. The bit had not
been used until the change, so we can just increase the value.
Signed-off-by: Kazuhito Hagio
[Test Plan]
* Confirm that makedumpfile works as expected by triggering a kdump.
* Confirm that the patched makedumpfile works as expected on a system
known to experience the issue.
* Confirm that the patched makedumpfile is able to work with a cp-
generated known affected vmcore to compress it. The unpatched version
fails.
[Where problems could occur]
* This change could adversely affect the collection/compression of
vmcores during a kdump situation resulting in fallback to cp.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1970672/+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 1990294] Re: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..."
** Also affects: grub2 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** No longer affects: ubuntu -- 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/1990294 Title: Ampere AltraMax sometimes hangs after "EFI stub: Exiting boot services..." Status in grub2 package in Ubuntu: New Status in linux package in Ubuntu: New Bug description: When kernel test rebooted onto the 5.15.0-43-generic HWE kernel, no output appeared on the console after the EFI stub: Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint A0 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint 92 Checkpoint AD EFI stub: Booting Linux Kernel... EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1990294/+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 1922910] Re: Unable to deploy HWE kernel with sub-arch set to xgene-uboot
Well, yes and no. xgene-uboot *is* required. But xgene-uboot *is* the generic kernel - it just has a u-boot wrapper prepended. So what I meant by comment #10, is that I wonder should allow xgene-uboot in the same cases where we allow -generic for HWE kernels, such as this code from src/maasserver/utils/osystems.py: if subarch != "generic" and ( (hwe_kernel and validate_kernel_str(hwe_kernel)) or (min_hwe_kernel and validate_kernel_str(min_hwe_kernel)) ): raise ValidationError( "Subarchitecture(%s) must be generic when setting hwe_kernel." % subarch ) ** Changed in: maas Status: Incomplete => New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1922910 Title: Unable to deploy HWE kernel with sub-arch set to xgene-uboot Status in MAAS: New Status in linux package in Ubuntu: Expired Bug description: When trying to deploy Moonshot nodes, the sub-arch must be set to xgene-uboot for it to be deployed with GA kernel. However, when trying to deploy it with the HWE kernel it will complain that: Subarchitecture(xgene-uboot) must be generic when setting hwe_kernel. [ deleted the bit about how generic/hwe fails, because that is expected. this machine requires xgene-uboot/hwe ] To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1922910/+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 1922910] Re: Unable to deploy HWE kernel with sub-arch set to xgene-uboot
I wonder if we just need to treat xgene-uboot as an alias for generic in the MAAS code? -- 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/1922910 Title: Unable to deploy HWE kernel with sub-arch set to xgene-uboot Status in MAAS: New Status in linux package in Ubuntu: Expired Bug description: When trying to deploy Moonshot nodes, the sub-arch must be set to xgene-uboot for it to be deployed with GA kernel. However, when trying to deploy it with the HWE kernel it will complain that: Subarchitecture(xgene-uboot) must be generic when setting hwe_kernel. [ deleted the bit about how generic/hwe fails, because that is expected. this machine requires xgene-uboot/hwe ] To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1922910/+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 1922910] Re: Unable to deploy HWE kernel with sub-arch set to xgene-uboot
I'm not on the kernel team, but I'm not sure what would make this flavor
invalid w/ HWE. The xgene-uboot flavor is merely a wrapped version of
the -generic kernel. This kernel works fine on the target platform, once
you can get it installed.
** Changed in: maas
Status: Expired => New
** Description changed:
When trying to deploy Moonshot nodes, the sub-arch must be set to xgene-
uboot for it to be deployed with GA kernel.
However, when trying to deploy it with the HWE kernel it will complain that:
- Subarchitecture(xgene-uboot) must be generic when setting hwe_kernel.
+ Subarchitecture(xgene-uboot) must be generic when setting hwe_kernel.
- Not sure if this is a bug in MAAS, or some by-design limitation.
-
- If I set the sub-arch to arm64/generic, the deployment for Xenial +
- hwe-16.04 will drop into a boot loop with error message in console:
-
- append: nomodeset ro
-
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/hwe-16.04/xenial/stable/squashfs
- ip=mcdivitt35-kernel:BOOTIF ip6=off overlayroot=tmpfs
- overlayroot_cfgdisk=disabled cc:{'datasource_list': ['MAAS']}end_cc
- cloud-config-url=http://10.229.32.21:5248/MAAS/metadata/latest/by-
- id/chbcrm/?op=get_preseed apparmor=0 log_host=10.229.32.21 log_port=5247
- --- console=ttyS0,9600nBad Linux ARM zImage magic!
-
- hyper-maas
- MAAS version: 2.9.2 (9165-g.b5dc1fd6c)
+ [ deleted the bit about how generic/hwe fails, because that is expected.
+ this machine requires xgene-uboot/hwe ]
--
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/1922910
Title:
Unable to deploy HWE kernel with sub-arch set to xgene-uboot
Status in MAAS:
New
Status in linux package in Ubuntu:
Expired
Bug description:
When trying to deploy Moonshot nodes, the sub-arch must be set to
xgene-uboot for it to be deployed with GA kernel.
However, when trying to deploy it with the HWE kernel it will complain that:
Subarchitecture(xgene-uboot) must be generic when setting hwe_kernel.
[ deleted the bit about how generic/hwe fails, because that is
expected. this machine requires xgene-uboot/hwe ]
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1922910/+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 1987122] Re: Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka]
This is actually 100% reproducible for me - perhaps a hardware issue? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1987122 Title: Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] Status in linux-bluefield package in Ubuntu: New Status in linux-bluefield source package in Focal: New Bug description: Seen once booting 5.4.0-1042.47 [9.389510] Unable to handle kernel NULL pointer dereference at virtual address [9.398549] Mem abort info: [9.401407] ESR = 0x9604 [9.404494] EC = 0x25: DABT (current EL), IL = 32 bits [9.409820] SET = 0, FnV = 0 [9.412902] EA = 0, S1PTW = 0 [9.416047] Data abort info: [9.418939] ISV = 0, ISS = 0x0004 [9.422780] CM = 0, WnR = 0 [9.425800] user pgtable: 4k pages, 48-bit VAs, pgdp=00046971a000 [9.432254] [] pgd= [9.437144] Internal error: Oops: 9604 [#1] PREEMPT SMP [9.442715] Modules linked in: mlxbf_pka(+) mlx_trio mlx_bootctl bluefield_edac sch_fq_codel rdma_ucm ib_u verbs rdma_cm iw_cm ib_cm ib_core ipmi_devintf ipmi_msghandler ip_tables ipv6 crc_ccitt btrfs zstd_compress r aid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 cr ct10dif_ce mlxbf_gige i2c_mlxbf gpio_mlxbf2 aes_neon_bs aes_neon_blk [9.477244] CPU: 7 PID: 541 Comm: systemd-udevd Not tainted 5.4.0-1042-bluefield #47-Ubuntu [9.485588] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.1.0-0-g4 46abf2 Sep 15 2020 [9.496799] pstate: 6005 (nZCv daif -PAN -UAO) [9.501600] pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.502693] crng init done [9.506737] lr : pka_drv_probe+0x3f0/0x5f0 [mlxbf_pka] [9.509441] random: 1 urandom warning(s) missed due to ratelimiting [9.514569] sp : 8000126d3830 [9.514572] x29: 8000126d3830 x28: [9.529440] x27: x26: 0003eb59e810 [9.534743] x25: 8930d040 x24: [9.540045] x23: 0003e9759d00 x22: 89323000 [9.545347] x21: 0003eb59e800 x20: 0003e8a3a100 [9.550650] x19: 0003e74905c0 x18: 0001 [9.555952] x17: 58670ac4f1a91c84 x16: 77277994e98682bf [9.561255] x15: 0003e975a188 x14: [9.566557] x13: ff00 x12: 0018 [9.571860] x11: 0101010101010101 x10: ff7f7f7fff7f [9.577163] x9 : x8 : 0003ebaf10c0 [9.582465] x7 : 0008 x6 : 000f [9.587767] x5 : 0003ebaf1988 x4 : 0003ebaf18c8 [9.593070] x3 : x2 : [9.598372] x1 : 4500 x0 : 0100 [9.603676] Call trace: [9.606118] pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.610907] platform_drv_probe+0x5c/0xb0 [9.614908] really_probe+0xdc/0x430 [9.618475] driver_probe_device+0xe8/0x138 [9.622649] device_driver_attach+0x78/0x80 [9.626822] __driver_attach+0xb0/0x178 [9.630649] bus_for_each_dev+0x84/0xe0 [9.634476] driver_attach+0x34/0x40 [9.638041] bus_add_driver+0x148/0x220 [9.641868] driver_register+0x68/0x118 [9.645696] __platform_driver_register+0x58/0x68 [9.650394] pka_drv_register+0x114/0x1000 [mlxbf_pka] [9.655526] do_one_initcall+0x54/0x2d0 [9.659356] do_init_module+0x50/0x218 [9.663096] load_module+0x103c/0x1370 [9.666837] __do_sys_finit_module+0xac/0x118 [9.671185] __arm64_sys_finit_module+0x2c/0x38 [9.675708] el0_svc_common.constprop.0+0xf4/0x200 [9.680489] el0_svc_handler+0x38/0xa8 [9.684229] el0_svc+0x10/0x5c0 [9.687365] Code: f9400021 91000400 cb01 a90783e1 (f9400061) [9.693453] ---[ end trace 6f157873818019b7 ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1987122/+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 1987122] Re: Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka]
** Also affects: linux-bluefield (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1987122 Title: Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] Status in linux-bluefield package in Ubuntu: New Status in linux-bluefield source package in Focal: New Bug description: Seen once booting 5.4.0-1042.47 [9.389510] Unable to handle kernel NULL pointer dereference at virtual address [9.398549] Mem abort info: [9.401407] ESR = 0x9604 [9.404494] EC = 0x25: DABT (current EL), IL = 32 bits [9.409820] SET = 0, FnV = 0 [9.412902] EA = 0, S1PTW = 0 [9.416047] Data abort info: [9.418939] ISV = 0, ISS = 0x0004 [9.422780] CM = 0, WnR = 0 [9.425800] user pgtable: 4k pages, 48-bit VAs, pgdp=00046971a000 [9.432254] [] pgd= [9.437144] Internal error: Oops: 9604 [#1] PREEMPT SMP [9.442715] Modules linked in: mlxbf_pka(+) mlx_trio mlx_bootctl bluefield_edac sch_fq_codel rdma_ucm ib_u verbs rdma_cm iw_cm ib_cm ib_core ipmi_devintf ipmi_msghandler ip_tables ipv6 crc_ccitt btrfs zstd_compress r aid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 cr ct10dif_ce mlxbf_gige i2c_mlxbf gpio_mlxbf2 aes_neon_bs aes_neon_blk [9.477244] CPU: 7 PID: 541 Comm: systemd-udevd Not tainted 5.4.0-1042-bluefield #47-Ubuntu [9.485588] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.1.0-0-g4 46abf2 Sep 15 2020 [9.496799] pstate: 6005 (nZCv daif -PAN -UAO) [9.501600] pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.502693] crng init done [9.506737] lr : pka_drv_probe+0x3f0/0x5f0 [mlxbf_pka] [9.509441] random: 1 urandom warning(s) missed due to ratelimiting [9.514569] sp : 8000126d3830 [9.514572] x29: 8000126d3830 x28: [9.529440] x27: x26: 0003eb59e810 [9.534743] x25: 8930d040 x24: [9.540045] x23: 0003e9759d00 x22: 89323000 [9.545347] x21: 0003eb59e800 x20: 0003e8a3a100 [9.550650] x19: 0003e74905c0 x18: 0001 [9.555952] x17: 58670ac4f1a91c84 x16: 77277994e98682bf [9.561255] x15: 0003e975a188 x14: [9.566557] x13: ff00 x12: 0018 [9.571860] x11: 0101010101010101 x10: ff7f7f7fff7f [9.577163] x9 : x8 : 0003ebaf10c0 [9.582465] x7 : 0008 x6 : 000f [9.587767] x5 : 0003ebaf1988 x4 : 0003ebaf18c8 [9.593070] x3 : x2 : [9.598372] x1 : 4500 x0 : 0100 [9.603676] Call trace: [9.606118] pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.610907] platform_drv_probe+0x5c/0xb0 [9.614908] really_probe+0xdc/0x430 [9.618475] driver_probe_device+0xe8/0x138 [9.622649] device_driver_attach+0x78/0x80 [9.626822] __driver_attach+0xb0/0x178 [9.630649] bus_for_each_dev+0x84/0xe0 [9.634476] driver_attach+0x34/0x40 [9.638041] bus_add_driver+0x148/0x220 [9.641868] driver_register+0x68/0x118 [9.645696] __platform_driver_register+0x58/0x68 [9.650394] pka_drv_register+0x114/0x1000 [mlxbf_pka] [9.655526] do_one_initcall+0x54/0x2d0 [9.659356] do_init_module+0x50/0x218 [9.663096] load_module+0x103c/0x1370 [9.666837] __do_sys_finit_module+0xac/0x118 [9.671185] __arm64_sys_finit_module+0x2c/0x38 [9.675708] el0_svc_common.constprop.0+0xf4/0x200 [9.680489] el0_svc_handler+0x38/0xa8 [9.684229] el0_svc+0x10/0x5c0 [9.687365] Code: f9400021 91000400 cb01 a90783e1 (f9400061) [9.693453] ---[ end trace 6f157873818019b7 ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1987122/+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 1987122] [NEW] Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka]
Public bug reported: Seen once booting 5.4.0-1042.47 [9.389510] Unable to handle kernel NULL pointer dereference at virtual address [9.398549] Mem abort info: [9.401407] ESR = 0x9604 [9.404494] EC = 0x25: DABT (current EL), IL = 32 bits [9.409820] SET = 0, FnV = 0 [9.412902] EA = 0, S1PTW = 0 [9.416047] Data abort info: [9.418939] ISV = 0, ISS = 0x0004 [9.422780] CM = 0, WnR = 0 [9.425800] user pgtable: 4k pages, 48-bit VAs, pgdp=00046971a000 [9.432254] [] pgd= [9.437144] Internal error: Oops: 9604 [#1] PREEMPT SMP [9.442715] Modules linked in: mlxbf_pka(+) mlx_trio mlx_bootctl bluefield_edac sch_fq_codel rdma_ucm ib_u verbs rdma_cm iw_cm ib_cm ib_core ipmi_devintf ipmi_msghandler ip_tables ipv6 crc_ccitt btrfs zstd_compress r aid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 cr ct10dif_ce mlxbf_gige i2c_mlxbf gpio_mlxbf2 aes_neon_bs aes_neon_blk [9.477244] CPU: 7 PID: 541 Comm: systemd-udevd Not tainted 5.4.0-1042-bluefield #47-Ubuntu [9.485588] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.1.0-0-g4 46abf2 Sep 15 2020 [9.496799] pstate: 6005 (nZCv daif -PAN -UAO) [9.501600] pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.502693] crng init done [9.506737] lr : pka_drv_probe+0x3f0/0x5f0 [mlxbf_pka] [9.509441] random: 1 urandom warning(s) missed due to ratelimiting [9.514569] sp : 8000126d3830 [9.514572] x29: 8000126d3830 x28: [9.529440] x27: x26: 0003eb59e810 [9.534743] x25: 8930d040 x24: [9.540045] x23: 0003e9759d00 x22: 89323000 [9.545347] x21: 0003eb59e800 x20: 0003e8a3a100 [9.550650] x19: 0003e74905c0 x18: 0001 [9.555952] x17: 58670ac4f1a91c84 x16: 77277994e98682bf [9.561255] x15: 0003e975a188 x14: [9.566557] x13: ff00 x12: 0018 [9.571860] x11: 0101010101010101 x10: ff7f7f7fff7f [9.577163] x9 : x8 : 0003ebaf10c0 [9.582465] x7 : 0008 x6 : 000f [9.587767] x5 : 0003ebaf1988 x4 : 0003ebaf18c8 [9.593070] x3 : x2 : [9.598372] x1 : 4500 x0 : 0100 [9.603676] Call trace: [9.606118] pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] [9.610907] platform_drv_probe+0x5c/0xb0 [9.614908] really_probe+0xdc/0x430 [9.618475] driver_probe_device+0xe8/0x138 [9.622649] device_driver_attach+0x78/0x80 [9.626822] __driver_attach+0xb0/0x178 [9.630649] bus_for_each_dev+0x84/0xe0 [9.634476] driver_attach+0x34/0x40 [9.638041] bus_add_driver+0x148/0x220 [9.641868] driver_register+0x68/0x118 [9.645696] __platform_driver_register+0x58/0x68 [9.650394] pka_drv_register+0x114/0x1000 [mlxbf_pka] [9.655526] do_one_initcall+0x54/0x2d0 [9.659356] do_init_module+0x50/0x218 [9.663096] load_module+0x103c/0x1370 [9.666837] __do_sys_finit_module+0xac/0x118 [9.671185] __arm64_sys_finit_module+0x2c/0x38 [9.675708] el0_svc_common.constprop.0+0xf4/0x200 [9.680489] el0_svc_handler+0x38/0xa8 [9.684229] el0_svc+0x10/0x5c0 [9.687365] Code: f9400021 91000400 cb01 a90783e1 (f9400061) [9.693453] ---[ end trace 6f157873818019b7 ]--- ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Status: New ** Attachment added: "console.log" https://bugs.launchpad.net/bugs/1987122/+attachment/5610066/+files/console.log -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1987122 Title: Null pointer dereference at pc : pka_drv_probe+0x41c/0x5f0 [mlxbf_pka] Status in linux-bluefield package in Ubuntu: New Bug description: Seen once booting 5.4.0-1042.47 [9.389510] Unable to handle kernel NULL pointer dereference at virtual address [9.398549] Mem abort info: [9.401407] ESR = 0x9604 [9.404494] EC = 0x25: DABT (current EL), IL = 32 bits [9.409820] SET = 0, FnV = 0 [9.412902] EA = 0, S1PTW = 0 [9.416047] Data abort info: [9.418939] ISV = 0, ISS = 0x0004 [9.422780] CM = 0, WnR = 0 [9.425800] user pgtable: 4k pages, 48-bit VAs, pgdp=00046971a000 [9.432254] [] pgd= [9.437144] Internal error: Oops: 9604 [#1] PREEMPT SMP [9.442715] Modules linked in: mlxbf_pka(+) mlx_trio mlx_bootctl bluefield_edac sch_fq_codel rdma_ucm ib_u verbs rdma_cm iw_cm ib_cm ib_core ipmi_devintf ipmi_msghandler ip_tables ipv6 crc_ccitt btrfs zstd_compress r aid10 raid456 async_raid6_recov async_memcpy async_pq
[Kernel-packages] [Bug 1973153] Re: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel"
The merging of 5.15.44 is tracked in bug 1981649 -- 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/1973153 Title: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel" Status in ubuntu-kernel-tests: Confirmed Status in linux package in Ubuntu: In Progress Status in linux source package in Jammy: In Progress Bug description: Issue found on Jammy 5.17.0-8-generic #8~22.04.2-Ubuntu and Jammy 5.15.0-27-generic with ARM64 node helo-kernel only. It looks like this is hardware-specific. The read_all_sys test in fs from ubuntu_ltp will cause kernel oops and test will timeout. Steps to reproduce this: git clone -b sru git://git.launchpad.net/~canonical-kernel-team/+git/ltp cd ltp make autotools ./configure make sudo make install echo "read_all_sys read_all -d /sys -q -r 3" > /tmp/fs sudo /opt/ltp/runltp -f /tmp/fs Test log: <<>> tag=read_all_sys stime=1652343855 cmdline="read_all -d /sys -q -r 3" contacts="" analysis=exit <<>> incrementing stop tst_test.c:1456: TINFO: Timeout per run is 0h 30m 00s Test timeouted, sending SIGKILL! tst_test.c:1500: TINFO: Killed the leftover descendant processes tst_test.c:1506: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1508: TBROK: Test killed! (timeout?) Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 <<>> initiation_status="ok" duration=1800 termination_type=exited termination_id=2 corefile=no cutime=39 cstime=140 <<>> dmesg output: [ 1614.203083] LTP: starting read_all_sys (read_all -d /sys -q -r 3) [ 1617.509566] mpt3sas :8d:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 1617.543837] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550373] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550381] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550474] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550504] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550593] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.550622] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.598371] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.606183] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.641990] mpt3sas :8d:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 1617.973894] WARNING! power/level is deprecated; use power/control instead [ 1619.368112] bdi 7:6: the stable_pages_required attribute has been removed. Use the stable_writes queue attribute instead. [ 1627.430319] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.438256] Mem abort info: [ 1627.441086] ESR = 0x9621 [ 1627.444133] EC = 0x25: DABT (current EL), IL = 32 bits [ 1627.449469] SET = 0, FnV = 0 [ 1627.452515] EA = 0, S1PTW = 0 [ 1627.455676] FSC = 0x21: alignment fault [ 1627.459701] Data abort info: [ 1627.462597] ISV = 0, ISS = 0x0021 [ 1627.466449] CM = 0, WnR = 0 [ 1627.469434] swapper pgtable: 4k pages, 48-bit VAs, pgdp=f4aba000 [ 1627.476160] [800033b503bf] pgd=10bffcfff003, p4d=10bffcfff003, pud=10bffcffe003, pmd=1008948f5003, pte=006880213f0f [ 1627.488712] Internal error: Oops: 9621 [#1] SMP [ 1627.493585] Modules linked in: efi_pstore nls_iso8859_1 joydev input_leds acpi_ipmi ipmi_ssif thunderx2_pmu cppc_cpufreq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid uas hid usb_storage ast drm_vram_helper drm_ttm_helper i2c_smbus ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 rc_core sha1_ce qede mpt3sas qed raid_class drm scsi_transport_sas xhci_pci ahci xhci_pci_renesas gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [ 1627.500861] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.562614] CPU: 71 PID: 4190 Comm: read_all Not tainted 5.17.0-8-generic #8~22.04.2-Ubuntu [ 1627.562623] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL030 06/04/2020 [ 1627.562626] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1627.570544] Mem abort
[Kernel-packages] [Bug 1977847] Re: OVS/CT kernel stack trace during boot on Jammy OS
This appears to now be addressed in stable: https://www.mail-archive.com/ovs-dev@openvswitch.org/msg65275.html And that fix is currently queued in jammy/master-next: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next=352a39407e5bab5a5965e5bcb7abf1f3e1e34f7f So there should be a fixed kernel in jammy-proposed next week, per the SRU cycle schedule: https://kernel.ubuntu.com/ If someone who can reproduce this can do a local build of the current master-next branch and verify that the problem is indeed solved, that'd be keen :) ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Changed in: openvswitch (Ubuntu) Status: Confirmed => Invalid -- 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/1977847 Title: OVS/CT kernel stack trace during boot on Jammy OS Status in linux package in Ubuntu: Confirmed Status in openvswitch package in Ubuntu: Invalid Bug description: Charmed Openstack deployment (Yoga) with Jammy series (For testing OVN Hardware Offload with Connection Tracking) # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04 LTS" root@node3:/home/ubuntu# uname -a Linux node3 5.15.0-35-generic #36-Ubuntu SMP Sat May 21 02:24:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@node3:/home/ubuntu# ovs-vsctl --version ovs-vsctl (Open vSwitch) 2.17.0 DB Schema 8.3.0 I see the following trace on dmesg every time the server boots up (full trace in the attached file): [Mon Jun 6 10:51:09 2022] RIP: 0010:__ovs_ct_lookup+0x36c/0x3e0 [openvswitch] [Mon Jun 6 10:51:09 2022] Call Trace: [Mon Jun 6 10:51:09 2022] [Mon Jun 6 10:51:09 2022] ovs_ct_execute+0x3a2/0x490 [openvswitch] [Mon Jun 6 10:51:09 2022] do_execute_actions+0xbb/0xa90 [openvswitch] [Mon Jun 6 10:51:09 2022] ? __ovs_nla_copy_actions+0x5a0/0x8a0 [openvswitch] [Mon Jun 6 10:51:09 2022] ? __kmalloc+0x179/0x330 [Mon Jun 6 10:51:09 2022] ovs_execute_actions+0x4c/0x110 [openvswitch] [Mon Jun 6 10:51:09 2022] ovs_packet_cmd_execute+0x280/0x300 [openvswitch] [Mon Jun 6 10:51:09 2022] genl_family_rcv_msg_doit+0xe7/0x150 [Mon Jun 6 10:51:09 2022] genl_rcv_msg+0xe2/0x1e0 [Mon Jun 6 10:51:09 2022] ? ovs_vport_cmd_del+0x200/0x200 [openvswitch] I see the same trace when deploying OpenStack with Focal series and HWE-Edge kernel... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1977847/+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 1977847] Re: OVS/CT kernel stack trace during boot on Jammy OS
** 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 in Ubuntu. https://bugs.launchpad.net/bugs/1977847 Title: OVS/CT kernel stack trace during boot on Jammy OS Status in linux package in Ubuntu: New Status in openvswitch package in Ubuntu: Confirmed Bug description: Charmed Openstack deployment (Yoga) with Jammy series (For testing OVN Hardware Offload with Connection Tracking) # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04 LTS" root@node3:/home/ubuntu# uname -a Linux node3 5.15.0-35-generic #36-Ubuntu SMP Sat May 21 02:24:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@node3:/home/ubuntu# ovs-vsctl --version ovs-vsctl (Open vSwitch) 2.17.0 DB Schema 8.3.0 I see the following trace on dmesg every time the server boots up (full trace in the attached file): [Mon Jun 6 10:51:09 2022] RIP: 0010:__ovs_ct_lookup+0x36c/0x3e0 [openvswitch] [Mon Jun 6 10:51:09 2022] Call Trace: [Mon Jun 6 10:51:09 2022] [Mon Jun 6 10:51:09 2022] ovs_ct_execute+0x3a2/0x490 [openvswitch] [Mon Jun 6 10:51:09 2022] do_execute_actions+0xbb/0xa90 [openvswitch] [Mon Jun 6 10:51:09 2022] ? __ovs_nla_copy_actions+0x5a0/0x8a0 [openvswitch] [Mon Jun 6 10:51:09 2022] ? __kmalloc+0x179/0x330 [Mon Jun 6 10:51:09 2022] ovs_execute_actions+0x4c/0x110 [openvswitch] [Mon Jun 6 10:51:09 2022] ovs_packet_cmd_execute+0x280/0x300 [openvswitch] [Mon Jun 6 10:51:09 2022] genl_family_rcv_msg_doit+0xe7/0x150 [Mon Jun 6 10:51:09 2022] genl_rcv_msg+0xe2/0x1e0 [Mon Jun 6 10:51:09 2022] ? ovs_vport_cmd_del+0x200/0x200 [openvswitch] I see the same trace when deploying OpenStack with Focal series and HWE-Edge kernel... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1977847/+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 1952933] Re: impish kernel crashes on hp m400 in mlx4_en_poll_rx_cq
** Changed in: linux (Ubuntu Jammy) Status: Fix Committed => 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/1952933 Title: impish kernel crashes on hp m400 in mlx4_en_poll_rx_cq Status in linux package in Ubuntu: Fix Committed Status in linux source package in Impish: In Progress Status in linux source package in Jammy: Fix Released Bug description: During MAAS deployment: [ 107.768146] Unable to handle kernel read from unreadable memory at virtual address domain : maas[ 107.943413] Mem abort info: rootserver: 10.229.32.21 rootpath: filename :[ 108.043666] ESR = 0x9604 lpxelinux.0 :: root=squash:http://10.229.32.21:5248/images/ubu[ 108.147045] EC = 0x25: DABT (current EL), IL = 32 bits ntu/arm64/xgene-uboot/impish/stable/squashfs :: mount_squash do[ 108.277541] SET = 0, FnV = 0 wnloading http://10.229.32.21:5248/images/ubuntu/arm64/xgene-ubo[ 108.380921] EA = 0, S1PTW = 0 ot/impish/stable/squashfs to /root.tmp.img Connecting to 10.229[ 108.485351] Data abort info: .32.21:5248 (10.229.32.21:5248) [ 108.586639] ISV = 0, ISS = 0x0004 [ 108.667060] CM = 0, WnR = 0 [ 108.702635] user pgtable: 4k pages, 48-bit VAs, pgdp=00401ce02000 root.tmp.img [ 108.779941] [] pgd=, p4d= 4% [ 108.884372] Internal error: Oops: 9604 [#1] SMP [ 108.948102] Modules linked in: raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core gpio_keys_polled gpio_dwapb crct10dif_ce ahci_xgene gpio_xgene_sb aes_neon_bs aes_neon_blk crypto_simd cryptd [ 109.286243] CPU: 0 PID: 11 Comm: ksoftirqd/0 Not tainted 5.13.0-20-generic #20-Ubuntu [ 109.380233] Hardware name: HP ProLiant m400 Server Cartridge (DT) [ 109.453258] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 109.525342] pc : mlx4_en_poll_rx_cq+0xb4/0x17c [mlx4_en] [ 109.589087] lr : mlx4_en_poll_rx_cq+0x7c/0x17c [mlx4_en] [ 109.652828] sp : 8000129cbc60 [ 109.692470] x29: 8000129cbc60 x28: 012c x27: 000ff7e95fc0 [ 109.778115] x26: x25: 20908508 x24: 21b40940 [ 109.863763] x23: 20908508 x22: 20908400 x21: 21b4 [ 109.949409] x20: 0040 x19: 0040 x18: 0014 [ 110.035056] x17: 1122e350 x16: cb46f8bb x15: e2b6a183 [ 110.120703] x14: 26fff11e x13: 9312ff0b x12: [ 110.206349] x11: 0006 x10: 0040 x9 : 89119320 [ 110.291997] x8 : 08acdc00 x7 : 02c0 x6 : dff8 [ 110.377642] x5 : 0394 x4 : 03960040 x3 : 21c2 [ 110.463289] x2 : x1 : x0 : [ 110.548937] Call trace: [ 110.578147] mlx4_en_poll_rx_cq+0xb4/0x17c [mlx4_en] [ 110.637719] __napi_poll+0x40/0x1e0 [ 110.679551] net_rx_action+0x2d8/0x34c [ 110.724513] __do_softirq+0x128/0x388 [ 110.768432] run_ksoftirqd+0x6c/0x94 [ 110.811308] smpboot_thread_fn+0x15c/0x1a0 [ 110.860443] kthread+0x114/0x120 [ 110.899145] ret_from_fork+0x10/0x18 [ 110.942024] Code: 1100fc41 1a82b021 13067c21 93407c21 (f8617800) [ 111.015158] ---[ end trace b37ae99414884442 ]--- [ 111.070550] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 111.152964] SMP: stopping secondary CPUs [ 111.200016] Kernel Offset: 0x8 from 0x80001000 [ 111.265837] PHYS_OFFSET: 0x40 [ 111.309651] CPU features: 0x0251,0046 [ 111.361915] Memory Limit: none [ 111.398431] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1952933/+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 1973153] Re: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel"
This fix is merged in v5.15.44 -- 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/1973153 Title: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel" Status in ubuntu-kernel-tests: Confirmed Status in linux package in Ubuntu: In Progress Status in linux source package in Jammy: In Progress Bug description: Issue found on Jammy 5.17.0-8-generic #8~22.04.2-Ubuntu and Jammy 5.15.0-27-generic with ARM64 node helo-kernel only. It looks like this is hardware-specific. The read_all_sys test in fs from ubuntu_ltp will cause kernel oops and test will timeout. Steps to reproduce this: git clone -b sru git://git.launchpad.net/~canonical-kernel-team/+git/ltp cd ltp make autotools ./configure make sudo make install echo "read_all_sys read_all -d /sys -q -r 3" > /tmp/fs sudo /opt/ltp/runltp -f /tmp/fs Test log: <<>> tag=read_all_sys stime=1652343855 cmdline="read_all -d /sys -q -r 3" contacts="" analysis=exit <<>> incrementing stop tst_test.c:1456: TINFO: Timeout per run is 0h 30m 00s Test timeouted, sending SIGKILL! tst_test.c:1500: TINFO: Killed the leftover descendant processes tst_test.c:1506: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1508: TBROK: Test killed! (timeout?) Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 <<>> initiation_status="ok" duration=1800 termination_type=exited termination_id=2 corefile=no cutime=39 cstime=140 <<>> dmesg output: [ 1614.203083] LTP: starting read_all_sys (read_all -d /sys -q -r 3) [ 1617.509566] mpt3sas :8d:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 1617.543837] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550373] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550381] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550474] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550504] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550593] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.550622] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.598371] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.606183] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.641990] mpt3sas :8d:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 1617.973894] WARNING! power/level is deprecated; use power/control instead [ 1619.368112] bdi 7:6: the stable_pages_required attribute has been removed. Use the stable_writes queue attribute instead. [ 1627.430319] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.438256] Mem abort info: [ 1627.441086] ESR = 0x9621 [ 1627.444133] EC = 0x25: DABT (current EL), IL = 32 bits [ 1627.449469] SET = 0, FnV = 0 [ 1627.452515] EA = 0, S1PTW = 0 [ 1627.455676] FSC = 0x21: alignment fault [ 1627.459701] Data abort info: [ 1627.462597] ISV = 0, ISS = 0x0021 [ 1627.466449] CM = 0, WnR = 0 [ 1627.469434] swapper pgtable: 4k pages, 48-bit VAs, pgdp=f4aba000 [ 1627.476160] [800033b503bf] pgd=10bffcfff003, p4d=10bffcfff003, pud=10bffcffe003, pmd=1008948f5003, pte=006880213f0f [ 1627.488712] Internal error: Oops: 9621 [#1] SMP [ 1627.493585] Modules linked in: efi_pstore nls_iso8859_1 joydev input_leds acpi_ipmi ipmi_ssif thunderx2_pmu cppc_cpufreq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid uas hid usb_storage ast drm_vram_helper drm_ttm_helper i2c_smbus ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 rc_core sha1_ce qede mpt3sas qed raid_class drm scsi_transport_sas xhci_pci ahci xhci_pci_renesas gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [ 1627.500861] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.562614] CPU: 71 PID: 4190 Comm: read_all Not tainted 5.17.0-8-generic #8~22.04.2-Ubuntu [ 1627.562623] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL030 06/04/2020 [ 1627.562626] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1627.570544] Mem abort info: [
[Kernel-packages] [Bug 1966194] Re: [Jammy, mlx5, ConnectX-7] add CX7 support for software steering
** Changed in: linux (Ubuntu) Status: Fix Committed => 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/1966194 Title: [Jammy, mlx5, ConnectX-7] add CX7 support for software steering Status in linux package in Ubuntu: Fix Released Status in linux source package in Jammy: Fix Released Bug description: [Impact] Add support for software steering on cx7 [Test Case] configure software steering on cx7 setup run asap testing (reference https://github.com/Mellanox/ovs-tests) [Regression Potential] TBD [Other Info] Feature patchset: All patches are cleanly applied on Jamy master-next beside these two who add minor conflicts due to context difference. net/mlx5: Introduce software defined steering capabilities net/mlx5: DR, Add support for matching on #fixes 624bf42c2e39 net/mlx5: DR, Fix querying eswitch manager vport for ECPF 0aec12d97b20 net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte 9091b821aaa4 net/mlx5: DR, Handle eswitch manager and uplink vports separately #CX7 SMFS support 6862c787c7e8 net/mlx5: DR, Add support for ConnectX-7 steering 638a07f1090e net/mlx5: DR, Refactor ste_ctx handling for STE v0/1 75a3926ca6a4 net/mlx5: DR, Rename action modify fields to reflect naming in HW spec bdc3ab5795a6 net/mlx5: DR, Fix handling of different actions on the same STE in STEv1 11659ef8d28e net/mlx5: DR, Remove unneeded comments 5c422bfad2fb net/mlx5: DR, Add support for matching on Internet Header Length (IHL) #dependencies: 60dc0ef674ec net/mlx5: VLAN push on RX, pop on TX 8348b71ccd92 net/mlx5: Introduce software defined steering capabilities #depencecies: #SW STEERING DEBUG DUMP aa36c94853b2 net/mlx5: Set SMFS as a default steering mode if device supports it 4ff725e1d4ad net/mlx5: DR, Ignore modify TTL if device doesn't support it cc2295cd54e4 net/mlx5: DR, Improve steering for empty or RX/TX-only matchers f59464e257bd net/mlx5: DR, Add support for matching on geneve_tlv_option_0_exist field 09753babaf46 net/mlx5: DR, Support matching on tunnel headers 0 and 1 8c2b4fee9c4b net/mlx5: DR, Add misc5 to match_param structs 0f2a6c3b9219 net/mlx5: Add misc5 flow table match parameters b54128275ef8 net/mlx5: DR, Warn on failure to destroy objects due to refcount e3a0f40b2f90 net/mlx5: DR, Add support for UPLINK destination type 9222f0b27da2 net/mlx5: DR, Add support for dumping steering info 7766c9b922fe net/mlx5: DR, Add missing reserved fields to dr_match_param 89cdba3224f0 net/mlx5: DR, Add check for flex parser ID value 08fac109f7bb net/mlx5: DR, Rename list field in matcher struct to list_node 32e9bd585307 net/mlx5: DR, Remove unused struct member in matcher c3fb0e280b4c net/mlx5: DR, Fix lower case macro prefix "mlx5_" to "MLX5_" 84dfac39c61f net/mlx5: DR, Fix error flow in creating matcher 58a606dba708 net/mlx5: Introduce new uplink destination type 455832d49666 net/mlx5: DR, Fix check for unsupported fields in match param 9091b821aaa4 net/mlx5: DR, Handle eswitch manager and uplink vports separately #SW STEERING SF 515ce2ffa621 net/mlx5: DR, init_next_match only if needed 5dde00a73048 net/mlx5: DR, Fix typo 'offeset' to 'offset' 1ffd498901c1 net/mlx5: DR, Increase supported num of actions to 32 11a45def2e19 net/mlx5: DR, Add support for SF vports c0e90fc2ccaa net/mlx5: DR, Support csum recalculation flow table on SFs ee1887fb7cdd net/mlx5: DR, Align error messages for failure to obtain vport caps dd4acb2a0954 net/mlx5: DR, Add missing query for vport 0 7ae8ac9a5820 net/mlx5: DR, Replace local WIRE_PORT macro with the existing MLX5_VPORT_UPLINK f9f93bd55ca6 net/mlx5: DR, Fix vport number data type to u16 c228dce26222 net/mlx5: DR, Fix code indentation in dr_ste_v1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966194/+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 1970672] Re: makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid pmd_pte."
Yeah, I don't think an autopkgtest is a requirement. Having the test
live within the package itself would make it more accessible, and
autopkgtest was my first thought as to how to do that. But I don't see a
"disable by default" flag, and I agree that huge downloads on every test
run could be a problem. It would still be nice IMO if the test was
integrated into the package though, even if it needs to run manually.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1970672
Title:
makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid
pmd_pte."
Status in makedumpfile package in Ubuntu:
New
Bug description:
[Impact]
* On Focal with an HWE (>=5.12) kernel, makedumpfile can sometimes fail with
"__vtop4_x86_64: Can't get a valid pmd_pte."
* makedumpfile falls back to cp for the dump, resulting in extremely
large vmcores. This can impact both collection and analysis due to
lack of space for the resulting vmcore.
* This is fixed in upstream commit present in versions 1.7.0 and 1.7.1:
https://github.com/makedumpfile/makedumpfile/commit/646456862df8926ba10dd7330abf3bf0f887e1b6
commit 646456862df8926ba10dd7330abf3bf0f887e1b6
Author: Kazuhito Hagio
Date: Wed May 26 14:31:26 2021 +0900
[PATCH] Increase SECTION_MAP_LAST_BIT to 5
* Required for kernel 5.12
Kernel commit 1f90a3477df3 ("mm: teach pfn_to_online_page() about
ZONE_DEVICE section collisions") added a section flag
(SECTION_TAINT_ZONE_DEVICE) and causes makedumpfile an error on
some machines like this:
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(e2bdc200) to physical
address.
readmem: type_addr: 0, addr:e2bdc200, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
Increase SECTION_MAP_LAST_BIT to 5 to fix this. The bit had not
been used until the change, so we can just increase the value.
Signed-off-by: Kazuhito Hagio
[Test Plan]
* Confirm that makedumpfile works as expected by triggering a kdump.
* Confirm that the patched makedumpfile works as expected on a system
known to experience the issue.
* Confirm that the patched makedumpfile is able to work with a cp-
generated known affected vmcore to compress it. The unpatched version
fails.
[Where problems could occur]
* This change could adversely affect the collection/compression of
vmcores during a kdump situation resulting in fallback to cp.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1970672/+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 1973153] Re: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel"
Patches are now queued for all applicable stable trees (linux-4.14.y+) -- 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/1973153 Title: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel" Status in ubuntu-kernel-tests: Invalid Status in linux package in Ubuntu: In Progress Status in linux source package in Jammy: In Progress Bug description: Issue found on Jammy 5.17.0-8-generic #8~22.04.2-Ubuntu and Jammy 5.15.0-27-generic with ARM64 node helo-kernel only. It looks like this is hardware-specific. The read_all_sys test in fs from ubuntu_ltp will cause kernel oops and test will timeout. Steps to reproduce this: git clone -b sru git://git.launchpad.net/~canonical-kernel-team/+git/ltp cd ltp make autotools ./configure make sudo make install echo "read_all_sys read_all -d /sys -q -r 3" > /tmp/fs sudo /opt/ltp/runltp -f /tmp/fs Test log: <<>> tag=read_all_sys stime=1652343855 cmdline="read_all -d /sys -q -r 3" contacts="" analysis=exit <<>> incrementing stop tst_test.c:1456: TINFO: Timeout per run is 0h 30m 00s Test timeouted, sending SIGKILL! tst_test.c:1500: TINFO: Killed the leftover descendant processes tst_test.c:1506: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1508: TBROK: Test killed! (timeout?) Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 <<>> initiation_status="ok" duration=1800 termination_type=exited termination_id=2 corefile=no cutime=39 cstime=140 <<>> dmesg output: [ 1614.203083] LTP: starting read_all_sys (read_all -d /sys -q -r 3) [ 1617.509566] mpt3sas :8d:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 1617.543837] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550373] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550381] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550474] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550504] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550593] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.550622] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.598371] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.606183] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.641990] mpt3sas :8d:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 1617.973894] WARNING! power/level is deprecated; use power/control instead [ 1619.368112] bdi 7:6: the stable_pages_required attribute has been removed. Use the stable_writes queue attribute instead. [ 1627.430319] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.438256] Mem abort info: [ 1627.441086] ESR = 0x9621 [ 1627.444133] EC = 0x25: DABT (current EL), IL = 32 bits [ 1627.449469] SET = 0, FnV = 0 [ 1627.452515] EA = 0, S1PTW = 0 [ 1627.455676] FSC = 0x21: alignment fault [ 1627.459701] Data abort info: [ 1627.462597] ISV = 0, ISS = 0x0021 [ 1627.466449] CM = 0, WnR = 0 [ 1627.469434] swapper pgtable: 4k pages, 48-bit VAs, pgdp=f4aba000 [ 1627.476160] [800033b503bf] pgd=10bffcfff003, p4d=10bffcfff003, pud=10bffcffe003, pmd=1008948f5003, pte=006880213f0f [ 1627.488712] Internal error: Oops: 9621 [#1] SMP [ 1627.493585] Modules linked in: efi_pstore nls_iso8859_1 joydev input_leds acpi_ipmi ipmi_ssif thunderx2_pmu cppc_cpufreq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid uas hid usb_storage ast drm_vram_helper drm_ttm_helper i2c_smbus ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 rc_core sha1_ce qede mpt3sas qed raid_class drm scsi_transport_sas xhci_pci ahci xhci_pci_renesas gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [ 1627.500861] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.562614] CPU: 71 PID: 4190 Comm: read_all Not tainted 5.17.0-8-generic #8~22.04.2-Ubuntu [ 1627.562623] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL030 06/04/2020 [ 1627.562626] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [
[Kernel-packages] [Bug 1970672] Re: makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid pmd_pte."
Thanks everyone for trying to tackle this long-standing issue. fwiw,
here's my $0.02 no how we could proceed:
Someone should draft a special case page for makedumpfile:
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
I'm happy to review/provide feedback, but I'd rather someone who would be
carrying out the plan drive it.
As others have mentioned, testing is the hard part, and we need to
define what will be tested in the special case documentation. Since
makedumpfile is really just a filter, I don't think we need to (or
reasonably could) boot a bunch of systems in different configs and
generate crashdumps for every new update. Rather, i think we could build
a repository of representative, unfiltered, /proc/vmcore files that
focal's existing makedumpfile can parse. Then we can just check that all
of those files can still be parsed by the proposed makedumpfile. With
some scripting and a multi-architecture cloud, this could be automated.
In fact, if this vmcore repo were online, we could implement this an
autopkgtest (w/ needs-internet set). But we should also do at least one
end-to-end kdump, just to make sure the kdump-tools->makedumpfile
interface hasn't been broken.
What is a representative sample? One of each of the current LTS and HWE
kernels on amd64, arm64, ppc64el and s390x seems like an obvious start
(or the subset of those that actually work today). I don't think the
machine type is as important, VMs should be fine IMO. If we know of
examples where different machines expose structures differently in a way
that makedumpfile cares about, then perhaps add those as well. Once a
new makedumpfile lands that adds support for a new HWE kernel, we should
probably then update the repo w/ vmcore samples from that kernel, so we
can make sure the next update doesn't regress that support (probably
convenient to do when verifying the SRU, since I imagine we'd be testing
that it works w/ the new HWE kernel then anyway).
It'd be good to note in the special case request that kdump-tools does fall
back to a raw /proc/vmcore file cp if makedumpfile fails, which can mitigate
regressions for a subset of users
- those with the necessary disk space and lack of time constraints.
While I agree that crash falls into the same category, I don't think it
necessarily needs to happen at the same time. Obviously users running
focal need to dump their vmcore using focal - bug for developers
debugging a crash, I don't think it is to onerous to use a newer version
of Ubuntu. Again, I'm no saying we *shouldn't* add crash to the special
case, it just seems like a makedumpfile exception is significantly more
important.
Finally, I don't think we need to commit to a frequency of backports, or
a point at which they will stop. Rather we can just stick to agreeing on
how it *can* be done when someone has the time/interest in doing it.
Guillherme's LTS->LTS+1 scheme sounds like a reasonable pattern to shoot
for, but if that doesn't happen every time, we're still improving the
situation over the status quo.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1970672
Title:
makedumpfile falls back to cp with "__vtop4_x86_64: Can't get a valid
pmd_pte."
Status in makedumpfile package in Ubuntu:
New
Bug description:
[Impact]
* On Focal with an HWE (>=5.12) kernel, makedumpfile can sometimes fail with
"__vtop4_x86_64: Can't get a valid pmd_pte."
* makedumpfile falls back to cp for the dump, resulting in extremely
large vmcores. This can impact both collection and analysis due to
lack of space for the resulting vmcore.
* This is fixed in upstream commit present in versions 1.7.0 and 1.7.1:
https://github.com/makedumpfile/makedumpfile/commit/646456862df8926ba10dd7330abf3bf0f887e1b6
commit 646456862df8926ba10dd7330abf3bf0f887e1b6
Author: Kazuhito Hagio
Date: Wed May 26 14:31:26 2021 +0900
[PATCH] Increase SECTION_MAP_LAST_BIT to 5
* Required for kernel 5.12
Kernel commit 1f90a3477df3 ("mm: teach pfn_to_online_page() about
ZONE_DEVICE section collisions") added a section flag
(SECTION_TAINT_ZONE_DEVICE) and causes makedumpfile an error on
some machines like this:
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(e2bdc200) to physical
address.
readmem: type_addr: 0, addr:e2bdc200, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
Increase SECTION_MAP_LAST_BIT to 5 to fix this. The bit had not
been used until the change, so we can just increase the value.
Signed-off-by: Kazuhito Hagio
[Test Plan]
* Confirm that makedumpfile works as expected by triggering a kdump.
* Confirm that the patched
[Kernel-packages] [Bug 1973153] Re: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel"
A fix for this is currently queued in linux-next: commit 1bbc21785b7336619fb6a67f1fff5afdaf229acc Author: Lorenzo Pieralisi Date: Thu Apr 7 11:51:20 2022 +0100 ACPI: sysfs: Fix BERT error region memory mapping My plan is to propose this for stable after it lands during the merge window. ** Changed in: ubuntu-kernel-tests Status: New => Invalid ** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu Jammy) Status: Incomplete => In Progress -- 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/1973153 Title: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel" Status in ubuntu-kernel-tests: Invalid Status in linux package in Ubuntu: In Progress Status in linux source package in Jammy: In Progress Bug description: Issue found on Jammy 5.17.0-8-generic #8~22.04.2-Ubuntu and Jammy 5.15.0-27-generic with ARM64 node helo-kernel only. It looks like this is hardware-specific. The read_all_sys test in fs from ubuntu_ltp will cause kernel oops and test will timeout. Steps to reproduce this: git clone -b sru git://git.launchpad.net/~canonical-kernel-team/+git/ltp cd ltp make autotools ./configure make sudo make install echo "read_all_sys read_all -d /sys -q -r 3" > /tmp/fs sudo /opt/ltp/runltp -f /tmp/fs Test log: <<>> tag=read_all_sys stime=1652343855 cmdline="read_all -d /sys -q -r 3" contacts="" analysis=exit <<>> incrementing stop tst_test.c:1456: TINFO: Timeout per run is 0h 30m 00s Test timeouted, sending SIGKILL! tst_test.c:1500: TINFO: Killed the leftover descendant processes tst_test.c:1506: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1508: TBROK: Test killed! (timeout?) Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 <<>> initiation_status="ok" duration=1800 termination_type=exited termination_id=2 corefile=no cutime=39 cstime=140 <<>> dmesg output: [ 1614.203083] LTP: starting read_all_sys (read_all -d /sys -q -r 3) [ 1617.509566] mpt3sas :8d:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 1617.543837] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550373] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550381] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550474] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550504] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550593] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.550622] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.598371] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.606183] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.641990] mpt3sas :8d:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 1617.973894] WARNING! power/level is deprecated; use power/control instead [ 1619.368112] bdi 7:6: the stable_pages_required attribute has been removed. Use the stable_writes queue attribute instead. [ 1627.430319] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.438256] Mem abort info: [ 1627.441086] ESR = 0x9621 [ 1627.444133] EC = 0x25: DABT (current EL), IL = 32 bits [ 1627.449469] SET = 0, FnV = 0 [ 1627.452515] EA = 0, S1PTW = 0 [ 1627.455676] FSC = 0x21: alignment fault [ 1627.459701] Data abort info: [ 1627.462597] ISV = 0, ISS = 0x0021 [ 1627.466449] CM = 0, WnR = 0 [ 1627.469434] swapper pgtable: 4k pages, 48-bit VAs, pgdp=f4aba000 [ 1627.476160] [800033b503bf] pgd=10bffcfff003, p4d=10bffcfff003, pud=10bffcffe003, pmd=1008948f5003, pte=006880213f0f [ 1627.488712] Internal error: Oops: 9621 [#1] SMP [ 1627.493585] Modules linked in: efi_pstore nls_iso8859_1 joydev input_leds acpi_ipmi ipmi_ssif thunderx2_pmu cppc_cpufreq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid uas hid usb_storage ast drm_vram_helper drm_ttm_helper i2c_smbus ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 rc_core sha1_ce qede mpt3sas qed raid_class drm scsi_transport_sas xhci_pci ahci xhci_pci_renesas
[Kernel-packages] [Bug 1973153] Re: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel"
** Changed in: linux (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => dann frazier (dannf) -- 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/1973153 Title: kernel oops triggered by read_all_sys in ubuntu_ltp/fs on J-5.15 / J-5.17 ARM64 "helo-kernel", "howzit-kernel" Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in linux source package in Jammy: Incomplete Bug description: Issue found on Jammy 5.17.0-8-generic #8~22.04.2-Ubuntu and Jammy 5.15.0-27-generic with ARM64 node helo-kernel only. It looks like this is hardware-specific. The read_all_sys test in fs from ubuntu_ltp will cause kernel oops and test will timeout. Steps to reproduce this: git clone -b sru git://git.launchpad.net/~canonical-kernel-team/+git/ltp cd ltp make autotools ./configure make sudo make install echo "read_all_sys read_all -d /sys -q -r 3" > /tmp/fs sudo /opt/ltp/runltp -f /tmp/fs Test log: <<>> tag=read_all_sys stime=1652343855 cmdline="read_all -d /sys -q -r 3" contacts="" analysis=exit <<>> incrementing stop tst_test.c:1456: TINFO: Timeout per run is 0h 30m 00s Test timeouted, sending SIGKILL! tst_test.c:1500: TINFO: Killed the leftover descendant processes tst_test.c:1506: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1508: TBROK: Test killed! (timeout?) Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 <<>> initiation_status="ok" duration=1800 termination_type=exited termination_id=2 corefile=no cutime=39 cstime=140 <<>> dmesg output: [ 1614.203083] LTP: starting read_all_sys (read_all -d /sys -q -r 3) [ 1617.509566] mpt3sas :8d:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 1617.543837] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550373] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550381] mpt3sas_cm0: host_trace_buffer_size_show: host_trace_buffer is not registered [ 1617.550474] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550504] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.550593] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.550622] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.598371] mpt3sas_cm0: host_trace_buffer_show: host_trace_buffer is not registered [ 1617.606183] mpt3sas_cm0: BRM_status_show: BRM attribute is only for warpdrive [ 1617.641990] mpt3sas :8d:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 1617.973894] WARNING! power/level is deprecated; use power/control instead [ 1619.368112] bdi 7:6: the stable_pages_required attribute has been removed. Use the stable_writes queue attribute instead. [ 1627.430319] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.438256] Mem abort info: [ 1627.441086] ESR = 0x9621 [ 1627.444133] EC = 0x25: DABT (current EL), IL = 32 bits [ 1627.449469] SET = 0, FnV = 0 [ 1627.452515] EA = 0, S1PTW = 0 [ 1627.455676] FSC = 0x21: alignment fault [ 1627.459701] Data abort info: [ 1627.462597] ISV = 0, ISS = 0x0021 [ 1627.466449] CM = 0, WnR = 0 [ 1627.469434] swapper pgtable: 4k pages, 48-bit VAs, pgdp=f4aba000 [ 1627.476160] [800033b503bf] pgd=10bffcfff003, p4d=10bffcfff003, pud=10bffcffe003, pmd=1008948f5003, pte=006880213f0f [ 1627.488712] Internal error: Oops: 9621 [#1] SMP [ 1627.493585] Modules linked in: efi_pstore nls_iso8859_1 joydev input_leds acpi_ipmi ipmi_ssif thunderx2_pmu cppc_cpufreq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid uas hid usb_storage ast drm_vram_helper drm_ttm_helper i2c_smbus ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 rc_core sha1_ce qede mpt3sas qed raid_class drm scsi_transport_sas xhci_pci ahci xhci_pci_renesas gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [ 1627.500861] Unable to handle kernel paging request at virtual address 800033b503bf [ 1627.562614] CPU: 71 PID: 4190 Comm: read_all Not tainted 5
[Kernel-packages] [Bug 1951289] Re: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3, 9, 11, 17, 19, 25 report incorrect sched domain for cpu#32
= bionic verification = ubuntu@d06-4:~$ cat /proc/version Linux version 4.15.0-179-generic (buildd@bos02-arm64-025) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #188-Ubuntu SMP Tue May 10 20:51:17 UTC 2022 ubuntu@d06-4:~$ grep domain2 /proc/schedstat | wc -l 128 ubuntu@d06-4:~$ grep domain3 /proc/schedstat | wc -l 128 ubuntu@d06-4:~$ ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1951289 Title: ubuntu_ltp_controllers:cpuset_sched_domains: tests 3,9,11,17,19,25 report incorrect sched domain for cpu#32 Status in kunpeng920: In Progress Status in kunpeng920 ubuntu-18.04 series: In Progress Status in kunpeng920 ubuntu-18.04-hwe series: Fix Committed Status in kunpeng920 ubuntu-20.04 series: Fix Committed Status in kunpeng920 upstream-kernel series: Fix Released Status in ubuntu-kernel-tests: Invalid Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Won't Fix Bug description: [Impact] The LTP cpuset_sched_domains test, authored by Miao Xie, fails on a Kunpeng920 server that has 4 NUMA nodes: https://launchpad.net/bugs/1951289 This does appear to be a real bug. /proc/schedstat displays 4 domain levels for CPUs on 2 of the nodes, but only 3 levels for the others 2 (see below). I assume this means the scheduler is making suboptimal decisions about where to place/move processes. [Test Case] On a 128 core Kunpeng 920 system, observe that half the CPUs are missing a 3rd level scheduling domain: ubuntu@d06-4:~$ grep domain2 /proc/schedstat | wc -l 128 ubuntu@d06-4:~$ grep domain3 /proc/schedstat | wc -l 64 ubuntu@d06-4:~$ [What Could Go Wrong] This changes the code used for populating sched domains, so it could potentially break on other systems, leading to poor scheduling characteristics (higher latencies, lower overall throughput etc). To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1951289/+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 1966194] Re: [Jammy, mlx5, ConnectX-7] add CX7 support for software steering
@kernel when we've already tested a kernel in its GA release, do we also now need to retest the HWE backport? -- 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/1966194 Title: [Jammy, mlx5, ConnectX-7] add CX7 support for software steering Status in linux package in Ubuntu: Fix Committed Status in linux source package in Jammy: Fix Committed Bug description: [Impact] Add support for software steering on cx7 [Test Case] configure software steering on cx7 setup run asap testing (reference https://github.com/Mellanox/ovs-tests) [Regression Potential] TBD [Other Info] Feature patchset: All patches are cleanly applied on Jamy master-next beside these two who add minor conflicts due to context difference. net/mlx5: Introduce software defined steering capabilities net/mlx5: DR, Add support for matching on #fixes 624bf42c2e39 net/mlx5: DR, Fix querying eswitch manager vport for ECPF 0aec12d97b20 net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte 9091b821aaa4 net/mlx5: DR, Handle eswitch manager and uplink vports separately #CX7 SMFS support 6862c787c7e8 net/mlx5: DR, Add support for ConnectX-7 steering 638a07f1090e net/mlx5: DR, Refactor ste_ctx handling for STE v0/1 75a3926ca6a4 net/mlx5: DR, Rename action modify fields to reflect naming in HW spec bdc3ab5795a6 net/mlx5: DR, Fix handling of different actions on the same STE in STEv1 11659ef8d28e net/mlx5: DR, Remove unneeded comments 5c422bfad2fb net/mlx5: DR, Add support for matching on Internet Header Length (IHL) #dependencies: 60dc0ef674ec net/mlx5: VLAN push on RX, pop on TX 8348b71ccd92 net/mlx5: Introduce software defined steering capabilities #depencecies: #SW STEERING DEBUG DUMP aa36c94853b2 net/mlx5: Set SMFS as a default steering mode if device supports it 4ff725e1d4ad net/mlx5: DR, Ignore modify TTL if device doesn't support it cc2295cd54e4 net/mlx5: DR, Improve steering for empty or RX/TX-only matchers f59464e257bd net/mlx5: DR, Add support for matching on geneve_tlv_option_0_exist field 09753babaf46 net/mlx5: DR, Support matching on tunnel headers 0 and 1 8c2b4fee9c4b net/mlx5: DR, Add misc5 to match_param structs 0f2a6c3b9219 net/mlx5: Add misc5 flow table match parameters b54128275ef8 net/mlx5: DR, Warn on failure to destroy objects due to refcount e3a0f40b2f90 net/mlx5: DR, Add support for UPLINK destination type 9222f0b27da2 net/mlx5: DR, Add support for dumping steering info 7766c9b922fe net/mlx5: DR, Add missing reserved fields to dr_match_param 89cdba3224f0 net/mlx5: DR, Add check for flex parser ID value 08fac109f7bb net/mlx5: DR, Rename list field in matcher struct to list_node 32e9bd585307 net/mlx5: DR, Remove unused struct member in matcher c3fb0e280b4c net/mlx5: DR, Fix lower case macro prefix "mlx5_" to "MLX5_" 84dfac39c61f net/mlx5: DR, Fix error flow in creating matcher 58a606dba708 net/mlx5: Introduce new uplink destination type 455832d49666 net/mlx5: DR, Fix check for unsupported fields in match param 9091b821aaa4 net/mlx5: DR, Handle eswitch manager and uplink vports separately #SW STEERING SF 515ce2ffa621 net/mlx5: DR, init_next_match only if needed 5dde00a73048 net/mlx5: DR, Fix typo 'offeset' to 'offset' 1ffd498901c1 net/mlx5: DR, Increase supported num of actions to 32 11a45def2e19 net/mlx5: DR, Add support for SF vports c0e90fc2ccaa net/mlx5: DR, Support csum recalculation flow table on SFs ee1887fb7cdd net/mlx5: DR, Align error messages for failure to obtain vport caps dd4acb2a0954 net/mlx5: DR, Add missing query for vport 0 7ae8ac9a5820 net/mlx5: DR, Replace local WIRE_PORT macro with the existing MLX5_VPORT_UPLINK f9f93bd55ca6 net/mlx5: DR, Fix vport number data type to u16 c228dce26222 net/mlx5: DR, Fix code indentation in dr_ste_v1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966194/+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
