[Kernel-packages] [Bug 2019013] Re: Audio stops working in kernel 5.15.0-71-generic on ASUS Zenbook
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2019013 Title: Audio stops working in kernel 5.15.0-71-generic on ASUS Zenbook Status in linux package in Ubuntu: Expired Bug description: I've been using audio on a ASUS Zenbook for about 2 years now without problems. I recently switched from kernel 5.15.0-70 to 5.15.0-71 - and suddenly I have severe audio problems: playback or record stops after a while, or it stops working more or less immediately when I plugin my headset. Really annoying during web meetings ;-) I switched back to 5.15.0-70 and it works fine as always. I reported the issue to kernel.org already as https://bugzilla.kernel.org/show_bug.cgi?id=217409#c2, but got the information that as this is a vendor kernel, I should report it here as well, as there might be patches in place. Is 5.15.0-71-generic based on the 5.15.71 kernel or on a different version? Operating System: Linux Mint 20.3 Kernel Version: 5.15.0-71-generic Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz ❯ apt policy linux-image-5.15.0-71-generic linux-image-5.15.0-71-generic: Installiert: 5.15.0-71.78~20.04.1 Installationskandidat: 5.15.0-71.78~20.04.1 Versionstabelle: *** 5.15.0-71.78~20.04.1 500 500 http://ftp.uni-mainz.de/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status ❯ inxi -MmCA Machine: Type: Convertible System: ASUSTeK product: ZenBook UX562FAC_UX562FA v: 1.0 serial: Mobo: ASUSTeK model: UX562FAC v: 1.0 UEFI: American Megatrends v: UX562FAC.304 date: 05/06/2020 Memory:RAM: total: 15.45 GiB used: 8.20 GiB (53.1%) CPU: Topology: Quad Core model: Intel Core i7-10510U bits: 64 type: MT MCP L2 cache: 8192 KiB Speed: 3901 MHz min/max: 400/4900 MHz Core speeds (MHz): 1: 3824 2: 3863 3: 3842 4: 2246 5: 2613 6: 2613 7: 3551 8: 3126 Audio: Device-1: Intel driver: snd_hda_intel Sound Server: ALSA v: k5.15.0-70-generic ❯ arecord -l Liste der Hardware-Geräte (CAPTURE) Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC294 Analog [ALC294 Analog] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 ❯ aplay -l Liste der Hardware-Geräte (PLAYBACK) Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC294 Analog [ALC294 Analog] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 3: HDMI 0 [HDMI 0] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 7: HDMI 1 [HDMI 1] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 8: HDMI 2 [HDMI 2] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 9: HDMI 3 [HDMI 3] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: PCH [HDA Intel PCH], Gerät 10: HDMI 4 [HDMI 4] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 ❯ lspci -v | grep -i audio 00:1f.3 Audio device: Intel Corporation Device 02c8 (prog-if 80) --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.26 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ptandler 2198 F pulseaudio /dev/snd/pcmC0D0p: ptandler 2198 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: KDE DistroRelease: Linux Mint 20.3 EcryptfsInUse: Yes InstallationDate: Installed on 2020-06-29 (1044 days ago) InstallationMedia: Linux Mint 20 "Ulyana" - Release amd64 20200624 MachineType: ASUSTeK COMPUTER INC. ZenBook UX562FAC_UX562FA Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.15.0-70-generic root=UUID=3005a256-5664-4f8b-a26c-f11e7f9d0392 ro rootflags=subvol=@ quiet splash ProcVersionSignature: Ubuntu 5.15.0-70.77~20.04.1-generic 5.15.92 RelatedPackageVersions: linux-restricted-modules-5.15.0-70-generic N/A linux-backports-modules-5.15.0-70-generic N/A linux-firmware 1.187.38 Tags: una Uname: Linux 5.15.0-70-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip docker kvm libvirt lpadmin plugdev sambashare scanner sudo www-data _MarkForUpload: True dmi.bios.date: 05/06/2020 dmi.bios.release: 5.16 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: UX562FAC.304 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX562FAC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: ASUSTeK
[Kernel-packages] [Bug 2026632] [NEW] Can't boot anymore without noapic
Public bug reported: 5.19.0-43 was the last kernel that I could boot just fine, without noapic. The ones after that (-45 and -46) won't boot and display nothing at all. They must have a kernel panic related to IO-APIC very early on in the boot because adding panic=10 reboots the system after 10 seconds. I tried adding earlyprintk=efi,keep but even then I get no messages. With noapic the kernel does work. System is a Ryzen 5 1400 on a B350 chipset mainboard ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-46-generic 5.19.0-46.47~22.04.1 ProcVersionSignature: Ubuntu 5.19.0-43.44~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-43-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Sun Jul 9 00:03:26 2023 InstallationDate: Installed on 2022-05-14 (420 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: linux-signed-hwe-5.19 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-signed-hwe-5.19 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy wayland-session -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2026632 Title: Can't boot anymore without noapic Status in linux-signed-hwe-5.19 package in Ubuntu: New Bug description: 5.19.0-43 was the last kernel that I could boot just fine, without noapic. The ones after that (-45 and -46) won't boot and display nothing at all. They must have a kernel panic related to IO-APIC very early on in the boot because adding panic=10 reboots the system after 10 seconds. I tried adding earlyprintk=efi,keep but even then I get no messages. With noapic the kernel does work. System is a Ryzen 5 1400 on a B350 chipset mainboard ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-46-generic 5.19.0-46.47~22.04.1 ProcVersionSignature: Ubuntu 5.19.0-43.44~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-43-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Sun Jul 9 00:03:26 2023 InstallationDate: Installed on 2022-05-14 (420 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: linux-signed-hwe-5.19 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.19/+bug/2026632/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2026216] Re: ethernet not found after kernel update to linux-image-5.19.0-46-generic
lspci shows the ethernet card is: 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2026216 Title: ethernet not found after kernel update to linux- image-5.19.0-46-generic Status in linux-signed-hwe-5.19 package in Ubuntu: New Bug description: After updating kernel to linux-image-5.19.0-46-generic (by apt upgrade), ubuntu doesn't discover ethernet. Things work as expected after choosing older kernel at grub. After (kernel) update ubuntu stopped at terminal (did not show gdm screen). After logging in to terminal, ifconfig didn't show ethernet (did show lo and docker). ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-45-generic 5.19.0-45.46~22.04.1 ProcVersionSignature: Ubuntu 5.19.0-45.46~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-45-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Wed Jul 5 17:47:51 2023 InstallationDate: Installed on 2023-02-03 (152 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) ProcEnviron: TERM=alacritty PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/usr/bin/zsh RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: linux-signed-hwe-5.19 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.19/+bug/2026216/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2026620] Re: kernel 5.19.0-1010-nvidia-lowlatency issue with rootless podman
EACCES is the same code that triggers the failed chromium start that is described in bug https://bugs.launchpad.net/ubuntu/+source/linux-meta- nvidia-5.19/+bug/2017980 as written in comment https://bugs.launchpad.net/ubuntu/+source/linux-meta- nvidia-5.19/+bug/2017980/comments/27 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-nvidia-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2026620 Title: kernel 5.19.0-1010-nvidia-lowlatency issue with rootless podman Status in libpod package in Ubuntu: New Status in linux-signed-nvidia-5.19 package in Ubuntu: New Bug description: Description: Ubuntu 22.04.2 LTS Release: 22.04 Podman version 3.4.4+ds1-1ubuntu1.22.04.1 What I expected to happen: podman commands in rootless mode should work. What happened instead: podman commands in rootless mode do not work, and return an error message that seems to have something to do with permissions. Whenever I try to type a podman command, such as $ podman info as my regular user, I get: cannot clone: Permission denied Error: cannot re-exec process I have completed the steps in the Rootless Tutorial from the official Podman documentation. I have all the necessary packages to operate rootless podman. I have added valid subuid and subgid range for my user. I have user namespaces enabled. I can't even run $ podman info but $ sudo podman info works fine If I use $ strace -f podman ps I get this error code: clone(child_stack=NULL, flags=CLONE_NEWNS|CLONE_NEWUSER|SIGCHLD [pid 18832] <... nanosleep resumed>NULL) = 0 [pid 18836] <... clone resumed>) = -1 EACCES (Permission denied) By searching through the clone(2) man page, EACCES seems to be an error code to do with extra restrictions concerning version 2 of cgroups. This may be a red herring though. I have tried uninstalling, purging, and then reinstalling podman. I still have the same problem. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: podman 3.4.4+ds1-1ubuntu1.22.04.1 ProcVersionSignature: Ubuntu 5.19.0-1010.10-nvidia-lowlatency 5.19.17 Uname: Linux 5.19.0-1010-nvidia-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jul 8 08:28:24 2023 InstallationDate: Installed on 2022-10-15 (266 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libpod UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2026620/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2026625] [NEW] package linux-headers-6.2.0-24-generic 6.2.0-24.24 failed to install/upgrade: installed linux-headers-6.2.0-24-generic package post-installation script subprocess
Public bug reported: Occurred during installation ProblemType: Package DistroRelease: Ubuntu 23.04 Package: linux-headers-6.2.0-24-generic 6.2.0-24.24 ProcVersionSignature: Ubuntu 6.2.0-20.20-generic 6.2.6 Uname: Linux 6.2.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: unknown Date: Sat Jul 8 12:13:10 2023 ErrorMessage: installed linux-headers-6.2.0-24-generic package post-installation script subprocess returned error exit status 1 MachineType: Alienware Alienware Aurora Ryzen Edition ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-20-generic root=UUID=b6810121-855e-41ef-a565-e89e88e0b75f ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1 PythonDetails: /usr/bin/python3.11, Python 3.11.2, unpackaged RelatedPackageVersions: grub-pc 2.06-2ubuntu16 SourcePackage: linux Title: package linux-headers-6.2.0-24-generic 6.2.0-24.24 failed to install/upgrade: installed linux-headers-6.2.0-24-generic package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to lunar on 2023-05-09 (60 days ago) dmi.bios.date: 01/13/2023 dmi.bios.release: 2.4 dmi.bios.vendor: Alienware dmi.bios.version: 2.4.0 dmi.board.name: 0NWN7M dmi.board.vendor: Alienware dmi.board.version: A00 dmi.chassis.type: 3 dmi.chassis.vendor: Alienware dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnAlienware:bvr2.4.0:bd01/13/2023:br2.4:svnAlienware:pnAlienwareAuroraRyzenEdition:pvr2.4.0:rvnAlienware:rn0NWN7M:rvrA00:cvnAlienware:ct3:cvrNotSpecified:sku098E: dmi.product.family: Alienware dmi.product.name: Alienware Aurora Ryzen Edition dmi.product.sku: 098E dmi.product.version: 2.4.0 dmi.sys.vendor: Alienware ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package lunar need-duplicate-check -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2026625 Title: package linux-headers-6.2.0-24-generic 6.2.0-24.24 failed to install/upgrade: installed linux-headers-6.2.0-24-generic package post-installation script subprocess returned error exit status 1 Status in linux package in Ubuntu: New Bug description: Occurred during installation ProblemType: Package DistroRelease: Ubuntu 23.04 Package: linux-headers-6.2.0-24-generic 6.2.0-24.24 ProcVersionSignature: Ubuntu 6.2.0-20.20-generic 6.2.6 Uname: Linux 6.2.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: unknown Date: Sat Jul 8 12:13:10 2023 ErrorMessage: installed linux-headers-6.2.0-24-generic package post-installation script subprocess returned error exit status 1 MachineType: Alienware Alienware Aurora Ryzen Edition ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-20-generic root=UUID=b6810121-855e-41ef-a565-e89e88e0b75f ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1 PythonDetails: /usr/bin/python3.11, Python 3.11.2, unpackaged RelatedPackageVersions: grub-pc 2.06-2ubuntu16 SourcePackage: linux Title: package linux-headers-6.2.0-24-generic 6.2.0-24.24 failed to install/upgrade: installed linux-headers-6.2.0-24-generic package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to lunar on 2023-05-09 (60 days ago) dmi.bios.date: 01/13/2023 dmi.bios.release: 2.4 dmi.bios.vendor: Alienware dmi.bios.version: 2.4.0 dmi.board.name: 0NWN7M dmi.board.vendor: Alienware dmi.board.version: A00 dmi.chassis.type: 3 dmi.chassis.vendor: Alienware dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnAlienware:bvr2.4.0:bd01/13/2023:br2.4:svnAlienware:pnAlienwareAuroraRyzenEdition:pvr2.4.0:rvnAlienware:rn0NWN7M:rvrA00:cvnAlienware:ct3:cvrNotSpecified:sku098E: dmi.product.family: Alienware dmi.product.name: Alienware Aurora Ryzen Edition dmi.product.sku: 098E dmi.product.version: 2.4.0 dmi.sys.vendor: Alienware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2026625/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2024774] Re: AMD Rembrandt / Phoenix PSR-SU related freezes
** Changed in: linux-firmware
Status: New => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-firmware in Ubuntu.
https://bugs.launchpad.net/bugs/2024774
Title:
AMD Rembrandt / Phoenix PSR-SU related freezes
Status in Linux Firmware:
Fix Released
Status in linux-firmware package in Ubuntu:
Fix Released
Status in linux-firmware source package in Jammy:
Fix Committed
Status in linux-firmware source package in Lunar:
Fix Committed
Status in linux-firmware source package in Mantic:
Fix Released
Bug description:
[ Impact ]
When using kernel 6.2 or later AMD has enabled PSR selective update (PSR-SU).
After a non-deterministic amount of time the system may hang with a message
like this in the logs:
"[amdgpu :67:00.0: [drm] *ERROR* [CONNECTOR:78:eDP-1] commit wait timed
out]"
Affects users of laptops that contain:
* AMD Rembrandt (Yellow Carp) or AMD Phoenix (Pink Sardine) chips
* eDP panels with Parade TCONs (8-03 and 8-01 both reported to fail)
[ Test Plan ]
* Test an affected laptop with the newer firmware and ensure that PSR-SU
function can be enabled and system is stable.
* Ensure other functions such as hotplugging monitors and suspending
continue to work.
[ Where problems could occur ]
* Affected firmware only is loaded on Rembrandt and Phoenix laptops.
Problems would be localized to these machines.
[ Other Info ]
The minimum firmware needed to help these hangs:
* Rembrandt: 0x43a or later
* Phoenix: 0x8001000 or later
The following commit upgrades the firmware for Rembrandt
(amdgpu/yellow_carp_dmcub.bin) to 0x43c:
9dbd8ec2 ("amdgpu: DMCUB updates for various AMDGPU asics")
The following commit upgrades the firmware for Phoenix
(amdgpu/dcn_3_1_4_dmcub.bin) to 0x8001a00:
045b2136 ("amdgpu: update DMCUB to v0.0.172.0 for various AMDGPU ASICs")
The TCON in a given laptop can be identified from the DPCD with this script:
https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/psr.py
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux-firmware/+bug/2024774/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
The attachment "lp2024479_focal.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: Incomplete Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: In Progress Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. KEXEX - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. KEXEC - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
kexec-tools debdiff LUNAR. ** Patch added: "lp2024479_lunar.debdiff" https://bugs.launchpad.net/ubuntu/lunar/+source/kexec-tools/+bug/2024479/+attachment/5684766/+files/lp2024479_lunar.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: Incomplete Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: In Progress Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. KEXEX - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. KEXEC - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64:
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
kexec-tools debdiff JAMMY. ** Patch added: "lp2024479_jammy.debdiff" https://bugs.launchpad.net/ubuntu/lunar/+source/kexec-tools/+bug/2024479/+attachment/5684765/+files/lp2024479_jammy.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: Incomplete Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: In Progress Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. KEXEX - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. KEXEC - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64:
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
kexec-tools debdiff MANTIC. ** Patch added: "lp2024479_mantic.debdiff" https://bugs.launchpad.net/ubuntu/lunar/+source/kexec-tools/+bug/2024479/+attachment/5684767/+files/lp2024479_mantic.debdiff ** Changed in: kexec-tools (Ubuntu Focal) Status: New => In Progress ** Changed in: kexec-tools (Ubuntu Jammy) Status: New => In Progress ** Changed in: kexec-tools (Ubuntu Lunar) Status: New => In Progress ** Changed in: kexec-tools (Ubuntu Mantic) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: Incomplete Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: In Progress Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. KEXEX - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. KEXEC - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
Kexec-tools debdiff FOCAL. ** Patch added: "lp2024479_focal.debdiff" https://bugs.launchpad.net/ubuntu/lunar/+source/kexec-tools/+bug/2024479/+attachment/5684764/+files/lp2024479_focal.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: In Progress Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: In Progress Status in linux source package in Jammy: Incomplete Status in kexec-tools source package in Kinetic: Won't Fix Status in linux source package in Kinetic: Won't Fix Status in kexec-tools source package in Lunar: In Progress Status in kexec-tools source package in Mantic: In Progress Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. KEXEX - FOCAL: To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. Commit cf977b1af9ec67fab adds code without altering current functionality. Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. KEXEC - JAMMY, LUNAR, MANTIC: Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64:
[Kernel-packages] [Bug 2025538] Re: Unrequested kernel update
This kernel creates problems for me as well, with rootless podman commands. See Bug #2026620 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-nvidia-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2025538 Title: Unrequested kernel update Status in linux-signed-nvidia-5.19 package in Ubuntu: Confirmed Status in ubuntu-drivers-common package in Ubuntu: Confirmed Bug description: Running Kubuntu 22.04 LTS (lsb_release -a: Ubuntu 22.04.2 LTS) I was informed that new packages are available and I just hit update. This caused my system running 5.15.0-76-generic to be switched to 5.19.0-1010-nvidia-lowlatency. I noted this as I was now running into bugs like https://bugs.launchpad.net/ubuntu/+source/chromium- browser/+bug/2017980 The update was, as stated in history.log: Start-Date: 2023-07-01 00:25:40 Commandline: packagekit role='update-packages' Requested-By: cm (1000) Install: linux-objects-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-signatures-nvidia-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-image-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-nvidia-510-nvidia-lowlatency-edge:amd64 (5.19.0-1010.10, automatic) Upgrade: libmm-glib0:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2), modemmanager:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2) => This simple update was changing my kernel from 5.15 to 5.19 without a request from my side ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-1010-nvidia-lowlatency 5.19.0-1010.10 ProcVersionSignature: Ubuntu 5.19.0-1010.10-nvidia-lowlatency 5.19.17 Uname: Linux 5.19.0-1010-nvidia-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sat Jul 1 21:16:09 2023 InstallationDate: Installed on 2018-10-10 (1724 days ago) InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: linux-signed-nvidia-5.19 UpgradeStatus: Upgraded to jammy on 2022-07-24 (342 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-nvidia-5.19/+bug/2025538/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2026620] Re: kernel 5.19.0-1010-nvidia-lowlatency issue with rootless podman
** Summary changed: - Any podman command in rootless mode does not work. Root usage works fine + kernel 5.19.0-1010-nvidia-lowlatency issue with rootless podman ** Also affects: linux-signed-nvidia (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux-signed-nvidia (Ubuntu) ** Also affects: linux-signed-nvidia-5.19 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-nvidia-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2026620 Title: kernel 5.19.0-1010-nvidia-lowlatency issue with rootless podman Status in libpod package in Ubuntu: New Status in linux-signed-nvidia-5.19 package in Ubuntu: New Bug description: Description: Ubuntu 22.04.2 LTS Release: 22.04 Podman version 3.4.4+ds1-1ubuntu1.22.04.1 What I expected to happen: podman commands in rootless mode should work. What happened instead: podman commands in rootless mode do not work, and return an error message that seems to have something to do with permissions. Whenever I try to type a podman command, such as $ podman info as my regular user, I get: cannot clone: Permission denied Error: cannot re-exec process I have completed the steps in the Rootless Tutorial from the official Podman documentation. I have all the necessary packages to operate rootless podman. I have added valid subuid and subgid range for my user. I have user namespaces enabled. I can't even run $ podman info but $ sudo podman info works fine If I use $ strace -f podman ps I get this error code: clone(child_stack=NULL, flags=CLONE_NEWNS|CLONE_NEWUSER|SIGCHLD [pid 18832] <... nanosleep resumed>NULL) = 0 [pid 18836] <... clone resumed>) = -1 EACCES (Permission denied) By searching through the clone(2) man page, EACCES seems to be an error code to do with extra restrictions concerning version 2 of cgroups. This may be a red herring though. I have tried uninstalling, purging, and then reinstalling podman. I still have the same problem. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: podman 3.4.4+ds1-1ubuntu1.22.04.1 ProcVersionSignature: Ubuntu 5.19.0-1010.10-nvidia-lowlatency 5.19.17 Uname: Linux 5.19.0-1010-nvidia-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jul 8 08:28:24 2023 InstallationDate: Installed on 2022-10-15 (266 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libpod UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2026620/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
** Description changed: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. + KEXEX - FOCAL: + To fix the kexec_tools in focal we need to pull in 6 commits (see [Other section for details]). They all cherry pick. + Four out of six commits touch only arm64 code. Any regression potential because of these commits would regard either crashdump or kexec functionality. + Commit cf977b1af9ec67fab adds code without altering current functionality. + Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive it moves the code from vmcore-dmesg.c to elf_info.c so it can be used by other features. + + KEXEC - JAMMY, LUNAR, MANTIC: + Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 code. It enables kexec to recognise that teh reserved kernel may use more than one kernel region. Things could go worng when gatherinng a crashdump. + + [Other] Commits to backport *** MANTIC: kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - - ***LUNAR: + ***LUNAR: kernel 6.2: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - *** KINETIC: WON'T FIX Kinetic won't be fixed as it EOLs soon. - *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash low memory if not needed 5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel description for arm64 944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X d339f1584f0acf32b32326627fa3b48e6e65c599 arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - *** FOCAL: Kernel 5.4: Won't fix because of high regression potential. Instead the 5.15-hwe kernel can be used. kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions 2572b8d702e452624bdb8d7b7c39f458e7dcf2ce arm64: kdump: deal with a lot of resource entries in /proc/iomem cf977b1af9ec67fabcc6a625589c49c52d07b11d kexec: add variant helper functions for handling memory regions
[Kernel-packages] [Bug 2025538] Re: Unrequested kernel update
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: ubuntu-drivers-common (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-nvidia-5.19 in Ubuntu. https://bugs.launchpad.net/bugs/2025538 Title: Unrequested kernel update Status in linux-signed-nvidia-5.19 package in Ubuntu: Confirmed Status in ubuntu-drivers-common package in Ubuntu: Confirmed Bug description: Running Kubuntu 22.04 LTS (lsb_release -a: Ubuntu 22.04.2 LTS) I was informed that new packages are available and I just hit update. This caused my system running 5.15.0-76-generic to be switched to 5.19.0-1010-nvidia-lowlatency. I noted this as I was now running into bugs like https://bugs.launchpad.net/ubuntu/+source/chromium- browser/+bug/2017980 The update was, as stated in history.log: Start-Date: 2023-07-01 00:25:40 Commandline: packagekit role='update-packages' Requested-By: cm (1000) Install: linux-objects-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-signatures-nvidia-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-image-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic), linux-modules-nvidia-510-nvidia-lowlatency-edge:amd64 (5.19.0-1010.10, automatic) Upgrade: libmm-glib0:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2), modemmanager:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2) => This simple update was changing my kernel from 5.15 to 5.19 without a request from my side ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.19.0-1010-nvidia-lowlatency 5.19.0-1010.10 ProcVersionSignature: Ubuntu 5.19.0-1010.10-nvidia-lowlatency 5.19.17 Uname: Linux 5.19.0-1010-nvidia-lowlatency x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sat Jul 1 21:16:09 2023 InstallationDate: Installed on 2018-10-10 (1724 days ago) InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: linux-signed-nvidia-5.19 UpgradeStatus: Upgraded to jammy on 2022-07-24 (342 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-nvidia-5.19/+bug/2025538/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
** Description changed: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] KERNEL 5.15: To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. - [Other] Commits to backport + *** MANTIC: - KINETIC: WON'T FIX - Kinetic won't be fixed as it EOLs soon. - kernel (5.19 kernel) : - a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones - a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified + kernel 6.3: not affected kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - JAMMY: + + ***LUNAR: + + kernel 6.2: not affected + + kexec: + b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions + + + *** KINETIC: WON'T FIX + Kinetic won't be fixed as it EOLs soon. + + + *** JAMMY: kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash low memory if not needed 5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel description for arm64 944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X d339f1584f0acf32b32326627fa3b48e6e65c599 arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef - kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - FOCAL: + + *** FOCAL: Kernel 5.4: Won't fix because of high regression potential. + Instead the 5.15-hwe kernel can be used. kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions 2572b8d702e452624bdb8d7b7c39f458e7dcf2ce arm64: kdump: deal with a lot of resource entries in /proc/iomem cf977b1af9ec67fabcc6a625589c49c52d07b11d kexec: add variant helper functions for handling memory regions f736104f533290b4ce6fbfbca74abde9ffd3888c arm64: kexec: allocate memory space avoiding reserved regions 64c49f27d88024eaab990d2cd6069289cf853098 arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or pt_load (if available) f4ce0706d9574aecb7d4aa9af7208a1bc9b6afb4 util_lib: Add functionality to read elf notes -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu.
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
** Description changed: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] + KERNEL 5.15: + To address this problem in the 5.15 kernel we need to pull in 7 commits (see [Other] section for details. + All the commits are changing code only for arm64 architecture and only the code related to reserving the crashkernel. + This means that any regression potential will affect only the arm64 architecture and in particular the crash/kdump functionality. + However, since the reservation of the crashkernel occurs at boot up, potentially things could go wrong there as well. + + [Other] Commits to backport - JAMMY: - - kernel: + KINETIC: WON'T FIX + Kinetic won't be fixed as it EOLs soon. + kernel (5.19 kernel) : a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions - FOCAL: + JAMMY: - kernel (5.15 hwe kernel): + kernel (5.15 kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash low memory if not needed 5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel description for arm64 944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X d339f1584f0acf32b32326627fa3b48e6e65c599 arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef + + kexec: + b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions + + FOCAL: + + Kernel 5.4: Won't fix because of high regression potential. + kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions 2572b8d702e452624bdb8d7b7c39f458e7dcf2ce arm64: kdump: deal with a lot of resource entries in /proc/iomem cf977b1af9ec67fabcc6a625589c49c52d07b11d kexec: add variant helper functions for handling memory regions f736104f533290b4ce6fbfbca74abde9ffd3888c arm64: kexec: allocate memory space avoiding reserved regions 64c49f27d88024eaab990d2cd6069289cf853098 arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or pt_load (if available) f4ce0706d9574aecb7d4aa9af7208a1bc9b6afb4 util_lib: Add functionality to read elf notes ** Also affects: kexec-tools (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: kexec-tools (Ubuntu Mantic) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status:
[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified
** Changed in: linux (Ubuntu Focal) Status: Incomplete => Won't Fix ** Changed in: kexec-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: kexec-tools (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: kexec-tools (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: kexec-tools (Ubuntu Jammy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: kexec-tools (Ubuntu Focal) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: kexec-tools (Ubuntu) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/2024479 Title: kdump fails on arm64 when offset is not specified Status in kexec-tools package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in kexec-tools source package in Focal: New Status in linux source package in Focal: Won't Fix Status in kexec-tools source package in Jammy: New Status in linux source package in Jammy: Incomplete Bug description: [Description] kdump fails on arm64, on machines with a lot of memory when offeset is not specified, e.g when /etc/default/grub.d/kdump-tools.cfg looks like: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G" If kdump-tools.cfg specifies the offset e.g.: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G" it works ok. The reason for this is that the kernel needs to allocate memory for the crashkernel both in low and high memory. This is addressed in kernel 6.2. In addition kexec-tools needs to support more than one crash kernel regions. To address this issue the following upstrem commits are needed: From the kernel side : commit a9ae89df737756d92f0e14873339cf393f7f7eb0 Author: Zhen Lei Date: Wed Nov 16 20:10:44 2022 +0800 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones commit a149cf00b158e1793a8dd89ca492379c366300d2 Author: Zhen Lei Date: Wed Nov 16 20:10:43 2022 +0800 arm64: kdump: Provide default size when crashkernel=Y,low is not specified From kexec-tools commit b5a34a20984c4ad27cc5054d9957af8130b42a50 Author: Chen Zhou Date: Mon Jan 10 18:20:08 2022 +0800 arm64: support more than one crash kernel regions Affected releases: Jammy, Focal, Bionic For Bionic we won't fix it as we need to backport a lot of code and the regression potential is too high. The same applies for the Focal 5.4 kernel. Only the 5.15 hwe focal kernel will be fixed. [Test] You need a machine (can be a VM too) with large memory e.g. 128G. Install linux-crashdump and trigger a crash. It won't work unless the offset is specified because the memory crashkernel cannot be allocated. With the patches applied it works as expected without having to specify the offset. [Regression Potential] [Other] Commits to backport JAMMY: kernel: a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions FOCAL: kernel (5.15 hwe kernel): a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size when crashkernel=Y,low is not specified 4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define defer_reserve_crashkernel() 8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash low memory if not needed 5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel description for arm64 944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X d339f1584f0acf32b32326627fa3b48e6e65c599 arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef kexec: b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash kernel regions 2572b8d702e452624bdb8d7b7c39f458e7dcf2ce arm64: kdump: deal with a lot of resource entries in /proc/iomem cf977b1af9ec67fabcc6a625589c49c52d07b11d kexec: add variant helper functions for handling memory regions f736104f533290b4ce6fbfbca74abde9ffd3888c arm64: kexec: allocate memory space avoiding
[Kernel-packages] [Bug 1964916] Re: [HP Omni 120-2110il AIO] Flickering white lines on screen
I installed Ubuntu 22.04.2 LTS (Jammy Jellyfish) with safe graphics mode. After installation open terminal and do the following (able to do despite the flikering): Sudo nano /etc/defaul/grub add nomodeset to GRUB_CMDLINE_LINUX_DEFAULT: GRUB_DEFAULT=0 GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=0 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset" GRUB_CMDLINE_LINUX="" Then save by hitting Ctrl+O enter, exit nano whit Ctrl+X Then run: sudo update-grub sudo reboot. Now lines do not appear but the screen is large Next still whit terminal. xrandr_ to see which Display is in use. (My was default) $cvt 1600 900 (At this point there were several bug reports, I didn't care) $cvt 1600 900 # 1600x900 59.95 Hz (CVT 1.44M9) hsync: 55.99 kHz; pclk: 118.25 MHz Modeline "1600x900_60.00" 118.25 1600 1696 1856 2112 900 903 908 934 -hsync +vsync $xrandr --newmode "1600x900_60.00" 118.25 1600 1696 1856 2112 900 903 908 934 -hsync +vsync $xrandr --addmode default "1600x900_60.00" $ xgamma -> Red 1.000, Green 1.000, Blue 1.000 (Just see the result) then $sudo nano /etc/default/grub find the line exsample: #GRUB_GFXMODE=1024x768 (maybe something else) edit 1024x786 to your resolution: 1600x900, remove the # example: GRUB_GFXMODE=1600x900 update by the command $sudo update-grub Then reboot your computer $sudo reboot This is what I done whit my HP Omni 120-1100eo Desktop PC -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1964916 Title: [HP Omni 120-2110il AIO] Flickering white lines on screen Status in linux-hwe-5.11 package in Ubuntu: Confirmed Bug description: https://www.youtube.com/watch?v=GcAXAicoZqY this is the video of my error i am having this issue on all versions of ubuntu-- i have tried installing versions 20.04, 18.04.06, 12.04.. i have intel pentium g630 processor with intel graphics 2000 (Vram-256M). I used Windows 10 on my PC but i thought of switching to ubuntu when this problem arose.. The glitch shows up on ubuntu splash screen and remains there until i restart my pc with nomodeset parameter...i have reinstalled windows 10 but i want this issue to get fixed.. i need to use ubuntu ...pls ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.11.0-27.29~20.04.1-generic 5.11.22 Uname: Linux 5.11.0-27-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Mar 15 14:59:57 2022 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company 2nd Generation Core Processor Family Integrated Graphics Controller [103c:2ac5] InstallationDate: Installed on 2022-03-05 (9 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) MachineType: Hewlett-Packard 120-2110il ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-27-generic root=UUID=54d1c05e-a544-4510-8da7-87e1a7242e0f ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/17/2011 dmi.bios.release: 4.6 dmi.bios.vendor: AMI dmi.bios.version: LEO_707 dmi.board.name: 2AC5 dmi.board.vendor: Quanta dmi.board.version: 101 dmi.chassis.asset.tag: 4CS2040B0F dmi.chassis.type: 3 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnAMI:bvrLEO_707:bd11/17/2011:br4.6:svnHewlett-Packard:pn120-2110il:pvr:rvnQuanta:rn2AC5:rvr101:cvnHewlett-Packard:ct3:cvr: dmi.product.family: 103C_53316J G=D dmi.product.name: 120-2110il dmi.product.sku: QF135AA#ACJ dmi.sys.vendor: Hewlett-Packard version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.105-3~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1964916/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help :
[Kernel-packages] [Bug 2006042] Re: [Asus ZenBook UX430UAR] Laptop often freezes after waking up from suspend to ram
Adding to my original report: it would seem using the laptop for a short while (a few minutes, about less than a hour most of the time) and then suspending to RAM greatly increases chances the issue will trigger. ** Description changed: Hi, After waking up from suspend to RAM, my computer actually wakes up but can sometimes then hang on a black screen (no prompt, nothing displayed, screen is active). This issue happens quite frequently but seems rather random. I think certain circumstances lower the frequency (I'll elaborate in the report). First of all, I'm not exactly sure when it started but I would say first notable frequent occurrences were around summer 2021 (yes, I'm late, sorry for that). - When this happens, Algr+SysRQ+[usb] is unresponsive. Or at least that's - what I used to believe as it used to be true as I always tried from the - laptop integrated keyboard. Until I connected an USB-C mechanical - keyboard, from which I'm *sometimes* able to use the magic keys (not - always, and with a lot of lag, but still). + When this happens, Algr+SysRQ+[usb] is unresponsive. + + -- EDIT -- + EDIT: This is actually not true. The laptop will eventually reboot by itself, and when this happens quickly enough after I have hit SysRq keys, it can be mistakenly taken for a working SysRq request. + + Or at least that's what I used to believe as it used to be true as I always tried from the laptop integrated keyboard. Until I connected an USB-C mechanical keyboard, from which I'm *sometimes* able to use the magic keys (not always, and with a lot of lag, but still). + -- EDIT -- If magic keys are unresponsive, I need to hard reset/long press power. There is nothing unusual before that in syslog nor kern.log, at least not that I know of. Except the ^@^@^@ characters when I had to hard reset the computer. If I leave the laptop like that for a while, it eventually reboots by itself and stays on the FDE passphrase prompt (which is not nice as the screen can then stay on for a very long like that if I did not notice). I'm running KDE/Plasma desktop, and this issue has happened regardless of the display manager. I used to run Xorg but now I'm on wayland flavor (mostly to alleviate firefox rendering/compositing issues). This also seems unrelated to external screen being connected or not, as it happened in the past regardless of that parameter. Although, it *seems* frequency has lowered a bit since I changed the way I wake up my laptop. Higher frequency (almost every day): - no external screen or external screen connected to HDMI port - waking up from integrated keyboard power button short press Lower frequency (one to multiple times a week, but somewhat irregular, since ~ 2 months ago): - external screen connected to USB-C port - mechanical keyboard connected to USB-C port of screen - waking up from the mechanical keyboard It also seems to happen more frequently if I wake up the computer, do some very fast task and send it to sleep in under a few minutes. It's not guaranteed to happen, but seems to highly increase the probability. Also, this might be related so I'm adding that bit: I had to disable shutting the screen Off in energy saving settings, as enabling that option would trigger a similar behavior after a break long enough for that setting to trigger. I would come back on a laptop having self-rebooted and waiting for my input on the FDE passphrase prompt. During ACPI options testing, I noticed that setting might cause the sleep order to get cancelled. From that, I suspect in that case the laptop would go to sleep, then wake up immediately, which could have been triggering the bug as I described previously that rapid state changes would increase probability. Then as I described earlier, if I do nothing when this happens, the computer eventually reboots. This is only speculation as I'm usually not here to observe the behavior (this mostly happened during lunch breaks, which are long enough for all of these steps to happen). I disabled screen turn-off energy saving option a long while ago and have taken the habit of manually suspending to RAM when I intend on going away from the computer for more than a few minutes. As I described above, I've tried a few changes to check for behavior but that was a few months ago and I don't clearly remember all scenario. What I remember is that changing any of these did not resolve my issue and some even prevented my computer to even suspend to RAM properly (waking up immediately after). Among the options I tried is: - booting with a previous kernel, but then it's been happening for so long this would obviously not work (just for the sake of completion) - booting on latest mainstream kernel (tested
[Kernel-packages] [Bug 1921536] Re: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch
> Can you elaborate on what you think Ubuntu should be doing differently? What do you think? I have not been able to use Ubuntu with external monitor for 3 weeks now! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1921536 Title: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch Status in linux package in Ubuntu: Confirmed Status in linux-restricted-modules package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-525 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-535 package in Ubuntu: Confirmed Bug description: If a user does not have the same version of binutils installed as the one used to produce the nvidia module signature, the module generated at postinst maybe unloadable: modprobe: ERROR: could not insert 'nvidia': Key was rejected by service I ran into this when I tried to install the hirsute kernel/nvidia driver on a focal system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921536/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1921536] Re: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch
What do you mean "different version of binutils"? I don't install these myself. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1921536 Title: "modprobe: ERROR: could not insert 'nvidia': Key was rejected by service" due to binutils mismatch Status in linux package in Ubuntu: Confirmed Status in linux-restricted-modules package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-525 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-535 package in Ubuntu: Confirmed Bug description: If a user does not have the same version of binutils installed as the one used to produce the nvidia module signature, the module generated at postinst maybe unloadable: modprobe: ERROR: could not insert 'nvidia': Key was rejected by service I ran into this when I tried to install the hirsute kernel/nvidia driver on a focal system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921536/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
