[Bug 2064809] [NEW] zstd support not enabled in makedumpfile
Public bug reported: Zstd support seems to be missing from the latest makedumpfile versions. Although it seemed to have been introduced after bug 1949395, this is what I get in a Debian sid VM: halves@sid:~$ makedumpfile -v makedumpfile: version 1.7.5 (released on 12 Apr 2024) lzo enabled snappy disabled zstddisabled The same is the case in a fresh Noble container: halves@noble:~$ makedumpfile -v makedumpfile: version 1.7.5 (released on 12 Apr 2024) lzo enabled snappy disabled zstddisabled halves@noble:~$ dpkg -l | grep makedumpfile ii makedumpfile 1:1.7.5-1amd64VMcore extraction tool ** Affects: makedumpfile (Ubuntu) Importance: Medium Assignee: Heitor Alves de Siqueira (halves) Status: In Progress ** Changed in: makedumpfile (Ubuntu) Status: Confirmed => In Progress ** Changed in: makedumpfile (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064809 Title: zstd support not enabled in makedumpfile To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/2064809/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1916303] Re: [RFE] kdump memory estimator
Thanks, gpiccoli! This is fixed in kdump-tools 1.10, so I'm marking it as Fix Released (Noble and Oracular already ship with version 1.10.3ubuntu2). I'm also marking makedumpfile as Invalid, since kdump-tools was split from that source package. ** Changed in: makedumpfile (Ubuntu) Status: Fix Committed => Invalid ** Also affects: kdump-tools (Ubuntu) Importance: Undecided Status: New ** Changed in: kdump-tools (Ubuntu) Status: New => Fix Released ** Changed in: kdump-tools (Ubuntu) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1916303 Title: [RFE] kdump memory estimator To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1916303/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2061825] Re: [SRU] ucf fails to work for local diversions on Jammy
Thanks for the confirmation on Focal, @pponnuvel! I've tested your debdiff, and it seems to work correctly. Patch is also a straightforward cherry-pick from Debian. Sponsored for Jammy, with the update-maintainer changes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061825 Title: [SRU] ucf fails to work for local diversions on Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ucf/+bug/2061825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953572] Re: Broken links in the View Trends and the View Histogram menu
** Changed in: nagios4 (Ubuntu Noble) Status: Incomplete => In Progress ** Changed in: nagios4 (Ubuntu) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953572 Title: Broken links in the View Trends and the View Histogram menu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nagios4/+bug/1953572/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1919154] Re: Enable CONFIG_NO_HZ_FULL on supported architectures
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919154 Title: Enable CONFIG_NO_HZ_FULL on supported architectures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1919154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds
Marking as verified according to comment #21 ** Tags removed: verification-needed verification-needed-mantic ** Tags added: verification-done verification-done-mantic ** Changed in: software-properties (Ubuntu) Status: Confirmed => Invalid ** Changed in: software-properties (Ubuntu Mantic) Status: Confirmed => Invalid ** Changed in: software-properties (Ubuntu Noble) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2036761 Title: [mantic] ppa-purge no longer purges what add-apt-repository adds To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ppa-purge/+bug/2036761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2016881] Re: Building for Focal fails on riscv64
Bionic is EoL, if RISC-V support is needed there we'll need to target Pro 18.04. ** Tags removed: patch se-sponsor-halves ** Description changed: - Building zfs-linux for riscv64 fails on Ubuntu 18.04. There is a single - patch missing: - https://github.com/openzfs/zfs/commit/4254e407294b211f3399da2ee131b45fe9f4ac80 + [Impact] + * riscv64 builds fail completely, so users on that architecture can't use ZFS. + + [Test Plan] + * Build zfs-linux on target architecture. No test failure is expected. + + [Where problems could occur] + * Test failures and bugs that are exclusive to RISCV64 might show up + + [Other Info] + * Upstream introduced support riscv64 with 4254e407294b + * Builds succeed on Jammy and newer, Focal is missing the enablement patch + + -- + [Original Description] + Building zfs-linux for riscv64 fails on Ubuntu 18.04. There is a single patch missing: https://github.com/openzfs/zfs/commit/4254e407294b211f3399da2ee131b45fe9f4ac80 ** Changed in: zfs-linux (Ubuntu Bionic) Status: Invalid => Won't Fix ** Summary changed: - Building for Focal fails on riscv64 + zfs-linux FTBFS for riscv64 on Focal ** Changed in: zfs-linux (Ubuntu Bionic) Importance: Medium => Undecided -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2016881 Title: zfs-linux FTBFS for riscv64 on Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2016881/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1987052] Re: Running MySQL8 in Docker on ZFS only works if you have ZFS 2.1.5. Ubuntu 22.04 only has 2.1.4 right now.
** Changed in: zfs-linux (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1987052 Title: Running MySQL8 in Docker on ZFS only works if you have ZFS 2.1.5. Ubuntu 22.04 only has 2.1.4 right now. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1987052/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1980848] Re: arc_summary doesn't work with HWE kernel 5.15
** Also affects: zfs-linux (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: zfs-linux (Ubuntu Focal) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: zfs-linux (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: zfs-linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: zfs-linux (Ubuntu) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: zfs-linux (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1980848 Title: arc_summary doesn't work with HWE kernel 5.15 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1980848/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953572] Re: Broken links in the View Trends and the View Histogram menu
Thanks for the debdiff, Jorge! A few comments: Even though the fix is the same for J/M/N, we'll need separate debdiffs and versions for each. We'll need to keep the upgrade path working between each release, so I'd suggest something like below (according to [0]): - 4.4.6-4ubuntu0.22.04.1 for Jammy - 4.4.6-4ubuntu0.23.10.1 for Mantic - 4.4.6-4ubuntu0.24.04.1 or 4.4.6-4ubuntu1 for Noble (depending on whether O will need fixing as well) And it's great that you ran the update-maintainer script as well. Would you be able to add a mention of this in the changelog entries, too? Finally, I'd really appreciate it if we had any mention of the fix on the SRU template. Maybe a short section explaining why we're changing the --with-cgiurl flag, and where that fix came from? [0] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging ** Changed in: nagios4 (Ubuntu Noble) Status: Confirmed => Incomplete ** Changed in: nagios4 (Ubuntu Focal) Status: New => In Progress ** Changed in: nagios4 (Ubuntu Jammy) Status: New => In Progress ** Changed in: nagios4 (Ubuntu Mantic) Status: New => In Progress ** Changed in: nagios4 (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: nagios4 (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: nagios4 (Ubuntu Mantic) Importance: Undecided => Medium ** Changed in: nagios4 (Ubuntu Noble) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953572 Title: Broken links in the View Trends and the View Histogram menu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nagios4/+bug/1953572/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2061825] Re: [SRU] ucf fails to work for local diversions on Jammy
Hi Pon, thanks for the revised debdiff! This seems to be a non-quilt package, so your approach of directly patching the ucf/ucfr scripts is correct. The only thing missing is running the update-maintainer script, as the ubuntu1 version requires having an ubuntu.com address on the maintainers field. This is something a sponsor can run easily, so don't worry about fixing it for now (but feel free to do it for future debdiffs!). Before uploading this, I'd like to check about Focal; is that release affected at all? If it is, any reason why we shouldn't patch it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061825 Title: [SRU] ucf fails to work for local diversions on Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ucf/+bug/2061825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2061986] Re: Mount CIFS fails with Permission denied
Marking Ubuntu as "Fix Released" according to parent description, as fix was introduced upstream in v5.16. ** Changed in: linux (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Jammy) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061986 Title: Mount CIFS fails with Permission denied To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061986/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2061986] Re: Mount CIFS fails with Permission denied
** Changed in: linux (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061986 Title: Mount CIFS fails with Permission denied To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061986/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2038453] Re: [SRU] apt snapshot integration backport
** Changed in: ubuntu-pro/18.04 Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2038453 Title: [SRU] apt snapshot integration backport To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-pro/+bug/2038453/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1855189] Re: usbguard stops responding when recvmsg receives ENOBUFS
# VERIFICATION FOCAL Validation performed on a 6-core VM with 8Gb or RAM. The following stress-ng command was running throughout the test from the description: # stress-ng --class memory --class vm --all 1 --timeout 96h Afterwards, the udevadm test loop was executed as below: # date; while /bin/true; do sudo udevadm control --reload-rules sudo udevadm trigger sudo udevadm settle --timeout=3 done Thu Apr 11 19:19:18 UTC 2024 ... A few minutes later, the errors started showing up on journald: # journalctl --follow -b -u usbguard | grep -A2 "failed to read" Apr 11 19:21:59 z-rotomvm34 usbguard-daemon[197214]: [1712863318.753] (E) ueventProcessRead: failed to read pending uevent: rc=-1 errno=105 Apr 11 19:21:59 z-rotomvm34 usbguard-daemon[197214]: [1712863318.755] (E) UEventDeviceManager thread: UEvent device manager: recvmsg: No buffer space available ..and usbguard became unresponsive. This seems good indication that the reproducer is valid. I then upgraded to the usbguard version from proposed and repeated the tests (plus stress-ng workload). The VM has been running for many hours since then, and journald indicates that we've triggered the ENOBUFS issues more than a few times. usbguard-daemon continued chugging along and responding to events, so we can mark this as verified. Below are the verification logs. ### $ dpkg -l | grep usbguard ii libusbguard0 0.7.6+ds-1ubuntu1 amd64USB device authorization policy framework - shared library ii usbguard 0.7.6+ds-1ubuntu1 amd64USB device authorization policy framework $ date; while /bin/true; do sudo udevadm control --reload-rules sudo udevadm trigger sudo udevadm settle --timeout=3 done Tue Apr 16 10:20:33 UTC 2024 # stress-ng --class memory --class vm --all 1 --timeout 96h $ sudo journalctl -b -u usbguard | grep -A1 "failed to read" Apr 16 13:40:40 z-rotomvm34 usbguard-daemon[712]: [1713274840.663] (E) ueventProcessRead: failed to read pending uevent (returning): rc= -1 errno=105 Apr 16 13:40:40 z-rotomvm34 usbguard-daemon[712]: [1713274840.827] (A) uid=0 pid=712 result='SUCCESS' device.rule='allow id 1d6b:0001 se rial ":00:04.0" name "UHCI Host Controller" hash "sKXn6PthDDlGgdxZHdnlUQ9DROkH/YSojkBlfpcnsaU=" parent-hash "9Ii0Zm8Mvu2nYz9z/EgAXJ/ed6bLW8Ctv1iUD5rh6qY=" via-port "usb2" with-interface 09:00:00 with-connect-type ""' device.system_name='/devices/pci:00/:00:04.0/usb2' type='Device.Present' -- Apr 16 14:15:45 z-rotomvm34 usbguard-daemon[712]: [1713276945.707] (E) ueventProcessRead: failed to read pending uevent (returning): rc=-1 errno=105 Apr 16 14:15:45 z-rotomvm34 usbguard-daemon[712]: [1713276945.709] (A) uid=0 pid=712 result='SUCCESS' device.rule='allow id 0627:0001 serial "28754-:00:04.7-1" name "QEMU USB Tablet" hash "74abnf32ZntGQv1XK1k5t/IqWo3wxePUnjpidwCzMk4=" parent-hash "CsKOZ6IY8v3eojsc1fqKDW84V+MMhD6HsjjojcZBjSg=" via-port "1-1" with-interface 03:00:00 with-connect-type "unknown"' device.system_name='/devices/pci:00/:00:04.7/usb1/1-1' type='Device.Present' -- Apr 16 14:43:09 z-rotomvm34 usbguard-daemon[712]: [1713278589.740] (E) ueventProcessRead: failed to read pending uevent (returning): rc=-1 errno=105 Apr 16 14:43:10 z-rotomvm34 usbguard-daemon[712]: [1713278590.573] (A) uid=0 pid=712 result='SUCCESS' device.rule='allow id 1d6b:0001 serial ":00:04.0" name "UHCI Host Controller" hash "sKXn6PthDDlGgdxZHdnlUQ9DROkH/YSojkBlfpcnsaU=" parent-hash "9Ii0Zm8Mvu2nYz9z/EgAXJ/ed6bLW8Ctv1iUD5rh6qY=" via-port "usb2" with-interface 09:00:00 with-connect-type ""' device.system_name='/devices/pci:00/:00:04.0/usb2' type='Device.Present' ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1855189 Title: usbguard stops responding when recvmsg receives ENOBUFS To manage notifications about this bug go to: https://bugs.launchpad.net/usbguard/+bug/1855189/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1855189] Re: usbguard stops responding when recvmsg receives ENOBUFS
Thanks, Robie! Our users reported that issues usually appear within one or two hours, but that's likely tied to machine-specific workloads. I've been able to force this issue to occur in a VM when running the test script from the description together with stress-ng memory/vm stressors. The "failed to read" logs then trigger consistently within a few minutes. Considering that we do need memory pressure for the ENOBUFS issues to happen, I think this is a valid test scenario. I'll add this to the test plan section of the bug, and see if I can do a long duration test with the package from proposed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1855189 Title: usbguard stops responding when recvmsg receives ENOBUFS To manage notifications about this bug go to: https://bugs.launchpad.net/usbguard/+bug/1855189/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Thanks for the revised debdiff, Matthew! And nice work on the extensive sanity check for the version laddering. The new debdiff looks good, I've sponsored it for Focal. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Hi Matthew, thanks for the quick follow-up on the regression! Being the sponsor for the original patch in bug 2049262, I wanted to give this one some deeper attention. Version parsing seems to have been a difficult area upstream, with several follow-up fixes indeed, so thank you for detailing the required commits. I've done a double-check upstream, and noticed an additional fix that doesn't seem to be on your list: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=5f32083c759b - 5f32083c mount.nfs: Fix auto protocol negotiation $ git describe --contains 5f32083c759b nfs-utils-2-3-2-rc2~9 This fixes a regression with falling back to NFSv3 on servers that don't support v4, and was introduced by 71b807e1. Could you please confirm whether we need to pull it in with the ones you already listed for Focal? It's already present in Jammy and newer. ** Changed in: nfs-utils (Ubuntu Focal) Status: In Progress => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2016881] Re: Building for Focal fails on riscv64
** Changed in: zfs-linux (Ubuntu Focal) Importance: Medium => Low ** Changed in: zfs-linux (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: zfs-linux (Ubuntu Focal) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2016881 Title: Building for Focal fails on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2016881/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2009885] Re: Timeshift 21.09.1-1 broken after Rsync upgrade to 3.2.7-0ubuntu0.22.04.2
** Changed in: timeshift (Ubuntu) Status: Confirmed => Fix Released ** Changed in: timeshift (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: timeshift (Ubuntu Jammy) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2009885 Title: Timeshift 21.09.1-1 broken after Rsync upgrade to 3.2.7-0ubuntu0.22.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/timeshift/+bug/2009885/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1855189] Re: usbguard stops responding when recvmsg receives ENOBUFS
We've had users report this bug under Focal, and the usbguard pkg there does seem to be missing this fix. I've updated the bug with the SRU template, and tested the patches (builds available at [0]). Users also reported that this patched version resolved this issue, so I've pushed it to the Focal upload queue. [0] https://launchpad.net/~halves/+archive/ubuntu/test -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1855189 Title: usbguard stops responding when recvmsg receives ENOBUFS To manage notifications about this bug go to: https://bugs.launchpad.net/usbguard/+bug/1855189/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1855189] Re: usbguard stops responding when recvmsg receives ENOBUFS
** Description changed:
- With 0.7.4+ds-1 from 19.10, usbguard may stop responding to events when
- recvmsg fails with ENOBUFS. To reproduce:
+ [Impact]
+ usbguard-daemon will no longer process device events until restarted
+
+ [Test Plan]
+ 1. Spin up a Focal VM with usbguard enabled
+ 2. Run the script below:
+
+ while /bin/true ; do
+ sudo udevadm control --reload-rules
+ sudo udevadm trigger
+ sudo udevadm settle --timeout=3
+ done
+
+ 3. journald logs will indicate the following errors:
+ usbguard-daemon[12488]: ueventProcessRead: failed to read pending uevent:
rc=-1 errno=105
+ usbguard-daemon[12488]: UEventDeviceManager thread: UEvent device manager:
recvmsg: No buffer space available
+
+ [Where problems could occur]
+ The fix introduces an additional check in the usbguard event handler, so we
should properly test this path. Potential regressions could cause USB devices
to not be probed correctly, or usbguard dropping device events. We should also
make sure the usbguard daemon is recovering from ENOBUFS and other errors
correctly without needing to be restarted.
+
+ [Other Info]
+ The fix has been introduced upstream in version usbguard-0.7.7:
+ $ git describe --contains 5f297079b843
+ usbguard-0.7.7~2
+
+ As such, releases starting with Jammy already contain the fix:
+ $ rmadison usbguard
+ usbguard | 0.7.2+ds-1 | bionic/universe | source, amd64, arm64, armhf,
i386, ppc64el, s390x
+ usbguard | 0.7.6+ds-1build1 | focal/universe | source, amd64, arm64, armhf,
ppc64el, riscv64, s390x
+ usbguard | 1.1.1+ds-3 | jammy/universe | source, amd64, arm64, armhf,
ppc64el, riscv64, s390x
+ usbguard | 1.1.2+ds-4 | mantic/universe | source, amd64, arm64, armhf,
ppc64el, riscv64, s390x
+ usbguard | 1.1.2+ds-6 | noble/universe | source, amd64, arm64, armhf,
ppc64el, riscv64, s390x
+
+ --
+ [Original description]
+ With 0.7.4+ds-1 from 19.10, usbguard may stop responding to events when
recvmsg fails with ENOBUFS. To reproduce:
while /bin/true ; do
sudo udevadm control --reload-rules
sudo udevadm trigger
sudo udevadm settle --timeout=3
done
Eventually, this pops out in the journald logs:
usbguard-daemon[12488]: ueventProcessRead: failed to read pending uevent:
rc=-1 errno=105
usbguard-daemon[12488]: UEventDeviceManager thread: UEvent device manager:
recvmsg: No buffer space available
and usbguard will no longer process events until restarted (sudo
systemctl restart usbguard).
I then installed usbguard 0.7.5 from the desktop team's PPA[1], ran the
loop and saw the equivalent error pop out:
usbguard-daemon[5958]: [1575487887.438] (E) ueventProcessRead: failed to
read pending uevent: rc=-1 errno=105
usbguard-daemon[5958]: [1575487887.438] (E) UEventDeviceManager thread:
UEvent device manager: recvmsg: No buffer space available
This is coming from
https://github.com/USBGuard/usbguard/blob/master/src/Library/UEventDeviceManager.cpp#L528
where recvmsg() is returning -1 with 'No buffer space available'
(ENOBUFS). Looking at sysdeps/gnu/errlist.c in glibc, ENOBUFS is
documented as:
#ifdef ENOBUFS
/*
TRANS The kernel's buffers for I/O operations are all in use. In GNU, this
TRANS error is always synonymous with @code{ENOMEM}; you may get one or the
TRANS other from network operations. */
[ERR_REMAP (ENOBUFS)] = N_("No buffer space available"),
It seems that usbguard should be able to handle transient ENOBUFS
scenarios with uevent storms and recover when the kernel's buffers are
back in order. In my testing, I treated ENOBUFS similarly to
EAGAIN/EWOULDBLOCK by logging a warning and simply returning[2]:
usbguard-daemon[2405]: ueventProcessRead: failed to read pending
uevent (returning): rc=-1 errno=105
It appears usbguard continues to function (eg, if I do the loop for a
long time, usbguard remains responsive and processes other uevents, but
I'm not sure this is the correct approach since, for example,
UEventDeviceManager::ueventOpen() speaks to this error condition by
saying: "Set a 1MiB receive buffer on the netlink socket to avoid
ENOBUFS error in recvmsg").
[1]https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/usbguard
[2]exploratory patch (do not commit in Ubuntu without upstream confirmation)
Index: usbguard-0.7.4+ds/src/Library/UEventDeviceManager.cpp
===
--- usbguard-0.7.4+ds.orig/src/Library/UEventDeviceManager.cpp
+++ usbguard-0.7.4+ds/src/Library/UEventDeviceManager.cpp
@@ -468,6 +468,12 @@ namespace usbguard
<< "reading from uevent source would block thread execution";
return;
}
+ else if (saved_errno == ENOBUFS) {
+USBGUARD_LOG(Error) << "ueventProcessRead: "
+ << "failed to read pending uevent (returning): "
+ << "rc=" << rc << "
[Bug 1855189] Re: usbguard stops responding when recvmsg receives ENOBUFS
** Also affects: usbguard (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: usbguard (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: usbguard (Ubuntu Focal) Status: New => In Progress ** Changed in: usbguard (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1855189 Title: usbguard stops responding when recvmsg receives ENOBUFS To manage notifications about this bug go to: https://bugs.launchpad.net/usbguard/+bug/1855189/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds
Hi Ghadi, thanks for the debdiff! I've considered trimming down the new version to 0.2.8+bzr63-0ubuntu1.1 according to [0], but ultimately think your approach is correct (otherwise it'll be hard to update ppa-purge in Jammy if we ever need to!). Tested and sponsored for Mantic. [0] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging ** Changed in: ppa-purge (Ubuntu Mantic) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2036761 Title: [mantic] ppa-purge no longer purges what add-apt-repository adds To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ppa-purge/+bug/2036761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1993009] Re: usbguard 0.7.8 focal backport request
*** This bug is a duplicate of bug 1855189 *** https://bugs.launchpad.net/bugs/1855189 This seems to be a duplicate of bug 1855189. Feel free to drop a comment if this isn't the case, and we can investigate further. Thanks! ** This bug has been marked a duplicate of bug 1855189 usbguard stops responding when recvmsg receives ENOBUFS -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1993009 Title: usbguard 0.7.8 focal backport request To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/usbguard/+bug/1993009/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056802] Re: crypttab does not honor `x-initrd.attach` option
Thank you for the bug, Heather! I'm marking Bionic as "Won't Fix", as it's EOL. If needed, please re-target against Pro 18.04. Thanks! ** Changed in: systemd (Ubuntu Bionic) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056802 Title: crypttab does not honor `x-initrd.attach` option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2056802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968805] Re: Hibernation fails when an additional swapfile is added due to priority mismatch
Uploaded to the stable series. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968805 Title: Hibernation fails when an additional swapfile is added due to priority mismatch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ec2-hibinit-agent/+bug/1968805/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968805] Re: Hibernation fails when an additional swapfile is added due to priority mismatch
** Tags removed: sts-sponsor ** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968805 Title: Hibernation fails when an additional swapfile is added due to priority mismatch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ec2-hibinit-agent/+bug/1968805/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1972029] Re: dhclient overriding stub-resolv.conf file on Jammy
** Tags added: sts sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1965325] Re: upstream patch from opendev - double encoding-decoding
Uploaded to stable releases, thanks! I had to adjust some minor things (package versions) due to the new kinetic upload, but the patches themselves were good. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1965325 Title: upstream patch from opendev - double encoding-decoding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-etcd3gw/+bug/1965325/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
Validated glibc from focal-proposed according to test case from description: halves@glibc-zen:~$ ./test_memcpy64 32 32 MB = 1.222535 ms -Compare match (should be zero): 0 halves@glibc-zen:~$ dpkg -l | grep libc-bin ii libc-bin 2.31-0ubuntu9.9amd64 GNU C Library: Binaries halves@glibc-zen:~$ grep -m1 "model name" /proc/cpuinfo model name : AMD Ryzen 7 3700X 8-Core Processor Also validated on an Intel system, and no performance regressions have been observed: halves@halves-focal-glibc-xeon:~$ ./test_memcpy64 32 32 MB = 2.174005 ms -Compare match (should be zero): 0 halves@halves-focal-glibc-xeon:~$ grep -m1 "model name" /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz halves@halves-focal-glibc-xeon:~$ dpkg -l | grep libc-bin ii libc-bin 2.31-0ubuntu9.9amd64 GNU C Library: Binaries ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872813] Re: cloud-init fails to detect iSCSI root on focal Oracle instances
Sponsored for Bionic. Thanks for the contribution, @jorge-merlino! ** Changed in: open-iscsi (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872813 Title: cloud-init fails to detect iSCSI root on focal Oracle instances To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872813/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1942624] Re: NVMe devices fail to probe due to ACPI power state change
** Description changed: [Impact] * Specific NVMe devices fail to probe and become unusable after boot * Caused by an ACPI regression that doesn't correctly handle power states * Upstream regression commit: 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally * Regression window for Ubuntu kernels includes 5.13 and 5.14 [Test Plan] * Boot affected kernel and validate whether NVMe device is usuble * Check kernel logs for failed probe message: "can't change power state from D3Cold to D0 (config space inaccessible" [Fix] * Fixed by not turning off power resources in unknown state * Fix was introduced by commit: bc2836859643 ACPI: PM: Do not turn off power resources in unknown state - * Ubuntu kernels starting with 5.15 (Jammy) not affected, as they contain the fix above + * Kernels starting with 5.15 (e.g. Jammy) not affected, as they already contain the fix above [Regression Potential] * NVMe devices continue failing to probe * Other devices become unusable after power state changes * Further regressions would affect power state of devices, possibly after boot -- [Original Description] NVME "can't change power state from D3Cold to D0 (config space inaccessible)" Bug with kernels after version 5.11.0-18 on Lenovo Ideapad 330-15ICH. The NVME drive with my root partition cannot be mounted at boot with an error "can't change power state from D3Cold to D0 (config space inaccessible)". I'm willing to help find a root cause if I don't need to spent too many hours. All Ubuntu kernels after 5.11.0-18 exhibit this bug, but I could boot properly with the official linux kernel 5.13.0. Thanks a lot for your help ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: linux-image-5.11.0-18-generic 5.11.0-18.19 ProcVersionSignature: Ubuntu 5.11.0-18.19-generic 5.11.17 Uname: Linux 5.11.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris 7503 F pulseaudio /dev/snd/pcmC0D0p: chris 7503 F...m pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Sep 3 18:46:35 2021 InstallationDate: Installed on 2019-07-17 (779 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 5986:210e Acer, Inc EasyCamera Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 007: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 81FK ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-18-generic root=UUID=9d963312-3a16-428d-8efd-f1323c6528f1 ro quiet nosplash crashkernel=512M-:192M RelatedPackageVersions: linux-restricted-modules-5.11.0-18-generic N/A linux-backports-modules-5.11.0-18-generic N/A linux-firmware 1.197.3 SourcePackage: linux UpgradeStatus: Upgraded to hirsute on 2021-06-03 (92 days ago) dmi.bios.date: 10/24/2018 dmi.bios.release: 1.29 dmi.bios.vendor: LENOVO dmi.bios.version: 7ZCN29WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 330-15ICH dmi.ec.firmware.release: 1.29 dmi.modalias: dmi:bvnLENOVO:bvr7ZCN29WW:bd10/24/2018:br1.29:efr1.29:svnLENOVO:pn81FK:pvrLenovoideapad330-15ICH:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoideapad330-15ICH: dmi.product.family: ideapad 330-15ICH dmi.product.name: 81FK dmi.product.sku: LENOVO_MT_81FK_BU_idea_FM_ideapad 330-15ICH dmi.product.version: Lenovo ideapad 330-15ICH dmi.sys.vendor: LENOVO ** Description changed: [Impact] * Specific NVMe devices fail to probe and become unusable after boot * Caused by an ACPI regression that doesn't correctly handle power states * Upstream regression commit: 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally * Regression window for Ubuntu kernels includes 5.13 and 5.14 [Test Plan] - * Boot affected kernel and validate whether NVMe device is usuble + * Boot affected kernel and validate whether NVMe device is usable * Check kernel logs for failed probe message: - "can't change power state from D3Cold to D0 (config space inaccessible" + "can't change power state from D3Cold to D0 (config space inaccessible)" [Fix] * Fixed by not turning off power resources in unknown state * Fix was introduced by commit: bc2836859643 ACPI: PM: Do not turn off power resources in unknown state * Kernels starting with 5.15 (e.g. Jammy) not affected, as they already contain the fix
[Bug 1942624] Re: NVMe devices fail to probe due to ACPI power state change
** Summary changed: - NVME "can't change power state from D3Cold to D0 (config space inaccessible)" + NVMe devices fail to probe due to ACPI power state change ** Description changed: + [Impact] + * Specific NVMe devices fail to probe and become unusable after boot + * Caused by an ACPI regression that doesn't correctly handle power states + * Upstream regression commit: + 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally + + [Test Plan] + * Boot affected kernel and validate whether NVMe device is usuble + * Check kernel logs for failed probe message: + "can't change power state from D3Cold to D0 (config space inaccessible" + + [Fix] + * Fixed by not turning off power resources in unknown state + * Fix was introduced by commit: + bc2836859643 ACPI: PM: Do not turn off power resources in unknown state + + [Regression Potential] + * NVMe devices continue failing to probe + * Other devices become unusable after power state changes + * Further regressions would affect power state of devices, possibly after boot + + -- + [Original Description] + NVME "can't change power state from D3Cold to D0 (config space inaccessible)" + Bug with kernels after version 5.11.0-18 on Lenovo Ideapad 330-15ICH. The NVME drive with my root partition cannot be mounted at boot with an error "can't change power state from D3Cold to D0 (config space inaccessible)". I'm willing to help find a root cause if I don't need to spent too many hours. All Ubuntu kernels after 5.11.0-18 exhibit this bug, but I could boot properly with the official linux kernel 5.13.0. Thanks a lot for your help ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: linux-image-5.11.0-18-generic 5.11.0-18.19 ProcVersionSignature: Ubuntu 5.11.0-18.19-generic 5.11.17 Uname: Linux 5.11.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris 7503 F pulseaudio /dev/snd/pcmC0D0p: chris 7503 F...m pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Sep 3 18:46:35 2021 InstallationDate: Installed on 2019-07-17 (779 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 5986:210e Acer, Inc EasyCamera Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 007: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 81FK ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-18-generic root=UUID=9d963312-3a16-428d-8efd-f1323c6528f1 ro quiet nosplash crashkernel=512M-:192M RelatedPackageVersions: linux-restricted-modules-5.11.0-18-generic N/A linux-backports-modules-5.11.0-18-generic N/A linux-firmware 1.197.3 SourcePackage: linux UpgradeStatus: Upgraded to hirsute on 2021-06-03 (92 days ago) dmi.bios.date: 10/24/2018 dmi.bios.release: 1.29 dmi.bios.vendor: LENOVO dmi.bios.version: 7ZCN29WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 330-15ICH dmi.ec.firmware.release: 1.29 dmi.modalias: dmi:bvnLENOVO:bvr7ZCN29WW:bd10/24/2018:br1.29:efr1.29:svnLENOVO:pn81FK:pvrLenovoideapad330-15ICH:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoideapad330-15ICH: dmi.product.family: ideapad 330-15ICH dmi.product.name: 81FK dmi.product.sku: LENOVO_MT_81FK_BU_idea_FM_ideapad 330-15ICH dmi.product.version: Lenovo ideapad 330-15ICH dmi.sys.vendor: LENOVO ** Description changed: [Impact] * Specific NVMe devices fail to probe and become unusable after boot * Caused by an ACPI regression that doesn't correctly handle power states * Upstream regression commit: - 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally + 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally + * Regression window for Ubuntu kernels includes 5.13 and 5.14 [Test Plan] * Boot affected kernel and validate whether NVMe device is usuble * Check kernel logs for failed probe message: - "can't change power state from D3Cold to D0 (config space inaccessible" + "can't change power state from D3Cold to D0 (config space inaccessible" [Fix] * Fixed by not turning off power resources in unknown state * Fix was introduced by commit: - bc2836859643 ACPI: PM: Do not turn off power resources in unknown state + bc2836859643 ACPI: PM: Do not turn off power resources in unknown state + * Ubuntu kernels starting with 5.15 (Jammy) not affected, as they contain the fix above
[Bug 1964512] Re: Low RX performance for 40G Solarflare NICs
In addition to my own validations above, impacted users that have 40G NICs have also confirmed the patch behaves as expected without major regressions. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964512] Re: Low RX performance for 40G Solarflare NICs
Validated for Ubuntu Impish with the current kernel from impish-proposed. Tested on a 10G NIC that's affected by this patch (device ID 0x0903). iperf3 shows that we're able to almost saturate the NIC successfully in both standard and reverse sender mode: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.1 GBytes 8.69 Gbits/sec 990 sender [ 5] 0.00-9.99 sec 10.1 GBytes 8.69 Gbits/sec receiver [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.8 GBytes 9.30 Gbits/sec 155 sender [ 5] 0.00-10.00 sec 10.8 GBytes 9.30 Gbits/sec receiver ubuntu@duduo:~$ uname -rv 5.13.0-40-generic #45-Ubuntu SMP Tue Mar 29 14:48:14 UTC 2022 Other basic smoke testing confirms no major regressions. ** Tags removed: verification-needed-impish ** Tags added: verification-done-impish -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964512] Re: Low RX performance for 40G Solarflare NICs
Validated for Ubuntu Bionic with the current HWE kernel from bionic-proposed. Tested on a 10G NIC that's affected by this patch (device ID 0x0903). iperf3 shows that we're able to almost saturate the NIC successfully in both standard and reverse sender mode: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.2 GBytes 8.80 Gbits/sec 376 sender [ 5] 0.00-10.00 sec 10.2 GBytes 8.80 Gbits/sec receiver [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec0 sender [ 5] 0.00-10.00 sec 10.9 GBytes 9.38 Gbits/sec receiver ubuntu@duduo:~$ uname -rv 5.4.0-108-generic #122~18.04.1-Ubuntu SMP Wed Apr 6 16:57:12 UTC 2022 Other basic smoke testing confirms no major regressions. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964512] Re: Low RX performance for 40G Solarflare NICs
Validated for Ubuntu Focal with the current kernel from focal-proposed. Tested on a 10G NIC that's affected by this patch (device ID 0x0903). iperf3 shows that we're able to almost saturate the NIC successfully in both standard and reverse sender mode: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.3 GBytes 8.83 Gbits/sec 266 sender [ 5] 0.00-10.00 sec 10.3 GBytes 8.82 Gbits/sec receiver [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 10.8 GBytes 9.30 Gbits/sec0 sender [ 5] 0.00-10.00 sec 10.8 GBytes 9.30 Gbits/sec receiver ubuntu@duduo:~$ uname -rv 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1872813] Re: cloud-init fails to detect iSCSI root on focal Oracle instances
** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872813 Title: cloud-init fails to detect iSCSI root on focal Oracle instances To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872813/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1965325] Re: upstream patch from opendev - double encoding-decoding
** Tags removed: sts-sponsor ** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1965325 Title: upstream patch from opendev - double encoding-decoding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-etcd3gw/+bug/1965325/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1942624] Re: NVME "can't change power state from D3Cold to D0 (config space inaccessible)"
Hi all, This seems to be related to a regression introduced by the following commit: * 7e4fdeafa61f ACPI: power: Turn off unused power resources unconditionally The fix seems to indeed be the commit @sclarkson mentioned: * bc2836859643 ACPI: PM: Do not turn off power resources in unknown state Looking at our kernels, it seems the affected version window is between v5.12 and v5.15. I've tagged the relevant packages in this bug, and have built a set of test kernels to validate the fixes. For the 5.13 kernels, we additionally require the commit below: * 9b7ff25d129d ACPI: power: Refine turning off unused power resources I'd greatly appreciate if anyone affected by this could give these test kernels a try, as I don't have the appropriate hardware to test it myself. I've uploaded packages for Focal-HWE/Impish (5.13) and Focal-OEM (5.14) to a public PPA, but please consider these packages for testing purposes only. If you can reproduce this bug on a different kernel, please add a comment and I'll look into backporting the required patches there as well. Cheers, Heitor [0] https://launchpad.net/~halves/+archive/ubuntu/test-1942624 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1942624 Title: NVME "can't change power state from D3Cold to D0 (config space inaccessible)" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942624/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1942624] Re: NVME "can't change power state from D3Cold to D0 (config space inaccessible)"
** Changed in: linux (Ubuntu Impish) Status: Confirmed => In Progress ** Changed in: linux-oem-5.14 (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: linux-oem-5.14 (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1942624 Title: NVME "can't change power state from D3Cold to D0 (config space inaccessible)" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942624/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1942624] Re: NVME "can't change power state from D3Cold to D0 (config space inaccessible)"
** Also affects: linux-oem-5.14 (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-oem-5.14 (Ubuntu) Status: New => Confirmed ** Also affects: linux (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: linux-oem-5.14 (Ubuntu Impish) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu Impish) Status: New => Confirmed ** Changed in: linux (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Impish) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-oem-5.14 (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Focal) Status: New => Invalid ** Changed in: linux-oem-5.14 (Ubuntu Impish) Status: New => Invalid ** Changed in: linux-oem-5.14 (Ubuntu Focal) Status: New => Confirmed ** Changed in: linux-oem-5.14 (Ubuntu) Importance: Undecided => Medium ** Changed in: linux-oem-5.14 (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux-oem-5.14 (Ubuntu) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux-oem-5.14 (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1942624 Title: NVME "can't change power state from D3Cold to D0 (config space inaccessible)" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942624/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964992] Re: ZFS ignores ARC sizes below allmem/32
** Patch added: "lp1964992-focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1964992/+attachment/5571326/+files/lp1964992-focal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964992 Title: ZFS ignores ARC sizes below allmem/32 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1964992/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964992] Re: ZFS ignores ARC sizes below allmem/32
This doesn't seem to be reproducible in Bionic, marking it as fixed accordingly. ** Changed in: zfs-linux (Ubuntu Bionic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964992 Title: ZFS ignores ARC sizes below allmem/32 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1964992/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964992] [NEW] ZFS ignores ARC sizes below allmem/32
Public bug reported:
[Impact]
ZFS ignores tunable "zfs_arc_max" due to it being below allmem/32 threshold.
This prevents users from properly restraining ARC sizes, and can cause
increased memory contention in some systems.
[Test Plan]
1. Deploy test system with ZFS storage and 32GB RAM
2. Add ARC tunables to /etc/modprobe.d/99-zfs-arc.conf
# cat /etc/modprobe.d/99-zfs-arc.conf
options zfs zfs_arc_min=536870912
options zfs zfs_arc_max=966367641
3. Reboot system
4. Verify ARC sizes through "arc_summary"
# arc_summary | grep -A3 "ARC size"
ARC size (current): < 0.1 %1.3 MiB
Target size (adaptive): 100.0 % 15.7 GiB
Min size (hard limit): 3.2 % 512.0 MiB
Max size (high water): 31:1 15.7 GiB
For a 32GB test system, we should be able to set max ARC sizes below
1GB.
[Fix]
This has been fixed by upstream commit:
- 36a6e2335c45 "Don't ignore zfs_arc_max below allmem/32"
The commit has been introduced in upstream zfs-2.0.0, so it's needed for
Bionic and Focal. Releases starting with Impish already have this commit
by default:
$ git describe --contains 36a6e2335c45
zfs-2.0.0-rc1~332
$ rmadison zfs-linux
zfs-linux | 0.7.5-1ubuntu15| bionic | source
zfs-linux | 0.7.5-1ubuntu16.12 | bionic-updates | source
zfs-linux | 0.8.3-1ubuntu12| focal | source
zfs-linux | 0.8.3-1ubuntu12.9 | focal-security | source
zfs-linux | 0.8.3-1ubuntu12.13 | focal-updates | source
zfs-linux | 0.8.3-1ubuntu12.14 | focal-proposed | source
zfs-linux | 2.0.6-1ubuntu2 | impish | source
zfs-linux | 2.0.6-1ubuntu2.1 | impish-updates | source
zfs-linux | 2.1.2-1ubuntu3 | jammy | source
[Regression Potential]
The introduced commit essentially removes the limitation of setting ARC
tunables below allmem/32, and re-arranges the order of how some of the tunables
are parsed. Regressions would possibly show up as other tunables being ignored
or not being set correctly due to parsing errors. We should validate whether
other ARC related tunables are still being set correctly, and whether ZFS is
using the set values for the ARC memory thresholds.
** Affects: zfs-linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: zfs-linux (Ubuntu Bionic)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: zfs-linux (Ubuntu Focal)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Tags: sts
** Changed in: zfs-linux (Ubuntu)
Status: New => Fix Released
** Also affects: zfs-linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: zfs-linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: zfs-linux (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: zfs-linux (Ubuntu Focal)
Status: New => Confirmed
** Changed in: zfs-linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: zfs-linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: zfs-linux (Ubuntu Bionic)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: zfs-linux (Ubuntu Focal)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Description changed:
[Impact]
- ZFS ignores tunable "zfs_arc_max" due to it being below allmem/32
- threshold. This prevents users from properly restraining ARC sizes, and can
- cause increased memory contention in some systems.
+ ZFS ignores tunable "zfs_arc_max" due to it being below allmem/32 threshold.
This prevents users from properly restraining ARC sizes, and can cause
increased memory contention in some systems.
[Test Plan]
1. Deploy test system with ZFS storage and 32GB RAM
2. Add ARC tunables to /etc/modprobe.d/99-zfs-arc.conf
-# cat /etc/modprobe.d/99-zfs-arc.conf
-options zfs zfs_arc_min=536870912
-options zfs zfs_arc_max=966367641
+ # cat /etc/modprobe.d/99-zfs-arc.conf
+ options zfs zfs_arc_min=536870912
+ options zfs zfs_arc_max=966367641
3. Reboot system
4. Verify ARC sizes through "arc_summary"
-# arc_summary | grep -A3 "ARC size"
-ARC size (current): < 0.1 %1.3 MiB
-Target size (adaptive): 100.0 % 15.7 GiB
-Min size (hard limit): 3.2 % 512.0 MiB
-Max size (high water): 31:1 15.7 GiB
+ # arc_summary | grep -A3 "ARC size"
+ ARC size (current): < 0.1 %1.3 MiB
+ Target size (adaptive): 100.0 % 15.7 GiB
+ Min size (hard limit):
[Bug 1964512] Re: Low RX performance for 40G Solarflare NICs
** Changed in: linux (Ubuntu Impish) Importance: Undecided => High ** Changed in: linux (Ubuntu Focal) Importance: Undecided => High ** Changed in: linux (Ubuntu Impish) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Impish) Status: New => In Progress ** Changed in: linux (Ubuntu Jammy) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1964512] [NEW] Low RX performance for 40G Solarflare NICs
Public bug reported: [Impact] * Some 40G Solarflare NICs have low RX performance in some cases, due low RX recycle ring size * RX recycle ring size is either 4096 for IOMMU, 16 for NOIOMMU * The low fixed sizes can cause a high number of calls to alloc_pages, tanking performance for higher link speeds [Test Plan] * Users report that iperf3 is sufficient to showcase the bad RX performance * For some setups, RX performance was around 15Gbps while TX stayed consistently above 30Gbps [Fix] * This patch sets the RX recycle ring size according to an adapter's maximum link speed * Fix was introduced by commit: 000fe940e51f "sfc: The size of the RX recycle ring should be more flexible" * --!-- Commit is from net-next --!-- [Regression Potential] * Regressions would show primarily as performance issues, as we're effectively changing ring sizes for all RX traffic * It's possible to see increased calls to alloc_pages if ring sizes aren't being set correctly * We should look out for excessive memory usage in the sfc driver due to the increased ring sizes ** Affects: linux (Ubuntu) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Affects: linux (Ubuntu Impish) Importance: Undecided Status: New ** Affects: linux (Ubuntu Jammy) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Tags: sts ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Also affects: linux (Ubuntu Impish) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1964512 Title: Low RX performance for 40G Solarflare NICs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964512/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953610] Re: cnf-update-db creates unreadable database if wrong umask
t - behaves incorrectly or unexpectedly once the behavior is corrected. + In general, regressions due to this bug would continue showing up as file access errors, either in automated tooling that currently works around the faulty database permissions, or in other packages relying on CNF. + + Admins could be relying on the incorrect behavior for some reason (e.g. + security), and some users could have existing automation in place to + correct the issue manually. We'd expect the fix to have little impact on + such scenarios, and the patches have been tested for these cases. ** Changed in: command-not-found (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: command-not-found (Ubuntu Impish) Status: Confirmed => In Progress ** Changed in: command-not-found (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: command-not-found (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: command-not-found (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: command-not-found (Ubuntu Impish) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953610 Title: cnf-update-db creates unreadable database if wrong umask To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1953610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953610] Re: cnf-update-db creates unreadable database if wrong umask
** Tags added: sts ** Changed in: command-not-found (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: command-not-found (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: command-not-found (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953610 Title: cnf-update-db creates unreadable database if wrong umask To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1953610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
Validated according to test case from description: root@bionic-ssh:~# python3 test_bug_1863930.py localhost Server is patched root@bionic-ssh:~# dpkg -l | grep openssh ii openssh-client 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines Given we have an ACK from both Server and Security and this is affecting multiple users, I'll remove the blocked tag as well. ** Tags removed: block-proposed-bionic verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953610] Re: cnf-update-db creates unreadable database if wrong umask
** Tags removed: sts-sponsor ** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953610 Title: cnf-update-db creates unreadable database if wrong umask To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1953610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
** Changed in: openssh (Ubuntu Bionic) Status: Incomplete => In Progress ** Tags added: sts sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
** Changed in: openssh (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: openssh (Ubuntu Bionic) Importance: Low => High ** Changed in: openssh (Ubuntu Bionic) Importance: High => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956849] Re: Almost all USB ports suddenly stopped working; unbootable
@dgatwood would you be able to upload kernel logs and lsusb output from the -44 kernel? From what you're describing it seems like a possible issue with host controllers, but it's hard to tell without looking at what is going in the kernel. You can use `apport-collect 1956849` to upload relevant data directly to this LP bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956849 Title: Almost all USB ports suddenly stopped working; unbootable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1956849/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1955129] Re: trace-cmd report buffer overflow detected
@joalif thank you for the debdiff! There are some minor nitpicks about the patch file that I'd like to confirm with you: - The 'Origin:' tag in your patch file seems to be missing the patch identifier. From the commit id, would it be appropriate to point it towards [0]? - I've seen you added a line that says "Backported from upstream commit ". If this required changes, please adjust the 'Origin:' tag with a "backport" prefix instead of "upstream" (you could then omit that additional line) [0] https://git.kernel.org/pub/scm/utils/trace-cmd/trace- cmd.git/commit/?id=1375d98d8017 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1955129 Title: trace-cmd report buffer overflow detected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/trace-cmd/+bug/1955129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1955129] Re: trace-cmd report buffer overflow detected
** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1955129 Title: trace-cmd report buffer overflow detected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/trace-cmd/+bug/1955129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
Validated glibc from -proposed according to test case from description: halves@focal-proposed:~$ grep -m1 "model name" /proc/cpuinfo model name : AMD Ryzen 7 3700X 8-Core Processor halves@focal-proposed:~$ ./test_memcpy64 32 32 MB = 1.340379 ms -Compare match (should be zero): 0 halves@focal-proposed:~$ dpkg -l | rg libc-bin ii libc-bin 2.31-0ubuntu9.4 amd64GNU C Library: Binaries I've also checked benchmark results on an Intel system, and no performance regressions have been observed there either: root@halves-focal-glibc-xeon:~# grep -m1 "model name" /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz root@halves-focal-glibc-xeon:~# ./test_memcpy64 32 32 MB = 2.167214 ms -Compare match (should be zero): 0 root@halves-focal-glibc-xeon:~# dpkg -l | rg libc-bin ii libc-bin 2.31-0ubuntu9.4 amd64GNU C Library: Binaries ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800544] Re: nvme-cli drops bash completion file in wrong location
Validated package from -proposed according to test case from description. Tab completion works correctly, and the bash completion script is found under the correct location: $ dpkg -l | grep nvme-cli ii nvme-cli 1.5-1ubuntu1.2 amd64 userspace tooling to control NVMe drives $ nvme admin-passthru delete-nsflushget-ns-idio-passthru memblaze resv-report smart-log-add attach-nsdetach-nsformat get_feature list read security-recvsubsystem-reset compare disconnect fw-activate help list-ctrl resetsecurity-sendversion connect discover fw-download id-ctrl list-ns resv-acquire set-feature write connect-all dsm fw-log id-nslist-subsys resv-registershow-regswrite-uncor create-nserror-logget-log intellnvm resv-release smart-logwrite-zeroes $ file /usr/share/bash-completion/completions/nvme /usr/share/bash-completion/completions/nvme: ASCII text ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800544 Title: nvme-cli drops bash completion file in wrong location To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1800544/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
It's been some time since the original benchmarks, so I'm repeating the test from the description. I haven't used hyperfine for the comparisons below, so they won't have the same statistical reliability but should nevertheless be sufficient for validation. Binaries have been compiled as below: $ gcc -mtune=generic -march=x86-64 -g -O3 test_memcpy.c -o test_memcpy64 AMD $ grep -m1 "model name" /proc/cpuinfo model name : AMD Ryzen 7 3700X 8-Core Processor $ dpkg -l | grep -m1 libc6 ii libc6:amd64 2.31-0ubuntu9.2 amd64GNU C Library: Shared libraries $ ./test_memcpy64 32 32 MB = 2.506206 ms -Compare match (should be zero): 0 $ dpkg -l | grep -m1 libc6 ii libc6:amd64 2.31-0ubuntu9.4~20210524ppa1 amd64GNU C Library: Shared libraries $ ./test_memcpy64 32 32 MB = 1.384115 ms -Compare match (should be zero): 0 So, for AMD it's a very noticeable improvement (1.38ms vs 2.51ms). Intel $ grep -m1 "model name" /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz $ dpkg -l | grep -m1 libc6 ii libc6:amd64 2.31-0ubuntu9.2 amd64GNU C Library: Shared libraries $ ./test_memcpy64 32 32 MB = 2.304554 ms -Compare match (should be zero): 0 $ dpkg -l | grep -m1 libc6 ii libc6:amd64 2.31-0ubuntu9.4~20210524ppa1 amd64GNU C Library: Shared libraries $ ./test_memcpy64 32 32 MB = 2.209747 ms -Compare match (should be zero): 0 For Intel the difference isn't very significant, but there are also no performance regressions (2.30ms vs 2.21ms). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800544] Re: nvme-cli drops bash completion file in wrong location
** Tags removed: sts-sponsor-volunteer ** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800544 Title: nvme-cli drops bash completion file in wrong location To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1800544/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800544] Re: nvme-cli drops bash completion file in wrong location
** Changed in: nvme-cli (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: nvme-cli (Ubuntu Bionic) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800544 Title: nvme-cli drops bash completion file in wrong location To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1800544/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
Verified for Focal according to test case from description. A standard multipass VM with 8 vCPUs configured was able to capture a kernel dump without errors. Additionally, since the 5.4 kernel doesn't hit the MMU/reset bug directly, I've done some additional testing to ensure we didn't introduce any weird regressions. These scenarios included: - default crash kernel config - nested VM crash kernel with multiple CPUs - nested VM crash kernel with default config - basic smoke testing of VM up/down through virsh - basic smoke testing of reboots from within the VM All of these behaved as expected and showed no issues. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
For future reference, this bug has been reported in Ubuntu KVM hosts outside of the specific kdump test scenario (i.e. when running actual VMs in production-like setups). The "kdump with multiple CPUs" case was discovered as an alternative that hits the same MMU context bug, without needing complex hypervisor setups or fancy configuration. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
** Changed in: linux (Ubuntu Focal) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
** Description changed:
[Impact]
When kexec'ing into a crash kernel with ncpus > 1, VMs can raise a KVM
emulation failure. This will cause the VM to go into the "paused" state, and
prevents it from being restored without a full VM restart.
This happens only when there are multiple enabled CPUs in the crash
kernel command-line, regardless of whether `nr_cpus` or `maxcpus` is
being used. Due to the vCPU MMU state not being cleaned up correctly,
the secondary CPUs try to access virtual addresses with a faulty MMU
context that will result in the emulation failure. This shows up with a
similar spew as below:
$ sudo tail -n20 /var/log/libvirt/qemu/focal-vm.log
KVM internal error. Suberror: 1
emulation failure
EAX=de8f EBX= ECX=008f EDX=0600
ESI= EDI= EBP= ESP=f90c
EIP=cdb1 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES = 9300
CS =f000 000f 9b00
SS =de00 000de000 9300
DS =de00 000de000 9300
FS = 9300
GS = 9300
LDT= 8200
TR = 8b00
GDT=
IDT=
CR0=6010 CR2= CR3=290b8001 CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 71 66
0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a
[Test Plan]
1. Boot an Ubuntu guest VM with e.g. multipass:
$ multipass launch daily:focal -c8 -m16g -n focal-vm
2. Configure guest crash kernel command-line with `nr_cpus=8`:
ubuntu@focal-vm:~$ grep CMDLINE_APPEND /etc/default/kdump-tools
# KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line
KDUMP_CMDLINE_APPEND="reset_devices systemd.unit=kdump-tools-dump.service
nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0"
3. Crash guest VM and watch for the KVM emulation failure:
ubuntu@focal-vm:~$ echo c | sudo tee /proc/sysrq-trigger
[Where problems could occur]
As we're resetting MMU context on vCPUs, potential regressions would show up
in workloads relying on KVM guests. We should properly test the scenario
mentioned in the bug to make sure secondary CPUs are being cleaned up properly,
and that no other regressions have been introduced when rebooting or kexec'ing
into different kernels.
Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression
potential should be fairly low and contained to starting/resetting vCPUs (i.e.
VM start and reboot).
[Other info]
This has been fixed by upstream commit:
- 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT
+ 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT
- And the two follow up commits, which revert the vendor-specific resets:
- 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT
- 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode()
+ The commit above has been picked up by stable trees up until 5.11, so it's
only needed in Bionic and Focal (4.15 and 5.4 kernels). There are also two
follow up commits, which revert the vendor-specific resets:
+ 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT
+ 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode()
- These commits have been introduced during the upstream 5.14 and 5.15 release
candidates. They have been picked up by upstream stable up until 5.11, so
backports are only needed for Bionic and Focal (4.15 and 5.4 kernels).
- $ git describe --contains 0aa1837533e5 5d2d7e41e3b8 61152cd907d5
- v5.14-rc1~166^2~58
- v5.15-rc1~65^2~119
- v5.15-rc1~65^2~120
+ These follow ups have not been picked up in stable trees due to the risk of
+ regressions. According to the original fix, they have been introduced
primarily to aid bisection in case there are workflows relying on the vendor
resets. As these are not required for the fix and don't conflict with the
backport, we should leave them out to prevent potential regressions in the
older kernels.
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Released
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => High
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
--
You received this bug notification because you are a memb
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
** Description changed: [Impact] When kexec'ing into a crash kernel with ncpus > 1, VMs can raise a KVM emulation failure. This will cause the VM to go into the "paused" state, and prevents it from being restored without a full VM restart. This happens only when there are multiple enabled CPUs in the crash kernel command-line, regardless of whether `nr_cpus` or `maxcpus` is being used. Due to the vCPU MMU state not being cleaned up correctly, the secondary CPUs try to access virtual addresses with a faulty MMU context that will result in the emulation failure. This shows up with a similar spew as below: $ sudo tail -n20 /var/log/libvirt/qemu/focal-vm.log KVM internal error. Suberror: 1 emulation failure EAX=de8f EBX= ECX=008f EDX=0600 ESI= EDI= EBP= ESP=f90c EIP=cdb1 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS =de00 000de000 9300 DS =de00 000de000 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3=290b8001 CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 71 66 0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a [Test Plan] 1. Boot an Ubuntu guest VM with e.g. multipass: $ multipass launch daily:focal -c8 -m16g -n focal-vm 2. Configure guest crash kernel command-line with `nr_cpus=8`: ubuntu@focal-vm:~$ grep CMDLINE_APPEND /etc/default/kdump-tools # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line KDUMP_CMDLINE_APPEND="reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0" 3. Crash guest VM and watch for the KVM emulation failure: ubuntu@focal-vm:~$ echo c | sudo tee /proc/sysrq-trigger [Where problems could occur] As we're resetting MMU context on vCPUs, potential regressions would show up in workloads relying on KVM guests. We should properly test the scenario mentioned in the bug to make sure secondary CPUs are being cleaned up properly, and that no other regressions have been introduced when rebooting or kexec'ing into different kernels. Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression potential should be fairly low and contained to starting/resetting vCPUs (i.e. VM start and reboot). [Other info] This has been fixed by upstream commit: 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT And the two follow up commits, which revert the vendor-specific resets: 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode() - These commits have been introduced during the upstream 5.14 and 5.15 release candidates, and as such should be backported to previous supported kernels. + These commits have been introduced during the upstream 5.14 and 5.15 release candidates. They have been picked up by upstream stable up until 5.11, so backports are only needed for Bionic and Focal (4.15 and 5.4 kernels). $ git describe --contains 0aa1837533e5 5d2d7e41e3b8 61152cd907d5 v5.14-rc1~166^2~58 v5.15-rc1~65^2~119 v5.15-rc1~65^2~120 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948862] Re: KVM emulation failure when booting into VM crash kernel with multiple CPUs
** Description changed: [Impact] - When kexec'ing into a crash kernel with `ncpus` > 1, VMs can raise a KVM - emulation failure. This will cause the VM to go into the "paused" state, and - prevents it from being restored without a full VM restart. + When kexec'ing into a crash kernel with ncpus > 1, VMs can raise a KVM emulation failure. This will cause the VM to go into the "paused" state, and prevents it from being restored without a full VM restart. - This happens only when there are multiple enabled CPUs in the crash kernel - command-line, regardless of whether `nr_cpus` or `maxcpus` is being used. Due to - the vCPU MMU state not being cleaned up correctly, the secondary CPUs try to - access virtual addresses with a faulty MMU context that will result in the - emulation failure. This shows up with a similar spew as below: + This happens only when there are multiple enabled CPUs in the crash + kernel command-line, regardless of whether `nr_cpus` or `maxcpus` is + being used. Due to the vCPU MMU state not being cleaned up correctly, + the secondary CPUs try to access virtual addresses with a faulty MMU + context that will result in the emulation failure. This shows up with a + similar spew as below: $ sudo tail -n20 /var/log/libvirt/qemu/focal-vm.log KVM internal error. Suberror: 1 emulation failure EAX=de8f EBX= ECX=008f EDX=0600 ESI= EDI= EBP= ESP=f90c EIP=cdb1 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS =de00 000de000 9300 DS =de00 000de000 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3=290b8001 CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 71 66 0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a [Test Plan] 1. Boot an Ubuntu guest VM with e.g. multipass: $ multipass launch daily:focal -c8 -m16g -n focal-vm 2. Configure guest crash kernel command-line with `nr_cpus=8`: ubuntu@focal-vm:~$ grep CMDLINE_APPEND /etc/default/kdump-tools # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line KDUMP_CMDLINE_APPEND="reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0" 3. Crash guest VM and watch for the KVM emulation failure: ubuntu@focal-vm:~$ echo c | sudo tee /proc/sysrq-trigger [Where problems could occur] - As we're resetting MMU context on vCPUs, potential regressions would show up in - workloads relying on KVM guests. We should properly test the scenario mentioned - in the bug to make sure secondary CPUs are being cleaned up properly, and that - no other regressions have been introduced when rebooting or kexec'ing into - different kernels. - Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression - potential should be fairly low and contained to starting/resetting vCPUs - (i.e. VM start and reboot). + As we're resetting MMU context on vCPUs, potential regressions would show up in workloads relying on KVM guests. We should properly test the scenario mentioned in the bug to make sure secondary CPUs are being cleaned up properly, and that no other regressions have been introduced when rebooting or kexec'ing into different kernels. + Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression potential should be fairly low and contained to starting/resetting vCPUs (i.e. VM start and reboot). [Other info] This has been fixed by upstream commit: - 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT + 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT And the two follow up commits, which revert the vendor-specific resets: - 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT - 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode() + 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT + 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode() - These commits have been introduced during the upstream 5.14 and 5.15 release - candidates, and as such should be backported to previous supported kernels. + These commits have been introduced during the upstream 5.14 and 5.15 release candidates, and as such should be backported to previous supported kernels. $ git describe --contains 0aa1837533e5 5d2d7e41e3b8 61152cd907d5 v5.14-rc1~166^2~58 v5.15-rc1~65^2~119 v5.15-rc1~65^2~120 -- You received this bug notification because you are a member of Ubuntu Bugs, which
[Bug 1948862] [NEW] KVM emulation failure when booting into VM crash kernel with multiple CPUs
Public bug reported: [Impact] When kexec'ing into a crash kernel with `ncpus` > 1, VMs can raise a KVM emulation failure. This will cause the VM to go into the "paused" state, and prevents it from being restored without a full VM restart. This happens only when there are multiple enabled CPUs in the crash kernel command-line, regardless of whether `nr_cpus` or `maxcpus` is being used. Due to the vCPU MMU state not being cleaned up correctly, the secondary CPUs try to access virtual addresses with a faulty MMU context that will result in the emulation failure. This shows up with a similar spew as below: $ sudo tail -n20 /var/log/libvirt/qemu/focal-vm.log KVM internal error. Suberror: 1 emulation failure EAX=de8f EBX= ECX=008f EDX=0600 ESI= EDI= EBP= ESP=f90c EIP=cdb1 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS =de00 000de000 9300 DS =de00 000de000 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3=290b8001 CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 71 66 0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a [Test Plan] 1. Boot an Ubuntu guest VM with e.g. multipass: $ multipass launch daily:focal -c8 -m16g -n focal-vm 2. Configure guest crash kernel command-line with `nr_cpus=8`: ubuntu@focal-vm:~$ grep CMDLINE_APPEND /etc/default/kdump-tools # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line KDUMP_CMDLINE_APPEND="reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0" 3. Crash guest VM and watch for the KVM emulation failure: ubuntu@focal-vm:~$ echo c | sudo tee /proc/sysrq-trigger [Where problems could occur] As we're resetting MMU context on vCPUs, potential regressions would show up in workloads relying on KVM guests. We should properly test the scenario mentioned in the bug to make sure secondary CPUs are being cleaned up properly, and that no other regressions have been introduced when rebooting or kexec'ing into different kernels. Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression potential should be fairly low and contained to starting/resetting vCPUs (i.e. VM start and reboot). [Other info] This has been fixed by upstream commit: 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT And the two follow up commits, which revert the vendor-specific resets: 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode() These commits have been introduced during the upstream 5.14 and 5.15 release candidates, and as such should be backported to previous supported kernels. $ git describe --contains 0aa1837533e5 5d2d7e41e3b8 61152cd907d5 v5.14-rc1~166^2~58 v5.15-rc1~65^2~119 v5.15-rc1~65^2~120 ** Affects: linux (Ubuntu) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: New ** Tags: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1875577] Re: Encrypted swap won't load on 20.04 with zfs root
Validated with ZFS from focal-proposed, according to test case from description: ubuntu@z-rotomvm34:~$ dpkg -l | grep zfsutils ii zfsutils-linux 0.8.3-1ubuntu12.12 amd64command-line tools to manage OpenZFS filesystems ubuntu@z-rotomvm34:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 2.50G 25.6G 176K / rpool/ROOT 2.50G 25.6G 176K none rpool/ROOT/zfsroot 2.50G 25.6G 2.50G / ubuntu@z-rotomvm34:~$ sudo journalctl -b | grep -i ordering ubuntu@z-rotomvm34:~$ lsblk -e 7 NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:00 30G 0 disk ├─vda1 252:10 512M 0 part /boot/efi └─vda2 252:20 29.5G 0 part nvme0n1 259:00 9.8G 0 disk └─nvme0n1p1 259:10 9.8G 0 part └─swap253:00 9.8G 0 crypt [SWAP] In addition to the test above, I've also tested the configurations suggested in the [Test Plan] section. Besides validating the ordering bug, I've also done basic smoke tests and verified that the ZFS pools are working as expected. - Encrypted rootfs on LVM + separate ZFS partitions: ubuntu@ubuntu-focal:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT zfspool492K 4.36G 96K /mnt/zfspool zfspool/tank96K 4.36G 96K /mnt/zfspool/tank ubuntu@ubuntu-focal:~$ dpkg -l | grep zfsutils ii zfsutils-linux 0.8.3-1ubuntu12.12 amd64command-line tools to manage OpenZFS filesystems ubuntu@ubuntu-focal:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT zfspool492K 4.36G 96K /mnt/zfspool zfspool/tank96K 4.36G 96K /mnt/zfspool/tank ubuntu@ubuntu-focal:~$ sudo journalctl -b | grep -i ordering ubuntu@ubuntu-focal:~$ lsblk -e7 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:01 1024M 0 rom vda 252:00 30G 0 disk ├─vda1 252:10 512M 0 part /boot/efi ├─vda2 252:201K 0 part ├─vda5 252:50 731M 0 part /boot └─vda6 252:60 28.8G 0 part └─vda6_crypt 253:00 28.8G 0 crypt ├─vgubuntu--focal-root 253:10 27.8G 0 lvm / └─vgubuntu--focal-swap_1 253:20 980M 0 lvm [SWAP] vdb 252:16 05G 0 disk ├─vdb1 252:17 05G 0 part └─vdb9 252:25 08M 0 part - ZFS on LUKS ubuntu@z-rotomvm33:~$ dpkg -l | grep zfsutils ii zfsutils-linux 0.8.3-1ubuntu12.12 amd64command-line tools to manage OpenZFS filesystems ubuntu@z-rotomvm33:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT zfspool612K 9.20G 96K /mnt/zfspool zfspool/tank96K 9.20G 96K /mnt/zfspool/tank ubuntu@z-rotomvm33:~$ sudo journalctl -b | grep -i ordering ubuntu@z-rotomvm33:~$ lsblk -e7 NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:00 30G 0 disk ├─vda1 252:10 512M 0 part /boot/efi └─vda2 252:20 29.5G 0 part / nvme0n1 259:00 9.8G 0 disk └─nvme0n1p1 259:10 9.8G 0 part └─zfspool 253:00 9.8G 0 crypt ubuntu@z-rotomvm33:~$ cat /etc/crypttab # zfspool /dev/nvme0n1p1 /etc/keyfile luks - ZFS on dm-raid ubuntu@z-rotomvm33:~$ dpkg -l | grep zfsutils ii zfsutils-linux 0.8.3-1ubuntu12.12 amd64command-line tools to manage OpenZFS filesystems ubuntu@z-rotomvm33:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT zfspool612K 9.20G 96K /mnt/zfspool zfspool/tank96K 9.20G 96K /mnt/zfspool/tank ubuntu@z-rotomvm33:~$ sudo journalctl -b | grep -i ordering ubuntu@z-rotomvm33:~$ lsblk -e7 NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:00 30G 0 disk ├─vda1 252:10 512M 0 part /boot/efi └─vda2 252:20 29.5G 0 part / nvme0n1 259:00 9.8G 0 disk └─md127 9:127 0 9.8G 0 raid0 ├─md127p1 259:10 9.8G 0 part └─md127p9 259:208M 0 part ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1875577 Title: Encrypted swap won't load on 20.04 with zfs root To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1875577/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
Verified Hirsute according to test case from description: root@h-sos:~# dpkg -l | grep sos ii sosreport 4.1-1ubuntu1.2 amd64Set of tools to gather troubleshooting data from a system root@h-sos:~# lsmod | grep -i devlink root@h-sos:~# sos report -o networking [...] root@h-sos:~# lsmod | grep -i devlink root@h-sos:~# ** Tags removed: verification-needed verification-needed-hirsute ** Tags added: verification-done verification-done-hirsute -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
Verified Focal according to test case from description: root@f-sos:~# dpkg -l | grep sosreport ii sosreport 4.1-1ubuntu0.20.04.3 amd64 Set of tools to gather troubleshooting data from a system root@f-sos:~# lsmod | grep -i devlink root@f-sos:~# sos report -o networking [...] root@f-sos:~# lsmod | grep -i devlink root@f-sos:~# ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
Verified Bionic according to test case from description: root@b-sos:~# dpkg -l | grep sosreport ii sosreport4.1-1ubuntu0.18.04.3 amd64Set of tools to gather troubleshooting data from a system root@b-sos:~# lsmod | grep -i devlink root@b-sos:~# sos report -o networking [...] root@b-sos:~# lsmod | grep -i devlink root@b-sos:~# ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1875577] Re: Encrypted swap won't load on 20.04 with zfs root
** Description changed: [Impact] Encrypted swap partitions may not load correctly with ZFS root, due to ordering cycle on zfs-mount.service. [Test Plan] 1. Install Ubuntu 20.04 using ZFS-on-root 2. Add encrypted partition to /etc/crypttab: -swap/dev/nvme0n1p1 /dev/urandom swap,cipher=aes-xts-plain64,size=256 + swap/dev/nvme0n1p1 /dev/urandom swap,cipher=aes-xts-plain64,size=256 3. Add swap partition to /etc/fstab: -/dev/mapper/swapnoneswapsw 0 0 + /dev/mapper/swapnoneswapsw 0 0 4. Reboot and check whether swap has loaded correctly, and whether boot logs show ordering cycle: [6.638228] systemd[1]: systemd-random-seed.service: Found ordering cycle on zfs-mount.service/start [6.639418] systemd[1]: systemd-random-seed.service: Found dependency on zfs-import.target/start [6.640474] systemd[1]: systemd-random-seed.service: Found dependency on zfs-import-cache.service/start [6.641637] systemd[1]: systemd-random-seed.service: Found dependency on cryptsetup.target/start [6.642734] systemd[1]: systemd-random-seed.service: Found dependency on systemd-cryptsetup@swap.service/start [6.643951] systemd[1]: systemd-random-seed.service: Found dependency on systemd-random-seed.service/start [6.645098] systemd[1]: systemd-random-seed.service: Job zfs-mount.service/start deleted to break ordering cycle starting with systemd-random-seed.service/start [ SKIP ] Ordering cycle found, skipping Mount ZFS filesystems [Where problems could occur] Since we're changing the zfs-mount-generator service, regressions could show up during mounting of ZFS partitions. We should thoroughly test different scenarios of ZFS such as ZFS-on-root, separate ZFS partitions and the presence of swap, to make sure all partitions are mounted correctly and no ordering cycles are present. + Below is a list of suggested test scenarios that we should check for regressions: + 1. ZFS-on-root + encrypted swap (see "Test Plan" section above) + 2. Encrypted root + separate ZFS partitions + 3. ZFS on LUKS + 4. ZFS on dm-raid + + Although scenario 4 is usually advised against (ZFS itself should handle + RAID), it's a good smoke test to validate that mount order is being + handled correctly. + [Other Info] This has been fixed upstream by the following commits: * ec41cafee1da Fix a dependency loop [0] * 62663fb7ec19 Fix another dependency loop [1] The patches above have been introduced in version 2.1.0, with upstream backports to zfs-2.0. In Ubuntu, it's present in Groovy and later releases, so it's still needed in Focal. $ rmadison -a source zfs-linux - zfs-linux | 0.8.3-1ubuntu12| focal | source - zfs-linux | 0.8.3-1ubuntu12.9 | focal-security | source - zfs-linux | 0.8.3-1ubuntu12.10 | focal-updates | source - zfs-linux | 0.8.4-1ubuntu11| groovy | source - zfs-linux | 0.8.4-1ubuntu11.2 | groovy-updates | source - zfs-linux | 2.0.2-1ubuntu5 | hirsute | source - zfs-linux | 2.0.3-8ubuntu5 | impish | source + zfs-linux | 0.8.3-1ubuntu12| focal | source + zfs-linux | 0.8.3-1ubuntu12.9 | focal-security | source + zfs-linux | 0.8.3-1ubuntu12.10 | focal-updates | source + zfs-linux | 0.8.4-1ubuntu11| groovy | source + zfs-linux | 0.8.4-1ubuntu11.2 | groovy-updates | source + zfs-linux | 2.0.2-1ubuntu5 | hirsute | source + zfs-linux | 2.0.3-8ubuntu5 | impish | source [0] https://github.com/openzfs/zfs/commit/ec41cafee1da [1] https://github.com/openzfs/zfs/commit/62663fb7ec19 ORIGINAL DESCRIPTION root@eu1:/var/log# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal root@eu1:/var/log# apt-cache policy cryptsetup cryptsetup: Installed: (none) Candidate: 2:2.2.2-3ubuntu2 Version table: 2:2.2.2-3ubuntu2 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages OTHER BACKGROUND INFO: == 1. machine has 2 drives. each drive is partitioned into 2 partitions, zfs and swap 2. Ubuntu 20.04 installed on ZFS root using debootstrap (debootstrap_1.0.118ubuntu1_all) 3. The ZFS root pool is a 2 partition mirror (the first partition of each disk) 4. /etc/crypttab is set up as follows: swap /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HALR-0_S3W6NX0M802914-part2 /dev/urandom swap,cipher=aes-xts-plain64,size=256 swap /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HALR-0_S3W6NX0M802933-part2 /dev/urandom swap,cipher=aes-xts-plain64,size=256 WHAT I EXPECTED === I expected machine would reboot and have encrypted swap that used two devices under /dev/mapper WHAT HAPPENED INSTEAD
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Patch added: "lp1923661-h.debdiff" https://bugs.launchpad.net/ubuntu/focal/+source/sosreport/+bug/1923661/+attachment/5510566/+files/lp1923661-h.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Patch added: "lp1923661-g.debdiff" https://bugs.launchpad.net/ubuntu/focal/+source/sosreport/+bug/1923661/+attachment/5510565/+files/lp1923661-g.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Patch added: "lp1923661-f.debdiff" https://bugs.launchpad.net/ubuntu/focal/+source/sosreport/+bug/1923661/+attachment/5510564/+files/lp1923661-f.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Patch added: "lp1923661-b.debdiff" https://bugs.launchpad.net/ubuntu/focal/+source/sosreport/+bug/1923661/+attachment/5510563/+files/lp1923661-b.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1875577] Re: Encrypted swap won't load on 20.04 with zfs root
** Description changed: + [Impact] + Encrypted swap partitions may not load correctly with ZFS root, due to ordering cycle on zfs-mount.service. + + [Test Plan] + 1. Install Ubuntu 20.04 using ZFS-on-root + 2. Add encrypted partition to /etc/crypttab: +swap/dev/nvme0n1p1 /dev/urandom swap,cipher=aes-xts-plain64,size=256 + 3. Add swap partition to /etc/fstab: +/dev/mapper/swapnoneswapsw 0 0 + 4. Reboot and check whether swap has loaded correctly, and whether boot logs show ordering cycle: + [6.638228] systemd[1]: systemd-random-seed.service: Found ordering cycle on zfs-mount.service/start + [6.639418] systemd[1]: systemd-random-seed.service: Found dependency on zfs-import.target/start + [6.640474] systemd[1]: systemd-random-seed.service: Found dependency on zfs-import-cache.service/start + [6.641637] systemd[1]: systemd-random-seed.service: Found dependency on cryptsetup.target/start + [6.642734] systemd[1]: systemd-random-seed.service: Found dependency on systemd-cryptsetup@swap.service/start + [6.643951] systemd[1]: systemd-random-seed.service: Found dependency on systemd-random-seed.service/start + [6.645098] systemd[1]: systemd-random-seed.service: Job zfs-mount.service/start deleted to break ordering cycle starting with systemd-random-seed.service/start + [ SKIP ] Ordering cycle found, skipping Mount ZFS filesystems + + [Where problems could occur] + Since we're changing the zfs-mount-generator service, regressions could show up during mounting of ZFS partitions. We should thoroughly test different scenarios of ZFS such as ZFS-on-root, separate ZFS partitions and the presence of swap, to make sure all partitions are mounted correctly and no ordering cycles are present. + + [Other Info] + This has been fixed upstream by the following commits: + * ec41cafee1da Fix a dependency loop [0] + * 62663fb7ec19 Fix another dependency loop [1] + + The patches above have been introduced in version 2.1.0, with upstream + backports to zfs-2.0. In Ubuntu, it's present in Groovy and later + releases, so it's still needed in Focal. + + $ rmadison -a source zfs-linux + zfs-linux | 0.8.3-1ubuntu12| focal | source + zfs-linux | 0.8.3-1ubuntu12.9 | focal-security | source + zfs-linux | 0.8.3-1ubuntu12.10 | focal-updates | source + zfs-linux | 0.8.4-1ubuntu11| groovy | source + zfs-linux | 0.8.4-1ubuntu11.2 | groovy-updates | source + zfs-linux | 2.0.2-1ubuntu5 | hirsute | source + zfs-linux | 2.0.3-8ubuntu5 | impish | source + + [0] https://github.com/openzfs/zfs/commit/ec41cafee1da + [1] https://github.com/openzfs/zfs/commit/62663fb7ec19 + + ORIGINAL DESCRIPTION + + root@eu1:/var/log# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal root@eu1:/var/log# apt-cache policy cryptsetup cryptsetup: - Installed: (none) - Candidate: 2:2.2.2-3ubuntu2 - Version table: - 2:2.2.2-3ubuntu2 500 - 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages + Installed: (none) + Candidate: 2:2.2.2-3ubuntu2 + Version table: + 2:2.2.2-3ubuntu2 500 + 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages OTHER BACKGROUND INFO: == 1. machine has 2 drives. each drive is partitioned into 2 partitions, zfs and swap + 2. Ubuntu 20.04 installed on ZFS root using debootstrap + (debootstrap_1.0.118ubuntu1_all) - 2. Ubuntu 20.04 installed on ZFS root using debootstrap (debootstrap_1.0.118ubuntu1_all) - - - 3. The ZFS root pool is a 2 partition mirror (the first partition of each disk) - + 3. The ZFS root pool is a 2 partition mirror (the first partition of + each disk) 4. /etc/crypttab is set up as follows: swap /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HALR-0_S3W6NX0M802914-part2 /dev/urandom swap,cipher=aes-xts-plain64,size=256 swap /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HALR-0_S3W6NX0M802933-part2 /dev/urandom swap,cipher=aes-xts-plain64,size=256 - - WHAT I EXPECTED === I expected machine would reboot and have encrypted swap that used two devices under /dev/mapper - WHAT HAPPENED INSTEAD = - - On reboot, swap setup fails with the following messages in /var/log/syslog: + On reboot, swap setup fails with the following messages in + /var/log/syslog: Apr 28 17:13:01 eu1 kernel: [5.360793] systemd[1]: cryptsetup.target: Found ordering cycle on systemd-cryptsetup@swap.service/start Apr 28 17:13:01 eu1 kernel: [5.360795] systemd[1]: cryptsetup.target: Found dependency on systemd-random-seed.service/start Apr 28 17:13:01 eu1 kernel: [5.360796] systemd[1]: cryptsetup.target: Found dependency on zfs-mount.service/start Apr 28 17:13:01 eu1 kernel: [5.360797]
[Bug 1875577] Re: Encrypted swap won't load on 20.04 with zfs root
** Changed in: zfs-linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: zfs-linux (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1875577 Title: Encrypted swap won't load on 20.04 with zfs root To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1875577/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1920047] Re: sanlock global lock creation fail
We've determined this to be due to using disks with mixed sector sizes (i.e. different physical and logical sector sizes). The mentioned patch [0] enables lvmlockd to create shared leases in mixed sector sized disks, but additional support is needed in sanlock for these to work correctly. The required sanlock patches are: * d5e4def0d087 - sanlock: add flags to specify sector size [1] * 445e86700fa3 - configurable sector size and align size [2] If we don't have these additional sanlock patches, sanlock isn't able to find the written leases due to alignment issues and ultimately those are handled as invalid. Unfortunately, both sanlock patches are extensive and change a lot of low-level internal structures, so providing them as SRU updates would be prone to backporting errors and regressions. Since both lvm2 and sanlock are working as expected with non-mixed sector sizes, and the current versions actively prevent leases to be written to mixed sector disks, we can consider that things are working correctly. Support for mixed sector sizes should be considered a "feature" instead, which is available starting with the versions below: - lvm2: 2.03.10 - sanlock: 3.8.0 These versions are available in Ubuntu releases starting with Hirsute, and have been provided as backports in focal-backports and groovy- backports. Please refer to bug #1929432 and bug #1928708 for further details on the -backports versions. [0] https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=2d1fe38d84d4 [1] https://pagure.io/sanlock/c/d5e4def0d087 [2] https://pagure.io/sanlock/c/445e86700fa3 ** Changed in: lvm2 (Ubuntu Focal) Status: Confirmed => Won't Fix ** Changed in: lvm2 (Ubuntu Groovy) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1920047 Title: sanlock global lock creation fail To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
Since we don't have a reliable test procedure for triggering the KVM emulation failures, I did basic smoke tests on VMs using seabios from mitaka-proposed. Things look good, and general NMI functionality seems to be working correctly. I've also confirmed with affected users that this version has fixed those specific instances of KVM emulation failures for them, so they also confirmed the fix is working as intended. ** Tags removed: verification-mitaka-needed ** Tags added: verification-mitaka-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1927547/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
There's currently a pending SRU for glibc on Groovy, which I based my debdiff on. Although that SRU has already cleared the 7 day grace period, there are still a few pending bugs for verification which we would need to clear before being able to upload a fix for this one. Since Groovy is going EOL in a couple of weeks, I don't think we should spend too much effort for that release. Marking as "won't fix" accordingly. ** Changed in: glibc (Ubuntu Groovy) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Description changed: [Impact] sos's networking plugin may trigger the devlink kernel module to load. We don't want sos to modify/change/alter the state of a machine whatsoever, especially during troubleshooting. But it may be the case for the networking plugin, depending on the running kernel configuration. As a side note, this is also causing Bionic autopkgtest to fails as it is tested w/ 4.15 series kernel by default. 'simple.sh' (sos testsuite part of the autopkgtest) will report a failure as follows: "new kernel modules loaded during execution" [Test case] On a 4.15 kernel (Bionic) On a bare metal system: root@srv:~# lsmod | grep -i devlink root@srv:~# sos report -o networking root@srv:~# lsmod | grep -i devlink devlink 45056 0 Not reproducible on Bionic w/ 5.4 kernel for instance Reason: config-4.15.0-140-generic:CONFIG_MAY_USE_DEVLINK=m config-5.4.0-70-generic:CONFIG_NET_DEVLINK=y CONFIG_MAY_USE_DEVLINK: Drivers using the devlink infrastructure should have a dependency on MAY_USE_DEVLINK to ensure they do not cause link errors when devlink is a loadable module and the driver using it is built-in. [Where problem could occur] + The fix first checks for /sys/class/devlink before adding the devlink commands to the networking plugin. If this path changes in future kernels, or it becomes possible to collect devlink information without this path being present, we'll miss that information in sosreports. It's also possible that in future kernels, additional modules get loaded due to the devlink commands, so we should also be on the lookout for those changing the system state between sos executions. + + The above are very unlikely scenarios in any case, and we should get + previous notice of such changes. The patchset will also be tested with + the now fixed autopkgtests, and that should give a bit more confidence + in the fixes. [Other information] + This is fixed by upstream commit: + - c90315e23c57 "[networking] check for the presence of devlink" Upstream issues: https://github.com/sosreport/sos/commit/e7801c5bf50d129f93559f8c459a3c96bba1375e -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Description changed:
[Impact]
On AMD Zen systems, memcpy() calls see a heavy performance regression in
Focal and Groovy, due to the way __x86_non_temporal_threshold is calculated.
Before 'glibc-2.33~455', cache values were calculated taking into
consideration the number of hardware threads in the CPU. On AMD Ryzen
and EPYC systems, this can be counter-productive if the number of
threads is high enough for the last-level caches to "overrun" each other
and cause cache line flushes. The solution is to reduce the allocated
size for these non_temporal stores, removing the number of threads from
the equation.
[Test Plan]
Attached to this bug is a short C program that exercises memcpy() calls in
buffers of variable length. This has been obtained from a similar bug report
for Red Hat, and is publicly available at [0].
This test program was compiled with gcc 10.2.0, using the following flags:
$ gcc -mtune=generic -march=x86_64 -g -03 test_memcpy.c -o test_memcpy64
Tests were performed with the following criteria:
- use 32Mb buffers ("./test_memcpy64 32")
- benchmark with the hyperfine tool [1], as it calculates relevant statistics
automatically
- benchmark with at least 10 runs in the same environment, to minimize
variance
- measure on AMD Zen (3700X) and on Intel Xeon (E5-2683), to ensure we don't
penalize one x86 vendor in favor of the other
Below is a comparison between two Focal containers, leveraging LXD to
make use of different libc versions on the same host:
$ hyperfine -n libc-2.31-0ubuntu9.2 'lxc exec focal ./test_memcpy64 32' -n
libc-patched 'lxc exec focal-patched ./test_memcpy64 32'
Benchmark #1: libc-2.31-0ubuntu9.2
Time (mean ± σ): 2.723 s ± 0.013 s[User: 4.7 ms, System: 5.1 ms]
Range (min … max):2.693 s … 2.735 s10 runs
Benchmark #2: libc-patched
Time (mean ± σ): 1.522 s ± 0.004 s[User: 3.9 ms, System: 5.6 ms]
Range (min … max):1.515 s … 1.528 s10 runs
Summary
'libc-patched' ran
1.79 ± 0.01 times faster than 'libc-2.31-0ubuntu9.2'
$ head -n5 /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 113
model name : AMD Ryzen 7 3700X 8-Core Processor
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1880670
[1] https://github.com/sharkdp/hyperfine/
[Where problems could occur]
Since we're messing with the cacheinfo for x86 in general, we need to be
careful not to introduce further performance regressions on memory-heavy
workloads. Even though initial results might reveal improvement on AMD Ryzen
and EPYC hardware, we should also validate different configurations (e.g.
Intel, different buffer sizes, etc) to make sure we won't hurt performance in
other non-AMD environments.
[Other Info]
- This has been fixed by the following upstream commit:
+ This issue has been fixed by the following upstream commit:
- d3c57027470b (Reversing calculation of __x86_shared_non_temporal_threshold)
$ git describe --contains d3c57027470b
glibc-2.33~455
$ rmadison glibc -s focal,focal-updates,groovy,groovy-proposed,hirsute
glibc | 2.31-0ubuntu9 | focal | source
glibc | 2.31-0ubuntu9.2 | focal-updates | source
glibc | 2.32-0ubuntu3 | groovy | source
glibc | 2.32-0ubuntu3.2 | groovy-proposed | source
glibc | 2.33-0ubuntu5 | hirsute | source
Affected releases include Ubuntu Focal and Groovy. Bionic is not
affected, and releases starting with Hirsute already ship the upstream
patch to fix this regression.
+
+ glibc exports this specific variable as a tunable, so we could also tweak it
with the GLIBC_TUNABLES env var:
+ $ hyperfine -n clean-env 'lxc exec focal env ./test_memcpy64 32' -n tunables
'lxc exec focal env
GLIBC_TUNABLES=glibc.cpu.x86_non_temporal_threshold=1024*1024*3*4
./test_memcpy64 32'
+ Benchmark #1: clean-env
+ Time (mean ± σ): 2.529 s ± 0.061 s[User: 6.0 ms, System: 4.7 ms]
+ Range (min … max):2.457 s … 2.615 s10 runs
+
+ Benchmark #2: tunables
+ Time (mean ± σ): 1.427 s ± 0.030 s[User: 6.5 ms, System: 3.8 ms]
+ Range (min … max):1.402 s … 1.482 s10 runs
+
+ Summary
+ 'tunables' ran
+ 1.77 ± 0.06 times faster than 'clean-env'
+
+ This solution is not ideal, but it offers a secondary way of fixing the
+ performance issues. However, the speed gains for memcpy() are noticeable
+ enough that we should strongly consider changing the defaults in the
+ Focal LTS release, so that it performs similarly to Bionic and future
+ Ubuntu releases starting with Hirsute.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928508
Title:
Performance regression on memcpy() calls for AMD Zen
To manage notifications about this bug go to:
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Changed in: sosreport (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1923661] Re: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured
** Changed in: sosreport (Ubuntu Bionic) Assignee: Eric Desrochers (slashd) => Heitor Alves de Siqueira (halves) ** Changed in: sosreport (Ubuntu Focal) Assignee: Eric Desrochers (slashd) => Heitor Alves de Siqueira (halves) ** Changed in: sosreport (Ubuntu Groovy) Assignee: Eric Desrochers (slashd) => Heitor Alves de Siqueira (halves) ** Changed in: sosreport (Ubuntu Hirsute) Assignee: Eric Desrochers (slashd) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923661 Title: [sos41][networking] May invoke devlink module when not loaded depending on how the kernel is configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1923661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Patch added: "lp1928508-groovy-v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5503158/+files/lp1928508-groovy-v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Patch removed: "lp1928508-focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5502960/+files/lp1928508-focal.debdiff ** Patch removed: "lp1928508-groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5502961/+files/lp1928508-groovy.debdiff ** Patch added: "lp1928508-focal-v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5503157/+files/lp1928508-focal-v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Patch added: "lp1928508-groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5502961/+files/lp1928508-groovy.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Patch added: "lp1928508-focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5502960/+files/lp1928508-focal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
I've ran the same test on an Intel system, to ensure we aren't introducing any regressions there. Besides basic smoke tests, the benchmarks from the description showed that the performance on Intel is not significantly affected by this patch. halves@rotom:~$ head -n5 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz halves@rotom:~$ .cargo/bin/hyperfine -n focal-2.31-0ubuntu9.2 'lxc exec halves-focal ./test_memcpy64 32' -n focal-patched 'lxc exec halves-focal-patched ./test_memcpy64 32' Benchmark #1: focal-2.31-0ubuntu9.2 Time (mean ± σ): 2.662 s ± 0.058 s[User: 53.4 ms, System: 79.6 ms] Range (min … max):2.559 s … 2.718 s10 runs Benchmark #2: focal-patched Time (mean ± σ): 2.650 s ± 0.074 s[User: 61.5 ms, System: 76.1 ms] Range (min … max):2.558 s … 2.759 s10 runs Summary 'focal-patched' ran 1.00 ± 0.04 times faster than 'focal-2.31-0ubuntu9.2' halves@rotom:~$ .cargo/bin/hyperfine -n groovy-2.32-0ubuntu3 'lxc exec halves-groovy ./test_memcpy64 32' -n groovy-patched 'lxc exec halves-groovy-patched ./test_memcpy64 32' Benchmark #1: groovy-2.32-0ubuntu3 Time (mean ± σ): 2.643 s ± 0.044 s[User: 52.4 ms, System: 76.0 ms] Range (min … max):2.575 s … 2.746 s10 runs Benchmark #2: groovy-patched Time (mean ± σ): 2.626 s ± 0.036 s[User: 63.1 ms, System: 79.7 ms] Range (min … max):2.590 s … 2.701 s10 runs Summary 'groovy-patched' ran 1.01 ± 0.02 times faster than 'groovy-2.32-0ubuntu3' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
Below is the same benchmark from the case description, validating the performance regression on Groovy. Patched glibc builds for both Focal and Groovy amd64/i386 are available at ppa:halves/lp1928508-test [0]. $ hyperfine -n groovy-2.32-0ubuntu3 'lxc exec groovy ./test_memcpy64 32' -n groovy-patched 'lxc exec groovy-patched ./test_memcpy64 32' Benchmark #1: groovy-2.32-0ubuntu3 Time (mean ± σ): 2.392 s ± 0.039 s[User: 4.8 ms, System: 5.4 ms] Range (min … max):2.366 s … 2.494 s10 runs Benchmark #2: groovy-patched Time (mean ± σ): 1.381 s ± 0.010 s[User: 6.1 ms, System: 4.3 ms] Range (min … max):1.372 s … 1.407 s10 runs Summary 'groovy-patched' ran 1.73 ± 0.03 times faster than 'groovy-2.32-0ubuntu3' $ head -n5 /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 113 model name : AMD Ryzen 7 3700X 8-Core Processor [0] https://launchpad.net/~halves/+archive/ubuntu/lp1928508-test ** Changed in: glibc (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: glibc (Ubuntu Groovy) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1920047] Re: sanlock global lock creation fail
** Changed in: lvm2 (Ubuntu) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu) Importance: Undecided => High ** Changed in: lvm2 (Ubuntu) Status: New => Fix Released ** Also affects: lvm2 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: lvm2 (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: lvm2 (Ubuntu Focal) Status: New => Confirmed ** Changed in: lvm2 (Ubuntu Groovy) Status: New => Confirmed ** Changed in: lvm2 (Ubuntu Focal) Importance: Undecided => High ** Changed in: lvm2 (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu Groovy) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu Groovy) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1920047 Title: sanlock global lock creation fail To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Description changed:
[Impact]
On AMD Zen systems, memcpy() calls see a heavy performance regression in
Focal and Groovy, due to the way __x86_non_temporal_threshold is calculated.
- Before 'glibc-2.33~455', cache values were calculated taking into
consideration the number of hardware threads in the CPU. On AMD Ryzen and EPYC
systems, this can be counter-productive if the number of threads is high enough
for the last-level caches to "overrun" each other and cause cache line flushes.
The solution is to reduce the allocated size for these non_temporal stores,
removing
- the number of threads from the equation.
+ Before 'glibc-2.33~455', cache values were calculated taking into
+ consideration the number of hardware threads in the CPU. On AMD Ryzen
+ and EPYC systems, this can be counter-productive if the number of
+ threads is high enough for the last-level caches to "overrun" each other
+ and cause cache line flushes. The solution is to reduce the allocated
+ size for these non_temporal stores, removing the number of threads from
+ the equation.
[Test Plan]
Attached to this bug is a short C program that exercises memcpy() calls in
buffers of variable length. This has been obtained from a similar bug report
for Red Hat, and is publicly available at [0].
This test program was compiled with gcc 10.2.0, using the following flags:
$ gcc -mtune=generic -march=x86_64 -g -03 test_memcpy.c -o test_memcpy64
Tests were performed with the following criteria:
- use 32Mb buffers ("./test_memcpy64 32")
- benchmark with the hyperfine tool [1], as it calculates relevant statistics
automatically
- benchmark with at least 10 runs in the same environment, to minimize
variance
- measure on AMD Zen (3700X) and on Intel Xeon (E5-2683), to ensure we don't
penalize one x86 vendor in favor of the other
Below is a comparison between two Focal containers, leveraging LXD to
make use of different libc versions on the same host:
$ hyperfine -n libc-2.31-0ubuntu9.2 'lxc exec focal ./test_memcpy64 32' -n
libc-patched 'lxc exec focal-patched ./test_memcpy64 32'
Benchmark #1: libc-2.31-0ubuntu9.2
Time (mean ± σ): 2.723 s ± 0.013 s[User: 4.7 ms, System: 5.1 ms]
Range (min … max):2.693 s … 2.735 s10 runs
Benchmark #2: libc-patched
Time (mean ± σ): 1.522 s ± 0.004 s[User: 3.9 ms, System: 5.6 ms]
Range (min … max):1.515 s … 1.528 s10 runs
Summary
'libc-patched' ran
1.79 ± 0.01 times faster than 'libc-2.31-0ubuntu9.2'
$ head -n5 /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 113
model name : AMD Ryzen 7 3700X 8-Core Processor
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1880670
[1] https://github.com/sharkdp/hyperfine/
[Where problems could occur]
Since we're messing with the cacheinfo for x86 in general, we need to be
careful not to introduce further performance regressions on memory-heavy
workloads. Even though initial results might reveal improvement on AMD Ryzen
and EPYC hardware, we should also validate different configurations (e.g.
Intel, different buffer sizes, etc) to make sure we won't hurt performance in
other non-AMD environments.
[Other Info]
This has been fixed by the following upstream commit:
- d3c57027470b (Reversing calculation of __x86_shared_non_temporal_threshold)
$ git describe --contains d3c57027470b
glibc-2.33~455
$ rmadison glibc -s focal,focal-updates,groovy,groovy-proposed,hirsute
glibc | 2.31-0ubuntu9 | focal | source
glibc | 2.31-0ubuntu9.2 | focal-updates | source
glibc | 2.32-0ubuntu3 | groovy | source
glibc | 2.32-0ubuntu3.2 | groovy-proposed | source
glibc | 2.33-0ubuntu5 | hirsute | source
Affected releases include Ubuntu Focal and Groovy. Bionic is not
affected, and releases starting with Hirsute already ship the upstream
patch to fix this regression.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928508
Title:
Performance regression on memcpy() calls for AMD Zen
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] Re: Performance regression on memcpy() calls for AMD Zen
** Attachment added: "test_memcpy.c" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+attachment/5497631/+files/test_memcpy.c -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928508 Title: Performance regression on memcpy() calls for AMD Zen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1928508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928508] [NEW] Performance regression on memcpy() calls for AMD Zen
Public bug reported:
[Impact]
On AMD Zen systems, memcpy() calls see a heavy performance regression in Focal
and Groovy, due to the way __x86_non_temporal_threshold is calculated.
Before 'glibc-2.33~455', cache values were calculated taking into consideration
the number of hardware threads in the CPU. On AMD Ryzen and EPYC systems, this
can be counter-productive if the number of threads is high enough for the
last-level caches to "overrun" each other and cause cache line flushes. The
solution is to reduce the allocated size for these non_temporal stores, removing
the number of threads from the equation.
[Test Plan]
Attached to this bug is a short C program that exercises memcpy() calls in
buffers of variable length. This has been obtained from a similar bug report
for Red Hat, and is publicly available at [0].
This test program was compiled with gcc 10.2.0, using the following flags:
$ gcc -mtune=generic -march=x86_64 -g -03 test_memcpy.c -o test_memcpy64
Tests were performed with the following criteria:
- use 32Mb buffers ("./test_memcpy64 32")
- benchmark with the hyperfine tool [1], as it calculates relevant statistics
automatically
- benchmark with at least 10 runs in the same environment, to minimize variance
- measure on AMD Zen (3700X) and on Intel Xeon (E5-2683), to ensure we don't
penalize one x86 vendor in favor of the other
Below is a comparison between two Focal containers, leveraging LXD to
make use of different libc versions on the same host:
$ hyperfine -n libc-2.31-0ubuntu9.2 'lxc exec focal ./test_memcpy64 32' -n
libc-patched 'lxc exec focal-patched ./test_memcpy64 32'
Benchmark #1: libc-2.31-0ubuntu9.2
Time (mean ± σ): 2.723 s ± 0.013 s[User: 4.7 ms, System: 5.1 ms]
Range (min … max):2.693 s … 2.735 s10 runs
Benchmark #2: libc-patched
Time (mean ± σ): 1.522 s ± 0.004 s[User: 3.9 ms, System: 5.6 ms]
Range (min … max):1.515 s … 1.528 s10 runs
Summary
'libc-patched' ran
1.79 ± 0.01 times faster than 'libc-2.31-0ubuntu9.2'
$ head -n5 /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 113
model name : AMD Ryzen 7 3700X 8-Core Processor
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1880670
[1] https://github.com/sharkdp/hyperfine/
[Where problems could occur]
Since we're messing with the cacheinfo for x86 in general, we need to be
careful not to introduce further performance regressions on memory-heavy
workloads. Even though initial results might reveal improvement on AMD Ryzen
and EPYC hardware, we should also validate different configurations (e.g.
Intel, different buffer sizes, etc) to make sure we won't hurt performance in
other non-AMD environments.
[Other Info]
This has been fixed by the following upstream commit:
- d3c57027470b (Reversing calculation of __x86_shared_non_temporal_threshold)
$ git describe --contains d3c57027470b
glibc-2.33~455
$ rmadison glibc -s focal,focal-updates,groovy,groovy-proposed,hirsute
glibc | 2.31-0ubuntu9 | focal | source
glibc | 2.31-0ubuntu9.2 | focal-updates | source
glibc | 2.32-0ubuntu3 | groovy | source
glibc | 2.32-0ubuntu3.2 | groovy-proposed | source
glibc | 2.33-0ubuntu5 | hirsute | source
Affected releases include Ubuntu Focal and Groovy. Bionic is not
affected, and releases starting with Hirsute already ship the upstream
patch to fix this regression.
** Affects: glibc (Ubuntu)
Importance: High
Assignee: Heitor Alves de Siqueira (halves)
Status: Fix Released
** Affects: glibc (Ubuntu Focal)
Importance: High
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: glibc (Ubuntu Groovy)
Importance: High
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Tags: sts
** Also affects: glibc (Ubuntu Groovy)
Importance: Undecided
Status: New
** Also affects: glibc (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: glibc (Ubuntu Focal)
Importance: Undecided => High
** Changed in: glibc (Ubuntu Groovy)
Importance: Undecided => High
** Changed in: glibc (Ubuntu Focal)
Status: New => Confirmed
** Changed in: glibc (Ubuntu Groovy)
Status: New => Won't Fix
** Changed in: glibc (Ubuntu Groovy)
Status: Won't Fix => Confirmed
** Changed in: glibc (Ubuntu)
Status: New => Fix Released
** Changed in: glibc (Ubuntu Focal)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: glibc (Ubuntu Groovy)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Description changed:
[Impact]
On AMD Zen systems, memcpy() calls see a heavy performance regression in
Focal and Groovy, due to the way __x86_non_temporal_threshold is calculated.
Before 'glibc-2.33~455', cache values were calculated taking into
consideration the number of hardwa
[Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/mitaka Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Fix Released ** Changed in: cloud-archive Importance: Undecided => High ** Changed in: cloud-archive/mitaka Importance: Undecided => High ** Changed in: cloud-archive/mitaka Status: New => Confirmed ** Changed in: cloud-archive/mitaka Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: cloud-archive Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1927547/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
Fixes are now available under the "ESM Infrastructure Security" PPA for Trusty and Xenial, according to the versions below: Trusty -- 1.7.4-4ubuntu1+esm1 Xenial -- 1.8.2-1ubuntu1+esm1 ** Changed in: seabios (Ubuntu Trusty) Status: In Progress => Fix Released ** Changed in: seabios (Ubuntu Xenial) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/1927547/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
** Patch added: "lp1927547-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/1927547/+attachment/5497092/+files/lp1927547-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/1927547/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
