** Attachment added: "dmesg6.8.0134BAD.log" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616/+attachment/5981808/+files/dmesg6.8.0134BAD.log ** Tags added: iommu kernel-bug noble regression-update -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160616 Title: [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) Status in linux package in Ubuntu: New Bug description: I updated my DL360 gen8 server to the newest kernel and got a non functioning P420i due to massive errors in dmesg. Since I'm not that familiar with kernel stuff and storage drivers I've asked an LLM to provide all necessary information to file a bug against the ubuntu kernel package. This is the result of the information that was already found. Let me know if you need any further information on this issue. # [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) **Package:** linux (Ubuntu Noble 24.04) **Broken:** 6.8.0-134.134 (6.8.12) **Last good:** 6.8.0-124.124 **Also present in:** 6.8.0-136.136 (per changelog; no fix/revert present) **Severity:** total storage loss on affected hosts — 32 TB RAID volume dropped offline, 10 production VMs lost their disks --- > **Note on how this report was produced.** The diagnosis, log analysis and the > text of this report were assembled with the help of an AI assistant (Claude) > working on the affected machine under my supervision. I have reviewed it and > can vouch for the underlying facts; the raw logs are attached so every claim > can be checked independently. The address/RMRR correlation below was verified > programmatically against the raw log rather than by eye. > > **I am happy to supply any additional information, run diagnostics, or test a > proposed kernel on request** — see the "Control machine" note near the end. --- ## Summary On 6.8.0-134, the Intel IOMMU IOVA allocator hands out IOVAs that fall inside BIOS-declared RMRR regions. Those regions are already identity-mapped, so `__domain_mapping()` finds an existing PTE, throws `WARNING at drivers/iommu/intel/iommu.c:2227`, and the DMA mapping fails: ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` Note `bdf81003` — vPFN 0xbdf81 is mapped to PFN 0xbdf81, i.e. an identity mapping, which is what RMRR regions get. This is **not driver-specific**. On this host it hit three drivers within 90 seconds: `nvme` first, then `hpsa`, then `tg3`. The HP Smart Array P420i was simply the one that could not recover: its logical volume reset failed, the device went offline (`DID_NO_CONNECT`), and the 32 TB RAID-5 volume backing our LVM volume group disappeared, taking 10 production VMs with it. ## Root cause evidence The BIOS declares these RMRR regions (identical on both kernels, see below): ``` DMAR: RMRR base: 0x000000bdf6e000 end: 0x000000bdf6efff -> PFN 0xbdf6e DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff -> PFN 0xbdf6f-0xbdf7e DMAR: RMRR base: 0x000000bdf7f000 end: 0x000000bdf82fff -> PFN 0xbdf7f-0xbdf82 DMAR: RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff -> PFN 0xbdf83-0xbdf84 union -> PFN 0xbdf6e-0xbdf84 ``` The complete set of colliding vPFNs observed across all 66 errors: ``` 0xbdf6e 0xbdf6f 0xbdf70 0xbdf71 0xbdf72 0xbdf73 0xbdf74 0xbdf75 0xbdf76 0xbdf77 0xbdf78 0xbdf79 0xbdf7a 0xbdf7b 0xbdf7c 0xbdf7d 0xbdf7e 0xbdf7f 0xbdf80 0xbdf81 0xbdf82 0xbdf83 0xbdf84 ``` That is `0xbdf6e`-`0xbdf84` — an exact, complete match with the RMRR union. All 23 distinct colliding IOVAs lie inside an RMRR region; none lies outside one. (Checked programmatically over the attached log, not by inspection.) The RMRR reserved-region exclusion in the IOVA allocator appears not to be in effect. ## This is not a firmware or BIOS problem The RMRR regions declared by the BIOS are **byte-for-byte identical** on 6.8.0-124 and 6.8.0-134 (diffed; both logs attached). Same machine, same BIOS (P71, 05/24/2019), same controller firmware. The only variable is the kernel. 6.8.0-124 handles these exact regions correctly. ## This is not passthrough-specific No VFIO/PCI passthrough is configured on this host (`lsmod | grep vfio` -> 0). This is a plain KVM/libvirt host using virtio and LVM-backed disks. Reports elsewhere tie the 6.8.12 IOMMU regression to VFIO group assignment; this reproducer has no VFIO involvement at all, which suggests the underlying defect is broader than the passthrough symptom it was first noticed through. ## A/B evidence (same physical machine, consecutive boots) | Boot | Kernel | Uptime | DMAR errors | I/O errors | |------|--------|--------|-------------|------------| | -2 | 6.8.0-124 | 2026-06-13 -> 2026-07-14 (31 days) | 0 | 0 | | -1 | 6.8.0-134 | ~10 min to controller loss | 66 | 4701 | | 0 | 6.8.0-124 | since revert, stable | 0 | 0 | Booting 6.8.0-124 restored full function immediately: controller status OK, volume group back, all VMs recovered. ## Timeline (boot -1, kernel 6.8.0-134) ``` 12:32:34 boot 12:41:24 first WARNING - nvme_map_data (mdraid rebuild driving heavy DMA) 12:42:46 hpsa_scatter_gather hits the same warning 12:42:50 tg3_start_xmit hits it too (network path) 12:43:23 hpsa: resetting logical Direct-Access HP LOGICAL VOLUME RAID-5 12:44:32 hpsa: reset logical failed / sd 3:1:0:0: rejecting I/O to offline device sda offline -> volume group gone -> 10 VMs lose their disks 13:25:05 reboot into 6.8.0-124 -> fully recovered ``` The first failure came ~9 minutes in, under sustained DMA load from an mdraid rebuild — consistent with the allocator only reaching the RMRR range once lower IOVA space was under pressure. Hosts may therefore appear fine after boot and fail later under load. ## Representative stack trace ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 CPU: 32 PID: 562 Comm: kworker/32:1H Tainted: G I 6.8.0-134-generic #134-Ubuntu Hardware name: HP ProLiant DL360p Gen8, BIOS P71 05/24/2019 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:__domain_mapping+0x2b5/0x320 Call Trace: <TASK> intel_iommu_map_pages+0xe1/0x140 __iommu_map+0x121/0x280 iommu_map_sg+0xbf/0x1f0 iommu_dma_map_sg+0x463/0x4f0 __dma_map_sg_attrs+0x35/0xd0 dma_map_sgtable+0x1d/0x40 nvme_map_data+0xd6/0x480 [nvme] nvme_prep_rq.part.0+0x35/0x120 [nvme] nvme_queue_rq+0x7e/0x207 [nvme] blk_mq_dispatch_rq_list+0x137/0x520 __blk_mq_sched_dispatch_requests+0x118/0x190 blk_mq_sched_dispatch_requests+0x2f/0x80 blk_mq_run_work_fn+0x72/0x90 process_one_work+0x184/0x3a0 worker_thread+0x18b/0x330 kthread+0xf2/0x120 ret_from_fork+0x47/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` The same warning with `hpsa_scatter_gather+0x3e/0x310 [hpsa]` and with `__tg3_start_xmit+0x1f0/0xd60 [tg3]` in place of the nvme frames is in the attached log (46 nvme, 18 hpsa, 4 tg3 occurrences). ## Environment ``` Hardware: HP ProLiant DL360p Gen8 BIOS: HP P71, 05/24/2019 CPU: Intel Xeon E5-2697 v2 @ 2.70GHz (48 threads) RAM: 503 GB Controller: Smart Array P420i [103c:323b] rev 01, subsystem [103c:3354] PCI 0000:02:00.0, IOMMU group 49 Driver: hpsa 3.4.20-200 OS: Ubuntu 24.04.4 LTS Cmdline: BOOT_IMAGE=/boot/vmlinuz-6.8.0-134-generic root=UUID=<redacted> ro maybe-ubiquity (no intel_iommu= or iommu= parameter set; IOMMU on by default, 132 groups) Workload: KVM/libvirt host, ~30 VMs, LVM on hpsa RAID-5 + LVM on NVMe mdraid1 ``` **Control machine:** a second, identical DL360p Gen8 (same BIOS, same P420i) running 6.8.0-101 has 18+ weeks uptime with zero DMAR errors. It has not been exposed to -134 and is available to test a proposed kernel. I can also reproduce on the primary host in a maintenance window if that is more useful. ## Related reports Same signature (`DMA PTE ... already set` from a RAID driver's scatter-gather mapping, leading to controller resets) reported downstream on Proxmox, where a Proxmox developer states "the -29 one had an IOMMU related regression that is fixed there", referring to their 6.8.12-30 kernel: - https://forum.proxmox.com/threads/has-anyone-seen-dma-pte-megaraid-controller-resets-after-upgrading-to-recent-proxmox-8-kernels.184389/ - https://forum.proxmox.com/threads/proxmox-kernel-6-8-12-29-causing-array-controller-errors.184181/ Proxmox 6.8.12-29/-30 share the 6.8.12 base with Ubuntu's 6.8.0-134. If the fix there is a revert of an upstream stable commit, the same revert would plausibly apply here. **This is an inference from the shared code base and matching signature, not something I was able to confirm** — the referenced upstream report (kernel bugzilla #221234) is behind an anti-bot gate, and I could not identify the offending commit. An older, still-untriaged Ubuntu bug with the same signature: https://bugs.launchpad.net/bugs/1970453 ## Workarounds - Boot 6.8.0-124 (what we did; fully effective) - `iommu=pt` or `intel_iommu=off` reported effective by others (untested here) None of these are acceptable long-term for hosts that must stay on a supported kernel. ## Request Please identify and revert/backport the fix for the RMRR reserved-region handling in the 6.8.0 Noble series. ## Attachments and how they were prepared The attached logs have been **filtered before upload** — please read this so you know what you are and are not looking at: - `[UFW BLOCK]` firewall lines were **removed entirely**. They carried third-party source IP addresses (personal data under GDPR) and were unrelated to the fault. - Hostname, IP addresses, MAC addresses and UUIDs were replaced with placeholders. - Full `dmidecode` output is **not attached**: it embeds the chassis serial number three times over (including as a raw hex dump), and the system UUID is a hex encoding of that same serial. `hardware-summary.txt` contains the model-level fields instead. No kernel-relevant line was altered. The evidence was counted before and after filtering to confirm nothing was lost: 66 DMAR errors, 66 `iommu.c:2227` warnings, 132 `__domain_mapping` frames, 23 distinct vPFNs, 9 RMRR regions and the complete hpsa reset-to-offline chain are all present in both. **If you need an unfiltered log, ask me and I will provide one through a private channel.** - `dmesg-6.8.0-134-BAD.log` — full kernel log of the failing boot - `dmesg-6.8.0-124-GOOD-boot.log` — boot log of the working kernel, showing the identical RMRR regions and no collisions - `lspci-vvnn.txt` — full PCI topology - `hardware-summary.txt` — curated hardware/firmware details - `version.txt` — kernel, cmdline, distro, hpsa module info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616/+subscriptions
вторник
[Bug 2160616] Re: [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i)
** Attachment added: "lspcivvnn.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616/+attachment/5981806/+files/lspcivvnn.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160616 Title: [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) Status in linux package in Ubuntu: New Bug description: I updated my DL360 gen8 server to the newest kernel and got a non functioning P420i due to massive errors in dmesg. Since I'm not that familiar with kernel stuff and storage drivers I've asked an LLM to provide all necessary information to file a bug against the ubuntu kernel package. This is the result of the information that was already found. Let me know if you need any further information on this issue. # [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) **Package:** linux (Ubuntu Noble 24.04) **Broken:** 6.8.0-134.134 (6.8.12) **Last good:** 6.8.0-124.124 **Also present in:** 6.8.0-136.136 (per changelog; no fix/revert present) **Severity:** total storage loss on affected hosts — 32 TB RAID volume dropped offline, 10 production VMs lost their disks --- > **Note on how this report was produced.** The diagnosis, log analysis and the > text of this report were assembled with the help of an AI assistant (Claude) > working on the affected machine under my supervision. I have reviewed it and > can vouch for the underlying facts; the raw logs are attached so every claim > can be checked independently. The address/RMRR correlation below was verified > programmatically against the raw log rather than by eye. > > **I am happy to supply any additional information, run diagnostics, or test a > proposed kernel on request** — see the "Control machine" note near the end. --- ## Summary On 6.8.0-134, the Intel IOMMU IOVA allocator hands out IOVAs that fall inside BIOS-declared RMRR regions. Those regions are already identity-mapped, so `__domain_mapping()` finds an existing PTE, throws `WARNING at drivers/iommu/intel/iommu.c:2227`, and the DMA mapping fails: ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` Note `bdf81003` — vPFN 0xbdf81 is mapped to PFN 0xbdf81, i.e. an identity mapping, which is what RMRR regions get. This is **not driver-specific**. On this host it hit three drivers within 90 seconds: `nvme` first, then `hpsa`, then `tg3`. The HP Smart Array P420i was simply the one that could not recover: its logical volume reset failed, the device went offline (`DID_NO_CONNECT`), and the 32 TB RAID-5 volume backing our LVM volume group disappeared, taking 10 production VMs with it. ## Root cause evidence The BIOS declares these RMRR regions (identical on both kernels, see below): ``` DMAR: RMRR base: 0x000000bdf6e000 end: 0x000000bdf6efff -> PFN 0xbdf6e DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff -> PFN 0xbdf6f-0xbdf7e DMAR: RMRR base: 0x000000bdf7f000 end: 0x000000bdf82fff -> PFN 0xbdf7f-0xbdf82 DMAR: RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff -> PFN 0xbdf83-0xbdf84 union -> PFN 0xbdf6e-0xbdf84 ``` The complete set of colliding vPFNs observed across all 66 errors: ``` 0xbdf6e 0xbdf6f 0xbdf70 0xbdf71 0xbdf72 0xbdf73 0xbdf74 0xbdf75 0xbdf76 0xbdf77 0xbdf78 0xbdf79 0xbdf7a 0xbdf7b 0xbdf7c 0xbdf7d 0xbdf7e 0xbdf7f 0xbdf80 0xbdf81 0xbdf82 0xbdf83 0xbdf84 ``` That is `0xbdf6e`-`0xbdf84` — an exact, complete match with the RMRR union. All 23 distinct colliding IOVAs lie inside an RMRR region; none lies outside one. (Checked programmatically over the attached log, not by inspection.) The RMRR reserved-region exclusion in the IOVA allocator appears not to be in effect. ## This is not a firmware or BIOS problem The RMRR regions declared by the BIOS are **byte-for-byte identical** on 6.8.0-124 and 6.8.0-134 (diffed; both logs attached). Same machine, same BIOS (P71, 05/24/2019), same controller firmware. The only variable is the kernel. 6.8.0-124 handles these exact regions correctly. ## This is not passthrough-specific No VFIO/PCI passthrough is configured on this host (`lsmod | grep vfio` -> 0). This is a plain KVM/libvirt host using virtio and LVM-backed disks. Reports elsewhere tie the 6.8.12 IOMMU regression to VFIO group assignment; this reproducer has no VFIO involvement at all, which suggests the underlying defect is broader than the passthrough symptom it was first noticed through. ## A/B evidence (same physical machine, consecutive boots) | Boot | Kernel | Uptime | DMAR errors | I/O errors | |------|--------|--------|-------------|------------| | -2 | 6.8.0-124 | 2026-06-13 -> 2026-07-14 (31 days) | 0 | 0 | | -1 | 6.8.0-134 | ~10 min to controller loss | 66 | 4701 | | 0 | 6.8.0-124 | since revert, stable | 0 | 0 | Booting 6.8.0-124 restored full function immediately: controller status OK, volume group back, all VMs recovered. ## Timeline (boot -1, kernel 6.8.0-134) ``` 12:32:34 boot 12:41:24 first WARNING - nvme_map_data (mdraid rebuild driving heavy DMA) 12:42:46 hpsa_scatter_gather hits the same warning 12:42:50 tg3_start_xmit hits it too (network path) 12:43:23 hpsa: resetting logical Direct-Access HP LOGICAL VOLUME RAID-5 12:44:32 hpsa: reset logical failed / sd 3:1:0:0: rejecting I/O to offline device sda offline -> volume group gone -> 10 VMs lose their disks 13:25:05 reboot into 6.8.0-124 -> fully recovered ``` The first failure came ~9 minutes in, under sustained DMA load from an mdraid rebuild — consistent with the allocator only reaching the RMRR range once lower IOVA space was under pressure. Hosts may therefore appear fine after boot and fail later under load. ## Representative stack trace ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 CPU: 32 PID: 562 Comm: kworker/32:1H Tainted: G I 6.8.0-134-generic #134-Ubuntu Hardware name: HP ProLiant DL360p Gen8, BIOS P71 05/24/2019 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:__domain_mapping+0x2b5/0x320 Call Trace: <TASK> intel_iommu_map_pages+0xe1/0x140 __iommu_map+0x121/0x280 iommu_map_sg+0xbf/0x1f0 iommu_dma_map_sg+0x463/0x4f0 __dma_map_sg_attrs+0x35/0xd0 dma_map_sgtable+0x1d/0x40 nvme_map_data+0xd6/0x480 [nvme] nvme_prep_rq.part.0+0x35/0x120 [nvme] nvme_queue_rq+0x7e/0x207 [nvme] blk_mq_dispatch_rq_list+0x137/0x520 __blk_mq_sched_dispatch_requests+0x118/0x190 blk_mq_sched_dispatch_requests+0x2f/0x80 blk_mq_run_work_fn+0x72/0x90 process_one_work+0x184/0x3a0 worker_thread+0x18b/0x330 kthread+0xf2/0x120 ret_from_fork+0x47/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` The same warning with `hpsa_scatter_gather+0x3e/0x310 [hpsa]` and with `__tg3_start_xmit+0x1f0/0xd60 [tg3]` in place of the nvme frames is in the attached log (46 nvme, 18 hpsa, 4 tg3 occurrences). ## Environment ``` Hardware: HP ProLiant DL360p Gen8 BIOS: HP P71, 05/24/2019 CPU: Intel Xeon E5-2697 v2 @ 2.70GHz (48 threads) RAM: 503 GB Controller: Smart Array P420i [103c:323b] rev 01, subsystem [103c:3354] PCI 0000:02:00.0, IOMMU group 49 Driver: hpsa 3.4.20-200 OS: Ubuntu 24.04.4 LTS Cmdline: BOOT_IMAGE=/boot/vmlinuz-6.8.0-134-generic root=UUID=<redacted> ro maybe-ubiquity (no intel_iommu= or iommu= parameter set; IOMMU on by default, 132 groups) Workload: KVM/libvirt host, ~30 VMs, LVM on hpsa RAID-5 + LVM on NVMe mdraid1 ``` **Control machine:** a second, identical DL360p Gen8 (same BIOS, same P420i) running 6.8.0-101 has 18+ weeks uptime with zero DMAR errors. It has not been exposed to -134 and is available to test a proposed kernel. I can also reproduce on the primary host in a maintenance window if that is more useful. ## Related reports Same signature (`DMA PTE ... already set` from a RAID driver's scatter-gather mapping, leading to controller resets) reported downstream on Proxmox, where a Proxmox developer states "the -29 one had an IOMMU related regression that is fixed there", referring to their 6.8.12-30 kernel: - https://forum.proxmox.com/threads/has-anyone-seen-dma-pte-megaraid-controller-resets-after-upgrading-to-recent-proxmox-8-kernels.184389/ - https://forum.proxmox.com/threads/proxmox-kernel-6-8-12-29-causing-array-controller-errors.184181/ Proxmox 6.8.12-29/-30 share the 6.8.12 base with Ubuntu's 6.8.0-134. If the fix there is a revert of an upstream stable commit, the same revert would plausibly apply here. **This is an inference from the shared code base and matching signature, not something I was able to confirm** — the referenced upstream report (kernel bugzilla #221234) is behind an anti-bot gate, and I could not identify the offending commit. An older, still-untriaged Ubuntu bug with the same signature: https://bugs.launchpad.net/bugs/1970453 ## Workarounds - Boot 6.8.0-124 (what we did; fully effective) - `iommu=pt` or `intel_iommu=off` reported effective by others (untested here) None of these are acceptable long-term for hosts that must stay on a supported kernel. ## Request Please identify and revert/backport the fix for the RMRR reserved-region handling in the 6.8.0 Noble series. ## Attachments and how they were prepared The attached logs have been **filtered before upload** — please read this so you know what you are and are not looking at: - `[UFW BLOCK]` firewall lines were **removed entirely**. They carried third-party source IP addresses (personal data under GDPR) and were unrelated to the fault. - Hostname, IP addresses, MAC addresses and UUIDs were replaced with placeholders. - Full `dmidecode` output is **not attached**: it embeds the chassis serial number three times over (including as a raw hex dump), and the system UUID is a hex encoding of that same serial. `hardware-summary.txt` contains the model-level fields instead. No kernel-relevant line was altered. The evidence was counted before and after filtering to confirm nothing was lost: 66 DMAR errors, 66 `iommu.c:2227` warnings, 132 `__domain_mapping` frames, 23 distinct vPFNs, 9 RMRR regions and the complete hpsa reset-to-offline chain are all present in both. **If you need an unfiltered log, ask me and I will provide one through a private channel.** - `dmesg-6.8.0-134-BAD.log` — full kernel log of the failing boot - `dmesg-6.8.0-124-GOOD-boot.log` — boot log of the working kernel, showing the identical RMRR regions and no collisions - `lspci-vvnn.txt` — full PCI topology - `hardware-summary.txt` — curated hardware/firmware details - `version.txt` — kernel, cmdline, distro, hpsa module info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616/+subscriptions
[Bug 2160616] [NEW] [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i)
Public bug reported: I updated my DL360 gen8 server to the newest kernel and got a non functioning P420i due to massive errors in dmesg. Since I'm not that familiar with kernel stuff and storage drivers I've asked an LLM to provide all necessary information to file a bug against the ubuntu kernel package. This is the result of the information that was already found. Let me know if you need any further information on this issue. # [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) **Package:** linux (Ubuntu Noble 24.04) **Broken:** 6.8.0-134.134 (6.8.12) **Last good:** 6.8.0-124.124 **Also present in:** 6.8.0-136.136 (per changelog; no fix/revert present) **Severity:** total storage loss on affected hosts — 32 TB RAID volume dropped offline, 10 production VMs lost their disks --- > **Note on how this report was produced.** The diagnosis, log analysis and the > text of this report were assembled with the help of an AI assistant (Claude) > working on the affected machine under my supervision. I have reviewed it and > can vouch for the underlying facts; the raw logs are attached so every claim > can be checked independently. The address/RMRR correlation below was verified > programmatically against the raw log rather than by eye. > > **I am happy to supply any additional information, run diagnostics, or test a > proposed kernel on request** — see the "Control machine" note near the end. --- ## Summary On 6.8.0-134, the Intel IOMMU IOVA allocator hands out IOVAs that fall inside BIOS-declared RMRR regions. Those regions are already identity-mapped, so `__domain_mapping()` finds an existing PTE, throws `WARNING at drivers/iommu/intel/iommu.c:2227`, and the DMA mapping fails: ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` Note `bdf81003` — vPFN 0xbdf81 is mapped to PFN 0xbdf81, i.e. an identity mapping, which is what RMRR regions get. This is **not driver-specific**. On this host it hit three drivers within 90 seconds: `nvme` first, then `hpsa`, then `tg3`. The HP Smart Array P420i was simply the one that could not recover: its logical volume reset failed, the device went offline (`DID_NO_CONNECT`), and the 32 TB RAID-5 volume backing our LVM volume group disappeared, taking 10 production VMs with it. ## Root cause evidence The BIOS declares these RMRR regions (identical on both kernels, see below): ``` DMAR: RMRR base: 0x000000bdf6e000 end: 0x000000bdf6efff -> PFN 0xbdf6e DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff -> PFN 0xbdf6f-0xbdf7e DMAR: RMRR base: 0x000000bdf7f000 end: 0x000000bdf82fff -> PFN 0xbdf7f-0xbdf82 DMAR: RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff -> PFN 0xbdf83-0xbdf84 union -> PFN 0xbdf6e-0xbdf84 ``` The complete set of colliding vPFNs observed across all 66 errors: ``` 0xbdf6e 0xbdf6f 0xbdf70 0xbdf71 0xbdf72 0xbdf73 0xbdf74 0xbdf75 0xbdf76 0xbdf77 0xbdf78 0xbdf79 0xbdf7a 0xbdf7b 0xbdf7c 0xbdf7d 0xbdf7e 0xbdf7f 0xbdf80 0xbdf81 0xbdf82 0xbdf83 0xbdf84 ``` That is `0xbdf6e`-`0xbdf84` — an exact, complete match with the RMRR union. All 23 distinct colliding IOVAs lie inside an RMRR region; none lies outside one. (Checked programmatically over the attached log, not by inspection.) The RMRR reserved-region exclusion in the IOVA allocator appears not to be in effect. ## This is not a firmware or BIOS problem The RMRR regions declared by the BIOS are **byte-for-byte identical** on 6.8.0-124 and 6.8.0-134 (diffed; both logs attached). Same machine, same BIOS (P71, 05/24/2019), same controller firmware. The only variable is the kernel. 6.8.0-124 handles these exact regions correctly. ## This is not passthrough-specific No VFIO/PCI passthrough is configured on this host (`lsmod | grep vfio` -> 0). This is a plain KVM/libvirt host using virtio and LVM-backed disks. Reports elsewhere tie the 6.8.12 IOMMU regression to VFIO group assignment; this reproducer has no VFIO involvement at all, which suggests the underlying defect is broader than the passthrough symptom it was first noticed through. ## A/B evidence (same physical machine, consecutive boots) | Boot | Kernel | Uptime | DMAR errors | I/O errors | |------|--------|--------|-------------|------------| | -2 | 6.8.0-124 | 2026-06-13 -> 2026-07-14 (31 days) | 0 | 0 | | -1 | 6.8.0-134 | ~10 min to controller loss | 66 | 4701 | | 0 | 6.8.0-124 | since revert, stable | 0 | 0 | Booting 6.8.0-124 restored full function immediately: controller status OK, volume group back, all VMs recovered. ## Timeline (boot -1, kernel 6.8.0-134) ``` 12:32:34 boot 12:41:24 first WARNING - nvme_map_data (mdraid rebuild driving heavy DMA) 12:42:46 hpsa_scatter_gather hits the same warning 12:42:50 tg3_start_xmit hits it too (network path) 12:43:23 hpsa: resetting logical Direct-Access HP LOGICAL VOLUME RAID-5 12:44:32 hpsa: reset logical failed / sd 3:1:0:0: rejecting I/O to offline device sda offline -> volume group gone -> 10 VMs lose their disks 13:25:05 reboot into 6.8.0-124 -> fully recovered ``` The first failure came ~9 minutes in, under sustained DMA load from an mdraid rebuild — consistent with the allocator only reaching the RMRR range once lower IOVA space was under pressure. Hosts may therefore appear fine after boot and fail later under load. ## Representative stack trace ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 CPU: 32 PID: 562 Comm: kworker/32:1H Tainted: G I 6.8.0-134-generic #134-Ubuntu Hardware name: HP ProLiant DL360p Gen8, BIOS P71 05/24/2019 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:__domain_mapping+0x2b5/0x320 Call Trace: <TASK> intel_iommu_map_pages+0xe1/0x140 __iommu_map+0x121/0x280 iommu_map_sg+0xbf/0x1f0 iommu_dma_map_sg+0x463/0x4f0 __dma_map_sg_attrs+0x35/0xd0 dma_map_sgtable+0x1d/0x40 nvme_map_data+0xd6/0x480 [nvme] nvme_prep_rq.part.0+0x35/0x120 [nvme] nvme_queue_rq+0x7e/0x207 [nvme] blk_mq_dispatch_rq_list+0x137/0x520 __blk_mq_sched_dispatch_requests+0x118/0x190 blk_mq_sched_dispatch_requests+0x2f/0x80 blk_mq_run_work_fn+0x72/0x90 process_one_work+0x184/0x3a0 worker_thread+0x18b/0x330 kthread+0xf2/0x120 ret_from_fork+0x47/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` The same warning with `hpsa_scatter_gather+0x3e/0x310 [hpsa]` and with `__tg3_start_xmit+0x1f0/0xd60 [tg3]` in place of the nvme frames is in the attached log (46 nvme, 18 hpsa, 4 tg3 occurrences). ## Environment ``` Hardware: HP ProLiant DL360p Gen8 BIOS: HP P71, 05/24/2019 CPU: Intel Xeon E5-2697 v2 @ 2.70GHz (48 threads) RAM: 503 GB Controller: Smart Array P420i [103c:323b] rev 01, subsystem [103c:3354] PCI 0000:02:00.0, IOMMU group 49 Driver: hpsa 3.4.20-200 OS: Ubuntu 24.04.4 LTS Cmdline: BOOT_IMAGE=/boot/vmlinuz-6.8.0-134-generic root=UUID=<redacted> ro maybe-ubiquity (no intel_iommu= or iommu= parameter set; IOMMU on by default, 132 groups) Workload: KVM/libvirt host, ~30 VMs, LVM on hpsa RAID-5 + LVM on NVMe mdraid1 ``` **Control machine:** a second, identical DL360p Gen8 (same BIOS, same P420i) running 6.8.0-101 has 18+ weeks uptime with zero DMAR errors. It has not been exposed to -134 and is available to test a proposed kernel. I can also reproduce on the primary host in a maintenance window if that is more useful. ## Related reports Same signature (`DMA PTE ... already set` from a RAID driver's scatter-gather mapping, leading to controller resets) reported downstream on Proxmox, where a Proxmox developer states "the -29 one had an IOMMU related regression that is fixed there", referring to their 6.8.12-30 kernel: - https://forum.proxmox.com/threads/has-anyone-seen-dma-pte-megaraid-controller-resets-after-upgrading-to-recent-proxmox-8-kernels.184389/ - https://forum.proxmox.com/threads/proxmox-kernel-6-8-12-29-causing-array-controller-errors.184181/ Proxmox 6.8.12-29/-30 share the 6.8.12 base with Ubuntu's 6.8.0-134. If the fix there is a revert of an upstream stable commit, the same revert would plausibly apply here. **This is an inference from the shared code base and matching signature, not something I was able to confirm** — the referenced upstream report (kernel bugzilla #221234) is behind an anti-bot gate, and I could not identify the offending commit. An older, still-untriaged Ubuntu bug with the same signature: https://bugs.launchpad.net/bugs/1970453 ## Workarounds - Boot 6.8.0-124 (what we did; fully effective) - `iommu=pt` or `intel_iommu=off` reported effective by others (untested here) None of these are acceptable long-term for hosts that must stay on a supported kernel. ## Request Please identify and revert/backport the fix for the RMRR reserved-region handling in the 6.8.0 Noble series. ## Attachments and how they were prepared The attached logs have been **filtered before upload** — please read this so you know what you are and are not looking at: - `[UFW BLOCK]` firewall lines were **removed entirely**. They carried third-party source IP addresses (personal data under GDPR) and were unrelated to the fault. - Hostname, IP addresses, MAC addresses and UUIDs were replaced with placeholders. - Full `dmidecode` output is **not attached**: it embeds the chassis serial number three times over (including as a raw hex dump), and the system UUID is a hex encoding of that same serial. `hardware-summary.txt` contains the model-level fields instead. No kernel-relevant line was altered. The evidence was counted before and after filtering to confirm nothing was lost: 66 DMAR errors, 66 `iommu.c:2227` warnings, 132 `__domain_mapping` frames, 23 distinct vPFNs, 9 RMRR regions and the complete hpsa reset-to-offline chain are all present in both. **If you need an unfiltered log, ask me and I will provide one through a private channel.** - `dmesg-6.8.0-134-BAD.log` — full kernel log of the failing boot - `dmesg-6.8.0-124-GOOD-boot.log` — boot log of the working kernel, showing the identical RMRR regions and no collisions - `lspci-vvnn.txt` — full PCI topology - `hardware-summary.txt` — curated hardware/firmware details - `version.txt` — kernel, cmdline, distro, hpsa module info ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: iommu kernel-bug noble regression-update -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160616 Title: [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) Status in linux package in Ubuntu: New Bug description: I updated my DL360 gen8 server to the newest kernel and got a non functioning P420i due to massive errors in dmesg. Since I'm not that familiar with kernel stuff and storage drivers I've asked an LLM to provide all necessary information to file a bug against the ubuntu kernel package. This is the result of the information that was already found. Let me know if you need any further information on this issue. # [regression] 6.8.0-134: IOVA allocator hands out addresses inside BIOS RMRR regions, causing DMA mapping failures and storage controller loss (HP ProLiant Gen8 / P420i) **Package:** linux (Ubuntu Noble 24.04) **Broken:** 6.8.0-134.134 (6.8.12) **Last good:** 6.8.0-124.124 **Also present in:** 6.8.0-136.136 (per changelog; no fix/revert present) **Severity:** total storage loss on affected hosts — 32 TB RAID volume dropped offline, 10 production VMs lost their disks --- > **Note on how this report was produced.** The diagnosis, log analysis and the > text of this report were assembled with the help of an AI assistant (Claude) > working on the affected machine under my supervision. I have reviewed it and > can vouch for the underlying facts; the raw logs are attached so every claim > can be checked independently. The address/RMRR correlation below was verified > programmatically against the raw log rather than by eye. > > **I am happy to supply any additional information, run diagnostics, or test a > proposed kernel on request** — see the "Control machine" note near the end. --- ## Summary On 6.8.0-134, the Intel IOMMU IOVA allocator hands out IOVAs that fall inside BIOS-declared RMRR regions. Those regions are already identity-mapped, so `__domain_mapping()` finds an existing PTE, throws `WARNING at drivers/iommu/intel/iommu.c:2227`, and the DMA mapping fails: ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` Note `bdf81003` — vPFN 0xbdf81 is mapped to PFN 0xbdf81, i.e. an identity mapping, which is what RMRR regions get. This is **not driver-specific**. On this host it hit three drivers within 90 seconds: `nvme` first, then `hpsa`, then `tg3`. The HP Smart Array P420i was simply the one that could not recover: its logical volume reset failed, the device went offline (`DID_NO_CONNECT`), and the 32 TB RAID-5 volume backing our LVM volume group disappeared, taking 10 production VMs with it. ## Root cause evidence The BIOS declares these RMRR regions (identical on both kernels, see below): ``` DMAR: RMRR base: 0x000000bdf6e000 end: 0x000000bdf6efff -> PFN 0xbdf6e DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff -> PFN 0xbdf6f-0xbdf7e DMAR: RMRR base: 0x000000bdf7f000 end: 0x000000bdf82fff -> PFN 0xbdf7f-0xbdf82 DMAR: RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff -> PFN 0xbdf83-0xbdf84 union -> PFN 0xbdf6e-0xbdf84 ``` The complete set of colliding vPFNs observed across all 66 errors: ``` 0xbdf6e 0xbdf6f 0xbdf70 0xbdf71 0xbdf72 0xbdf73 0xbdf74 0xbdf75 0xbdf76 0xbdf77 0xbdf78 0xbdf79 0xbdf7a 0xbdf7b 0xbdf7c 0xbdf7d 0xbdf7e 0xbdf7f 0xbdf80 0xbdf81 0xbdf82 0xbdf83 0xbdf84 ``` That is `0xbdf6e`-`0xbdf84` — an exact, complete match with the RMRR union. All 23 distinct colliding IOVAs lie inside an RMRR region; none lies outside one. (Checked programmatically over the attached log, not by inspection.) The RMRR reserved-region exclusion in the IOVA allocator appears not to be in effect. ## This is not a firmware or BIOS problem The RMRR regions declared by the BIOS are **byte-for-byte identical** on 6.8.0-124 and 6.8.0-134 (diffed; both logs attached). Same machine, same BIOS (P71, 05/24/2019), same controller firmware. The only variable is the kernel. 6.8.0-124 handles these exact regions correctly. ## This is not passthrough-specific No VFIO/PCI passthrough is configured on this host (`lsmod | grep vfio` -> 0). This is a plain KVM/libvirt host using virtio and LVM-backed disks. Reports elsewhere tie the 6.8.12 IOMMU regression to VFIO group assignment; this reproducer has no VFIO involvement at all, which suggests the underlying defect is broader than the passthrough symptom it was first noticed through. ## A/B evidence (same physical machine, consecutive boots) | Boot | Kernel | Uptime | DMAR errors | I/O errors | |------|--------|--------|-------------|------------| | -2 | 6.8.0-124 | 2026-06-13 -> 2026-07-14 (31 days) | 0 | 0 | | -1 | 6.8.0-134 | ~10 min to controller loss | 66 | 4701 | | 0 | 6.8.0-124 | since revert, stable | 0 | 0 | Booting 6.8.0-124 restored full function immediately: controller status OK, volume group back, all VMs recovered. ## Timeline (boot -1, kernel 6.8.0-134) ``` 12:32:34 boot 12:41:24 first WARNING - nvme_map_data (mdraid rebuild driving heavy DMA) 12:42:46 hpsa_scatter_gather hits the same warning 12:42:50 tg3_start_xmit hits it too (network path) 12:43:23 hpsa: resetting logical Direct-Access HP LOGICAL VOLUME RAID-5 12:44:32 hpsa: reset logical failed / sd 3:1:0:0: rejecting I/O to offline device sda offline -> volume group gone -> 10 VMs lose their disks 13:25:05 reboot into 6.8.0-124 -> fully recovered ``` The first failure came ~9 minutes in, under sustained DMA load from an mdraid rebuild — consistent with the allocator only reaching the RMRR range once lower IOVA space was under pressure. Hosts may therefore appear fine after boot and fail later under load. ## Representative stack trace ``` WARNING: CPU: 32 PID: 562 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320 CPU: 32 PID: 562 Comm: kworker/32:1H Tainted: G I 6.8.0-134-generic #134-Ubuntu Hardware name: HP ProLiant DL360p Gen8, BIOS P71 05/24/2019 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:__domain_mapping+0x2b5/0x320 Call Trace: <TASK> intel_iommu_map_pages+0xe1/0x140 __iommu_map+0x121/0x280 iommu_map_sg+0xbf/0x1f0 iommu_dma_map_sg+0x463/0x4f0 __dma_map_sg_attrs+0x35/0xd0 dma_map_sgtable+0x1d/0x40 nvme_map_data+0xd6/0x480 [nvme] nvme_prep_rq.part.0+0x35/0x120 [nvme] nvme_queue_rq+0x7e/0x207 [nvme] blk_mq_dispatch_rq_list+0x137/0x520 __blk_mq_sched_dispatch_requests+0x118/0x190 blk_mq_sched_dispatch_requests+0x2f/0x80 blk_mq_run_work_fn+0x72/0x90 process_one_work+0x184/0x3a0 worker_thread+0x18b/0x330 kthread+0xf2/0x120 ret_from_fork+0x47/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- DMAR: ERROR: DMA PTE for vPFN 0xbdf81 already set (to bdf81003 not 128759003) ``` The same warning with `hpsa_scatter_gather+0x3e/0x310 [hpsa]` and with `__tg3_start_xmit+0x1f0/0xd60 [tg3]` in place of the nvme frames is in the attached log (46 nvme, 18 hpsa, 4 tg3 occurrences). ## Environment ``` Hardware: HP ProLiant DL360p Gen8 BIOS: HP P71, 05/24/2019 CPU: Intel Xeon E5-2697 v2 @ 2.70GHz (48 threads) RAM: 503 GB Controller: Smart Array P420i [103c:323b] rev 01, subsystem [103c:3354] PCI 0000:02:00.0, IOMMU group 49 Driver: hpsa 3.4.20-200 OS: Ubuntu 24.04.4 LTS Cmdline: BOOT_IMAGE=/boot/vmlinuz-6.8.0-134-generic root=UUID=<redacted> ro maybe-ubiquity (no intel_iommu= or iommu= parameter set; IOMMU on by default, 132 groups) Workload: KVM/libvirt host, ~30 VMs, LVM on hpsa RAID-5 + LVM on NVMe mdraid1 ``` **Control machine:** a second, identical DL360p Gen8 (same BIOS, same P420i) running 6.8.0-101 has 18+ weeks uptime with zero DMAR errors. It has not been exposed to -134 and is available to test a proposed kernel. I can also reproduce on the primary host in a maintenance window if that is more useful. ## Related reports Same signature (`DMA PTE ... already set` from a RAID driver's scatter-gather mapping, leading to controller resets) reported downstream on Proxmox, where a Proxmox developer states "the -29 one had an IOMMU related regression that is fixed there", referring to their 6.8.12-30 kernel: - https://forum.proxmox.com/threads/has-anyone-seen-dma-pte-megaraid-controller-resets-after-upgrading-to-recent-proxmox-8-kernels.184389/ - https://forum.proxmox.com/threads/proxmox-kernel-6-8-12-29-causing-array-controller-errors.184181/ Proxmox 6.8.12-29/-30 share the 6.8.12 base with Ubuntu's 6.8.0-134. If the fix there is a revert of an upstream stable commit, the same revert would plausibly apply here. **This is an inference from the shared code base and matching signature, not something I was able to confirm** — the referenced upstream report (kernel bugzilla #221234) is behind an anti-bot gate, and I could not identify the offending commit. An older, still-untriaged Ubuntu bug with the same signature: https://bugs.launchpad.net/bugs/1970453 ## Workarounds - Boot 6.8.0-124 (what we did; fully effective) - `iommu=pt` or `intel_iommu=off` reported effective by others (untested here) None of these are acceptable long-term for hosts that must stay on a supported kernel. ## Request Please identify and revert/backport the fix for the RMRR reserved-region handling in the 6.8.0 Noble series. ## Attachments and how they were prepared The attached logs have been **filtered before upload** — please read this so you know what you are and are not looking at: - `[UFW BLOCK]` firewall lines were **removed entirely**. They carried third-party source IP addresses (personal data under GDPR) and were unrelated to the fault. - Hostname, IP addresses, MAC addresses and UUIDs were replaced with placeholders. - Full `dmidecode` output is **not attached**: it embeds the chassis serial number three times over (including as a raw hex dump), and the system UUID is a hex encoding of that same serial. `hardware-summary.txt` contains the model-level fields instead. No kernel-relevant line was altered. The evidence was counted before and after filtering to confirm nothing was lost: 66 DMAR errors, 66 `iommu.c:2227` warnings, 132 `__domain_mapping` frames, 23 distinct vPFNs, 9 RMRR regions and the complete hpsa reset-to-offline chain are all present in both. **If you need an unfiltered log, ask me and I will provide one through a private channel.** - `dmesg-6.8.0-134-BAD.log` — full kernel log of the failing boot - `dmesg-6.8.0-124-GOOD-boot.log` — boot log of the working kernel, showing the identical RMRR regions and no collisions - `lspci-vvnn.txt` — full PCI topology - `hardware-summary.txt` — curated hardware/firmware details - `version.txt` — kernel, cmdline, distro, hpsa module info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616/+subscriptions
[Bug 1982483] Re: No sound from built-in speakers HP Pavilion All-in-One Desktop 27-ca1xxx (ALC274)
I think ca2xxxx is a different hardware than ca1xxxx. Did you try if it worked... ? -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1982483 Title: No sound from built-in speakers HP Pavilion All-in-One Desktop 27-ca1xxx (ALC274) Status in Linux: Confirmed Status in alsa-driver package in Ubuntu: New Status in linux package in Ubuntu: New Bug description: I have tried: options snd-hda-intel model=alc285-hp-amp-init options snd-hda-intel model=alc274-dell-aio and newer kernels up to 5.19-rc6. 21: PCI 1f.3: 0403 Audio device [Created at pci.386] Unique ID: nS1_.2CriaNVEdN5 SysFS ID: /devices/pci0000:00/0000:00:1f.3 SysFS BusID: 0000:00:1f.3 Hardware Class: sound Device Name: "Onboard - Sound" Model: "Intel Audio device" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x7ad0 SubVendor: pci 0x103c "Hewlett-Packard Company" SubDevice: pci 0x89e9 Revision: 0x11 Driver: "snd_hda_intel" Driver Modules: "snd_hda_intel" Memory Range: 0x6105238000-0x610523bfff (rw,non-prefetchable) Memory Range: 0x6105000000-0x61050fffff (rw,non-prefetchable) IRQ: 161 (1098 events) Module Alias: "pci:v00008086d00007AD0sv0000103Csd000089E9bc04sc03i80" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Driver Info #1: Driver Status: snd_sof_pci_intel_tgl is active Driver Activation Cmd: "modprobe snd_sof_pci_intel_tgl" Config Status: cfg=new, avail=yes, need=no, active=unknown <6>[ 3.582352] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC274: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker <6>[ 3.582359] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) <6>[ 3.582362] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) <6>[ 3.582364] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 <6>[ 3.582366] snd_hda_codec_realtek hdaudioC0D0: inputs: <6>[ 3.582367] snd_hda_codec_realtek hdaudioC0D0: Mic=0x19 <6>[ 3.582369] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 Alsa-info: https://alsa- project.org/db/?f=ed6190cfc9d9eb1c758c6c3106dd236b150f5b31 Here is a kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=216139 --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ernst 1560 F.... pulseaudio /dev/snd/controlC0: ernst 1560 F.... pulseaudio CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2022-06-15 (143 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: HP HP Pavilion All-in-One Desktop 27-ca1xxx NonfreeKernelModules: nvidia_modeset nvidia Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.0.0-1006-oem root=UUID=72ea78e1-7744-4fcc-b63c-3aa577c86a80 ro quiet splash ibt=off mitigations=off vt.handoff=7 ProcVersionSignature: Ubuntu 6.0.0-1006.6-oem 6.0.0 RelatedPackageVersions: linux-restricted-modules-6.0.0-1006-oem N/A linux-backports-modules-6.0.0-1006-oem N/A linux-firmware 20220329.git681281e4-0ubuntu3.6 Tags: jammy wayland-session Uname: Linux 6.0.0-1006-oem x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 02/09/2022 dmi.bios.release: 15.2 dmi.bios.vendor: AMI dmi.bios.version: F.02 dmi.board.name: 89E9 dmi.board.vendor: HP dmi.board.version: 0100 dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.ec.firmware.release: 1.16 dmi.modalias: dmi:bvnAMI:bvrF.02:bd02/09/2022:br15.2:efr1.16:svnHP:pnHPPavilionAll-in-OneDesktop27-ca1xxx:pvr:rvnHP:rn89E9:rvr0100:cvnHP:ct13:cvr:sku661Q7EA#UUW: dmi.product.family: 103C_53311M HP Pavilion dmi.product.name: HP Pavilion All-in-One Desktop 27-ca1xxx dmi.product.sku: 661Q7EA#UUW dmi.sys.vendor: HP modified.conffile..etc.default.apport: [modified] mtime.conffile..etc.default.apport: 2022-06-15T22:28:44.879144 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1982483/+subscriptions
[Bug 2160504] Re: random freeze of laptop complete only the screen is shown nothing works no keys except power on off button
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160504 Title: random freeze of laptop complete only the screen is shown nothing works no keys except power on off button Status in linux package in Ubuntu: New Bug description: my alptop randomly freezes it happens on linux mint with new kernal and now its happening with ubuntu ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: mysteries 4046 F.... wireplumber /dev/snd/seq: mysteries 4028 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jul 13 16:35:13 2026 InstallationDate: Installed on 2026-07-11 (2 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1bcf:2b96 Sunplus Innovation Technology Inc. Integrated_Webcam_HD Bus 001 Device 004: ID 0a5c:5834 Broadcom Corp. 5880 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 413c:81b6 Dell Computer Corp. DW5811e Snapdragon™ X7 LTE MachineType: Dell Inc. Latitude 7490 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-27-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv 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: 04/08/2025 dmi.bios.release: 1.44 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.44.0 dmi.board.name: 0KP0FT dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.44.0:bd04/08/2025:br1.44:svnDellInc.:pnLatitude7490:pvr:rvnDellInc.:rn0KP0FT:rvrA00:cvnDellInc.:ct10:cvr:sku081C:pfaLatitude: dmi.product.family: Latitude dmi.product.name: Latitude 7490 dmi.product.sku: 081C dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160504/+subscriptions
[Bug 1982483] Re: No sound from built-in speakers HP Pavilion All-in-One Desktop 27-ca1xxx (ALC274)
I had this issue on HP Pavilion All-in-One (Realtek ALC274, SSID 103c:8acf). With the help of claude, I dumped the codec on Windows with RWEverything while the amp was working, and diffed it against the Linux state. Attached is the report for my fix. ** Attachment added: "REPORT.md" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1982483/+attachment/5981782/+files/REPORT.md -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1982483 Title: No sound from built-in speakers HP Pavilion All-in-One Desktop 27-ca1xxx (ALC274) Status in Linux: Confirmed Status in alsa-driver package in Ubuntu: New Status in linux package in Ubuntu: New Bug description: I have tried: options snd-hda-intel model=alc285-hp-amp-init options snd-hda-intel model=alc274-dell-aio and newer kernels up to 5.19-rc6. 21: PCI 1f.3: 0403 Audio device [Created at pci.386] Unique ID: nS1_.2CriaNVEdN5 SysFS ID: /devices/pci0000:00/0000:00:1f.3 SysFS BusID: 0000:00:1f.3 Hardware Class: sound Device Name: "Onboard - Sound" Model: "Intel Audio device" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x7ad0 SubVendor: pci 0x103c "Hewlett-Packard Company" SubDevice: pci 0x89e9 Revision: 0x11 Driver: "snd_hda_intel" Driver Modules: "snd_hda_intel" Memory Range: 0x6105238000-0x610523bfff (rw,non-prefetchable) Memory Range: 0x6105000000-0x61050fffff (rw,non-prefetchable) IRQ: 161 (1098 events) Module Alias: "pci:v00008086d00007AD0sv0000103Csd000089E9bc04sc03i80" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Driver Info #1: Driver Status: snd_sof_pci_intel_tgl is active Driver Activation Cmd: "modprobe snd_sof_pci_intel_tgl" Config Status: cfg=new, avail=yes, need=no, active=unknown <6>[ 3.582352] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC274: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker <6>[ 3.582359] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) <6>[ 3.582362] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) <6>[ 3.582364] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 <6>[ 3.582366] snd_hda_codec_realtek hdaudioC0D0: inputs: <6>[ 3.582367] snd_hda_codec_realtek hdaudioC0D0: Mic=0x19 <6>[ 3.582369] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 Alsa-info: https://alsa- project.org/db/?f=ed6190cfc9d9eb1c758c6c3106dd236b150f5b31 Here is a kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=216139 --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ernst 1560 F.... pulseaudio /dev/snd/controlC0: ernst 1560 F.... pulseaudio CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2022-06-15 (143 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: HP HP Pavilion All-in-One Desktop 27-ca1xxx NonfreeKernelModules: nvidia_modeset nvidia Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.0.0-1006-oem root=UUID=72ea78e1-7744-4fcc-b63c-3aa577c86a80 ro quiet splash ibt=off mitigations=off vt.handoff=7 ProcVersionSignature: Ubuntu 6.0.0-1006.6-oem 6.0.0 RelatedPackageVersions: linux-restricted-modules-6.0.0-1006-oem N/A linux-backports-modules-6.0.0-1006-oem N/A linux-firmware 20220329.git681281e4-0ubuntu3.6 Tags: jammy wayland-session Uname: Linux 6.0.0-1006-oem x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 02/09/2022 dmi.bios.release: 15.2 dmi.bios.vendor: AMI dmi.bios.version: F.02 dmi.board.name: 89E9 dmi.board.vendor: HP dmi.board.version: 0100 dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.ec.firmware.release: 1.16 dmi.modalias: dmi:bvnAMI:bvrF.02:bd02/09/2022:br15.2:efr1.16:svnHP:pnHPPavilionAll-in-OneDesktop27-ca1xxx:pvr:rvnHP:rn89E9:rvr0100:cvnHP:ct13:cvr:sku661Q7EA#UUW: dmi.product.family: 103C_53311M HP Pavilion dmi.product.name: HP Pavilion All-in-One Desktop 27-ca1xxx dmi.product.sku: 661Q7EA#UUW dmi.sys.vendor: HP modified.conffile..etc.default.apport: [modified] mtime.conffile..etc.default.apport: 2022-06-15T22:28:44.879144 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1982483/+subscriptions
[Bug 1786013] Autopkgtest regression report (linux-meta-hwe-6.17/6.17.0-41.41~24.04.1)
All autopkgtests for the newly accepted linux-meta-hwe-6.17 (6.17.0-41.41~24.04.1) for noble have finished running. The following regressions have been reported in tests triggered by the package: dkms/3.0.11-1ubuntu13 (amd64) dpdk-kmods/0~20230205+git-1 (amd64) glibc/unknown (armhf) lxc/1:5.0.3-2ubuntu7.2 (amd64) snapd/2.75.2+ubuntu24.04 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/noble/update_excuses.html#linux-meta-hwe-6.17 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions
[Bug 2160608] [NEW] DisplayPort-over-Thunderbolt external monitor not detected at warm-boot
Public bug reported: Dock: Dell WD19TB, external monitor connected to it does not show up in kubuntu 26.04 after "reboot" command. Rest of devices on the dock work fine (usb keyboards etc). It works from cold start. What helps if this happens is either unplug the dock from both tb and power, and reconnect, or do the following: echo 0000:00:0d.2 | sudo tee /sys/bus/pci/drivers/thunderbolt/unbind sleep 2 echo 0000:00:0d.2 | sudo tee /sys/bus/pci/drivers/thunderbolt/bind Summary: DisplayPort-over-Thunderbolt external monitor not restored after warm reboot on Meteor Lake — TB connection manager tears down the DP tunnel before the GPU driver is ready, tunnel never recreated. Hardware: MSI Prestige 13 AI Evo A1MG (Meteor Lake-P) Host TB: Intel Meteor Lake-P Thunderbolt 4 NHI #0 [8086:7ec2], driver thunderbolt Dock: Dell WD19TB (Intel JHL7440 Titan Ridge, Thunderbolt 3), single external monitor via DP-over-TB Session: Wayland (KDE Plasma), Kubuntu 26.04 Kernel: 7.0.0-27-generic #27-Ubuntu SMP PREEMPT_DYNAMIC Thu Jun 18 2026 What happens: After a warm reboot (reboot, not cold power-off), the external monitor connected via DisplayPort-over-Thunderbolt stays dark. Cold boot works; warm reboot does not. dmesg shows the DP tunnel being torn down among the earliest kernel messages, i.e. before the i915/xe display driver is up: thunderbolt 0-3: Dell WD19TB Thunderbolt Dock thunderbolt 0-0:3.1: new retimer found, vendor=0x8087 device=0xd9c thunderbolt 0000:00:0d.2: 0:5 <-> 3:11 (DP): not active, tearing down The tunnel is destroyed and never recreated, because at teardown time the DP source (iGPU) is not yet driving it, and no later hotplug event triggers re-tunneling. Recovery (confirms HW is fine, this is a boot-ordering race): Physically unplugging/replugging the TB cable after boot → monitor comes up immediately, or Rebinding the NHI after the GPU driver is loaded works too: echo 0000:00:0d.2 > /sys/bus/pci/drivers/thunderbolt/unbind echo 0000:00:0d.2 > /sys/bus/pci/drivers/thunderbolt/bind Regression note: Probably similar teardown signature as reported on Ubuntu 26.04 for Panther Lake/xe, where 7.0.0-22 regressed and 7.0.0-15 worked. I'm on 7.0.0-27 on Meteor Lake and it still occurs — so the fix has not landed for this platform. Workaround in use: systemd oneshot unit that rebinds the NHI after graphical.target. boltctl shows the dock authorizes cleanly (iommu+user, auto-auth OK), so this is not an authorization issue. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jul 14 12:38:15 2026 InstallationDate: Installed on 2026-07-13 (1 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) MachineType: Micro-Star International Co., Ltd. Prestige 13 AI Evo A1MG ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-27-generic root=UUID=523ca483-c48f-4f58-bf0b-74682d2d8535 ro quiet cryptdevice=UUID=77a13756-e087-418d-857e-9bd8d72aa6d5:luks-77a13756-e087-418d-857e-9bd8d72aa6d5 root=/dev/mapper/luks-77a13756-e087-418d-857e-9bd8d72aa6d5 splash 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: 11/04/2025 dmi.bios.release: 1.13 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E13Q2IMS.10D dmi.board.asset.tag: Default string dmi.board.name: MS-13Q2 dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: REV:1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE13Q2IMS.10D:bd11/04/2025:br1.13:svnMicro-StarInternationalCo.,Ltd.:pnPrestige13AIEvoA1MG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-13Q2:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct10:cvrN/A:sku13Q2.1:pfaPrestige: dmi.product.family: Prestige dmi.product.name: Prestige 13 AI Evo A1MG dmi.product.sku: 13Q2.1 dmi.product.version: REV:1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160608 Title: DisplayPort-over-Thunderbolt external monitor not detected at warm- boot Status in linux package in Ubuntu: New Bug description: Dock: Dell WD19TB, external monitor connected to it does not show up in kubuntu 26.04 after "reboot" command. Rest of devices on the dock work fine (usb keyboards etc). It works from cold start. What helps if this happens is either unplug the dock from both tb and power, and reconnect, or do the following: echo 0000:00:0d.2 | sudo tee /sys/bus/pci/drivers/thunderbolt/unbind sleep 2 echo 0000:00:0d.2 | sudo tee /sys/bus/pci/drivers/thunderbolt/bind Summary: DisplayPort-over-Thunderbolt external monitor not restored after warm reboot on Meteor Lake — TB connection manager tears down the DP tunnel before the GPU driver is ready, tunnel never recreated. Hardware: MSI Prestige 13 AI Evo A1MG (Meteor Lake-P) Host TB: Intel Meteor Lake-P Thunderbolt 4 NHI #0 [8086:7ec2], driver thunderbolt Dock: Dell WD19TB (Intel JHL7440 Titan Ridge, Thunderbolt 3), single external monitor via DP-over-TB Session: Wayland (KDE Plasma), Kubuntu 26.04 Kernel: 7.0.0-27-generic #27-Ubuntu SMP PREEMPT_DYNAMIC Thu Jun 18 2026 What happens: After a warm reboot (reboot, not cold power-off), the external monitor connected via DisplayPort-over-Thunderbolt stays dark. Cold boot works; warm reboot does not. dmesg shows the DP tunnel being torn down among the earliest kernel messages, i.e. before the i915/xe display driver is up: thunderbolt 0-3: Dell WD19TB Thunderbolt Dock thunderbolt 0-0:3.1: new retimer found, vendor=0x8087 device=0xd9c thunderbolt 0000:00:0d.2: 0:5 <-> 3:11 (DP): not active, tearing down The tunnel is destroyed and never recreated, because at teardown time the DP source (iGPU) is not yet driving it, and no later hotplug event triggers re-tunneling. Recovery (confirms HW is fine, this is a boot-ordering race): Physically unplugging/replugging the TB cable after boot → monitor comes up immediately, or Rebinding the NHI after the GPU driver is loaded works too: echo 0000:00:0d.2 > /sys/bus/pci/drivers/thunderbolt/unbind echo 0000:00:0d.2 > /sys/bus/pci/drivers/thunderbolt/bind Regression note: Probably similar teardown signature as reported on Ubuntu 26.04 for Panther Lake/xe, where 7.0.0-22 regressed and 7.0.0-15 worked. I'm on 7.0.0-27 on Meteor Lake and it still occurs — so the fix has not landed for this platform. Workaround in use: systemd oneshot unit that rebinds the NHI after graphical.target. boltctl shows the dock authorizes cleanly (iommu+user, auto-auth OK), so this is not an authorization issue. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Tue Jul 14 12:38:15 2026 InstallationDate: Installed on 2026-07-13 (1 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) MachineType: Micro-Star International Co., Ltd. Prestige 13 AI Evo A1MG ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-27-generic root=UUID=523ca483-c48f-4f58-bf0b-74682d2d8535 ro quiet cryptdevice=UUID=77a13756-e087-418d-857e-9bd8d72aa6d5:luks-77a13756-e087-418d-857e-9bd8d72aa6d5 root=/dev/mapper/luks-77a13756-e087-418d-857e-9bd8d72aa6d5 splash 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: 11/04/2025 dmi.bios.release: 1.13 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E13Q2IMS.10D dmi.board.asset.tag: Default string dmi.board.name: MS-13Q2 dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: REV:1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE13Q2IMS.10D:bd11/04/2025:br1.13:svnMicro-StarInternationalCo.,Ltd.:pnPrestige13AIEvoA1MG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-13Q2:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct10:cvrN/A:sku13Q2.1:pfaPrestige: dmi.product.family: Prestige dmi.product.name: Prestige 13 AI Evo A1MG dmi.product.sku: 13Q2.1 dmi.product.version: REV:1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160608/+subscriptions
[Bug 2154418] Re: Backport ASoC SDCA, AMD SoundWire, and RT722 audio fixes
On 26.04, microphone device shows up with kernel 7.0.0-28 and alsa-ucm-conf 1.2.15.3-1ubuntu1.4 in proposed. I could do record audio with 'arecord' and hear the sound from speak with 'aplay'. LED of Speaker mute and Microphone mute work fine. $ amixer -c1 info Card sysdefault:1 'amdsoundwire'/'LENOVO-21YWSIT002-ThinkPadT14sGen7' Mixer name→ : '' Components→ : ' cfg-amp:1 mic:acp-dmic cfg-mics:1 spk:rt1320 hs:rt722' Controls : 29 Simple ctrls : 23 $ apt-cache policy alsa-ucm-conf linux-generic-hwe-26.04 alsa-ucm-conf: Installed: 1.2.15.3-1ubuntu1.4 Candidate: 1.2.15.3-1ubuntu1.4 Version table: *** 1.2.15.3-1ubuntu1.4 100 100 http://archive.ubuntu.com/ubuntu resolute-proposed/main amd64 Packages 100 /var/lib/dpkg/status 1.2.15.3-1ubuntu1.2 500 500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages 1.2.15.3-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages linux-generic-hwe-26.04: Installed: 7.0.0-28.28 Candidate: 7.0.0-28.28 Version table: *** 7.0.0-28.28 100 100 http://archive.ubuntu.com/ubuntu resolute-proposed/main amd64 Packages 100 /var/lib/dpkg/status 7.0.0-27.27 500 500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages 7.0.0-14.14 500 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages ** Tags removed: verification-needed-resolute-linux ** Tags added: verification-done-resolute-linux ** Tags removed: verification-needed-resolute ** Tags added: verification-done-resolute -- 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 Released Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Released Status in alsa-ucm-conf 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 alsa-ucm-conf source package in Resolute: Fix Committed Status in linux source package in Resolute: Fix Committed Status in linux-oem-6.17 source package in Resolute: Invalid 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 2160583] Re: MAAS deployment fails on 32GB memory system with systemd-journald "No space left on device" error
with current latest MAAS 3.6.5, the issue re-produced on the 2nd system ST50 V3 with 32GB mem and both error points as below, assume it takes much size, please double check if it is the root cause. Setting up checkbox-provider-gpgpu (7.3.0~dev42~ubuntu26.04.1) ... 2026-07-13T08:01:53Z INFO Waiting for automatic snapd restart... 2026-07-13T08:01:54Z INFO Waiting for automatic snapd restart... 2026-07-13T08:01:55Z INFO Waiting for automatic snapd restart... 2026-07-13T08:01:56Z INFO Waiting for automatic snapd restart... Warning: /snap/bin was not found in your $PATH. If you've not restarted your session since you installed snapd, try doing that. Please see https://forum.snapcraft.io/t/9469 for more details. rocm-validation-suite 6.3.3 from Pedro Avalos installed error: cannot communicate with server: Get "http://localhost/v2/changes/6": EOF dpkg: error processing package checkbox-provider-gpgpu (--configure): old checkbox-provider-gpgpu package postinst maintainer script subprocess failed with exit status 1 Setting up qemu-system-gui (1:10.2.1+ds-1ubuntu3.1) ... Setting up checkbox-provider-certification-server (7.3.0~dev42~ubuntu26.04.1) ... Setting up canonical-certification-server (7.3.0~dev42~ubuntu26.04.1) ... Processing triggers for libc-bin (2.43-2ubuntu2) ... Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.44.5+dfsg-4ubuntu1) ... Errors were encountered while processing: checkbox-provider-gpgpu needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Done. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160583 Title: MAAS deployment fails on 32GB memory system with systemd-journald "No space left on device" error Status in linux package in Ubuntu: New Bug description: Ubuntu is deployed through MAAS. During deployment, the installation progresses normally and the deployment log contains: curtin: Installation Finished However, later in the deployment process, the following error is observed: systemd-journaldfailed to save stream data /run/systemd/journal/streams/10:128376: No space left on device Shortly afterward, MAAS marks the machine deployment as failed. see attachment"happy-swan.maas-installation-output-2026-07-13.log" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160583/+subscriptions
[Bug 1786013] Autopkgtest regression report (linux-meta-gcp/6.8.0-1064.72)
All autopkgtests for the newly accepted linux-meta-gcp (6.8.0-1064.72) for noble have finished running. The following regressions have been reported in tests triggered by the package: dkms/3.0.11-1ubuntu13 (amd64) dpdk-kmods/unknown (amd64) glibc/2.39-0ubuntu8.7 (amd64, arm64) lxc/1:5.0.3-2ubuntu7.2 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/noble/update_excuses.html#linux-meta-gcp [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions
[Bug 2158858] Please test proposed package
Hello Chris, or anyone else affected, Accepted linux-firmware-misc into resolute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/linux-firmware- misc/20260319.git217ca6e4-0ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- resolute to verification-done-resolute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-resolute. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158858 Title: Fix no audio output and mute hotkey not working on HP ZBook 8 G2a Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-firmware package in Ubuntu: Invalid Status in linux-firmware-misc 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-firmware source package in Noble: Fix Committed Status in linux-oem-6.17 source package in Noble: New Status in linux source package in Resolute: New Status in linux-firmware source package in Resolute: Invalid Status in linux-firmware-misc source package in Resolute: Fix Committed Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] No audio output from the built-in speaker and the speaker and mic mute LEDs never turn on on affected HP systems (SSIDs 0x103c:0x8f94 and 0x103c:0x8f95). ================ Linux Kernel ======================== [Fix] Add the ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED quirk to enable speaker and mic mute LEDs for SSIDs 0x103c:0x8f94 and 0x103c:0x8f95. ================ linux-firmware ======================== [Fix] Backport upstream fix a16ce5c67 ("linux-firmware: Add firmware for new projects") [Test Plan] 1. Boot up the affected machine 2. Check the audio output by pressing `Test speakers` on the g-d-d sound menu. 3. Press the speaker and mic mute keys and verify the following - Speaker muted: LED is on - Speaker not muted: LED is off - Mic muted: LED is on - Mic not muted: LED is off [Where problems could occur] This change is restricted on particular SSIDs. Should be no risk of regression. -- PR: Noble: https://kernel.ubuntu.com/forgejo/kernel/linux-firmware/pulls/393 Resolute: https://kernel.ubuntu.com/forgejo/kernel/linux-firmware/pulls/394 To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2158858/+subscriptions
[Bug 2158858] Re: Fix no audio output and mute hotkey not working on HP ZBook 8 G2a
** Changed in: linux-oem-6.17 (Ubuntu) Status: New => Invalid ** Changed in: linux-firmware-misc (Ubuntu) Status: New => Fix Released ** Changed in: linux-firmware (Ubuntu) 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/2158858 Title: Fix no audio output and mute hotkey not working on HP ZBook 8 G2a Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-firmware package in Ubuntu: Invalid Status in linux-firmware-misc 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-firmware source package in Noble: Fix Committed Status in linux-oem-6.17 source package in Noble: New Status in linux source package in Resolute: New Status in linux-firmware source package in Resolute: Invalid Status in linux-firmware-misc source package in Resolute: Fix Committed Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] No audio output from the built-in speaker and the speaker and mic mute LEDs never turn on on affected HP systems (SSIDs 0x103c:0x8f94 and 0x103c:0x8f95). ================ Linux Kernel ======================== [Fix] Add the ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED quirk to enable speaker and mic mute LEDs for SSIDs 0x103c:0x8f94 and 0x103c:0x8f95. ================ linux-firmware ======================== [Fix] Backport upstream fix a16ce5c67 ("linux-firmware: Add firmware for new projects") [Test Plan] 1. Boot up the affected machine 2. Check the audio output by pressing `Test speakers` on the g-d-d sound menu. 3. Press the speaker and mic mute keys and verify the following - Speaker muted: LED is on - Speaker not muted: LED is off - Mic muted: LED is on - Mic not muted: LED is off [Where problems could occur] This change is restricted on particular SSIDs. Should be no risk of regression. -- PR: Noble: https://kernel.ubuntu.com/forgejo/kernel/linux-firmware/pulls/393 Resolute: https://kernel.ubuntu.com/forgejo/kernel/linux-firmware/pulls/394 To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2158858/+subscriptions