[Bug 2155222] Re: [hyperv] Ensure MMIO Mapping is Correct for Kexec / kdump kernel on Azure v6 Instance Types

** Description changed: 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] The fix landed in 7.2-rc1: commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 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/torvalds/linux.git/commit/?id=016a25e4b0df4d77e7c258edee4aaf982e4ee809 - Jammy also needs the following dependency: + This fix is required for hyperv users, and is mostly relevant for -azure users + only, so we will only target linux-azure for this fix. - commit 2a8a8afba0c3053d0ea8686182f6b2104293037e - Author: Vitaly Kuznetsov <vkuznets@redhat.com> - Date: Sat Aug 27 15:03:44 2022 +0200 - Subject: Drivers: hv: Always reserve framebuffer region for Gen1 VMs - Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a8a8afba0c3053d0ea8686182f6b2104293037e - - 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. + Note: -generic does not boot on Azure as-is without changes, so there are likely + no -generic users on Azure. [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/ ** No longer affects: linux (Ubuntu) ** No longer affects: linux (Ubuntu Jammy) ** No longer affects: linux (Ubuntu Noble) ** No longer affects: linux (Ubuntu Questing) ** No longer affects: linux (Ubuntu Resolute) -- 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-azure package in Ubuntu: Fix Released Status in linux-azure source package in Jammy: In Progress Status in linux-azure source package in Noble: In Progress Status in linux-azure source package in Questing: In Progress Status in linux-azure 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] The fix landed in 7.2-rc1: commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 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/torvalds/linux.git/commit/?id=016a25e4b0df4d77e7c258edee4aaf982e4ee809 This fix is required for hyperv users, and is mostly relevant for -azure users only, so we will only target linux-azure for this fix. Note: -generic does not boot on Azure as-is without changes, so there are likely no -generic users on Azure. [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-azure/+bug/2155222/+subscriptions

[Bug 2154418] Re: Backport ASoC SDCA, AMD SoundWire, and RT722 audio fixes

On Thinkpad platform, the speaker is 'Dummy' and no mic device, after updating the packages from noble-proposed, sound card probes successfully, the speaker and mic works fine, the led and function of speaker mute and mic mute also works. $ amixer -c1 info Card sysdefault:1 'amdsoundwire'/'LENOVO-21YXZDW0US-ThinkPadT14sGen7' Mixer name→ : '' Components→ : ' cfg-amp:1 mic:acp-dmic cfg-mics:1 spk:rt1320 hs:rt722' Controls : 24 Simple ctrls : 18 $ apt-cache policy alsa-ucm-conf linux-oem-24.04d alsa-ucm-conf: Installed: 1.2.10-1ubuntu5.13 Candidate: 1.2.10-1ubuntu5.13 Version table: *** 1.2.10-1ubuntu5.13 100 100 http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages 100 http://archive.ubuntu.com/ubuntu noble-proposed/main i386 Packages 100 /var/lib/dpkg/status 1.2.10-1ubuntu5.11 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu noble-updates/main i386 Packages 1.2.10-1ubuntu5 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu noble/main i386 Packages linux-oem-24.04d: Installed: 6.17.0-1026.26 Candidate: 6.17.0-1026.26 Version table: *** 6.17.0-1026.26 100 100 http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages 100 /var/lib/dpkg/status 6.17.0-1025.25 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages ** Tags removed: verification-needed-noble verification-needed-noble-linux-oem-6.17 ** Tags added: verification-done-noble verification-done-noble-linux-oem-6.17 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154418 Title: Backport ASoC SDCA, AMD SoundWire, and RT722 audio fixes Status in HWE Next: In Progress Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress 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: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in alsa-ucm-conf source package in Questing: Fix Committed Status in linux source package in Questing: Won't Fix Status in linux-oem-6.17 source package in Questing: Invalid Status in alsa-ucm-conf source package in Resolute: Fix Committed Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: SRU Justification: [ Impact ] Some newer audio configurations require SoundWire/SDCA updates for companion amplifier handling, AMD ACP7.0 Realtek match entries, Lenovo AMD SoundWire DMIC quirks, combined speaker component naming, and RT722 speaker mute control. Without these fixes, affected systems may fail to expose the expected audio topology, DMIC component naming, PCM numbering, or speaker mute switch needed by userspace/UCM. [ Fix ] Backport upstream commits: - f5cb3ee251b4 ("ASoC: SDCA: Add companion amp Function") - 7869f1c1123c ("ASoC: amd: acp: Add ACP7.0 match entries for Realtek parts") - 3acf517e1ae0 ("ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models") - 68130eef1e0d ("ASoC: soc-component: re-add pcm_new()/pcm_free()") - fe33a69681e3 ("ASoC: amd: name back to pcm_new()/pcm_free()") - 5902e1f3c501 ("ASoC: amd: acp: update dmic_num logic for acp pdm dmic") - 371f6a1d2a97 ("ASoC: amd: acp-sdw-legacy: rename the dmic component name") - 3666dc0c47c3 ("ASoC: amd: ps: fix the pcm device numbering for acp pdm dmic") - 80a7916ca2d9 ("ASoC: amd: acp: add Lenovo P16s G5 AMD quirk for legacy SDW machine") - 6b6f7263d626 ("ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms") - 87a3f5c8ac20 ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined") - bda41dd5e1dd ("ASoC: rt722-sdca: add FU06 Playback Switch for speaker mute control") [ Test Plan ] Boot affected hardware and verify: 1. Sound card probes successfully. 2. Expected ALSA PCMs and controls are present. 3. DMIC capture works on affected AMD SoundWire platforms. 4. Speaker playback works. 5. Speaker mute control is exposed and can be toggled by userspace. [ Where problems could occur ] The changes affect ASoC SoundWire/SDCA machine matching, component naming, PCM setup, and RT722 codec mute handling. Regressions could appear as sound card probe failures, changed component strings affecting UCM matching, missing or renumbered PCM devices, or incorrect speaker mute behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2154418/+subscriptions

[Bug 2148636] Re: backport Intel iwlwifi core102 support from linux-next to linux/resolute 7.0.

Verified linux-oem-7.0/7.0.0-1006.6 on Intel WCL-U RVP with BE211 module. $ sudo dmesg|grep iwlwifi [ 4.338208] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002) [ 4.353825] iwlwifi 0000:00:14.3: Detected crf-id 0x1002a10, cnv-id 0x1080901 wfpm id 0x80005b20 [ 4.353839] iwlwifi 0000:00:14.3: PCI dev 4d40/0110, rev=0x4b1, rfid=0x20113100 [ 4.353842] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 7 BE211 320MHz [ 4.359587] iwlwifi 0000:00:14.3: loaded firmware version 102.07fca168.0 bz-b0-wh-b0-c102.ucode op_mode iwlmld [ 5.110607] iwlwifi 0000:00:14.3: Detected RF WH, rfid=0x20113100 [ 5.222102] iwlwifi 0000:00:14.3: base HW address: 04:f0:ee:28:02:17 [ 5.291647] iwlwifi 0000:00:14.3 wlp0s20f3: renamed from wlan0 $ modinfo iwlwifi|head filename: /lib/modules/7.0.0-1006-oem/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko.zst $ dpkg -S /usr/lib/modules/7.0.0-1006-oem/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko.zst linux-modules-7.0.0-1006-oem: /usr/lib/modules/7.0.0-1006-oem/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko.zst ** Tags removed: verification-needed-resolute-linux-oem-7.0 ** Tags added: verification-done-resolute-linux-oem-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148636 Title: backport Intel iwlwifi core102 support from linux-next to linux/resolute 7.0. Status in linux package in Ubuntu: Fix Released Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: Won't Fix Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Questing: Won't Fix Status in linux-oem-7.0 source package in Questing: Invalid Status in linux source package in Resolute: Won't Fix Status in linux-oem-7.0 source package in Resolute: Fix Committed Status in linux source package in Stonking: Fix Released Status in linux-oem-7.0 source package in Stonking: Invalid Bug description: [SRU Justification] [Impact] While we are to support Intel Wilcat Lake in oem projects, the PV driver release depends on firmware release of core102 API. In Ubuntu, core102 API is currently only supported through backport-iwlwifi-dkms >= 0~102 version, or linux-unstable based kernel v7.1-rcX. The support plan is: 1. to enable linux-oem-6.17 supportness using backport-iwlwifi-dkms, 2. when migrated to linux-hwe-7.0 and/or generic linux-7.0, expect native support of iwlwifi core102 API in them. Without 2., the Intel Wildcat Lake platforms shipped with linux-oem-6.17 kernel will be blocked until a latter point release in around early 2027, a hwe kernel based on Stonking generic kernel 7.3 or so. While the PV driver is only upstreamed until v7.1-rc, it's impossible to integrate this before Resolute linux-7.0 release. [Fix] The backport is made of 57 patches from mainline kernel. A few patches proposed by Intel but appears irrelevant to the core function have been removed because they lead to either build failures to other components, or external dkms packages due to API changes. Most of the patches touch only iwlwifi driver itself. For those walk across the border: 1. from wireless-next-2026-03-19: - f10ebd136dfef wifi: nl80211: use int for band coming from netlink - eb092b188fcf9 wifi: mac80211: fix STA link removal during link removal - 6fb86f7b696e8 wifi: nl80211: reject S1G/60G with HT chantype - 7218d8e9d8485 wifi: cfg80211: check non-S1G width with S1G chandef - 92d77e06e73ca wifi: cfg80211: restrict cfg80211_chandef_create() to only HT-based bands - a6d4291eae040 wifi: mac80211: don't use cfg80211_chandef_create() for default chandef - 84674b03d8bf3 wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work() - fd2905157d692 wifi: cfg80211: split control freq check from chandef check - f932856649b07 wifi: mac80211: always use full chanctx compatible check - ba9d121f85771 wifi: mac80211: refactor chandef tracing macros - f2514ff78855c wifi: mac80211: validate HE 6 GHz operation when EHT is used Above commits are internal to nl80211/mac80211/cfg80211 and did not touch API/ABI. - e4b993f2bca78 wifi: nl80211: split out UHR operation information This is to define a new nl80211 attribute for userspace program use. For hostap/wpa_supplicant, it's in the main branch starting from commit b6bdf8581 ("UHR: Protocol definitions from IEEE P802.11bn/D1.4") and is not yet released ever. hostap, actually libnl already handles unknown attribute by passing maximum accepted attribute id NL80211_ATTR_MAX to nla_parse() or so. - 35de87bf598ca wifi: Add SPDX ids to some files in the wireless subsystem - a140826caa2c1 wifi: nl80211: fix UHR capability validation - 9f39e2cc2b012 wifi: mac80211: remove AID bit stripping for print - 2f211be112e64 wifi: mac80211: remove stale TODO item Another few commit irrelevant to API/ABI changes. 2. from wireless-next-2026-03-04: - 5d048bbed1bb2 wifi: mac80211: give the AP more time for EPPKE as well - b8a57b979a7c2 wifi: mac80211: update outdated comment Internal fixes only. - 6a584e336cefb wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver This is to notify upper layers about the signal interference event. mac80211 simulator (MAC80211_HWSIM), uses it. hostap implemented this process since commit bfc3fe08a ("nl80211: Incumbent signal interference event") in main branch; before that, it's simply dropped with a debug message indicating an unsupported event. - f3f52e6f20ac8 wifi: mac80211: Set link ID for NULL packets sent to probe stations - 73e7df69edb6f wifi: mac80211: set band information only for non-MLD when probing stations using NULL frame [Test Plan] 1. Install the new patched kernel from -proposed. 2. On an Intel Wildcat Lake platform, with BE211/BE213 wireless modules, check the dmesg gives something like: ``` $ sudo dmesg | grep iwlwifi kernel: iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 7 BE211 320MHz kernel: iwlwifi 0000:00:14.3: loaded firmware version 102.07fca168.0 bz-b0-wh-b0-c102.ucode op_mode iwlmld ``` 3. Install checkbox: ``` $ sudo apt-add-repository ppa:checkbox-dev/stable $ sudo apt install canonical-certification-client ``` Run wireless automated test plan: ``` $ sudo checkbox-cli run-plan # Pick "Automated tests for wireless and follow further menus ``` 4. Replace the module with other models even with a different vendor if possible. Retry with step 2. and 3. 5. Tested dkms packages: ``` $ dkms status backport-iwlwifi/0~103.14434-gitdf6b5bf4, 7.0.0-3015-generic, x86_64: installed broadcom-sta/6.30.223.271, 7.0.0-3015-generic, x86_64: installed ezurio-qcacld-2.0/0.0~git20240408.aa96a9f+dfsg, 7.0.0-3015-generic, x86_64: installed ipt-netflow/2.6, 7.0.0-3015-generic, x86_64: installed jool/4.1.15, 7.0.0-3015-generic, x86_64: installed osmocom-dahdi/0.0~git20250226.6dada77, 7.0.0-3015-generic, x86_64: installed ovpn-dco/0.0+git20251017, 7.0.0-3015-generic, x86_64: installed r8125/9.016.01, 7.0.0-3015-generic, x86_64: installed r8168/8.055.00, 7.0.0-3015-generic, x86_64: installed rtpengine/13.5.1.4, 7.0.0-3015-generic, x86_64: installed sl-modem/2.9.11~20110321, 7.0.0-3015-generic, x86_64: installed west-chamber/20100405+svn20111107.r124, 7.0.0-3015-generic, x86_64: installed xtables-addons/3.30, 7.0.0-3015-generic, x86_64: installed ``` [Where problems could occur] By lifting iwlwifi firmware API from core101 which linux-7.0 supports to core102, it follows a few firmware may become active while they were not although released in linux-firmware/resolute. These files are: * intel/iwlwifi/iwlwifi-bz-b0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode (BE211/BE213) * intel/iwlwifi/iwlwifi-gl-c0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-sc-a0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-sc-a0-wh-b0-c102.ucode (BE211/BE213) While these models are expected to be supported in Intel Wildcat Lake, it follows they must become active to meet device enablement plan. The blobs are PV ones, they are supposed to be working fine. In addition, when Intel AX211 module is installed, there is a known issue LP #2152688 that iwlwifi gives "failed to send MCC_ALLOWED_AP_TYPE_CMD (-22)" error at initializing. This happens to backport-iwlwifi-dkms core105, too. [Other Info] While these patches are backported from v7.1-rcX, nominate for Resolute and oem-6.17 only. --- ProblemType: Bug ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse:  USER PID ACCESS COMMAND  /dev/snd/seq: gdm-greeter 1545 F.... pipewire CasperMD5CheckResult: pass DistroRelease: Ubuntu 26.04 InstallationDate: Installed on 2025-12-23 (157 days ago) InstallationMedia: Ubuntu 24.04.2 LTS "Noble Numbat" - Release amd64 (20250215) Lsusb:  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub  Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub  Bus 003 Device 002: ID 2a7a:8a5b CASUE USB KB  Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: Intel Corporation Wildcat Lake Client Platform Package: linux (not installed) ProcFB: 0 xedrmfb ProcKernelCmdLine: BOOT_IMAGE=/rootfs/resolute/boot/vmlinuz-7.0.0-19-generic root=UUID=e9935351-eaa0-4e67-9f5a-5910f8e4786e ro rootflags=subvol=rootfs/resolute quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ProcVersionSignature: Ubuntu 7.0.0-19.19-generic 7.0.9 Tags: resolute Uname: Linux 7.0.0-19-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 08/07/2025 dmi.bios.vendor: Intel Corporation dmi.bios.version: WCLPFWI1.R00.3323.D05.2508071747 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: WCL LP5x MD T3 RVP2 dmi.board.vendor: Intel Corporation dmi.board.version: 2 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 0.1 dmi.ec.firmware.release: 2.40 dmi.modalias: dmi:bvnIntelCorporation:bvrWCLPFWI1.R00.3323.D05.2508071747:bd08/07/2025:efr2.40:svnIntelCorporation:pnWildcatLakeClientPlatform:pvr0.1:rvnIntelCorporation:rnWCLLP5xMDT3RVP2:rvr2:cvnIntelCorporation:ct9:cvr0.1:sku0100000000210100:pfaWildcatLakeClientSystem: dmi.product.family: Wildcat Lake Client System dmi.product.name: Wildcat Lake Client Platform dmi.product.sku: 0100000000210100 dmi.product.version: 0.1 dmi.sys.vendor: Intel Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148636/+subscriptions

[Bug 2156830] Re: Fix missing audio output device on Dell Slate HPT platform

** Changed in: linux-firmware (Ubuntu Resolute) Status: Invalid => 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/2156830 Title: Fix missing audio output device on Dell Slate HPT platform Status in linux package in Ubuntu: New Status in linux-firmware 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-firmware source package in Noble: In Progress Status in linux-oem-6.17 source package in Noble: In Progress Status in linux source package in Resolute: Fix Released Status in linux-firmware source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] New Dell Slate HPT platform with CirrusLogic audio solution will have no basic audio functions w/o ACP6.3 match entries. ================ Linux Kernel ======================== [Fix] Backport upstream fix fd13fc700e3e ("ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts") ================ linux-firmware ======================== [Fix] Backport upstream fix [1]: cirrus: cs42l45: Update CS42L45 SDCA codec firmware for Dell laptops (!1094) · Merge requests · kernel-firmware / Linux Firmware · GitLab [2]: cirrus: cs35l63: Add Cirrus CS35L63 firmware mappings for various Dell laptops - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel [Test Case] 1. Boot up the machine of new Dell Slate HPT platform. 2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices 3. Click test icon for basic audio output functions 4. Use `aplay` basic speaker play functions. [Where problems could occur] The commit simply add ACP 6.3 entries for CirrusLogic codecs. No regression expected at the current stage. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2156830/+subscriptions

[Bug 2156830] Re: Fix missing audio output device on Dell Slate HPT platform

** Changed in: linux-firmware (Ubuntu Resolute) Status: In Progress => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156830 Title: Fix missing audio output device on Dell Slate HPT platform Status in linux package in Ubuntu: New Status in linux-firmware 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-firmware source package in Noble: In Progress Status in linux-oem-6.17 source package in Noble: In Progress Status in linux source package in Resolute: Fix Released Status in linux-firmware source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] New Dell Slate HPT platform with CirrusLogic audio solution will have no basic audio functions w/o ACP6.3 match entries. ================ Linux Kernel ======================== [Fix] Backport upstream fix fd13fc700e3e ("ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts") ================ linux-firmware ======================== [Fix] Backport upstream fix [1]: cirrus: cs42l45: Update CS42L45 SDCA codec firmware for Dell laptops (!1094) · Merge requests · kernel-firmware / Linux Firmware · GitLab [2]: cirrus: cs35l63: Add Cirrus CS35L63 firmware mappings for various Dell laptops - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel [Test Case] 1. Boot up the machine of new Dell Slate HPT platform. 2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices 3. Click test icon for basic audio output functions 4. Use `aplay` basic speaker play functions. [Where problems could occur] The commit simply add ACP 6.3 entries for CirrusLogic codecs. No regression expected at the current stage. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2156830/+subscriptions

[Bug 2148636] Re: backport Intel iwlwifi core102 support from linux-next to linux/resolute 7.0.

Rejected by stable team. ** Changed in: linux (Ubuntu Resolute) Status: In Progress => Won't Fix ** Changed in: linux (Ubuntu Resolute) Assignee: You-Sheng Yang (vicamo) => (unassigned) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148636 Title: backport Intel iwlwifi core102 support from linux-next to linux/resolute 7.0. Status in linux package in Ubuntu: Fix Released Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: Won't Fix Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Questing: Won't Fix Status in linux-oem-7.0 source package in Questing: Invalid Status in linux source package in Resolute: Won't Fix Status in linux-oem-7.0 source package in Resolute: Fix Committed Status in linux source package in Stonking: Fix Released Status in linux-oem-7.0 source package in Stonking: Invalid Bug description: [SRU Justification] [Impact] While we are to support Intel Wilcat Lake in oem projects, the PV driver release depends on firmware release of core102 API. In Ubuntu, core102 API is currently only supported through backport-iwlwifi-dkms >= 0~102 version, or linux-unstable based kernel v7.1-rcX. The support plan is: 1. to enable linux-oem-6.17 supportness using backport-iwlwifi-dkms, 2. when migrated to linux-hwe-7.0 and/or generic linux-7.0, expect native support of iwlwifi core102 API in them. Without 2., the Intel Wildcat Lake platforms shipped with linux-oem-6.17 kernel will be blocked until a latter point release in around early 2027, a hwe kernel based on Stonking generic kernel 7.3 or so. While the PV driver is only upstreamed until v7.1-rc, it's impossible to integrate this before Resolute linux-7.0 release. [Fix] The backport is made of 57 patches from mainline kernel. A few patches proposed by Intel but appears irrelevant to the core function have been removed because they lead to either build failures to other components, or external dkms packages due to API changes. Most of the patches touch only iwlwifi driver itself. For those walk across the border: 1. from wireless-next-2026-03-19: - f10ebd136dfef wifi: nl80211: use int for band coming from netlink - eb092b188fcf9 wifi: mac80211: fix STA link removal during link removal - 6fb86f7b696e8 wifi: nl80211: reject S1G/60G with HT chantype - 7218d8e9d8485 wifi: cfg80211: check non-S1G width with S1G chandef - 92d77e06e73ca wifi: cfg80211: restrict cfg80211_chandef_create() to only HT-based bands - a6d4291eae040 wifi: mac80211: don't use cfg80211_chandef_create() for default chandef - 84674b03d8bf3 wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work() - fd2905157d692 wifi: cfg80211: split control freq check from chandef check - f932856649b07 wifi: mac80211: always use full chanctx compatible check - ba9d121f85771 wifi: mac80211: refactor chandef tracing macros - f2514ff78855c wifi: mac80211: validate HE 6 GHz operation when EHT is used Above commits are internal to nl80211/mac80211/cfg80211 and did not touch API/ABI. - e4b993f2bca78 wifi: nl80211: split out UHR operation information This is to define a new nl80211 attribute for userspace program use. For hostap/wpa_supplicant, it's in the main branch starting from commit b6bdf8581 ("UHR: Protocol definitions from IEEE P802.11bn/D1.4") and is not yet released ever. hostap, actually libnl already handles unknown attribute by passing maximum accepted attribute id NL80211_ATTR_MAX to nla_parse() or so. - 35de87bf598ca wifi: Add SPDX ids to some files in the wireless subsystem - a140826caa2c1 wifi: nl80211: fix UHR capability validation - 9f39e2cc2b012 wifi: mac80211: remove AID bit stripping for print - 2f211be112e64 wifi: mac80211: remove stale TODO item Another few commit irrelevant to API/ABI changes. 2. from wireless-next-2026-03-04: - 5d048bbed1bb2 wifi: mac80211: give the AP more time for EPPKE as well - b8a57b979a7c2 wifi: mac80211: update outdated comment Internal fixes only. - 6a584e336cefb wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver This is to notify upper layers about the signal interference event. mac80211 simulator (MAC80211_HWSIM), uses it. hostap implemented this process since commit bfc3fe08a ("nl80211: Incumbent signal interference event") in main branch; before that, it's simply dropped with a debug message indicating an unsupported event. - f3f52e6f20ac8 wifi: mac80211: Set link ID for NULL packets sent to probe stations - 73e7df69edb6f wifi: mac80211: set band information only for non-MLD when probing stations using NULL frame [Test Plan] 1. Install the new patched kernel from -proposed. 2. On an Intel Wildcat Lake platform, with BE211/BE213 wireless modules, check the dmesg gives something like: ``` $ sudo dmesg | grep iwlwifi kernel: iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 7 BE211 320MHz kernel: iwlwifi 0000:00:14.3: loaded firmware version 102.07fca168.0 bz-b0-wh-b0-c102.ucode op_mode iwlmld ``` 3. Install checkbox: ``` $ sudo apt-add-repository ppa:checkbox-dev/stable $ sudo apt install canonical-certification-client ``` Run wireless automated test plan: ``` $ sudo checkbox-cli run-plan # Pick "Automated tests for wireless and follow further menus ``` 4. Replace the module with other models even with a different vendor if possible. Retry with step 2. and 3. 5. Tested dkms packages: ``` $ dkms status backport-iwlwifi/0~103.14434-gitdf6b5bf4, 7.0.0-3015-generic, x86_64: installed broadcom-sta/6.30.223.271, 7.0.0-3015-generic, x86_64: installed ezurio-qcacld-2.0/0.0~git20240408.aa96a9f+dfsg, 7.0.0-3015-generic, x86_64: installed ipt-netflow/2.6, 7.0.0-3015-generic, x86_64: installed jool/4.1.15, 7.0.0-3015-generic, x86_64: installed osmocom-dahdi/0.0~git20250226.6dada77, 7.0.0-3015-generic, x86_64: installed ovpn-dco/0.0+git20251017, 7.0.0-3015-generic, x86_64: installed r8125/9.016.01, 7.0.0-3015-generic, x86_64: installed r8168/8.055.00, 7.0.0-3015-generic, x86_64: installed rtpengine/13.5.1.4, 7.0.0-3015-generic, x86_64: installed sl-modem/2.9.11~20110321, 7.0.0-3015-generic, x86_64: installed west-chamber/20100405+svn20111107.r124, 7.0.0-3015-generic, x86_64: installed xtables-addons/3.30, 7.0.0-3015-generic, x86_64: installed ``` [Where problems could occur] By lifting iwlwifi firmware API from core101 which linux-7.0 supports to core102, it follows a few firmware may become active while they were not although released in linux-firmware/resolute. These files are: * intel/iwlwifi/iwlwifi-bz-b0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode (BE211/BE213) * intel/iwlwifi/iwlwifi-gl-c0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-sc-a0-fm-c0-c102.ucode (BE201) * intel/iwlwifi/iwlwifi-sc-a0-wh-b0-c102.ucode (BE211/BE213) While these models are expected to be supported in Intel Wildcat Lake, it follows they must become active to meet device enablement plan. The blobs are PV ones, they are supposed to be working fine. In addition, when Intel AX211 module is installed, there is a known issue LP #2152688 that iwlwifi gives "failed to send MCC_ALLOWED_AP_TYPE_CMD (-22)" error at initializing. This happens to backport-iwlwifi-dkms core105, too. [Other Info] While these patches are backported from v7.1-rcX, nominate for Resolute and oem-6.17 only. --- ProblemType: Bug ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse:  USER PID ACCESS COMMAND  /dev/snd/seq: gdm-greeter 1545 F.... pipewire CasperMD5CheckResult: pass DistroRelease: Ubuntu 26.04 InstallationDate: Installed on 2025-12-23 (157 days ago) InstallationMedia: Ubuntu 24.04.2 LTS "Noble Numbat" - Release amd64 (20250215) Lsusb:  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub  Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub  Bus 003 Device 002: ID 2a7a:8a5b CASUE USB KB  Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: Intel Corporation Wildcat Lake Client Platform Package: linux (not installed) ProcFB: 0 xedrmfb ProcKernelCmdLine: BOOT_IMAGE=/rootfs/resolute/boot/vmlinuz-7.0.0-19-generic root=UUID=e9935351-eaa0-4e67-9f5a-5910f8e4786e ro rootflags=subvol=rootfs/resolute quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ProcVersionSignature: Ubuntu 7.0.0-19.19-generic 7.0.9 Tags: resolute Uname: Linux 7.0.0-19-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 08/07/2025 dmi.bios.vendor: Intel Corporation dmi.bios.version: WCLPFWI1.R00.3323.D05.2508071747 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: WCL LP5x MD T3 RVP2 dmi.board.vendor: Intel Corporation dmi.board.version: 2 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 0.1 dmi.ec.firmware.release: 2.40 dmi.modalias: dmi:bvnIntelCorporation:bvrWCLPFWI1.R00.3323.D05.2508071747:bd08/07/2025:efr2.40:svnIntelCorporation:pnWildcatLakeClientPlatform:pvr0.1:rvnIntelCorporation:rnWCLLP5xMDT3RVP2:rvr2:cvnIntelCorporation:ct9:cvr0.1:sku0100000000210100:pfaWildcatLakeClientSystem: dmi.product.family: Wildcat Lake Client System dmi.product.name: Wildcat Lake Client Platform dmi.product.sku: 0100000000210100 dmi.product.version: 0.1 dmi.sys.vendor: Intel Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148636/+subscriptions

[Bug 2156830] [NEW] Fix missing audio output device on Dell Slate HPT platform

Public bug reported: [Impact] New Dell Slate HPT platform with CirrusLogic audio solution will have no basic audio functions w/o ACP6.3 match entries. ================ Linux Kernel ======================== [Fix] Backport upstream fix fd13fc700e3e ("ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts") ================ linux-firmware ======================== [Fix] Backport upstream fix [1]: cirrus: cs42l45: Update CS42L45 SDCA codec firmware for Dell laptops (!1094) · Merge requests · kernel-firmware / Linux Firmware · GitLab [2]: cirrus: cs35l63: Add Cirrus CS35L63 firmware mappings for various Dell laptops - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel [Test Case] 1. Boot up the machine of new Dell Slate HPT platform. 2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices 3. Click test icon for basic audio output functions 4. Use `aplay` basic speaker play functions. [Where problems could occur] The commit simply add ACP 6.3 entries for CirrusLogic codecs. No regression expected at the current stage. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-firmware (Ubuntu) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: Invalid ** Affects: linux-firmware (Ubuntu Noble) Importance: Undecided Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: In Progress ** Affects: linux (Ubuntu Resolute) Importance: Undecided Status: Fix Released ** Affects: linux-firmware (Ubuntu Resolute) Importance: Undecided Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: Invalid ** Also affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: New => In Progress ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid ** Also affects: linux-firmware (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-firmware (Ubuntu Noble) Status: New => In Progress ** Changed in: linux-firmware (Ubuntu Resolute) Status: New => In Progress ** Description changed: [Impact] New Dell Slate HPT platform with CirrusLogic audio solution will have no basic audio functions w/o ACP6.3 match entries. ================ Linux Kernel ======================== [Fix] Backport upstream fix fd13fc700e3e ("ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts") + ================ linux-firmware ======================== + + [Fix] + Backport upstream fix + [1]: cirrus: cs42l45: Update CS42L45 SDCA codec firmware for Dell laptops (!1094) · Merge requests · kernel-firmware / Linux Firmware · GitLab + [2]: cirrus: cs35l63: Add Cirrus CS35L63 firmware mappings for various Dell laptops - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel [Test Case] 1. Boot up the machine of new Dell Slate HPT platform. 2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices 3. Click test icon for basic audio output functions 4. Use `aplay` basic speaker play functions. [Where problems could occur] The commit simply add ACP 6.3 entries for CirrusLogic codecs. No regression expected at the current stage. ** Changed in: linux (Ubuntu Resolute) Status: New => Fix Released ** Changed in: linux (Ubuntu Noble) 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/2156830 Title: Fix missing audio output device on Dell Slate HPT platform Status in linux package in Ubuntu: New Status in linux-firmware 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-firmware source package in Noble: In Progress Status in linux-oem-6.17 source package in Noble: In Progress Status in linux source package in Resolute: Fix Released Status in linux-firmware source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] New Dell Slate HPT platform with CirrusLogic audio solution will have no basic audio functions w/o ACP6.3 match entries. ================ Linux Kernel ======================== [Fix] Backport upstream fix fd13fc700e3e ("ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts") ================ linux-firmware ======================== [Fix] Backport upstream fix [1]: cirrus: cs42l45: Update CS42L45 SDCA codec firmware for Dell laptops (!1094) · Merge requests · kernel-firmware / Linux Firmware · GitLab [2]: cirrus: cs35l63: Add Cirrus CS35L63 firmware mappings for various Dell laptops - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel [Test Case] 1. Boot up the machine of new Dell Slate HPT platform. 2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices 3. Click test icon for basic audio output functions 4. Use `aplay` basic speaker play functions. [Where problems could occur] The commit simply add ACP 6.3 entries for CirrusLogic codecs. No regression expected at the current stage. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2156830/+subscriptions

[Bug 2146517] Re: ov08x40 module mounted upside down on a certain DELL platforms

Verified linux/7.0.0-26.26. While we have a follow-up bug 2155837 for a SKU that is not available in cert pool, only works for the one Canonical has. ** Tags removed: verification-needed-resolute-linux ** Tags added: verification-done-resolute-linux -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2146517 Title: ov08x40 module mounted upside down on a certain DELL platforms Status in ipu6-drivers package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in linux-oem-6.17 package in Ubuntu: Invalid Status in ipu6-drivers source package in Noble: Won't Fix Status in linux source package in Noble: Won't Fix Status in linux-oem-6.17 source package in Noble: Fix Released Status in ipu6-drivers source package in Questing: Won't Fix Status in linux source package in Questing: Won't Fix Status in linux-oem-6.17 source package in Questing: Invalid Status in ipu6-drivers source package in Resolute: Fix Released Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [SRU Justification] [Impact] Camera streaming gives upside-down image because the hardware module is mounted rotated physically. [Fix] Proposed fix in https://github.com/intel/ipu6-drivers/pull/432, which has been merged into tag 20260327. [Test Plan] 1. Install the kernel from -proposed pocket along with linux-modules-{ipu6,ipu7,usbio,vision}-<variant> meta packages. 2. Start camera streaming and check if it's still upside-down. [Where problems could occur] We had switched to in-tree ov08x40 in bug 2137700, but in order not to patch in-tree camera sensor drivers that may be used in other embedded systems, the core driver fix is landed back in the dkms instead. This follows we may suffer from the lack of upstream updates from now on. [Other Info] This is only mandatory for OEM platforms that shipped with an inverted module running linux-oem-6.17 and on. Nominate for ipu6-drivers/resolute, which is taken to be built along with linux- oem-6.17/noble. ========== original bug report ========== Proposed fix in https://github.com/intel/ipu6-drivers/pull/432/, which requires updates in the dkms and in the in-tree kernel ipu-bridge driver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ipu6-drivers/+bug/2146517/+subscriptions

[Bug 2101816] Re: [amdgpu] Crash with SIGABRT in amdgpu_ctx_set_sw_reset_status() from amdgpu_cs_submit_ib() from util_queue_thread_func() from impl_thrd_routine() from start_thread()

** Changed in: linux-oem-6.17 (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2101816 Title: [amdgpu] Crash with SIGABRT in amdgpu_ctx_set_sw_reset_status() from amdgpu_cs_submit_ib() from util_queue_thread_func() from impl_thrd_routine() from start_thread() Status in Mesa: New Status in Mutter: New Status in linux package in Ubuntu: Confirmed Status in linux-oem-6.17 package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Opinion Status in xorg-server package in Ubuntu: Opinion Status in xwayland package in Ubuntu: Opinion Status in gnome-shell package in Fedora: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 48~beta-3ubuntu1, the problem page at https://errors.ubuntu.com/problem/fb85627cf28fc2fa707952f5c3c1a887e8f2b5fb contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/2101816/+subscriptions

[Bug 2101816] Re: [amdgpu] Crash with SIGABRT in amdgpu_ctx_set_sw_reset_status() from amdgpu_cs_submit_ib() from util_queue_thread_func() from impl_thrd_routine() from start_thread()

** Also affects: linux-oem-6.17 (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/2101816 Title: [amdgpu] Crash with SIGABRT in amdgpu_ctx_set_sw_reset_status() from amdgpu_cs_submit_ib() from util_queue_thread_func() from impl_thrd_routine() from start_thread() Status in Mesa: New Status in Mutter: New Status in linux package in Ubuntu: Confirmed Status in linux-oem-6.17 package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Opinion Status in xorg-server package in Ubuntu: Opinion Status in xwayland package in Ubuntu: Opinion Status in gnome-shell package in Fedora: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 48~beta-3ubuntu1, the problem page at https://errors.ubuntu.com/problem/fb85627cf28fc2fa707952f5c3c1a887e8f2b5fb contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/2101816/+subscriptions

[Bug 2155222] Re: [hyperv] Ensure MMIO Mapping is Correct for Kexec / kdump kernel on Azure v6 Instance Types

** Description changed: 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] The fix landed in 7.2-rc1: commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 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/torvalds/linux.git/commit/?id=016a25e4b0df4d77e7c258edee4aaf982e4ee809 + + Jammy also needs the following dependency: + + commit 2a8a8afba0c3053d0ea8686182f6b2104293037e + Author: Vitaly Kuznetsov <vkuznets@redhat.com> + Date: Sat Aug 27 15:03:44 2022 +0200 + Subject: Drivers: hv: Always reserve framebuffer region for Gen1 VMs + Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a8a8afba0c3053d0ea8686182f6b2104293037e 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/ -- 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] The fix landed in 7.2-rc1: commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 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/torvalds/linux.git/commit/?id=016a25e4b0df4d77e7c258edee4aaf982e4ee809 Jammy also needs the following dependency: commit 2a8a8afba0c3053d0ea8686182f6b2104293037e Author: Vitaly Kuznetsov <vkuznets@redhat.com> Date: Sat Aug 27 15:03:44 2022 +0200 Subject: Drivers: hv: Always reserve framebuffer region for Gen1 VMs Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a8a8afba0c3053d0ea8686182f6b2104293037e 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 2155120] Re: Fix audio mute function not working on new Dell platforms

Verified on Dell Sunfire Intel and AMD laptops with linux- oem-6.17/6.17.0-1026.26, press Fn+F4 to toggle the mic-mute function, the gnome shows the mic-mute enable/disable icon as expected and the `arecord` is functioned accordingly. ** Tags removed: verification-needed-noble-linux-oem-6.17 ** Tags added: verification-done-noble-linux-oem-6.17 -- 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: Fix Released Status in linux-oem-6.17 package in Ubuntu: Invalid 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 2153155] Re: Fix bad audio record quality when volume above 50% on Framework PTL

Verified on Framework PTL laptop with linux-oem-6.17/6.17.0-1026.26 kernel, go to g-s-d menu and adjust the input volume to > 50%. `arecord` to record an audio clip and play it with audio player, no obvious noise and the audio quality is played as expected ** Tags removed: verification-needed-noble-linux-oem-6.17 ** Tags added: verification-done-noble-linux-oem-6.17 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153155 Title: Fix bad audio record quality when volume above 50% on Framework PTL 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: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] Framework PTL platform with Realtek ALC295 audio solution will have audio recording quality when the input volume is configure > 50%. [Fix] Fix by backporting the commit: 67c738152207 ("67c738152207") which fix mic boost on particular SSIDs of the Framework machines [Test Case] 1. Boot up the machine of new Framework PTL platforms with Realtek ALC295 audio solution 2. Go to g-s-d and select sound --> input (Internal Microphone) --> Adjust the input volume > 50% 3. Do `arecord` with the internal microphone and play the recorded clips. [Where problems could occur] It only limit the mic boost based on particular SSIDs. The risk of regression is limited. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2153155/+subscriptions