Thank you very much for reporting this issue. ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Resolute) Importance: Undecided => High ** Changed in: linux (Ubuntu) Importance: Medium => High ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: linux (Ubuntu Resolute) Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169736 Title: RTC device disappears after updating to 7.0.0-39-generic Status in linux package in Ubuntu: Confirmed Status in linux source package in Resolute: Confirmed Bug description: Issue seen on 26.04 and probably other series as well. ubuntu@dell-latitude-5411-c27717:~$ uname -a Linux dell-latitude-5411-c27717 7.0.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026 x86_64 GNU/Linux ubuntu@dell-latitude-5411-c27717:~$ cat /sys/class/rtc/rtc0/since_epoch 1791307002 # Update to 7.0.0-39-generic and reboot ubuntu@dell-latitude-5411-c27717:~$ uname -a Linux dell-latitude-5411-c27717 7.0.0-39-generic #39-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 24 11:18:19 UTC 2026 x86_64 GNU/Linux ubuntu@dell-latitude-5411-c27717:~$ cat /sys/class/rtc/rtc0/since_epoch cat: /sys/class/rtc/rtc0/since_epoch: No such file or directory ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-39-generic 7.0.0-39.39 ProcVersionSignature: Ubuntu 7.0.0-39.39-generic 7.0.14 Uname: Linux 7.0.0-39-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: ubuntu 2123 F.... wireplumber /dev/snd/seq: ubuntu 2102 F.... pipewire CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: maas CloudName: maas CloudPlatform: maas CloudSubPlatform: seed-dir (http://10.102.160.2:5248/MAAS/metadata/) Date: Wed Oct 7 01:19:33 2026 InstallationDate: Installed on 2026-05-19 (141 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlo1Link: Not connected. MachineType: Dell Inc. Latitude 5411 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-39-generic root=UUID=16b44133-d26e-466c-8e12-da20de044692 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/03/2020 dmi.bios.release: 1.1 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.5 dmi.board.vendor: Dell Inc. dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.1.5:bd05/03/2020:br1.1:svnDellInc.:pnLatitude5411:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:sku09C0:pfaLatitude: dmi.product.family: Latitude dmi.product.name: Latitude 5411 dmi.product.sku: 09C0 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169736/+subscriptions
четверг
[Bug 2169339] Re: [iMac18,2] BCM43602 Wi-Fi (brcmfmac) cannot associate on 7.3 kernels: DMAR DMA Read faults, firmware hangs; works with intel_iommu=off
Thank you very much for reporting this issue. ** Changed in: linux (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169339 Title: [iMac18,2] BCM43602 Wi-Fi (brcmfmac) cannot associate on 7.3 kernels: DMAR DMA Read faults, firmware hangs; works with intel_iommu=off Status in linux package in Ubuntu: New Bug description: On an iMac18,2 (2017) with a Broadcom BCM43602 [14e4:43ba] (subsystem Apple [106b:016e]), Wi-Fi no longer connects since the installed system moved to the 7.3 kernel. Booting with intel_iommu=off makes it work again. Wi-Fi worked in the Ubuntu 26.10 live session used to install the machine (kernel 7.2.0-5, image of 2026-09-15). The installer then upgraded to linux 7.3.0-5 and removed 7.2.0-5, and Wi-Fi has failed on every boot since (7.3.0-5, 7.3.0-6 and 7.3.0-8, 13 boots in total). I have no logs from the 7.2 live session, so I cannot tell whether the IOMMU was enabled there. What happens on a default boot: 1. brcmfmac loads, firmware starts, wlp3s0 appears, the initial scan works (the access point is listed with a strong signal). 2. As soon as association starts, the IOMMU reports two faults for the Wi-Fi device: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [0000:03:00.0] fault addr 0xfffa3000 [fault reason 0x06] PTE Read access is not set DMAR: [DMA Read NO_PASID] Request device [0000:03:00.0] fault addr 0xfffa5000 [fault reason 0x06] PTE Read access is not set (the addresses vary between boots, e.g. 0xfff64000 / 0xfff65000) 3. The firmware stops answering: ieee80211 phy0: brcmf_msgbuf_query_dcmd: Timeout on response for query command ieee80211 phy0: brcmf_get_assoc_ies: could not get assoc info (-5) 4. After a few minutes the control ring fills up: ieee80211 phy0: brcmf_msgbuf_tx_ioctl: Failed to reserve space in commonring ieee80211 phy0: brcmf_run_escan: error (-12) 5. NetworkManager: "association took too long, failing activation", reason 'ssid-not-found', retried forever. WORKAROUND Adding intel_iommu=off to the kernel command line. With it, on the same kernel (7.3.0-8-generic): no DMAR fault, no firmware timeout, association succeeds within seconds and traffic flows (IPv4 and IPv6). The usual BCM43602 workarounds were already in place and did not help: options brcmfmac feature_disable=0x82000 roamoff=1 options cfg80211 ieee80211_regdom=FR SYSTEM Release: Ubuntu 26.10 "Stonking Stingray" (development branch) Kernel: 7.3.0-8-generic (7.3.0-8.8, based on 7.3.0-rc5); also 7.3.0-5.5 and 7.3.0-6.6 Machine: Apple iMac18,2 Wi-Fi: Broadcom BCM43602 802.11ac [14e4:43ba] rev 01, subsystem Apple [106b:016e] Driver: brcmfmac (in-tree), firmware brcm/brcmfmac43602-pcie Firmware: BCM43602/1 wl0: Nov 10 2015 06:38:10 version 7.35.177.61 (r598657) FWID 01-ea662a8c linux-firmware: 20260915.git1522c78a wpasupplicant: 2:2.11-2ubuntu2 Kernel config: CONFIG_INTEL_IOMMU_DEFAULT_ON=y, CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON=y, IOMMU default domain type "Translated", lazy TLB invalidation Secure Boot: not supported on this machine Note: a custom NVRAM file /lib/firmware/brcm/brcmfmac43602-pcie.txt was added on 2026-09-20 while trying to fix this. The failure already occurred on the boots before that file existed. Note: the logs attached automatically by apport come from a boot with intel_iommu=off (working). Kernel log excerpts from a failing boot (default command line) are attached separately as dmesg-failing- boot.txt. ProblemType: Bug DistroRelease: Ubuntu 26.10 Package: linux-image-7.3.0-8-generic 7.3.0-8.8 ProcVersionSignature: Ubuntu 7.3.0-8.8-generic 7.3.0-rc5 Uname: Linux 7.3.0-8-generic x86_64 ApportVersion: 2.36.0-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: parents 18057 F.... wireplumber /dev/snd/controlC1: parents 18057 F.... wireplumber /dev/snd/seq: parents 18053 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Oct 2 22:10:14 2026 InstallationDate: Installed on 2026-09-19 (13 days ago) InstallationMedia: Ubuntu 26.10 "Stonking Stingray" - Daily amd64 (20260915) MachineType: Apple Inc. iMac18,2 ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.3.0-8-generic root=UUID=449c41b8-da4d-4c34-ad74-1f7a5e150bb0 ro quiet splash intel_iommu=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/11/2022 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 451.140.1.0.0 dmi.board.name: Mac-77F17D7DA9285301 dmi.board.vendor: Apple Inc. dmi.board.version: iMac18,2 dmi.chassis.type: 9 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-77F17D7DA9285301 dmi.modalias: dmi:bvnAppleInc.:bvr451.140.1.0.0:bd04/11/2022:br0.1:svnAppleInc.:pniMac18,2:pvr1.0:rvnAppleInc.:rnMac-77F17D7DA9285301:rvriMac18,2:cvnAppleInc.:ct9:cvrMac-77F17D7DA9285301:sku:pfaiMac: dmi.product.family: iMac dmi.product.name: iMac18,2 dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169339/+subscriptions
[Bug 2169338] Re: Kernel oops / GPF in path_is_under() from complete_walk() on openat — 7.0.0-34/-38-generic and 7.0.0-1017-azure, Hyper-V Gen2 guest
Thanks a lot for your updates. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169338 Title: Kernel oops / GPF in path_is_under() from complete_walk() on openat — 7.0.0-34/-38-generic and 7.0.0-1017-azure, Hyper-V Gen2 guest Status in linux package in Ubuntu: New Status in linux-azure package in Ubuntu: New Bug description: An Ubuntu 26.04.1 LTS VM on Hyper-V repeatedly oopses in path_is_under(), called from complete_walk() during openat(). The faulting address is a different garbage value each time: either fffffffffffffff0 or a non-canonical pointer. That suggests a corrupted or freed struct mount being walked through mnt_parent. With panic_on_oops=0 the task dies holding a lock, every later bubblewrap (bwrap) process soft-locks in create_user_ns -> alloc_ucounts / current_chrooted -> _raw_spin_lock, and the system wedges. With panic_on_oops=1 it panics and reboots. Reproduced on three kernel builds within ~28 hours: - 7.0.0-34-generic: 3 oopses (Comm: MainThread x2, depmod) - 7.0.0-38-generic: 1 oops (Comm: MainThread) - 7.0.0-1017-azure (7.0.14 base): 1 oops (Comm: git) == Environment == - Ubuntu 26.04.1 LTS (resolute), cloud image (ubuntu-26.04-server-cloudimg-amd64.img) - Hyper-V Gen 2 VM on Windows 11 Pro 26200, Secure Boot (MS UEFI CA), 8 vCPU, 8 GB static RAM (Dynamic Memory was enabled for the first incident; disabled since), 8 GB swapfile, ext4 root - Host CPU: Intel Core i9-14900K - kernel.apparmor_restrict_unprivileged_userns=1 (default) == Trace (7.0.0-1017-azure, representative) == Oops: general protection fault, probably for non-canonical address 0xaa72f400ffffffef: 0000 [#1] SMP NOPTI CPU: 0 UID: 1000 PID: 45217 Comm: git Not tainted 7.0.0-1017-azure #17-Ubuntu PREEMPTLAZY Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025 RIP: 0010:path_is_under+0x60/0xa0 Call Trace: complete_walk+0x9c/0xc0 do_open+0x1b3/0x400 path_openat+0x113/0x290 do_file_open+0xdf/0x1a0 do_sys_openat2+0x7a/0xe0 __x64_sys_openat+0x5f/0xa0 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Kernel panic - not syncing: Fatal exception On -generic the first oops was "BUG: unable to handle page fault for address: fffffffffffffff0" at path_is_under+0x50/0x90 with the same call chain. == Workload / when it happens == - The VM ran cleanly for ~24h, then oopsed repeatedly once it was used as a development box: Claude Code (Node/Bun), git, pnpm, Chrome under XFCE/xrdp, and Tailscale. - Faulting tasks are ordinary file opens by unprivileged processes (MainThread = Claude Code's main thread, git) and root (depmod during a kernel package postinst). - Intervals between oopses ranged from ~1 minute to ~2 hours of uptime. == Ruled out == - Filesystem: a forced e2fsck of root was clean apart from an "extent tree could be narrower" optimisation note. - Memory pressure: it reproduces with static RAM and >5 GB free; no OOM events. - Host problems: no host errors, and a WSL2 guest on the same host is unaffected. == Possibly related == The first incident followed Hyper-V Dynamic Memory hot-add failures 6 minutes earlier: "40-vm-hotadd.rules: Failed to write 'online'" and "workqueue: hot_add_req [hv_balloon] hogged CPU". Dynamic Memory has been off since, and the oopses continue. == Attachments == - oops-all-6-crashes.txt: full oops texts from systemd-pstore (efi_pstore) for every incident - hyperv-guest-crash-events.txt: Hyper-V Worker event 18590, which includes the guest's final kmsg - system-info.txt: version_signature, uname, installed kernels, cmdline, CPU/memory, userns settings --- ProblemType: Bug AlsaDevices: total 0 crw-rw---- 1 root audio 116, 1 Oct 6 21:56 seq crw-rw---- 1 root audio 116, 33 Oct 6 21:56 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20260927 CloudSubPlatform: config-disk (/dev/sdb1) DistroRelease: Ubuntu 26.04 Lspci: Lspci-vt: Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Microsoft Corporation Virtual Machine Package: linux-azure (not installed) PciMultimedia: ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=unknown ProcFB: 0 hyperv_drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-38-generic root=UUID=747687d9-c20c-41f8-bfb8-7f4a57910c51 ro console=tty1 console=ttyS0 ProcVersionSignature: Ubuntu 7.0.0-38.38-generic 7.0.14 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: cloud-image resolute Uname: Linux 7.0.0-38-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 09/25/2025 dmi.bios.release: 4.1 dmi.bios.vendor: Microsoft Corporation dmi.bios.version: Hyper-V UEFI Release v4.1 dmi.board.asset.tag: None dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: Hyper-V UEFI Release v4.1 dmi.chassis.asset.tag: 3897-2538-6803-7408-7643-1671-78 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: Hyper-V UEFI Release v4.1 dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev4.1:bd09/25/2025:br4.1:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev4.1:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev4.1:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev4.1:skuNone:pfaVirtualMachine: dmi.product.family: Virtual Machine dmi.product.name: Virtual Machine dmi.product.sku: None dmi.product.version: Hyper-V UEFI Release v4.1 dmi.sys.vendor: Microsoft Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169338/+subscriptions
[Bug 2170396] Re: Lenovo Legion screen flickering on Kubuntu 26.04 (Fixed by lowering brightness / 165Hz conflict)
Trying to upload dmesg once again failed: Timeout error Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience. Trying again in a couple of minutes might work. If you report this as a bug, please include the error ID below, preferably by copying and pasting it rather than by taking a screenshot. (Error ID: OOPS-c4d7a1b4a813cc3750c6e2a1a0165880) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2170396 Title: Lenovo Legion screen flickering on Kubuntu 26.04 (Fixed by lowering brightness / 165Hz conflict) Status in linux package in Ubuntu: New Bug description: I installed Kubuntu 26.04 on my Lenovo Legion laptop (NVIDIA graphics) and experienced severe screen flickering. Key behaviors observed: • The panel natively runs at 165.04Hz. • Forcing the refresh rate down to 60Hz via kscreen-doctor temporarily improved the flickering but did not resolve it. • Forcing "Discrete Graphics" in the BIOS resulted in a total black screen upon OS load. • Crucial Hardware Link: Lowering the screen brightness manually to 30% reduces the flickering to minimal/manageable levels, suggesting a power-delivery/backlight voltage or PWM conflict with the modern kernel's power-saving features. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-38-generic 7.0.0-38.38 ProcVersionSignature: Ubuntu 7.0.0-38.38-generic 7.0.14 Uname: Linux 7.0.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: jgw 1549 F.... pipewire jgw 1561 F.... wireplumber /dev/snd/controlC0: jgw 1561 F.... wireplumber /dev/snd/seq: jgw 1549 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Fri Oct 9 19:23:43 2026 InstallationDate: Installed on 2026-10-07 (2 days ago) InstallationMedia: Kubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826.1) MachineType: LENOVO 82TF ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-38-generic root=UUID=3ad3b9bb-66ac-4411-a956-601a55f3254c ro quiet splash pcie_aspm=off acpi_backlight=native 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: 03/03/2025 dmi.bios.release: 1.58 dmi.bios.vendor: LENOVO dmi.bios.version: JYCN58WW dmi.board.asset.tag: No Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76461WIN dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion S7 16IAH7 dmi.ec.firmware.release: 1.55 dmi.modalias: dmi:bvnLENOVO:bvrJYCN58WW:bd03/03/2025:br1.58:efr1.55:svnLENOVO:pn82TF:pvrLegionS716IAH7:rvnLENOVO:rnLNVNB161216:rvrSDK0T76461WIN:cvnLENOVO:ct10:cvrLegionS716IAH7:skuLENOVO_MT_82TF_BU_idea_FM_LegionS716IAH7:pfaLegionS716IAH7: dmi.product.family: Legion S7 16IAH7 dmi.product.name: 82TF dmi.product.sku: LENOVO_MT_82TF_BU_idea_FM_Legion S7 16IAH7 dmi.product.version: Legion S7 16IAH7 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170396/+subscriptions
[Bug 2170917] Re: No internal microphone on AMD systems with RT712-VB SoundWire codec
** 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/2170917 Title: No internal microphone on AMD systems with RT712-VB SoundWire codec Status in HWE Next: New Status in linux package in Ubuntu: In Progress Status in linux-oem-7.3 package in Ubuntu: Invalid Status in linux source package in Resolute: Invalid Status in linux-oem-7.3 source package in Resolute: In Progress Status in linux source package in Stonking: In Progress Status in linux-oem-7.3 source package in Stonking: Invalid Bug description: [Impact] On some AMD systems with an RT712-VB SoundWire codec and TAS2783 amplifiers, the internal microphone and speakers don't show up. The machine driver needed to enable them is 28114992dd2f ("ASoC: amd: acp: enable TAS2783 and add RT712-VB SoundWire machine"). That commit makes SND_SOC_AMD_LEGACY_SDW_MACH select SND_SOC_TAS2783_SDW without checking its dependencies. The codec also needs SND_SOC_SDCA andEFI. With EFI=n, the build warns: WARNING: unmet direct dependencies detected for SND_SOC_TAS2783_SDW Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SOUNDWIRE [=m] && SND_SOC_SDCA [=m] && EFI [=n] Selected by [m]: - SND_SOC_AMD_LEGACY_SDW_MACH [=m] && ... The codec is force-enabled when its dependencies are not met. This can break builds and configs. [Fix] Two Kconfig fixes for the above commit. Both are in sound/soc/amd/acp/Kconfig. d06607bafb36 ASoC: amd: acp: fix TAS2783 SoundWire codec unmet dependencies Changes the select to "select SND_SOC_TAS2783_SDW if SND_SOC_SDCA && EFI". 4d2b92b82ee8 ASoC: amd: acp: add EFI dependency for selecting TAS2783 Makes SND_SOC_AMD_LEGACY_SDW_MACH depend on EFI. Both commits are merged upstream in the ASoC tree (Mark Brown). Neither is in a released v* tag yet. Links: https://patch.msgid.link/20260924124205.3376083-1-syed.sabakareem@amd.com https://patch.msgid.link/20260925131137.146638-1-arnd@kernel.org [Test Plan] Check the config with EFI off: $ scripts/config --disable EFI $ make olddefconfig Without patches: the "unmet direct dependencies detected for SND_SOC_TAS2783_SDW" warning shows up. With patches: no warning. On the Ubuntu config (EFI=y, SDCA=m), check the codec is still built: $ grep -E 'SND_SOC_TAS2783_SDW|SND_SOC_AMD_LEGACY_SDW_MACH' .config Both should be =m. On an affected AMD machine, check the microphone is still present: $ arecord -l The internal digital mic capture device should be listed. [Where problems could occur] Could break the AMD ACP SoundWire machine driver (snd-acp-sdw-legacy-mach) and the TAS2783 codec build. If the Kconfig conditions are wrong, the TAS2783 codec or the machine driver would not be built. The system would then have no internal microphone or speakers on the affected AMD systems. The new EFI dependency would also hide the machine driver in configs without EFI. Ubuntu kernels enable EFI, so this should not matter for them. The change only touches Kconfig. It has no runtime code change. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2170917/+subscriptions
[Bug 2171020] Re: PCI/PM: Restore BARs after powering up during enumeration
** 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/2171020 Title: PCI/PM: Restore BARs after powering up during enumeration Status in linux package in Ubuntu: New Bug description: Gather the crash kernel, which hangs. This issue was reported by HPE Commit 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing") added pci_pm_power_up_and_verify_state() to pci_pm_init(). The helper ignores pci_power_up()'s return value indicating that BARs need restoring. Its resume callers restore saved configuration afterwards; pci_pm_init() does not. D3hot-to-D0 may reset a device and lose its BARs (PCI PM 1.2, sec 5.4.1). After enumeration powers it up, pci_enable_device() reads D0 and skips the full power-up path. Previously, a device still in D3hot at enable time took that path, including BAR restoration. On AMD Venice SP7, two AMD xHCI controllers [1022:17d2] are in runtime D3hot with No_Soft_Reset clear before kdump. Diagnostic reads on v7.3-rc6-37 show the following for 0000:01:00.4 in the crash kernel: PMCSR BAR0 before the platform power call 0003 f4100004 after the platform power call 0003 f4100004 after native D0 power-up 0000 00000004 The upper BAR DWORD stays zero. pci_power_up() returns 1, but the BAR address remains zero while dev->resource[0] still contains 0xf4100000. Without BAR restoration, the crash kernel hangs during boot. The last console output includes: pci 0000:01:00.4: enabling device (0000 -> 0002) Restoring both controllers' BARs gives matching readbacks and allows kdump to save a vmcore and reboot. An AMD Turin xHCI [1022:1557] shows the same BAR loss; restoring its BAR also allows kdump to complete. Read the initial power state first. Otherwise, pci_power_up() may request a BAR restore based on a cached PCI_UNKNOWN state, even when the device is already in D0. For devices already in D0, only synchronize the platform state so that ACPI calls such as _REG still run. For other states, use pci_set_full_power_state() to power up the device and restore BARs when needed. Impact : kdump to save a vmcore and reboot with this fix. Without it , it hangs. See description above. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2171020/+subscriptions
[Bug 2141741] Re: 55-initrd.install silently exits 0 when initrd missing causing undetectable kernel panic on NVMe systems
** Changed in: grub2 (Debian) Status: Unknown => New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2141741 Title: 55-initrd.install silently exits 0 when initrd missing causing undetectable kernel panic on NVMe systems Status in grub2 package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in grub2 package in Debian: New Bug description: [ Impact ] When a kernel postinst hook fails (e.g. DKMS module build failure), the kernel package remains half-configured: vmlinuz is installed and /usr/lib/linux/triggers/<version> is present, but no matching initrd is generated. A subsequent update-grub invocation (such as during removal of an older kernel) scans /boot and generates a boot menuentry for the incomplete kernel without an initrd line. On systems where storage drivers (NVMe, SATA, SAS) are built as modules, booting this entry causes an immediate, undetectable kernel panic (VFS: Unable to mount root fs on unknown-block(0,0)). [ Fix ] In /etc/grub.d/10_linux, when inspecting a kernel where no initrd was found (test -z "${initrd_real}"), check if a pending kernel trigger marker exists in /usr/lib/linux/triggers/${version} or /usr/lib/linux/triggers/${alt_version}. If the trigger marker is present, skip generating a boot menuentry for that kernel image. This prevents update-grub from publishing unbootable kernels to grub.cfg. [ Test Plan ] 1. Simulate an incomplete kernel installation: sudo touch /boot/vmlinuz-9.9.0-test-generic sudo touch /usr/lib/linux/triggers/9.9.0-test-generic sudo rm -f /boot/initrd.img-9.9.0-test-generic 2. Run sudo update-grub. 3. Verify behavior: - Without fix: GRUB outputs "Found linux image: /boot/vmlinuz-9.9.0-test-generic" and writes a stanza lacking an initrd line. - With fix: GRUB outputs "Skipping linux image with pending post-installation trigger and no initrd: /boot/vmlinuz-9.9.0-test-generic", and no stanza is generated. 4. Clean up test files (sudo rm -f /boot/vmlinuz-9.9.0-test-generic /usr/lib/linux/triggers/9.9.0-test-generic) and verify standard installed kernels generate valid boot entries. [ Where problems could occur ] The check only triggers when both conditions are met: initrd_real is empty AND a trigger marker exists in /usr/lib/linux/triggers/. Custom kernels intentionally configured without an initrd do not have markers under /usr/lib/linux/triggers/ and continue to work as before. If a kernel postinst script fails to clean up its trigger marker after a successful run, that kernel would be skipped until the stale marker is removed. [ Other Info ] - Debian BTS bug: https://bugs.debian.org/1151014 - Development series (stonking): debdiff prepared against 2.14-2ubuntu3 (version 2.14-2ubuntu4). - Stable SRU (noble): debdiff prepared against 2.12-1ubuntu7.3 (version 2.12-1ubuntu7.4). - PPA test builds: ppa:steelf/ppa (grub2 2.14-2ubuntu4~ppa1, grub2 2.12-1ubuntu7.4~ppa1). --- [ Original Report ] ENVIRONMENT: - Ubuntu 24.04 Noble (HWE kernel) - systemd version: 255 (255.4-1ubuntu8.10) - Kernel: 6.17.0-14-generic - Storage: NVMe SSD - File: /usr/lib/kernel/install.d/55-initrd.install - Package owner: systemd (confirmed via dpkg -S) BUG: When initrd generation fails or is skipped during kernel installation, 55-initrd.install detects the missing initrd but exits 0 (success) instead of exit 1 (failure). Relevant code in 55-initrd.install (line 26): if [ -e "$INITRD_SRC" ]; then ln -fs "$INITRD_SRC" "$KERNEL_INSTALL_STAGING_AREA" else echo "$INITRD_SRC does not exist, not installing an initrd" fi exit 0 <- BUG IS HERE This silent success causes GRUB to write a boot entry for a kernel with no initrd, with zero warning to the user. HOW THIS CAUSES KERNEL PANIC: Ubuntu's kernel config has CONFIG_BLK_DEV_NVME=m meaning the NVMe storage driver exists ONLY as a module inside initramfs. Without initramfs: - NVMe driver never loads - Kernel cannot see any storage device - Results in: VFS: Unable to mount root fs on unknown-block(0,0) - KERNEL PANIC on every boot - silent, no warning given HOW I TRIGGERED THIS: virtualbox-dkms 7.0.16 (dfsg) fails to build for kernel 6.17 due to missing VBox/cdefs.h header. DKMS exits code 11. run-parts stops alphabetically - 'd' (dkms) runs before 'i' (initramfs-tools) - so initramfs is never generated. 55-initrd.install then silently exits 0 -> GRUB creates unbootable boot entry -> KERNEL PANIC on reboot. This failed silently 3 days in a row (Feb 11, 12, 13 2026) confirmed in /var/log/dpkg.log and /var/log/apt/term.log. PROPOSED FIX: Change line 26 of 55-initrd.install from: exit 0 to: exit 1 When initrd is missing, this should be a HARD FAILURE not a silent warning. This would cause apt to report the error visibly and prevent GRUB from creating an unbootable boot entry. RELATED BUG: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/2136499 (virtualbox-dkms FTBFS triggers this silent failure) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2141741/+subscriptions
среда
[Bug 2169477] Re: [regression] 6.8.0-146: l2tp/pppol2tp use-after-free -> kernel panic / soft lockup (L2TP/IPsec, xl2tpd)
Can confirm this happens on my machine with the 147 kernel also. I let Claude have a look at it, and this are it's findings: Also reproducible on 6.8.0-147.147 (noble) -- the bad hunk is still present, so this is not fixed by the -147 update. System: Dell Latitude 5530, BIOS 1.29.1, Ubuntu 24.04. VPN: NetworkManager-l2tp (kl2tpd / go-l2tp) + strongSwan, i.e. L2TP over IPsec. Last known good: 6.8.0-142.142. I have not tested -146 myself; I went straight from -142 to -147. Reproducer: activate an L2TP/IPsec connection. The machine hard-freezes within 30-120 seconds of ppp0 coming up (no panic written to disk, no shutdown sequence in the journal, power cycle required). Happened on 2/2 attempts on -147; reverting to -142 makes it go away completely. WHAT THE JOURNAL SHOWS The first warning fires in the same second ppp0 is created, from the L2TP UDP RX softirq path: ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 2872 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x150 CPU: 0 PID: 2872 Comm: kworker/0:5 Not tainted 6.8.0-147-generic #147-Ubuntu Hardware name: Dell Inc. Latitude 5530/0RN5CP, BIOS 1.29.1 04/10/2025 Workqueue: events xfrm_trans_reinject RIP: 0010:refcount_warn_saturate+0x12e/0x150 Call Trace: <TASK> l2tp_tunnel_get_session+0xc8/0xd0 [l2tp_core] l2tp_udp_recv_core+0xb1/0x350 [l2tp_core] ? __pfx_l2tp_udp_encap_recv+0x10/0x10 [l2tp_core] l2tp_udp_encap_recv+0x2c/0x54 [l2tp_core] udp_queue_rcv_one_skb+0x278/0x550 udp_queue_rcv_skb+0x4f/0x80 udp_unicast_rcv_skb+0x7a/0xa0 __udp4_lib_rcv+0x627/0x6f0 udp_rcv+0x25/0x40 ip_protocol_deliver_rcu+0xd8/0x210 ip_local_deliver_finish+0x77/0xa0 ip_local_deliver+0x6e/0x120 ? __pfx_ip_local_deliver_finish+0x10/0x10 xfrm4_rcv_encap_finish2+0x3c/0x60 xfrm_trans_reinject+0xe2/0x170 process_one_work+0x181/0x3a0 worker_thread+0x18b/0x330 kthread+0xef/0x120 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Immediately followed by "refcount_t: underflow; use-after-free" in l2tp_session_dec_refcount+0xbb/0xd0 [l2tp_core] and "refcount_t: saturated; leaking memory" in l2tp_tunnel_get_session+0xbc/0xd0 [l2tp_core], all from the same RX path. Two seconds later the TX side starts tripping over the same freed object, and from then on it warns on *every* packet: WARNING: CPU: 3 PID: 1094 at net/l2tp/l2tp_ppp.c:166 pppol2tp_xmit+0x1e1/0x220 [l2tp_ppp] CPU: 3 PID: 1094 Comm: systemd-resolve Tainted: G W 6.8.0-147-generic #147-Ubuntu Call Trace: <TASK> ppp_push+0xaf/0x110 ppp_send_frame+0x1e8/0x530 __ppp_xmit_process+0x88/0x100 ppp_xmit_process+0x3d/0xb0 ppp_start_xmit+0x159/0x200 dev_hard_start_xmit+0x62/0x1e0 __dev_queue_xmit+0x709/0x910 neigh_direct_output+0x13/0x20 ip_finish_output2+0x196/0x480 ... That is the WARN_ON(session->magic != L2TP_SESSION_MAGIC) inside the inlined pppol2tp_sock_to_session(). I counted 704 of these in ~2 minutes (24 in the first minute, 90, then 241 in the third). Each one dumps the full module list and a stack trace, which is what ultimately wedges the box. ANALYSIS I compared the shipped modules from -142 and -147: * l2tp_core.ko is byte-identical between the two (objdump -d output diffs clean apart from the filename), so l2tp_core itself did not change. * l2tp_ppp.ko changed in exactly two functions: pppol2tp_connect (+7 bytes, one added store, from the ppp RCU-free backport) and pppol2tp_ioctl (+126 bytes). The pppol2tp_ioctl change is the -146 backport of l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() (upstream stable patchset 2026-08-21, LP: #2164796 // CVE-2026-53262) and I believe it has been applied incorrectly for this tree. Disassembly of pppol2tp_ioctl in 6.8.0-147: 1a78: mov 0x18(%r8),%rbx ; rbx = sock->sk 1aa6: lock xadd %eax,0x80(%rbx) ; sock_hold(sk) -> ref on the SOCKET 1ac1: mov 0x278(%rbx),%r13 ; session = sk->sk_user_data 1ad1: cmpl $0xc04eb7d,0x0(%r13) ; session->magic == L2TP_SESSION_MAGIC ... 1b0c: call l2tp_session_dec_refcount ; -> ref dropped on the SESSION It takes the reference on the socket (6.8's pppol2tp_sock_to_session() still does sock_hold(sk)) but releases it on the session. Counting relocations in the two builds: l2tp_tunnel_get_session l2tp_session_dec_refcount 6.8.0-142 1 2 6.8.0-147 1 3 In -142 both dec_refcount calls pair with the single l2tp_tunnel_get_session() in the PPPIOCGL2TPSTATS peer-session path. In -147 there are three, and the two extra ones are on the generic exit paths, where nothing ever took a session reference. The matching sock_put(sk) only happens on the !session / bad-magic error paths, so on every *successful* ioctl the socket refcount is leaked and the session refcount is decremented once too often. The ioctl handler in -147 accepts 0x40047452, 0x40047459, 0x80047453, 0x8004745a and 0x80487436, i.e. PPPIOCSMRU, PPPIOCSFLAGS, PPPIOCGMRU, PPPIOCGFLAGS and PPPIOCGL2TPSTATS. pppd issues PPPIOCSMRU and PPPIOCSFLAGS on the PPPoL2TP session socket during link setup, so session->ref_count is driven to zero within a second of the tunnel coming up. The session is freed while still linked into the tunnel, l2tp_tunnel_get_session() then hits "addition on 0" on the next inbound packet, and pppol2tp_xmit()'s magic check fails forever after -- exactly the sequence above. Suggested fix: on 6.8, where pppol2tp_sock_to_session() returns with a sock_hold() on sk, those exit paths need sock_put(sk) rather than l2tp_session_dec_refcount(session). The upstream commit applies to a tree where the lookup helper hands back a session-refcounted pointer, which is why it does not transplant as-is. (Caveat: this is binary-level analysis of the shipped modules, I have not built a test kernel to confirm it.) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169477 Title: [regression] 6.8.0-146: l2tp/pppol2tp use-after-free -> kernel panic / soft lockup (L2TP/IPsec, xl2tpd) Status in linux package in Ubuntu: Confirmed Bug description: Package: linux (Ubuntu Noble) Affected: linux-image-6.8.0-146-generic 6.8.0-146.146 Last good: 6.8.0-142.142 (also 6.8.0-139.139) == Summary == After upgrading from 6.8.0-142 to 6.8.0-146, a host acting as an L2TP/IPsec server (LNS) and client (LAC) at the same time crashes within 1-10 minutes of boot: kernel panic ("Fatal exception in interrupt") or a permanent soft lockup. 11 crashes in ~2 hours, all on 6.8.0-146, all inside l2tp_core/l2tp_ppp. Booting back into 6.8.0-142 fixes it completely (no warnings at all since). Among the l2tp modules, only l2tp_ppp.ko changed between 142 and 146: l2tp_core srcversion: D5976517E8DDA0096C46F58 (139, 142, 146 - identical) l2tp_ppp srcversion: 410F7BD8BFBF7AF73E5803E (139, 142) 5FE6350B4BF3E0647293B12 (146) Suspected commit (146 changelog, LP: #2164796, CVE-2026-53262): "l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()" All failures are refcount errors on the L2TP session object and the faults that follow from them, which suggests an unbalanced session reference in the backport. == Environment == Ubuntu 24.04.5 LTS, x86_64 Hardware: YF ADLNN01 (Intel N150), BIOS 5.27 12/17/2025, 4x Intel I226-V (igc) xl2tpd 1.3.18-1build2, ppp 2.4.9-1+1.1ubuntu4, strongswan 5.9.13-2ubuntu4.24.04.5 Kernel-mode L2TP (l2tp_ppp), L2TP over IPsec transport (ESP in UDP 4500), xl2tpd configured with one [lns default] (several clients) plus one [lac] with redial=yes, redial timeout=30. == Reproduction == 1. Boot 6.8.0-146 with xl2tpd (LNS + LAC) over strongswan IPsec. 2. Let 2-3 L2TP tunnels come up; reconnects / session teardown happen. 3. Within 1-10 minutes: refcount warnings, then panic or soft lockup. Not reproducible on 6.8.0-142 (4 boots, hours of uptime, zero warnings). == Crash signatures (6.8.0-146) == 1) refcount UAF on RX path (first symptom on every bad boot) refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 42 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x150 Workqueue: events xfrm_trans_reinject l2tp_tunnel_get_session+0xc8/0xd0 [l2tp_core] l2tp_udp_recv_core+0xb1/0x350 [l2tp_core] l2tp_udp_encap_recv+0x2c/0x54 [l2tp_core] udp_queue_rcv_one_skb / __udp4_lib_rcv / udp_rcv followed by: refcount_t: underflow; use-after-free. (l2tp_session_dec_refcount+0xbb <- l2tp_udp_recv_core+0x103) refcount_t: saturated; leaking memory. 2) NULL pointer dereference on TX path -> panic BUG: kernel NULL pointer dereference, address: 000000000000002d CPU: 2 PID: 2608 Comm: pppd Tainted: G W 6.8.0-146-generic #146-Ubuntu xfrm_dst_check+0x24/0x40 __sk_dst_check+0x8f/0xa0 __ip_queue_xmit+0x2a0/0x510 l2tp_xmit_core.constprop.0+0x225/0x460 [l2tp_core] l2tp_xmit_skb+0x30/0xa0 [l2tp_core] pppol2tp_xmit+0x114/0x220 [l2tp_ppp] Kernel panic - not syncing: Fatal exception in interrupt (other instances: RIP _raw_spin_lock+0x13 / pppol2tp_xmit+0x1e1) 3) Soft lockup in tunnel deletion (host hangs, no auto-reboot) watchdog: BUG: soft lockup - CPU#1 stuck for 26s..130s! [kworker/u8:3:176] Workqueue: l2tp l2tp_tunnel_del_work [l2tp_core] RIP: _raw_spin_lock_bh+0x1b / l2tp_tunnel_del_work+0x98 l2tp_tunnel_del_work+0x8d/0x1b0 [l2tp_core] process_one_work / worker_thread / kthread preceded by a warning in pppol2tp_release+0x153 [l2tp_ppp] (sock close path). Some dumps also show faults in __mptcp_close_ssk / tcp_release_cb_override / xfrm_bundle_ok after the l2tp refcount warnings. These are most likely secondary memory corruption. == Boot statistics == 6.8.0-139: 16 days uptime, no issues 6.8.0-146: 13 boots in 2h, 11 pstore crash dumps (all l2tp), boots in between ended in hard hangs 6.8.0-142: 4 boots, 0 refcount warnings, 0 soft lockups, 0 l2tp traces == Attachments == pstore/*.txt - EFI pstore dumps (systemd-pstore). Inside each file the parts are in reverse order (PartN first). IPv4/MAC addresses redacted. == Workaround == Pin 6.8.0-142 in GRUB and hold linux-image-generic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169477/+subscriptions
[Bug 2170917] Re: No internal microphone on AMD systems with RT712-VB SoundWire codec
** Tags added: amd oem-priority originate-from-2167678 ** Tags added: jira-stella-4286 stella -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2170917 Title: No internal microphone on AMD systems with RT712-VB SoundWire codec Status in HWE Next: New Status in linux package in Ubuntu: In Progress Status in linux-oem-7.3 package in Ubuntu: Invalid Status in linux source package in Resolute: Invalid Status in linux-oem-7.3 source package in Resolute: In Progress Status in linux source package in Stonking: In Progress Status in linux-oem-7.3 source package in Stonking: Invalid Bug description: [Impact] On some AMD systems with an RT712-VB SoundWire codec and TAS2783 amplifiers, the internal microphone and speakers don't show up. The machine driver needed to enable them is 28114992dd2f ("ASoC: amd: acp: enable TAS2783 and add RT712-VB SoundWire machine"). That commit makes SND_SOC_AMD_LEGACY_SDW_MACH select SND_SOC_TAS2783_SDW without checking its dependencies. The codec also needs SND_SOC_SDCA andEFI. With EFI=n, the build warns: WARNING: unmet direct dependencies detected for SND_SOC_TAS2783_SDW Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SOUNDWIRE [=m] && SND_SOC_SDCA [=m] && EFI [=n] Selected by [m]: - SND_SOC_AMD_LEGACY_SDW_MACH [=m] && ... The codec is force-enabled when its dependencies are not met. This can break builds and configs. [Fix] Two Kconfig fixes for the above commit. Both are in sound/soc/amd/acp/Kconfig. d06607bafb36 ASoC: amd: acp: fix TAS2783 SoundWire codec unmet dependencies Changes the select to "select SND_SOC_TAS2783_SDW if SND_SOC_SDCA && EFI". 4d2b92b82ee8 ASoC: amd: acp: add EFI dependency for selecting TAS2783 Makes SND_SOC_AMD_LEGACY_SDW_MACH depend on EFI. Both commits are merged upstream in the ASoC tree (Mark Brown). Neither is in a released v* tag yet. Links: https://patch.msgid.link/20260924124205.3376083-1-syed.sabakareem@amd.com https://patch.msgid.link/20260925131137.146638-1-arnd@kernel.org [Test Plan] Check the config with EFI off: $ scripts/config --disable EFI $ make olddefconfig Without patches: the "unmet direct dependencies detected for SND_SOC_TAS2783_SDW" warning shows up. With patches: no warning. On the Ubuntu config (EFI=y, SDCA=m), check the codec is still built: $ grep -E 'SND_SOC_TAS2783_SDW|SND_SOC_AMD_LEGACY_SDW_MACH' .config Both should be =m. On an affected AMD machine, check the microphone is still present: $ arecord -l The internal digital mic capture device should be listed. [Where problems could occur] Could break the AMD ACP SoundWire machine driver (snd-acp-sdw-legacy-mach) and the TAS2783 codec build. If the Kconfig conditions are wrong, the TAS2783 codec or the machine driver would not be built. The system would then have no internal microphone or speakers on the affected AMD systems. The new EFI dependency would also hide the machine driver in configs without EFI. Ubuntu kernels enable EFI, so this should not matter for them. The change only touches Kconfig. It has no runtime code change. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2170917/+subscriptions
[Bug 2170917] Re: No internal microphone on AMD systems with RT712-VB SoundWire codec
** Also affects: linux-oem-7.3 (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux-oem-7.0 (Ubuntu) ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-7.3 (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-7.3 (Ubuntu Resolute) 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/2170917 Title: No internal microphone on AMD systems with RT712-VB SoundWire codec Status in HWE Next: New Status in linux package in Ubuntu: In Progress Status in linux-oem-7.3 package in Ubuntu: Invalid Status in linux source package in Resolute: Invalid Status in linux-oem-7.3 source package in Resolute: In Progress Status in linux source package in Stonking: In Progress Status in linux-oem-7.3 source package in Stonking: Invalid Bug description: [Impact] On some AMD systems with an RT712-VB SoundWire codec and TAS2783 amplifiers, the internal microphone and speakers don't show up. The machine driver needed to enable them is 28114992dd2f ("ASoC: amd: acp: enable TAS2783 and add RT712-VB SoundWire machine"). That commit makes SND_SOC_AMD_LEGACY_SDW_MACH select SND_SOC_TAS2783_SDW without checking its dependencies. The codec also needs SND_SOC_SDCA andEFI. With EFI=n, the build warns: WARNING: unmet direct dependencies detected for SND_SOC_TAS2783_SDW Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SOUNDWIRE [=m] && SND_SOC_SDCA [=m] && EFI [=n] Selected by [m]: - SND_SOC_AMD_LEGACY_SDW_MACH [=m] && ... The codec is force-enabled when its dependencies are not met. This can break builds and configs. [Fix] Two Kconfig fixes for the above commit. Both are in sound/soc/amd/acp/Kconfig. d06607bafb36 ASoC: amd: acp: fix TAS2783 SoundWire codec unmet dependencies Changes the select to "select SND_SOC_TAS2783_SDW if SND_SOC_SDCA && EFI". 4d2b92b82ee8 ASoC: amd: acp: add EFI dependency for selecting TAS2783 Makes SND_SOC_AMD_LEGACY_SDW_MACH depend on EFI. Both commits are merged upstream in the ASoC tree (Mark Brown). Neither is in a released v* tag yet. Links: https://patch.msgid.link/20260924124205.3376083-1-syed.sabakareem@amd.com https://patch.msgid.link/20260925131137.146638-1-arnd@kernel.org [Test Plan] Check the config with EFI off: $ scripts/config --disable EFI $ make olddefconfig Without patches: the "unmet direct dependencies detected for SND_SOC_TAS2783_SDW" warning shows up. With patches: no warning. On the Ubuntu config (EFI=y, SDCA=m), check the codec is still built: $ grep -E 'SND_SOC_TAS2783_SDW|SND_SOC_AMD_LEGACY_SDW_MACH' .config Both should be =m. On an affected AMD machine, check the microphone is still present: $ arecord -l The internal digital mic capture device should be listed. [Where problems could occur] Could break the AMD ACP SoundWire machine driver (snd-acp-sdw-legacy-mach) and the TAS2783 codec build. If the Kconfig conditions are wrong, the TAS2783 codec or the machine driver would not be built. The system would then have no internal microphone or speakers on the affected AMD systems. The new EFI dependency would also hide the machine driver in configs without EFI. Ubuntu kernels enable EFI, so this should not matter for them. The change only touches Kconfig. It has no runtime code change. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2170917/+subscriptions
[Bug 2161448] Re: mt7921u: USB Wi-Fi enters unrecoverable state after prolonged uptime; NetworkManager/supplicant stalls followed by USB disconnect deadlock
Hello Krystian, in August you mentioned you could try to bring Sean Wang's mt76 USB fix into the Ubuntu kernel. The full series has since landed in v7.3-rc1 ("harden USB reset and disconnect paths": d23353688dd0, 161596f033e8, e137e5fd245c, 7910bd565d8b, a4803d1801c7, b994cb409f21, with the dependency 5323d3e50c20). I see the same MT7921AU USB hang on resolute (7.0.0-38): the whole chip (WiFi and Bluetooth) stops answering, with "vendor request ... failed:-110" every ~3 s, and only a reboot recovers it. Logs are in LP#2167595, comment #16. Would you consider an SRU of this series for resolute (and noble HWE)? I can test a PPA or -proposed kernel on affected hardware. Thank you, Piotr -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161448 Title: mt7921u: USB Wi-Fi enters unrecoverable state after prolonged uptime; NetworkManager/supplicant stalls followed by USB disconnect deadlock Status in linux package in Ubuntu: Confirmed Bug description: Netgear A8000 (MediaTek mt7921u/mt7922 USB) intermittently loses connectivity after many hours or overnight. The interface remains associated with the AP and retains a DHCP address, but no traffic passes. Symptoms: nmcli shows connected or attempts reconnection. Ping to the default gateway returns "Destination Host Unreachable". Kernel repeatedly logs: unregister_netdevice: waiting for wlx... to become free. Usage count = 2 Previous debugging showed tee blocked inside mt792xu_disconnect() during usb_unbind_interface(). Restarting sudo systemctl restart wpa_supplicant NetworkManager immediately restores connectivity without unplugging the adapter or rebooting. Additional observations USB runtime power management disabled (power/control=on) rfkill not blocked interface still exists during failure Wi-Fi PHY still present NetworkManager restart does not recover the severe failure USB unbind hangs Driver unload therefore cannot complete NOTE: I also have a 394 MB apport report. Would it be useful, or are the attached failure-time logs sufficient? --- ProblemType: Bug ApportVersion: 2.28.2-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ysuhail 2853 F.... wireplumber /dev/snd/controlC0: ysuhail 2853 F.... wireplumber /dev/snd/seq: ysuhail 2851 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 24.04 InstallationDate: Installed on 2026-06-25 (28 days ago) InstallationMedia: Ubuntu-Server 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) MachineType: ASUS System Product Name Package: linux (not installed) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-28-generic root=UUID=8bb051d9-0961-4018-b123-40eba5aa4bdb ro nomodeset pcie_aspm=off loglevel=3 ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12 RelatedPackageVersions: linux-restricted-modules-7.0.0-28-generic N/A linux-backports-modules-7.0.0-28-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no Tags: noble Uname: Linux 7.0.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users _MarkForUpload: True dmi.bios.date: 07/18/2025 dmi.bios.release: 12.3 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1203 dmi.board.asset.tag: Default string dmi.board.name: Pro WS WRX90E-SAGE SE dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1203:bd07/18/2025:br12.3:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnProWSWRX90E-SAGESE:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161448/+subscriptions
[Bug 2167595] Re: mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc, blocks rtnl_lock and shutdown
LP#2167595 - second real-world failure, now with the v3 patch on 7.0.0-38 == Environment == - Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic - v3 patch built out of tree and loaded from /lib/modules/7.0.0-38-generic/updates/ (mt792x_usb srcversion BF5F60AFAFBFC93CA662D26, mt7921_common srcversion 9336B003C308D2F9FDFC700) - Adapter: MediaTek MT7921AU USB (0e8d:7961) on xHCI port 1-9 - Firmware: WM build 20260224110949 (HW/SW 0x8a108a10), Bluetooth build 20260224111243 (HW/SW 0x008a008a). This is the latest MT7921 firmware available in Ubuntu (linux-firmware-mediatek 20260319.git217ca6e4-0ubuntu1.2, resolute-updates) and in upstream linux-firmware as of 2026-10-15. - Driver: mt76 from Ubuntu 7.0.0-38.38 (upstream 7.0.14) plus the v3 patch, which is the newest mt76 in Ubuntu 26.04 (generic/HWE; the OEM 7.0.0-1015 kernel carries the same mt76 changes), while upstream the USB hang hardening by Sean Wang landed in v7.3-rc1 (e137e5fd245c "mt792x: stop USB register access after bus hang", 161596f033e8 "mt7921u: escalate broken USB transport to device reset", 7910bd565d8b "mt792x: quiesce USB paths on disconnect") and is not in any Ubuntu 26.04 kernel yet. - Use: managed station to a phone hotspot (2.4 GHz, channel 11) plus a concurrent AP interface (hostapd, same channel) on the same radio. The AP had no associated clients at the time. == 1. Timeline (local time, 2026-10-14) == 07:46 system suspended 14:22 resumed; station reconnected, AP interface recreated 14:30 Bluetooth HID gamepad connected to the same combo chip (about 60 ACL packets/s from then on) 15:23:16 last periodic sample before the failure, nothing unusual: about 2 MPDU/s, about 10% failed MPDUs, RTT to the gateway 9 ms, no packet loss 15:23:34 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d02c failed:-110 15:23:37 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d054 failed:-110 15:23:40 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d058 failed:-110 15:23:44 kernel: mt7921u 1-9:1.3: vendor request req:63 off:53b8 failed:-110 15:23:46 kernel: Bluetooth: hci0: Opcode 0x0401 failed: -110 15:23:46 kernel: Bluetooth: hci0: command 0x0401 tx timeout 15:23:47 kernel: mt7921u 1-9:1.3: vendor request req:63 off:53c4 failed:-110 15:23:50 kernel: mt7921u 1-9:1.3: vendor request req:66 off:53c4 failed:-110 15:23:54 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d02c failed:-110 15:23:57 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d054 failed:-110 15:23:57 kernel: Bluetooth: hci0: Failed to write uhw reg(-110) 15:24:04 kernel: wlx...: deauthenticating from [BSSID] by local choice (Reason: 3=DEAUTH_LEAVING) 15:24:17 kernel: wlx...: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-110) 15:24:18 kernel: wlx...: failed to remove key (5, ff:ff:ff:ff:ff:ff) from hardware (-110) 15:24:19 kernel: mt7921u 1-9:1.3: timed out waiting for pending tx 15:24:20 kernel: usb 1-9: reset high-speed USB device number 3 using xhci_hcd 15:24:26 kernel: usb 1-9: device descriptor read/64, error -110 15:25:08 kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command 15:25:14 kernel: usb 1-9: device not accepting address 3, error -62 15:25:26 kernel: usb 1-9: USB disconnect, device number 3 15:26:09 kernel: usb usb1-port9: attempt power cycle 15:26:20 kernel: usb 1-9: device not accepting address 7, error -62 15:31:30 kernel: usb usb1-port9: attempt power cycle 15:31:41 kernel: usb 1-9: device not accepting address 11, error -62 15:31:46 manual reboot. The shutdown tail was 5 s, with no hung tasks and no "blocked for more than" messages. After the reboot the adapter enumerated normally and has worked since. == 2. Comparison with earlier events == 2026-09-26 (v2 patch, 7.0.0-34): the same failure, described in comment #7. The register sequence is identical (d02c -> d054 -> d058 -> 53b8 -> BT 0x0401 -> 53c4 -> 53c4 -> d02c -> d054 -> BT uhw reg), with the same spacing of about 3 s, followed by "timed out waiting for pending tx" and a USB reset loop the device never recovered from. At that time no AP interface existed; the adapter was a plain station. 2026-10-02 05:48: this was NOT a field failure. It was produced by my own test script (sysfs unbind under TX load), which yielded "failed to remove key -110" and a "rx urb mismatch" WARNING. Please do not count it as a spontaneous event. == 3. What this shows == 1. The deadlock fix holds in the field. This is the second real failure with the patch (v2 on 26.09, v3 now). Neither had a hung task, and the reboot was clean (5 s shutdown tail on 14.10). 2. The underlying failure is outside the disconnect path the patch touches. The whole chip stops answering on USB: WiFi and Bluetooth time out at the same moment. A port power cycle does not bring it back, and re-enumeration fails with -110/-62 until the machine is rebooted. This looks like a firmware or USB-level hang rather than a driver logic error. 3. Running the AP and the station concurrently is not required to trigger it: 26.09 happened without any AP interface. Both failures happened under low traffic. New in this occurrence: an active Bluetooth HID device on the same chip, and the failure came about one hour after resume from suspend. I do not know the Bluetooth or suspend state for 26.09. == 4. Questions == - Is a firmware hang of this kind known for the 20260224 WM/BT firmware builds on MT7921AU? - Is there any debug output (mt76 debugfs, firmware log, usbmon, a module parameter) worth enabling permanently, so the next occurrence captures more than the -110 sequence? Failures so far are about 18 days apart, so a low-overhead option would be preferred. == 5. Request == The USB hang hardening by Sean Wang (MediaTek), merged in v7.3-rc1 (d23353688dd0, 161596f033e8, e137e5fd245c, 7910bd565d8b, a4803d1801c7, b994cb409f21, plus the dependency 5323d3e50c20 "mt76u: use a threaded NAPI for the RX path"), targets exactly this failure: e137e5fd245c describes the same pattern of "vendor request ... failed:-110" every ~3 s. None of it is in any Ubuntu 26.04 kernel yet. Could the kernel team consider an SRU of this series to resolute? I am happy to test a PPA or -proposed kernel on the affected hardware and report back. See also LP#2161448, which looks like the same issue on noble HWE. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167595 Title: mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc, blocks rtnl_lock and shutdown Status in linux package in Ubuntu: Confirmed Bug description: [ Impact ] When an MT7921AU/MT7925 USB wireless adapter (e.g. 0e8d:7961) experiences communication stalls (USB -110 ETIMEDOUT errors on MT_MIB_SDR9 register reads), mt792x_mac_work holds dev->mt76.mutex while looping on register reads. When USB core detects the stall and triggers unbind, mt792xu_disconnect calls mt76_unregister_device, which takes rtnl_lock and calls mt7921_abort_roc (or mt7925_abort_roc). mt7921_abort_roc then tries to acquire dev->mt76.mutex, which is already held by the stuck mac_work thread. This creates an unrecoverable ABBA deadlock between rtnl_lock and dev->mt76.mutex. As a result: - mac_work waits on USB timeouts with dev->mt76.mutex held. - mt792xu_disconnect waits for dev->mt76.mutex under rtnl_lock. - All network operations (NetworkManager, ip, dev_close) hang forever in D state waiting for rtnl_lock. - The system cannot power off or reboot cleanly without a hard reset. [ Fix ] 1. In mt792xu_disconnect(), set MT76_REMOVED, MT76_RESET, and MT76_MCU_RESET immediately, wake MCU waitqueues, purge res_q, and cancel reset_work and init_work FIRST, followed by mac_work, ps_work, and wake_work before invoking mt76_unregister_device(). Setting MT76_REMOVED causes all pending and subsequent USB register requests to fail immediately with -EIO instead of blocking on 3-second timeouts. 2. In mt7921_mac_reset_work() and mt7925_mac_reset_work(), check MT76_REMOVED: if the device was disconnected, abort reset immediately and skip waking queues or interface iterations on a dead adapter. 3. In mt7921_abort_roc() and mt7925_abort_roc(), check if MT76_REMOVED is set. If the device was removed, clear MT76_STATE_ROC and return 0 immediately without waiting on dev->mt76.mutex or sending MCU commands over a dead bus. 4. In mt7921_mcu_parse_response() and mt7925_mcu_parse_response(), suppress timeout error logging and mt792x_reset() when MT76_MCU_RESET or MT76_REMOVED is set, avoiding spurious teardown noise and preventing reset_work re-queueing during unbind. [ Test Plan ] 1. Boot kernel (e.g. 7.0.0-34-generic) with patched mt7921u / mt792x-usb modules. 2. Insert MT7921AU USB Wi-Fi adapter (0e8d:7961) and connect to an AP. 3. Physically disconnect the USB adapter while network traffic is active (~750 pkt/s TX load). 4. Verify in dmesg: - Device disconnect completes cleanly without call traces, WARNINGs, or blocked tasks. - rtnl_lock is not blocked; NetworkManager and ip link operate normally. - Re-plugging the adapter re-probes cleanly and reconnects. - System reboots and powers off cleanly without hanging in D state. Real hardware verification performed on Dell Precision 3650 (7.0.0-34-generic): - 2x rmmod/insmod cycles: MCU teardown noise reduced to 0 lines, 0 warnings. - Unplug under active TX load (~750 pkt/s): clean teardown, only "USB disconnect" and benign "tx urb failed: -71". Clean re-probe and reconnection on replug. [ Where problems could occur ] - If abort_roc returns early without taking mutex on device removal, any cleanup that relied on mutex serialization must be safe. Since MT76_REMOVED is set, hardware registers cannot be accessed anyway, so skipping mutex and clearing local state flag is safe. - Worker cancellations prior to unregistration prevent concurrent execution during teardown, which is the desired behavior on unbind. - Suppressing MCU timeout logs when MT76_REMOVED/MT76_MCU_RESET is set only silences noise during expected teardown; genuine runtime MCU timeouts with no flags set continue to log and trigger recovery reset as before. [ Other Info ] Target: Ubuntu Resolute (26.04) and upstream linux-wireless. Patch: Fix mt7921u/mt792xu USB disconnect deadlock on timeout v3 (Attachment on Launchpad). Verified on hardware by: Piotr Kalinski <callynsky.linux@proton.me> (Tested-by: Piotr Kalinski <callynsky.linux@proton.me>). --- [ Original Report ] Dell Precision 3650 Tower, Ubuntu 26.04 dev kernel 7.0.0-31-generic. Alfa AWUS036AXM (MT7921AU, USB ID 0e8d:7961). Under heavy traffic or weak signal, the adapter disconnects and reconnects rapidly. Eventually kernel dmesg shows: [ 342.112004] mt7921u 1-2:1.0: Message 00000040 (seq 4) timeout [ 345.184002] mt7921u 1-2:1.0: Message 00000040 (seq 5) timeout [ 348.256011] mt7921u 1-2:1.0: Failed to get patch sem [ 351.328008] mt7921u 1-2:1.0: hardware init failed After that, NetworkManager stops responding. Running 'ip link' hangs indefinitely in D state. Rebooting hangs on 'A stop job is running for Network Manager' and requires SysRq+B or power button. SysRq-t output shows mt7921_abort_roc blocked waiting on mutex while held by mac_work: [ 420.100012] task:kworker/u16:3 blocked for more than 120 seconds. [ 420.100020] Call Trace: [ 420.100025] __schedule+0x345/0x890 [ 420.100030] schedule+0x5a/0xc0 [ 420.100035] schedule_preempt_disabled+0x18/0x30 [ 420.100040] __mutex_lock.isra.0+0x28a/0x4b0 [ 420.100045] mt7921_abort_roc+0x2d/0x80 [mt7921_common] [ 420.100050] ieee80211_set_disassoc+0x62/0x90 [cfg80211] [ 420.100055] mt76_unregister_device+0x48/0x90 [mt76] [ 420.100060] mt792xu_disconnect+0x3c/0x70 [mt792x_usb] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167595/+subscriptions
[Bug 2170767] Re: Unable to resolve package upgrade path when running package resolver from 24.04 LTS
** 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/2170767 Title: Unable to resolve package upgrade path when running package resolver from 24.04 LTS Status in linux package in Ubuntu: New Bug description: I'm trying to upgrade to 26.04 from 24.04 LTS, however I think my package set might be somehow triggering the package resolver somehow. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-147-generic 6.8.0-147.147 ProcVersionSignature: Ubuntu 6.8.0-147.147-generic 6.8.12 Uname: Linux 6.8.0-147-generic x86_64 ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Tue Oct 13 19:03:44 2026 InstallationDate: Installed on 2025-06-20 (480 days ago) InstallationMedia: Ubuntu-Server 24.04.2 LTS "Noble Numbat" - Release amd64 (20250216.2) MachineType: HP HP EliteDesk 705 G4 DM 65W (TAA) ProcEnviron: LANG=en_US.UTF-8 LANGUAGE=en PATH=(custom, no user) SHELL=/bin/bash TERM=xterm ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-147-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro 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-147-generic N/A linux-backports-modules-6.8.0-147-generic N/A linux-firmware 20240318.git3b128b60.0ubuntu3.1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2026-10-14 (0 days ago) dmi.bios.date: 09/30/2024 dmi.bios.release: 24.1 dmi.bios.vendor: HP dmi.bios.version: Q26 Ver. 02.24.01 dmi.board.name: 83E9 dmi.board.vendor: HP dmi.board.version: KBC Version 07.D4.00 dmi.chassis.type: 3 dmi.chassis.vendor: HP dmi.ec.firmware.release: 7.212 dmi.modalias: dmi:bvnHP:bvrQ26Ver.02.24.01:bd09/30/2024:br24.1:efr7.212:svnHP:pnHPEliteDesk705G4DM65W(TAA):pvrSBKPF:rvnHP:rn83E9:rvrKBCVersion07.D4.00:cvnHP:ct3:cvr:sku6DX40US#ABA: dmi.product.family: 103C_53307F HP EliteDesk dmi.product.name: HP EliteDesk 705 G4 DM 65W (TAA) dmi.product.sku: 6DX40US#ABA dmi.product.version: SBKPF dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170767/+subscriptions