** Description changed: [ Impact ] Users connecting a Lenovo USB-C to VGA Adapter (or similar USB-C DP adapters with a FIXED_VS LTTPR retimer) get no display output. The AMD display driver fails DP link training and logs: - amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15 + amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15 The fix is a single-line change: - - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) - + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) + - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) + + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) The root cause is a typo in a C string literal used to check whether a FIXED_VS LTTPR retimer has no IEEE OUI. The literal "\x0,\x0,\x0" was intended to be three zero bytes but actually evaluates to five bytes {0x00, 0x2C, 0x00, 0x2C, 0x00} (0x2C = ASCII comma) because commas are not valid hex digits and terminate the \x escape early. The memcmp() against the 3-byte LTTPR OUI field therefore never matches, so the vendor-specific link rate toggle workaround required by these retimers is never applied, and link training fails. [ Test Plan ] 1. Connect a Lenovo USB-C to VGA Adapter to a system with an AMD GPU. 2. Without patch: confirm no display output and observe the following in dmesg: - amdgpu ...: [drm] enabling link N failed: 15 + amdgpu ...: [drm] enabling link N failed: 15 3. Install a new kernel with patch: confirm display output appears and the "enabling link failed: 15" - message is absent from dmesg. + message is absent from dmesg. [ Where problems could occur ] The change is confined to the FIXED_VS LTTPR link training path (dp_perform_fixed_vs_pe_training_sequence). It only affects systems where: - - An AMD GPU with USB-C DP output is present, AND - - A DP retimer (LTTPR) with no IEEE OUI is detected on the link. + - An AMD GPU with USB-C DP output is present, AND + - A DP retimer (LTTPR) with no IEEE OUI is detected on the link. The risk of regression is very low — the fix corrects a comparison that was always false before, restoring the originally intended behaviour. Systems without a FIXED_VS LTTPR retimer are completely unaffected. [ Other Info ] Upstream commit: 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 (v7.0-rc1) Stable backport: 91e6b6a7fe57d48c392d353ee50162a525d9e80c (v6.19.6) - Reported against: linux-oem-6.17 6.17.0-1025.25 + Affected kernel on noble and questing: + linux-oem-6.17 6.17.0-1025.25 + linux-image-generic-hwe-24.04 6.17.0-35.35~24.04.1 + Noble's hwe-24.04-edge and resolute is not affected. + linux-image-generic-hwe-24.04-edge 7.0.0-14.14~24.04.3 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155619 Title: [SRU] Correct FIXED_VS Link Rate Toggle Condition Status in linux package in Ubuntu: In Progress Bug description: [ Impact ] Users connecting a Lenovo USB-C to VGA Adapter (or similar USB-C DP adapters with a FIXED_VS LTTPR retimer) get no display output. The AMD display driver fails DP link training and logs: amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15 The fix is a single-line change: - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) The root cause is a typo in a C string literal used to check whether a FIXED_VS LTTPR retimer has no IEEE OUI. The literal "\x0,\x0,\x0" was intended to be three zero bytes but actually evaluates to five bytes {0x00, 0x2C, 0x00, 0x2C, 0x00} (0x2C = ASCII comma) because commas are not valid hex digits and terminate the \x escape early. The memcmp() against the 3-byte LTTPR OUI field therefore never matches, so the vendor-specific link rate toggle workaround required by these retimers is never applied, and link training fails. [ Test Plan ] 1. Connect a Lenovo USB-C to VGA Adapter to a system with an AMD GPU. 2. Without patch: confirm no display output and observe the following in dmesg: amdgpu ...: [drm] enabling link N failed: 15 3. Install a new kernel with patch: confirm display output appears and the "enabling link failed: 15" message is absent from dmesg. [ Where problems could occur ] The change is confined to the FIXED_VS LTTPR link training path (dp_perform_fixed_vs_pe_training_sequence). It only affects systems where: - An AMD GPU with USB-C DP output is present, AND - A DP retimer (LTTPR) with no IEEE OUI is detected on the link. The risk of regression is very low — the fix corrects a comparison that was always false before, restoring the originally intended behaviour. Systems without a FIXED_VS LTTPR retimer are completely unaffected. [ Other Info ] Upstream commit: 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 (v7.0-rc1) Stable backport: 91e6b6a7fe57d48c392d353ee50162a525d9e80c (v6.19.6) Affected kernel on noble and questing: linux-oem-6.17 6.17.0-1025.25 linux-image-generic-hwe-24.04 6.17.0-35.35~24.04.1 Noble's hwe-24.04-edge and resolute is not affected. linux-image-generic-hwe-24.04-edge 7.0.0-14.14~24.04.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155619/+subscriptions
четверг
[Bug 2155619] [NEW] [SRU] Correct FIXED_VS Link Rate Toggle Condition
Public bug reported: [ Impact ] Users connecting a Lenovo USB-C to VGA Adapter (or similar USB-C DP adapters with a FIXED_VS LTTPR retimer) get no display output. The AMD display driver fails DP link training and logs: amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15 The fix is a single-line change: - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) The root cause is a typo in a C string literal used to check whether a FIXED_VS LTTPR retimer has no IEEE OUI. The literal "\x0,\x0,\x0" was intended to be three zero bytes but actually evaluates to five bytes {0x00, 0x2C, 0x00, 0x2C, 0x00} (0x2C = ASCII comma) because commas are not valid hex digits and terminate the \x escape early. The memcmp() against the 3-byte LTTPR OUI field therefore never matches, so the vendor-specific link rate toggle workaround required by these retimers is never applied, and link training fails. [ Test Plan ] 1. Connect a Lenovo USB-C to VGA Adapter to a system with an AMD GPU. 2. Without patch: confirm no display output and observe the following in dmesg: amdgpu ...: [drm] enabling link N failed: 15 3. Install a new kernel with patch: confirm display output appears and the "enabling link failed: 15" message is absent from dmesg. [ Where problems could occur ] The change is confined to the FIXED_VS LTTPR link training path (dp_perform_fixed_vs_pe_training_sequence). It only affects systems where: - An AMD GPU with USB-C DP output is present, AND - A DP retimer (LTTPR) with no IEEE OUI is detected on the link. The risk of regression is very low — the fix corrects a comparison that was always false before, restoring the originally intended behaviour. Systems without a FIXED_VS LTTPR retimer are completely unaffected. [ Other Info ] Upstream commit: 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 (v7.0-rc1) Stable backport: 91e6b6a7fe57d48c392d353ee50162a525d9e80c (v6.19.6) Reported against: linux-oem-6.17 6.17.0-1025.25 ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Bin Li (binli) Status: In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155619 Title: [SRU] Correct FIXED_VS Link Rate Toggle Condition Status in linux package in Ubuntu: In Progress Bug description: [ Impact ] Users connecting a Lenovo USB-C to VGA Adapter (or similar USB-C DP adapters with a FIXED_VS LTTPR retimer) get no display output. The AMD display driver fails DP link training and logs: amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15 The fix is a single-line change: - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0], 3) == 0) The root cause is a typo in a C string literal used to check whether a FIXED_VS LTTPR retimer has no IEEE OUI. The literal "\x0,\x0,\x0" was intended to be three zero bytes but actually evaluates to five bytes {0x00, 0x2C, 0x00, 0x2C, 0x00} (0x2C = ASCII comma) because commas are not valid hex digits and terminate the \x escape early. The memcmp() against the 3-byte LTTPR OUI field therefore never matches, so the vendor-specific link rate toggle workaround required by these retimers is never applied, and link training fails. [ Test Plan ] 1. Connect a Lenovo USB-C to VGA Adapter to a system with an AMD GPU. 2. Without patch: confirm no display output and observe the following in dmesg: amdgpu ...: [drm] enabling link N failed: 15 3. Install a new kernel with patch: confirm display output appears and the "enabling link failed: 15" message is absent from dmesg. [ Where problems could occur ] The change is confined to the FIXED_VS LTTPR link training path (dp_perform_fixed_vs_pe_training_sequence). It only affects systems where: - An AMD GPU with USB-C DP output is present, AND - A DP retimer (LTTPR) with no IEEE OUI is detected on the link. The risk of regression is very low — the fix corrects a comparison that was always false before, restoring the originally intended behaviour. Systems without a FIXED_VS LTTPR retimer are completely unaffected. [ Other Info ] Upstream commit: 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 (v7.0-rc1) Stable backport: 91e6b6a7fe57d48c392d353ee50162a525d9e80c (v6.19.6) Reported against: linux-oem-6.17 6.17.0-1025.25 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155619/+subscriptions
[Bug 2155617] [NEW] Backlight device disappears and brightness breaks on kernel 6.17.0-23+ (Lenovo Legion 5 Pro, NVIDIA hybrid graphics)
Public bug reported: On Ubuntu 24.04.2 LTS running on a Lenovo Legion 5 Pro 16ACH6H (AMD + NVIDIA RTX 3070 hybrid system), brightness control breaks starting from kernel 6.17.0-23-generic and remains broken on all newer kernels up to 6.17.0-35. The issue is fully reproducible. WORKING KERNEL: - 6.17.0-22-generic - Display session: X11 - NVIDIA proprietary driver in use - Backlight device present: /sys/class/backlight/nvidia_0 - Brightness control works normally BROKEN KERNELS: - 6.17.0-23-generic and newer (tested up to 6.17.0-35) - Wayland or X11 both affected - Backlight directory is empty: /sys/class/backlight/ SYMPTOMS: - Brightness stuck at 100% - No backlight device exposed in sysfs - Mouse cursor shows trailing/ghosting artifacts on Wayland - Display rendering instability EXPECTED BEHAVIOR: - /sys/class/backlight/nvidia_0 should be present - Brightness control should function via NVIDIA DRM backlight interface ACTUAL BEHAVIOR: - No backlight device is registered at all in /sys/class/backlight/ - GNOME brightness controls have no effect HARDWARE: - Lenovo Legion 5 Pro 16ACH6H - AMD Ryzen CPU (iGPU present but not used for display in working kernel) - NVIDIA RTX 3070 Mobile (primary display output via nvidia-drm) - NVIDIA proprietary driver active REGRESSION: - Kernel 6.17.0-22 works correctly - 6.17.0-23 introduces regression and all newer kernels inherit it This appears to be a regression in NVIDIA DRM backlight device registration (fbdev / sysfs exposure). ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155617 Title: Backlight device disappears and brightness breaks on kernel 6.17.0-23+ (Lenovo Legion 5 Pro, NVIDIA hybrid graphics) Status in linux package in Ubuntu: New Bug description: On Ubuntu 24.04.2 LTS running on a Lenovo Legion 5 Pro 16ACH6H (AMD + NVIDIA RTX 3070 hybrid system), brightness control breaks starting from kernel 6.17.0-23-generic and remains broken on all newer kernels up to 6.17.0-35. The issue is fully reproducible. WORKING KERNEL: - 6.17.0-22-generic - Display session: X11 - NVIDIA proprietary driver in use - Backlight device present: /sys/class/backlight/nvidia_0 - Brightness control works normally BROKEN KERNELS: - 6.17.0-23-generic and newer (tested up to 6.17.0-35) - Wayland or X11 both affected - Backlight directory is empty: /sys/class/backlight/ SYMPTOMS: - Brightness stuck at 100% - No backlight device exposed in sysfs - Mouse cursor shows trailing/ghosting artifacts on Wayland - Display rendering instability EXPECTED BEHAVIOR: - /sys/class/backlight/nvidia_0 should be present - Brightness control should function via NVIDIA DRM backlight interface ACTUAL BEHAVIOR: - No backlight device is registered at all in /sys/class/backlight/ - GNOME brightness controls have no effect HARDWARE: - Lenovo Legion 5 Pro 16ACH6H - AMD Ryzen CPU (iGPU present but not used for display in working kernel) - NVIDIA RTX 3070 Mobile (primary display output via nvidia-drm) - NVIDIA proprietary driver active REGRESSION: - Kernel 6.17.0-22 works correctly - 6.17.0-23 introduces regression and all newer kernels inherit it This appears to be a regression in NVIDIA DRM backlight device registration (fbdev / sysfs exposure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155617/+subscriptions
[Bug 2150196] Re: [SRU] ASoC: enable rt1320 speaker amp and DMIC on PTL SoundWire platforms
Now 26.04 could be upgraded from 25.10. So I added the resolute repo in /etc/apt/sources, after that I installed the linux-generic-hwe-26.04 from resolute-proposed. Then the audio works beautifully. So the alsa- ucm-conf in questing works. I set the verification to done so that we wont' block the next release. $ do-release-upgrade -c Checking for a new Ubuntu release New release '26.04 LTS' available. Run 'do-release-upgrade' to upgrade to it. $ cat /etc/apt/sources.list.d/ubuntu.sources Types: deb URIs: http://archive.ubuntu.com/ubuntu/ Suites: questing questing-updates questing-backports questing-proposed Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb URIs: http://security.ubuntu.com/ubuntu/ Suites: questing-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb URIs: http://archive.ubuntu.com/ubuntu/ Suites: resolute resolute-updates resolute-backports resolute-proposed Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg ** Tags removed: verification-needed-questing ** Tags added: verification-done-questing -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150196 Title: [SRU] ASoC: enable rt1320 speaker amp and DMIC on PTL SoundWire platforms Status in HWE Next: In Progress Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Committed Status in linux-oem-6.17 package in Ubuntu: Invalid Status in alsa-ucm-conf source package in Noble: Fix Committed Status in linux source package in Noble: Won't Fix Status in linux-oem-6.17 source package in Noble: Fix Released Status in alsa-ucm-conf source package in Questing: Fix Committed Status in linux source package in Questing: New Status in linux-oem-6.17 source package in Questing: New Status in alsa-ucm-conf source package in Resolute: Fix Committed Status in linux source package in Resolute: Fix Committed Status in linux-oem-6.17 source package in Resolute: Invalid Status in alsa-ucm-conf source package in Stonking: Fix Released Status in linux source package in Stonking: Fix Committed Status in linux-oem-6.17 source package in Stonking: Invalid Bug description: SRU Justification: [ Impact ] Lenovo PTL systems with rt722 headset codec + rt1320 speaker amp over SoundWire have no speaker audio and no DMIC. The kernel's PTL match table lacks the rt722_l0_rt1320_l23 topology, the rt1320 codec_info_list is missing its DMIC dai, and the is_amp flag is absent -- so the machine driver never matches and the wrong name prefix is assigned. [ Fix ] Seven upstream commits from Linus's mainline, applied in topological order: 1. 38ecd1384079 (v6.19) -- add ptl_rt722_l0_rt1320_l23 match table entry 2. 4fbd3b2ec04d (v7.0) -- use aggregated endpoints for rt722 in that entry 3. 403a0591be68 (v6.19) -- fix name_prefix of second rt1320 (rt1320-2) 4. 754b3dade5dd (v7.0) -- drop rt721 monolithic match tables (prerequisite for 5) 5. 9033f7b7f27d (linux/master, not yet tagged) -- drop rt722 monolithic match tables 6. dd4a1963ddf0 (linux/master, not yet tagged) -- add is_amp flag to fix wrong name prefix 7. ae2cb3384337 (linux/master, not yet tagged) -- add rt1320/rt1321 DMIC dai in codec_info_list All cherry-pick cleanly with zero conflicts. Diffs are byte-identical to upstream (only hunk offsets and context lines differ due to different base tree). [ Test Plan ] On a Lenovo PTL system with spk:rt1320 + hs:rt722: 1. Boot without patches: no speaker sound card components, no DMIC 2. Boot with patches: - Speaker playback: aplay -D hw:0,2 tone.wav - DMIC loopback: play 1kHz tone through speaker, record from DMIC, FFT confirms peak at 1000 Hz - WirePlumber sees all devices - Mute LEDs functional (speaker and mic) - Suspend/resume: full status diff pre vs post identical, loopback and LEDs work after resume [ Where problems could occur ] Patches touch PTL match tables, SoundWire codec_info_list, and SOF HDA codec matching. A wrong match table entry could cause a different PTL topology to break (wrong codec matched). The is_amp flag override in find_acpi_adr_device() runs for all SoundWire codecs on Intel SOF platforms -- if the flag logic is wrong, non-amp codecs could get misidentified, breaking name prefixes and DAI routing. Commits 4-5 remove rt721/rt722 monolithic match tables; any PTL machine still relying on monolithic matching (rather than function topologies) would lose its match entry. [ Other Info ] Commits 5-7 are merged on linux/master but not yet in a tagged release. Tested on two Lenovo PTL machines -- full audio pass including loopback and suspend/resume. Target: oem-6.17 and resolute only. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2150196/+subscriptions
[Bug 2155120] Re: Fix audio mute function not working on new Dell platforms
** Changed in: linux (Ubuntu Resolute) Status: New => Fix Released ** Changed in: linux (Ubuntu Noble) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155120 Title: Fix audio mute function not working on new Dell platforms Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in linux source package in Resolute: Fix Released Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] Microphone mute hotkey(F4) have no function on Dell Sunfire powered by the AMD platform [Fix] Fix by backporting the commit: 26a7601471f6 ("platform/x86: dell-wmi: Add audio/mic mute key codes") by adding the corresponding key code for mute and mic mute. [Test Case] 1. Boot up the machine of new Dell Sunfire platforms 2. Press Fn+F4 to verify the mic-mute function. 3. Make sure the mic is muted by `arecord` [Where problems could occur] It only adds the key codes for the mic-mute and mute on some Dell platforms. The risk of regression is limited. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2155120/+subscriptions
[Bug 2155222] Re: [hyperv] Ensure MMIO Mapping is Correct for Kexec / kdump kernel on Azure v6 Instance Types
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155222 Title: [hyperv] Ensure MMIO Mapping is Correct for Kexec / kdump kernel on Azure v6 Instance Types Status in linux package in Ubuntu: Fix Committed Status in linux source package in Jammy: In Progress Status in linux source package in Noble: In Progress Status in linux source package in Questing: In Progress Status in linux source package in Resolute: In Progress Bug description: BugLink: https://bugs.launchpad.net/bugs/2155222 [Impact] Jammy VMs running on "Gen2" v6 instance types on Azure fail to collect a kdump with both the 5.15 and 6.8 HWE kernel, yet kdump succeeds for 6.8 onward on noble onward. Even stranger, it succeeds on jammy with secureboot enabled, and fails with secureboot disabled. The difference between jammy and noble onward can be explained with userspace tools, as kdump-tools uses -c (--kexec-syscall) by default, and changes to -s (--kexec-file-syscall) when secureboot is enabled. Noble onward works due to using -a (--kexec-syscall-auto) by default, which defaults to -s. Noble will fail when using -c instead. From man kexec: -s (--kexec-file-syscall) Specify that the new KEXEC_FILE_LOAD syscall should be used exclusively. -c (--kexec-syscall) Specify that the old KEXEC_LOAD syscall should be used exclusively (the default). -a (--kexec-syscall-auto) Try the new KEXEC_FILE_LOAD syscall first and when it is not supported or the kernel does not understand the supplied image fall back to the old KEXEC_LOAD interface. There is no one single interface that always works. KEXEC_FILE_LOAD is required on systems that use locked-down secure boot to verify the kernel signature. KEXEC_LOAD may be also disabled in the kernel configuration. KEXEC_LOAD is required for some kernel image formats and on architectures that do not implement KEXEC_FILE_LOAD. Regardless, the issue is actually a hyperv subsystem issue in the kernel. When the kexec / kdump kernel boots, vmbus_reserve_fb() fails to reserve the framebuffer MMIO range due to a Gen2 VM's screen.lfb_base being zero. This causes a MMIO conflict between hyperv-drm and pci-hyperv: when the pci-hyperv's hv_allocate_config_window() calls vmbus_allocate_mmio() to get an MMIO range, it usually gets a 32-bit MMIO range that overlaps with the framebuffer MMIO range, and later hv_pci_enter_d0() fails with an error message "PCI Pass-through VSP failed D0 Entry with status" since the host thinks that PCI devices must not use MMIO space that the host has assigned to the framebuffer. This is especially an issue if pci-hyperv is built-in and hyperv-drm is built as a module. Consequently, the kdump/kexec kernel fails to detect PCI devices via pci-hyperv, and may fail to mount the root file system, which may reside in a NVMe disk. The end result is that capturing kdumps fail when -c (--kexec-syscall) is used, which is the default on jammy. [Fix] This is currently queued up in the hyperv maintainer tree, in the hyperv-fixes branch: commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 hyperv From: Dexuan Cui <decui@microsoft.com> Date: Thu, 7 May 2026 14:28:38 -0700 Subject: Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs Link: https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/commit/?h=hyperv-fixes&id=016a25e4b0df4d77e7c258edee4aaf982e4ee809 This is expected to make the 7.2 merge window. This fix is required for hyperv users, and is mostly relevant for -azure users only, but I am still requesting this for -generic to ensure that anyone using -generic on Azure can still kexec, and to make it easier to bisect -generic on Azure in the future. [Testcase] This needs to be tested on Azure on both v5 and v6 instance types. The issue occurs with v6 instance types, but we need to ensure we do not cause a regression with v5 instance types. For each series you are testing, create a VM with the following instance types: - Standard_D4ads_v5 - Standard_D4ads_v6 For the image type, you need to select "Gen2" images: - "Ubuntu Server 22.04 LTS - x64 Gen2" - "Ubuntu Server 24.04 LTS - x64 Gen2" - "Ubuntu Server 25.10 - x64 Gen 2" - "Ubuntu Server 26.04 LTS - x64 Gen 2" If you are going to test with -c (--kexec-syscall), secureboot needs to be disabled, and you can do this with: - Under Security type, select "Configure security features" - uncheck "Enable Secure Boot". Save. Create the VM. Log in, and install kdump-tools: $ sudo apt update $ sudo apt install kdump-tools Say yes to each prompt. $ sudo vim /etc/default/grub.d/kdump-tools.cfg Change crashkernel=512M-:192M from 192M to 1G, save, exit. $ sudo vim /etc/kernel/postinst.d/kdump-tools Change dep to most, save exit. $ sudo update-grub $ sudo reboot Verify that the cmdline has crashkernel set to 1G memory: $ cat /proc/cmdline $ kdump-config show On the Azure Web Interface, select "Serial Console" for the VM, and watch the serial console. $ sudo sysctl -w kernel.sysrq=1 $ sudo su $ echo c > /proc/sysrq-trigger Watch the kernel panic and reboot into the crash kernel. On failure: The kexec kernel gets stuck, and writes these messages to dmesg. [ 1.157729] hv_pci 7ad35d50-c05b-47ab-b3a0-56a9a845852b: PCI VMBus probing: Using version 0x10004 [ 1.167427] hv_pci 7ad35d50-c05b-47ab-b3a0-56a9a845852b: Retrying D0 Entry [ 1.173231] hv_pci 7ad35d50-c05b-47ab-b3a0-56a9a845852b: PCI Pass-through VSP failed D0 Entry with status c000000d [ 1.181091] hv_vmbus: probe failed for device 7ad35d50-c05b-47ab-b3a0-56a9a845852b (-71) [ 1.186890] hv_pci: probe of 7ad35d50-c05b-47ab-b3a0-56a9a845852b failed with error -71 [ 1.194422] hv_pci 00000001-7870-47b5-b203-907d12ca697e: PCI VMBus probing: Using version 0x10004 [ 1.202172] hv_pci 00000001-7870-47b5-b203-907d12ca697e: Retrying D0 Entry [ 1.207877] hv_pci 00000001-7870-47b5-b203-907d12ca697e: PCI Pass-through VSP failed D0 Entry with status c000000d The kexec kernel gives up, and reboots. No kdump is generated. /var/crash will be empty. On success: The kdump is collected, and saved to /var/crash, and will be present on next boot. There are test kernels available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf425760-test If you install the test kernel and reboot, kdump will work correctly on v6 instance types. [Where problems could occur] This changes how vmbus_reserve_fb() reserves MMIO space for the framebuffer, and if a regression were to occur, it could affect the pci-hyperv and hyperv-drm drivers from being able to claim the correct MMIO ranges. This could show as instances failing to start or failing to kexec / collect a kdump with the crashkernel. This fix works both on amd64 and arm64 instance types, as well as with 32bit and 64bit pci busses. [Other info] Upstream mailing list threads: Abandoned Patch: V1: https://lore.kernel.org/linux-hyperv/20260122020337.94967-1-decui@microsoft.com/ V2: https://lore.kernel.org/linux-hyperv/20260402234313.2490779-1-decui@microsoft.com/ Current Patch: V1: https://lore.kernel.org/linux-hyperv/20260416183529.838321-1-decui@microsoft.com/ V2: https://lore.kernel.org/linux-hyperv/20260505004846.193441-1-decui@microsoft.com/ V3: https://lore.kernel.org/linux-hyperv/20260507212838.448891-1-decui@microsoft.com/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155222/+subscriptions
[Bug 2155492] Re: [resolute] Fix bug in VPE collaborate mode on Strix Halo
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155492 Title: [resolute] Fix bug in VPE collaborate mode on Strix Halo Status in linux package in Ubuntu: Fix Released Status in linux source package in Resolute: Triaged Bug description: [Impact] Strix Halo has two VPE IP blocks. Mesa has the capability to utilize both blocks in tandem in something called "Collaborate Mode". Newer versions of Mesa will utilize VPE as part of the hardware decode pipeline (for example for scaling). There are reports that Mesa 26.0.5 can expose a race condition with VPE collaborate mode and power gating that could lead to a system hang. Resolute has mesa 26.0.3, but there is a separate SRU to backport 26.0.8 to resolute for 26.04.1, and backported to noble for 24.04.5. Furthermore as mesa is contained within snaps it's plausible that an uprev in a snap can expose it too. There is a workaround for this that forces a SYNC command before power gating that avoids the issue. https://github.com/torvalds/linux/commit/b6074630a461b1322a814988779005cbc43612ea This is needed in resolute 7.0 and backported to noble as hwe-7.0. [Test case] TBF [Where things could go wrong] If the mesa update lands first, affected systems can suffer from hangs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155492/+subscriptions
среда
[Bug 2155161] Re: Jabra Evolve 2 85 headset keeps reconnecting via usb
Hi Alexander, Could you please try the following command? It may help us identify the issue. After running it and reboot, please check whether the issue is gone. ``` echo "options snd-usb-audio quirk_alias=0b0e24ca:0b0e0349,0b0e24ba:0b0e0349" | \ sudo tee /etc/modprobe.d/jabra-fix.conf ``` Thanks BR An ** Changed in: linux (Ubuntu) Assignee: (unassigned) => ChunAnWu (kiya956) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155161 Title: Jabra Evolve 2 85 headset keeps reconnecting via usb Status in linux package in Ubuntu: New Bug description: As soon as i want to use any kind of usb connection with the headset the usb connects and reconnects over and over again. I made sure its not an issue of cable used or the usb hub in the docking station. by connecting it directly to the laptop. Although i could use usb with this headset on ubuntu lts 24 without any issues since i reinstalled with kubuntu 26 this occurs (guess it would happen in ubuntu 26 too) I gladly provide more info if needed. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-22-generic 7.0.0-22.22 ProcVersionSignature: Ubuntu 7.0.0-22.22-generic 7.0.0 Uname: Linux 7.0.0-22-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Wed Jun 3 16:10:16 2026 InstallationDate: Installed on 2026-05-12 (22 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) IwDevWlp0s20f3Link: Not connected. MachineType: Dell Inc. Precision 3581 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=UUID=e1d7f812-2942-4efe-80f9-510636bb0378 ro quiet cryptdevice=UUID=24e90ca6-128d-41d3-be29-328e50acf97d:luks-24e90ca6-128d-41d3-be29-328e50acf97d root=/dev/mapper/luks-24e90ca6-128d-41d3-be29-328e50acf97d splash nvidia-drm.modeset=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/12/2025 dmi.bios.release: 1.27 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.27.1 dmi.board.name: 0V8YXF dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.ec.firmware.release: 1.25 dmi.modalias: dmi:bvnDellInc.:bvr1.27.1:bd12/12/2025:br1.27:efr1.25:svnDellInc.:pnPrecision3581:pvr:rvnDellInc.:rn0V8YXF:rvrA00:cvnDellInc.:ct10:cvr:sku0C07:pfaPrecision: dmi.product.family: Precision dmi.product.name: Precision 3581 dmi.product.sku: 0C07 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155161/+subscriptions
[Bug 2148534] Re: [Ubuntu 26.04] Failed install OS onto JBOD disk on B540d-2HS M.2 controller
this commit exists in the following ubuntu kernel tags. $ g tag --contains 9b8b84879d4ad Ubuntu-6.17.0-2.2 .... Ubuntu-7.0.0-10.10 Ubuntu-7.0.0-11.11 Ubuntu-7.0.0-12.12 Ubuntu-7.0.0-13.13 Ubuntu-7.0.0-14.14 Ubuntu-7.0.0-15.15 Ubuntu-7.0.0-16.16 Ubuntu-7.0.0-17.17 Ubuntu-7.0.0-18.18 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148534 Title: [Ubuntu 26.04] Failed install OS onto JBOD disk on B540d-2HS M.2 controller Status in linux package in Ubuntu: Confirmed Status in linux source package in Resolute: Confirmed Bug description: The system hangs during storage initialization when using a B540 RAID Kit with a single Micron 7450 Pro NVMe SSD configured in JBOD mode. Environment: Hardware: Lenovo ThinkSystem SR650 V4 Controller: B540d-2HS M.2 controller Disk: ThinkSystem M.2 7450 PRO 960GB Read Intensive NVMe PCIe 4.0 x4 NHS SSD Kernel (broken): 7.0.0-13-generic (Ubuntu) Kernel (working): 6.8.x (Ubuntu 24.04 LTS) Reproduce steps: 1. Set the B540 RAID controller to allow JBOD or configure the Micron 7450P as a JBOD drive. 2. Start Ubuntu 26.04 installation. 3. The installer/kernel attempts to scan scsi0. 4. The driver hangs at "waiting for commands" and eventually triggers a firmware reset loop. The megaraid_sas driver reports multiple command timeouts followed by a controller firmware crash. Even though the logs show Secure JBOD support-: Yes and NVMe passthru support-: Yes, It seems like kernel oops in megasas_make_prp_nvme due to a page fault on an unmapped virtual address while building the NVMe, which can be refered in logs below with Call Trace. [ 271.793726] #PF: supervisor write access in kernel mode [ 271.794694] #PF: error_code(0x0002) - not-present page [ 271.795648] PGD 100000067 P4D 101b42067 PUD 101b43067 PMD 10219a067 PTE 0 [ 271.796887] Oops: Oops: 0002 [#1] SMP NOPTI [ 271.797675] CPU: 1 UID: 0 PID: 1905 Comm: kworker/u1025:3 Tainted: P S O 7.0.0-13-generic #13-Ubuntu PREEMPT(lazy) [ 271.799778] Tainted: [P]=PROPRIETARY_MODULE, [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE [ 271.801123] Hardware name: Lenovo ThinkSystem SR650 V4/SB27B70076, BIOS IHE111A-1.21 03/28/2025 [ 271.801140] sd 0:0:2:0: [sda] tag#244 page boundary ptr_sgl: 0x0000000040507511 [ 271.802682] Workqueue: writeback wb_workfn [ 271.802733] sd 0:0:2:0: [sda] tag#245 page boundary ptr_sgl: 0x000000004c4d3310 [ 271.806138] (flush-8:0) [ 271.806643] RIP: 0010:megasas_make_prp_nvme.isra.0+0x12f/0x220 [megaraid_sas] [ 271.807955] Code: 20 49 83 c7 20 48 89 d1 48 83 e1 fc 83 e2 01 4c 0f 45 f9 49 8b 5f 10 45 8b 67 18 4c 89 e9 4c 8d 69 08 45 85 eb 74 52 45 29 ce <48> 89 19 83 c0 01 45 85 f6 7f af 4c 8b 7d c8 c1 e0 03 b9 01 00 00 [ 271.811246] RSP: 0018:ff50bfb988f8b298 EFLAGS: 00010206 [ 271.812215] RAX: 0000000000000200 RBX: 00000000f6a00000 RCX: ff50bfb983b9a000 [ 271.813520] RDX: ff50bfb983b9a008 RSI: 0000000000000000 RDI: 0000000000000000 [ 271.814822] RBP: ff50bfb988f8b2f8 R08: 00000000ffbb0000 R09: 0000000000001000 [ 271.816365] R10: 0000000000001000 R11: 0000000000000fff R12: 0000000000200000 [ 271.817860] R13: ff50bfb983b9a008 R14: 00000000001ff000 R15: ff2b1ee1e1f2cb08 [ 271.819321] FS: 0000000000000000(0000) GS:ff2b1ee542880000(0000) knlGS:0000000000000000 [ 271.820923] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 271.822134] CR2: ff50bfb983b9a000 CR3: 0000060144844004 CR4: 0000000000f73ef0 [ 271.823587] PKRU: 55555554 [ 271.824274] Call Trace: [ 271.824920] <TASK> [ 271.825514] megasas_build_io_fusion+0x2e2/0x330 [megaraid_sas] [ 271.826772] megasas_build_and_issue_cmd_fusion+0xa3/0x280 [megaraid_sas] [ 271.828168] ? sd_init_command+0x138/0x4a0 [ 271.829110] megasas_queue_command+0x11b/0x200 [megaraid_sas] [ 271.830347] ? scsi_init_command+0x74/0xc0 [ 271.831291] ? __rq_qos_issue+0x29/0x50 [ 271.832199] scsi_dispatch_cmd+0x95/0x290 [ 271.833129] scsi_queue_rq+0x62e/0x8e0 [ 271.834017] blk_mq_dispatch_rq_list+0x131/0x510 [ 271.835064] __blk_mq_do_dispatch_sched+0x2d9/0x360 [ 271.836154] ? mod_memcg_lruvec_state+0x101/0x2f0 [ 271.837206] __blk_mq_sched_dispatch_requests+0x157/0x1a0 [ 271.838369] ? elv_rb_add+0x70/0x90 [ 271.839210] blk_mq_sched_dispatch_requests+0x2d/0x80 [ 271.840316] blk_mq_run_hw_queue+0x2c0/0x330 [ 271.841295] blk_mq_dispatch_list+0x159/0x350 [ 271.842319] blk_mq_flush_plug_list+0x59/0x1e0 [ 271.843328] blk_add_rq_to_plug+0xe7/0x220 [ 271.844262] ? blk_account_io_start+0xd2/0x210 [ 271.845258] blk_mq_submit_bio+0x677/0x920 [ 271.846182] __submit_bio+0xad/0x250 [ 271.847022] submit_bio_noacct_nocheck+0x102/0x1d0 [ 271.848068] submit_bio_noacct+0x131/0x430 [ 271.848982] submit_bio+0xb3/0x110 [ 271.849782] ext4_io_submit+0x40/0x70 [ 271.850624] ext4_do_writepages+0x60a/0x970 [ 271.851546] ? psi_group_change+0x195/0x460 [ 271.852466] ext4_writepages+0xc8/0x1b0 [ 271.853325] ? ext4_writepages+0xc8/0x1b0 [ 271.854209] do_writepages+0xcb/0x180 [ 271.855038] ? write_inode+0x78/0x150 [ 271.855863] __writeback_single_inode+0x45/0x270 [ 271.856852] ? wbc_detach_inode+0x115/0x2c0 [ 271.857756] writeback_sb_inodes+0x25e/0x5e0 [ 271.858685] __writeback_inodes_wb+0x54/0x100 [ 271.859621] ? queue_io+0x13b/0x150 [ 271.860416] wb_writeback+0x2e0/0x370 [ 271.861223] wb_workfn+0x39e/0x470 [ 271.861987] process_one_work+0x1ac/0x3d0 [ 271.862851] worker_thread+0x1b8/0x360 [ 271.863671] ? __pfx_worker_thread+0x10/0x10 [ 271.864586] kthread+0xf7/0x130 [ 271.865304] ? __pfx_kthread+0x10/0x10 [ 271.866118] ret_from_fork+0x195/0x2a0 [ 271.866934] ? __pfx_kthread+0x10/0x10 [ 271.867743] ? __pfx_kthread+0x10/0x10 [ 271.868551] ret_from_fork_asm+0x1a/0x30 [ 271.869394] </TASK> To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148534/+subscriptions
[Bug 2153412] Re: Boot failure in 24.04.4 LTS after 6.8.0-117-generic upgrade
** Changed in: linux (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153412 Title: Boot failure in 24.04.4 LTS after 6.8.0-117-generic upgrade Status in linux package in Ubuntu: Fix Committed Bug description: Failure to boot system with three monitors and NVIDIA driver. Freezes at black screen or screen with Ubuntu text. Diagnostics (ChatGPT assisted) included this conclusion: +++Diagnostic+++ The failed boot’s journal simply stops abruptly at 09:25:12, while systemd is still in very early boot, just after starting Plymouth and flushing the journal to disk. There is no later evidence of reaching normal multi-user startup, let alone GDM. That makes this look like a hard freeze during early boot: The NVIDIA 470 modules do load. The machine then continues briefly through early device and systemd initialization. Logging stops suddenly before the display manager starts. (A separate user with Ubuntu 24.04.4, kernel 6.8.0-117, and an older NVIDIA GT 710 reports a strikingly similar failure, with 6.8.0-111 still working.) Kernel 6.8.0-117 is likely triggering a low-level regression on older NVIDIA 470-series systems, causing a freeze during early graphics- related boot initialization. ++++++++++summary+++++++++++++ Regression: 6.8.0-111-generic boots; 6.8.0-117-generic hard-freezes. GPU/driver: GeForce GT 730 GK208B, nvidia-driver-470 470.256.02. Symptoms: DP screens black/frozen splash, DVI screen multicolored stripes. Logs: NVIDIA module loads successfully; journal stops abruptly during early boot before GDM. Topology test: unplugging DVI or DisplayPort did not change the failure. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-111-generic 6.8.0-111.111 ProcVersionSignature: Ubuntu 6.8.0-111.111-generic 6.8.12 Uname: Linux 6.8.0-111-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: rae 3431 F.... wireplumber /dev/snd/controlC0: rae 3431 F.... wireplumber /dev/snd/controlC1: rae 3431 F.... wireplumber /dev/snd/seq: rae 3429 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed May 20 12:08:11 2026 InstallationDate: Installed on 2019-11-08 (2385 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) IwConfig: lo no wireless extensions. eno1 no wireless extensions. MachineType: HP HP EliteDesk 800 G5 TWR ProcFB: 0 simpledrmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-111-generic root=UUID=f85bdd6e-e36e-4cc1-a8a1-0063ccb67b0d ro quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-6.8.0-111-generic N/A linux-backports-modules-6.8.0-111-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/28/2021 dmi.bios.release: 12.0 dmi.bios.vendor: HP dmi.bios.version: R01 Ver. 02.12.00 dmi.board.name: 8591 dmi.board.vendor: HP dmi.board.version: KBC Version 08.98.00 dmi.chassis.asset.tag: CZC939FL6Q dmi.chassis.type: 3 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.152 dmi.modalias: dmi:bvnHP:bvrR01Ver.02.12.00:bd12/28/2021:br12.0:efr8.152:svnHP:pnHPEliteDesk800G5TWR:pvr:rvnHP:rn8591:rvrKBCVersion08.98.00:cvnHP:ct3:cvr:sku6BD61AV: dmi.product.family: 103C_53307F HP EliteDesk dmi.product.name: HP EliteDesk 800 G5 TWR dmi.product.sku: 6BD61AV dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153412/+subscriptions
[Bug 2149766] Re: Linux kernel 6.17.0-22.22 breaks amdxdna
This bug is awaiting verification that the linux-xilinx/6.8.0-1030.31 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-xilinx' to 'verification-done- noble-linux-xilinx'. If the problem still exists, change the tag 'verification-needed-noble-linux-xilinx' to 'verification-failed-noble- linux-xilinx'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-xilinx-v2 verification-needed-noble-linux-xilinx -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2149766 Title: Linux kernel 6.17.0-22.22 breaks amdxdna Status in linux package in Ubuntu: Fix Committed Status in linux-hwe-6.17 package in Ubuntu: Confirmed Status in linux-oem-6.17 package in Ubuntu: Confirmed Status in linux source package in Noble: Fix Released Status in linux-hwe-6.17 source package in Noble: Fix Released Status in linux-oem-6.17 source package in Noble: Fix Released Status in linux source package in Questing: Fix Released Status in linux-hwe-6.17 source package in Questing: Invalid Status in linux-oem-6.17 source package in Questing: Invalid Bug description: The kernel update causes amdxdna to no longer load. [ 30.859857] amdxdna 0000:c7:00.1: [drm] *ERROR* amdxdna_drm_open: SVA bind device failed, ret -95 It works fine on 6.17.0-20. This is caused by this stable update: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142250 Specifically this commit: " iommu: disable SVA when CONFIG_X86 is set" It was also reported in 6.18.y upstream. https://lore.kernel.org/stable/870872aa-28e9-412a-bac6-8020bf560e4f@amd.com/ These commits are needed to fix it. commit 27bfafac65d8 ("mm: add a ptdesc flag to mark kernel page tables") commit 977870522af3 ("mm: actually mark kernel page table pages") commit 412d000346ea ("x86/mm: use 'ptdesc' when freeing PMD pages") commit 018942956723 ("mm: introduce pure page table freeing function") commit bf9e4e30f353 ("x86/mm: use pagetable_free()") commit 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2149766/+subscriptions
[Bug 2155198] Re: Jammy update: v5.15.201 upstream stable release
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155198 Title: Jammy update: v5.15.201 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: In Progress Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.15.201 upstream stable release from git://git.kernel.org/ crypto: octeontx - Fix length check to avoid truncation in ucode_load_store crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly crypto: virtio - Add spinlock protection with virtqueue notification nilfs2: Fix potential block overflow that cause system hang scsi: qla2xxx: Validate sp before freeing associated memory scsi: qla2xxx: Delay module unload while fabric scan in progress scsi: qla2xxx: Query FW again before proceeding with login gpio: omap: do not register driver in probe() ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xU gpio: sprd: Change sprd_gpio lock to raw_spin_lock romfs: check sb_set_blocksize() return value drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used platform/x86: classmate-laptop: Add missing NULL pointer checks platform/x86: panasonic-laptop: Fix sysfs group leak in error path gpiolib: acpi: Fix gpio count with string references Revert "wireguard: device: enable threaded NAPI" btrfs: fix racy bitfield write in btrfs_clear_space_info_full() net: dsa: free routing table on probe failure selftests: mptcp: pm: ensure unknown flags are ignored mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() crypto: virtio - Remove duplicated virtqueue_kick in virtio_crypto_skcipher_crypt_req smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() bus: fsl-mc: Replace snprintf and sprintf with sysfs_emit in sysfs show functions bus: fsl-mc: fix use-after-free in driver_override_show() scsi: qla2xxx: Fix bsg_done() causing double free scsi: qla2xxx: Use named initializers for port_[d]state_str scsi: qla2xxx: Remove dead code (GNN ID) scsi: qla2xxx: Reduce fabric scan duplicate code scsi: qla2xxx: Free sp in error path to fix system crash PCI: endpoint: Automatically create a function specific attributes group PCI: endpoint: Remove unused field in struct pci_epf_group PCI: endpoint: Avoid creating sub-groups asynchronously fbdev: rivafb: fix divide error in nv3_arb() fbdev: smscufx: properly copy ioctl memory to kernelspace f2fs: fix to avoid UAF in f2fs_write_end_io() f2fs: fix out-of-bounds access in sysfs attribute read/write USB: serial: option: add Telit FN920C04 RNDIS compositions Linux 5.15.201 UBUNTU: Upstream stable to v5.15.201 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155198/+subscriptions
[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-ibm-6.8/6.8.0-1058.59~22.04.1)
All autopkgtests for the newly accepted linux-restricted-modules-ibm-6.8 (6.8.0-1058.59~22.04.1) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-470-server/470.256.02-0ubuntu0.22.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules-ibm-6.8 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions