[Bug 1117804] Re: ausearch doesn't show AppArmor denial messages

Debdiff for Stonking ** Patch added: "lp1117804-stonking-4.debdiff" https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1117804/+attachment/5984991/+files/lp1117804-stonking-4.debdiff -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1117804 Title: ausearch doesn't show AppArmor denial messages Status in AppArmor: Confirmed Status in audit package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in audit source package in Jammy: In Progress Status in audit source package in Noble: In Progress Status in audit source package in Questing: Won't Fix Status in audit source package in Resolute: In Progress Status in audit source package in Stonking: In Progress Bug description: [ Impact ]  * The following command should display all AppArmor AVC events: `ausearch --message AVC`; however, it doesn't work: ``` yachie@virtual:/etc/apparmor.d$ ausearch --message AVC <no matches> ```  * Users currently must inspect `/var/log/audit.log` to find the missing AppArmor AVC events: ``` yachie@virtual:/etc/apparmor.d$ sudo cat /var/log/audit.log type=AVC msg=audit(1774470501.870:1117918): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/2009624/cmdline" pid=106062 comm="in:imuxsock" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 FSUID="root" OUID="root" type=AVC msg=audit(1774470501.927:1117919): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/2009636/cmdline" pid=106062 comm="in:imuxsock" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 FSUID="root" OUID="root" ```  * The root cause is that `ausearch` is checking for a `tclass` field in the AppArmor events, because AppArmor is using event id `1400` (assigned to SELinux) instead of `1500`.  * AppArmor events don't have a `tclass` field, so `ausearch` treats every AppArmor event as 'malformed' and hides them. We can reveal the 'malformed' events with the `--debug` flag:  ``` yachie@virtual:~$ ausearch --message AVC --debug ( ... a ton of unrelated events ... ) Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.176:616): apparmor="AUDIT" operation="change_onexec" class="file" info="change_profile unprivileged unconfined converted to stacking" profile="unconfined" name="lsb_release" pid=5443 comm="aa-exec" Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:617): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/etc/nsswitch.conf" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:618): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/etc/passwd" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:619): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/etc/bash.bashrc" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:620): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/home/yachie/.bashrc" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:621): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/home/yachie/.bash_history" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:622): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/home/yachie/.bash_history" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Malformed event skipped, rc=9. type=AVC msg=audit(1776888566.177:623): apparmor="DENIED" operation="open" class="file" profile="lsb_release" name="/etc/inputrc" pid=5443 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 <no matches>  ```  * This bug makes `auditd` very difficult to use on Ubuntu: having the `auditd` package installed hides AVC events from the kernel log AND `ausearch` doesn't reveal them, making AppArmor events seemingly vanish unless you know where to look. [ Test plan ] # Install the relevant packages 1. sudo apt install apparmor auditd # Run the reproducer 2. aa-exec --profile=lsb_release bash # generates a ton of denials; see below: ``` root@jammy-vm:~# aa-exec --profile lsb_release bash bash: /etc/bash.bashrc: Permission denied bash: /root/.bashrc: Permission denied bash-5.1# exit ``` # Run `ausearch` and search for AVC events 3. ausearch --message AVC 3a. Unpatched package output (fail): ``` root@jammy-vm:~# ausearch --message AVC <no matches> ``` 3b. Patched package output (success): ``` root@jammy-vm:~# ausearch --message AVC ---- time->Tue Jul 14 21:03:18 2026 type=PROCTITLE msg=audit(1784062998.789:100): proctitle="bash" type=SYSCALL msg=audit(1784062998.789:100): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7f6a7274c150 a2=80000 a3=0 items=0 ppid=562 pid=3449 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=lsb_release key=(null) type=AVC msg=audit(1784062998.789:100): apparmor="DENIED" operation="open" profile="lsb_release" name="/etc/nsswitch.conf" pid=3449 comm="bash" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ---- time->Tue Jul 14 21:03:18 2026 type=PROCTITLE msg=audit(1784062998.789:101): proctitle="bash" type=SYSCALL msg=audit(1784062998.789:101): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7f6a7274c2ac a2=80000 a3=0 items=0 ppid=562 pid=3449 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=lsb_release key=(null) type=AVC msg=audit(1784062998.789:101): apparmor="DENIED" operation="open" profile="lsb_release" name="/etc/passwd" pid=3449 comm="bash" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ---- ( ...continues ) ``` [ Where problems could occur ]  * Currently, all AppArmor events are treated as 'malformed' SELinux events when they are actually well-formed AppArmor events.  * This patch modifies the filtration behavior of `ausearch` by making the `tclass` field optional, thus making AppArmor events be treated as well-formed SELinux events.  * The regression risk with this patch is such that potentially well- formed events will be hidden by `ausearch` unintentionally, or truly malformed events will be allowed past the filter.  * One major caveat is that regressions with respect to actual SELinux events are difficult to test on Ubuntu; some malformed SELinux events would potentially be allowed through the filter with this patch, or well-formed SELinux events hidden. This patch essentially trades correctness in the SELinux case for correctness in the AppArmor case. [ Other info ]  * Debian likely doesn't want this patch, as Debian officially won't be making any changes until upstream does [3].  * Upstream `audit` can't move the AppArmor event id to the `1500` range any time soon. AppArmor was moved to the `1400` range to align with the Linux kernel LSM infrastructure [2].  * This patch comes from SUSE; they've been carrying it for well over a decade [4], and they seem to still be carrying it even after switching to SELinux by default [5]. Targeted releases: All currently supported releases and all releases moving forward until AppArmor moves back to the `1500` event range or Ubuntu switches to SELinux by default. [1] Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726 [2] AA using 1400 reason: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726#39 [3] Debian `wontfix` closure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726#88 [4] SUSE KB: https://support.scc.suse.com/s/kb/audit-log-file-that-has-the-apparmor-AVC-entries-that-ausearch-can-t-read-1583239408721?language=en_US [5] SUSE Patch: https://build.opensuse.org/projects/security/packages/audit/files/audit-ausearch-do-not-require-tclass.patch [ Original bug (for posterity after over a decade) ] The following command should display all AVC denials: ausearch -m avc However, it doesn't work with AppArmor denials. Here's a quick test case to generate a denial, search for it with ausearch, and see that no messages are displayed: $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current cat: /proc/self/attr/current: Permission denied $ sudo ausearch -m avc -c cat <no matches> ausearch claims that there are no matches, but there's a matching audit message if you look in audit.log: type=AVC msg=audit(1360193426.539:64): apparmor="DENIED" operation="open" parent=8253 profile="/usr/sbin/tcpdump" name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions

[Bug 2161355] Re: Cannot issue auditctl -q to notify kernel of new subtrees

Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161355 Title: Cannot issue auditctl -q to notify kernel of new subtrees Status in linux package in Ubuntu: Confirmed Bug description: Package: linux-image-6.8.0-136-generic (not found in the drop down above) Description: Ubuntu 24.04.4 LTS Release: 24.04 Since upgrading from linux-image-6.8.0-134-generic(6.8.0-134.134) to linux-image-6.8.0-136-generic(6.8.0-136.136) it's no longer possible to invoke `auditctl -q /data,/data/tenant` . The result is the following error: Error sending make_equivalent command (Operation not permitted) Note that the command is invoked by a systemd unit that run after a specific mount operation. Downgrading to linux-image-6.8.0-134-generic restores the expected behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161355/+subscriptions

[Bug 2161093] Re: Black screen after boot with kernel 7.0.0-28-generic on AMD Radeon RX 580

Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161093 Title: Black screen after boot with kernel 7.0.0-28-generic on AMD Radeon RX 580 Status in linux package in Ubuntu: Confirmed Bug description: After installing the latest system updates on KDE neon, my system no longer boots into the graphical desktop when using kernel 7.0.0-28-generic. Hardware: - CPU: AMD Ryzen 5 1600 - GPU: AMD Radeon RX 580 8 GB (Polaris) Symptoms: - GRUB loads normally. - The boot logo is displayed. - After that the screen becomes completely black. - Ctrl+Alt+F1...F6 do not switch to a TTY. - Ctrl+Alt+Del reboots the computer. Booting the previous kernel (6.17.0-40-generic) on the same installation works normally. The issue started immediately after installing system updates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161093/+subscriptions

[Bug 2161425] Re: Lenovo Thunderbolt 4 dock intermittently fails or disconnects, causing USB device loss and both Radeon 680M-driven external MST displays to blank

Update: This is not a new 7.0 regression. Retained journals show the same dock-path failures on Ubuntu kernels 6.17.0-22-generic and 6.17.0-23-generic: USB setup/address failures (error -71), Thunderbolt disconnects, and AMDGPU AUX/MST/DPCD link errors. For example, a 6.17.0-22 boot logged 10 USB errors, 28 AUX/MST4 errors, and 183 Thunderbolt disconnect messages; another logged 13 USB errors, 24 AUX/MST errors, and 603 Thunderbolt disconnects. The newer 7.0 series adds recurring dcn31_program_compbuf_size warnings, first observed locally on 7.0.0-15, but 7.0.0-28 still exhibits the underlying failure: the dock can disconnect at runtime, blank both external displays, then re-enumerate. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161425 Title: Lenovo Thunderbolt 4 dock intermittently fails or disconnects, causing USB device loss and both Radeon 680M-driven external MST displays to blank Status in linux package in Ubuntu: New Bug description: # System - Lenovo ThinkPad T14s Gen 3 (`21CRS08P00`) - AMD Rembrandt / Radeon 680M (`1002:1681`) - BIOS `R22ET81W (1.51)`, dated 2026-04-10 - Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock - Ubuntu 26.04 LTS - Kernel `7.0.0-28-generic`, package version `7.0.0-28.28` - `linux-firmware` version `20260319.git217ca6e4.1ubuntu` # Expected result The dock should enumerate reliably on either supported laptop USB-C port. Its USB devices and both external displays should remain connected, without AMDGPU warnings or GNOME atomic-commit failures. # Actual result Observed outcomes include: 1. USB setup fails with `device not accepting address ..., error -71`; no Thunderbolt device or DP MST topology is created. 2. A docked boot shows `failed to allocate DP resource for port 7`, `DMUB notification skipped due to no handler: type=HPD`, and `DM_MST: Differing MST start`, then eventually recovers. 3. After successful enumeration, the entire dock disconnects and re-enumerates at runtime. Both external displays blank, GNOME reports failed atomic commits, and AMDGPU reports DPIA allocation-table and DCN compbuf warnings. # Reproduction / observations 1. Boot Ubuntu with the dock's rear/upstream port and both external displays already connected, or boot undocked and connect the dock after login. 2. Observe either successful enumeration or an early USB `error -71` failure. The result is port/path-sensitive: - Rear/upstream dock port to one laptop USB-C port: failed after the initial USB attempt with `error -71`; no Thunderbolt or display event followed. - Rear/upstream dock port to the other laptop USB-C port: full dock enumeration and both displays worked, after one recoverable AMDGPU `Sending link address failed with -5` message. 3. During a separate successful `7.0.0-28-generic` boot, the dock later disconnected and re-enumerated. Both displays went off and came back. # Relevant kernel messages Runtime disconnect on `7.0.0-28-generic`: ```text DM_MST: stopping TM USB devices below usb 8-1 and usb 9-1 disconnect thunderbolt 0-2: device disconnected gnome-shell: Page flip failed: drmModeAtomicCommit: Invalid argument WARNING in update_dpia_stream_allocation_table [amdgpu] REG_WAIT timeout in dcn31_program_compbuf_size WARNING in dcn31_program_compbuf_size [amdgpu] Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock detected again DM_MST: starting TM; DP14, 4-lane link detected ``` Docked-boot initialization on `7.0.0-28-generic`: ```text thunderbolt 0000:34:00.6: 0: failed to allocate DP resource for port 7 amdgpu: [drm] DMUB notification skipped due to no handler: type=HPD amdgpu: [drm] DM_MST: Differing MST start on aconnector ``` Failed hot-plug through one laptop USB-C port: ```text usb 8-1: Device not responding to setup address. usb 8-1: device not accepting address 2, error -71 ``` # Historical information Retained journals from kernels `6.17.0-22` and `6.17.0-23` already contain USB enumeration failures, Thunderbolt disconnects, and AMDGPU AUX/MST/DPCD failures. The `dcn31_program_compbuf_size` warning is newer locally: it first appears with `7.0.0-15-generic` and recurs through `7.0.0-27-generic`. # Notes The sequence suggests an interaction between USB4/Thunderbolt DP tunnel setup and AMDGPU DPIA/MST initialization, but that is only an inference from log ordering, not a root-cause claim. Please triage with both the Ubuntu kernel and relevant upstream AMDGPU/Thunderbolt components in mind. A one-time oops in `trigger_hpd_mst_set [amdgpu]` occurred only after manually writing an AMDGPU debugfs MST trigger. It was not part of normal operation, so I will report it separately if needed rather than using it as a workaround or conflating it with this issue. # Attachments 1. The Apport report generated with `ubuntu-bug linux`. 2. Full kernel journals for: the runtime-disconnect boot, the docked boot showing DP-resource/MST-ordering messages, the failed hot-plug path, and the successful alternate-port path. 3. `sudo boltctl list --verbose` (if Bolt is installed) and `lspci -nnk`. 4. Do not use the AMDGPU debugfs MST HPD trigger; it caused a separate diagnostic-only oops in this environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161425/+subscriptions

[Bug 2161425] [NEW] Lenovo Thunderbolt 4 dock intermittently fails or disconnects, causing USB device loss and both Radeon 680M-driven external MST displays to blank

Public bug reported: # System - Lenovo ThinkPad T14s Gen 3 (`21CRS08P00`) - AMD Rembrandt / Radeon 680M (`1002:1681`) - BIOS `R22ET81W (1.51)`, dated 2026-04-10 - Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock - Ubuntu 26.04 LTS - Kernel `7.0.0-28-generic`, package version `7.0.0-28.28` - `linux-firmware` version `20260319.git217ca6e4.1ubuntu` # Expected result The dock should enumerate reliably on either supported laptop USB-C port. Its USB devices and both external displays should remain connected, without AMDGPU warnings or GNOME atomic-commit failures. # Actual result Observed outcomes include: 1. USB setup fails with `device not accepting address ..., error -71`; no Thunderbolt device or DP MST topology is created. 2. A docked boot shows `failed to allocate DP resource for port 7`, `DMUB notification skipped due to no handler: type=HPD`, and `DM_MST: Differing MST start`, then eventually recovers. 3. After successful enumeration, the entire dock disconnects and re-enumerates at runtime. Both external displays blank, GNOME reports failed atomic commits, and AMDGPU reports DPIA allocation-table and DCN compbuf warnings. # Reproduction / observations 1. Boot Ubuntu with the dock's rear/upstream port and both external displays already connected, or boot undocked and connect the dock after login. 2. Observe either successful enumeration or an early USB `error -71` failure. The result is port/path-sensitive: - Rear/upstream dock port to one laptop USB-C port: failed after the initial USB attempt with `error -71`; no Thunderbolt or display event followed. - Rear/upstream dock port to the other laptop USB-C port: full dock enumeration and both displays worked, after one recoverable AMDGPU `Sending link address failed with -5` message. 3. During a separate successful `7.0.0-28-generic` boot, the dock later disconnected and re-enumerated. Both displays went off and came back. # Relevant kernel messages Runtime disconnect on `7.0.0-28-generic`: ```text DM_MST: stopping TM USB devices below usb 8-1 and usb 9-1 disconnect thunderbolt 0-2: device disconnected gnome-shell: Page flip failed: drmModeAtomicCommit: Invalid argument WARNING in update_dpia_stream_allocation_table [amdgpu] REG_WAIT timeout in dcn31_program_compbuf_size WARNING in dcn31_program_compbuf_size [amdgpu] Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock detected again DM_MST: starting TM; DP14, 4-lane link detected ``` Docked-boot initialization on `7.0.0-28-generic`: ```text thunderbolt 0000:34:00.6: 0: failed to allocate DP resource for port 7 amdgpu: [drm] DMUB notification skipped due to no handler: type=HPD amdgpu: [drm] DM_MST: Differing MST start on aconnector ``` Failed hot-plug through one laptop USB-C port: ```text usb 8-1: Device not responding to setup address. usb 8-1: device not accepting address 2, error -71 ``` # Historical information Retained journals from kernels `6.17.0-22` and `6.17.0-23` already contain USB enumeration failures, Thunderbolt disconnects, and AMDGPU AUX/MST/DPCD failures. The `dcn31_program_compbuf_size` warning is newer locally: it first appears with `7.0.0-15-generic` and recurs through `7.0.0-27-generic`. # Notes The sequence suggests an interaction between USB4/Thunderbolt DP tunnel setup and AMDGPU DPIA/MST initialization, but that is only an inference from log ordering, not a root-cause claim. Please triage with both the Ubuntu kernel and relevant upstream AMDGPU/Thunderbolt components in mind. A one-time oops in `trigger_hpd_mst_set [amdgpu]` occurred only after manually writing an AMDGPU debugfs MST trigger. It was not part of normal operation, so I will report it separately if needed rather than using it as a workaround or conflating it with this issue. # Attachments 1. The Apport report generated with `ubuntu-bug linux`. 2. Full kernel journals for: the runtime-disconnect boot, the docked boot showing DP-resource/MST-ordering messages, the failed hot-plug path, and the successful alternate-port path. 3. `sudo boltctl list --verbose` (if Bolt is installed) and `lspci -nnk`. 4. Do not use the AMDGPU debugfs MST HPD trigger; it caused a separate diagnostic-only oops in this environment. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "kernel amdgpu thunderbolt usb4 displayport mst external-monito" https://bugs.launchpad.net/bugs/2161425/+attachment/5984981/+files/ubuntu-linux-attachments-20260721.zip -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161425 Title: Lenovo Thunderbolt 4 dock intermittently fails or disconnects, causing USB device loss and both Radeon 680M-driven external MST displays to blank Status in linux package in Ubuntu: New Bug description: # System - Lenovo ThinkPad T14s Gen 3 (`21CRS08P00`) - AMD Rembrandt / Radeon 680M (`1002:1681`) - BIOS `R22ET81W (1.51)`, dated 2026-04-10 - Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock - Ubuntu 26.04 LTS - Kernel `7.0.0-28-generic`, package version `7.0.0-28.28` - `linux-firmware` version `20260319.git217ca6e4.1ubuntu` # Expected result The dock should enumerate reliably on either supported laptop USB-C port. Its USB devices and both external displays should remain connected, without AMDGPU warnings or GNOME atomic-commit failures. # Actual result Observed outcomes include: 1. USB setup fails with `device not accepting address ..., error -71`; no Thunderbolt device or DP MST topology is created. 2. A docked boot shows `failed to allocate DP resource for port 7`, `DMUB notification skipped due to no handler: type=HPD`, and `DM_MST: Differing MST start`, then eventually recovers. 3. After successful enumeration, the entire dock disconnects and re-enumerates at runtime. Both external displays blank, GNOME reports failed atomic commits, and AMDGPU reports DPIA allocation-table and DCN compbuf warnings. # Reproduction / observations 1. Boot Ubuntu with the dock's rear/upstream port and both external displays already connected, or boot undocked and connect the dock after login. 2. Observe either successful enumeration or an early USB `error -71` failure. The result is port/path-sensitive: - Rear/upstream dock port to one laptop USB-C port: failed after the initial USB attempt with `error -71`; no Thunderbolt or display event followed. - Rear/upstream dock port to the other laptop USB-C port: full dock enumeration and both displays worked, after one recoverable AMDGPU `Sending link address failed with -5` message. 3. During a separate successful `7.0.0-28-generic` boot, the dock later disconnected and re-enumerated. Both displays went off and came back. # Relevant kernel messages Runtime disconnect on `7.0.0-28-generic`: ```text DM_MST: stopping TM USB devices below usb 8-1 and usb 9-1 disconnect thunderbolt 0-2: device disconnected gnome-shell: Page flip failed: drmModeAtomicCommit: Invalid argument WARNING in update_dpia_stream_allocation_table [amdgpu] REG_WAIT timeout in dcn31_program_compbuf_size WARNING in dcn31_program_compbuf_size [amdgpu] Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock detected again DM_MST: starting TM; DP14, 4-lane link detected ``` Docked-boot initialization on `7.0.0-28-generic`: ```text thunderbolt 0000:34:00.6: 0: failed to allocate DP resource for port 7 amdgpu: [drm] DMUB notification skipped due to no handler: type=HPD amdgpu: [drm] DM_MST: Differing MST start on aconnector ``` Failed hot-plug through one laptop USB-C port: ```text usb 8-1: Device not responding to setup address. usb 8-1: device not accepting address 2, error -71 ``` # Historical information Retained journals from kernels `6.17.0-22` and `6.17.0-23` already contain USB enumeration failures, Thunderbolt disconnects, and AMDGPU AUX/MST/DPCD failures. The `dcn31_program_compbuf_size` warning is newer locally: it first appears with `7.0.0-15-generic` and recurs through `7.0.0-27-generic`. # Notes The sequence suggests an interaction between USB4/Thunderbolt DP tunnel setup and AMDGPU DPIA/MST initialization, but that is only an inference from log ordering, not a root-cause claim. Please triage with both the Ubuntu kernel and relevant upstream AMDGPU/Thunderbolt components in mind. A one-time oops in `trigger_hpd_mst_set [amdgpu]` occurred only after manually writing an AMDGPU debugfs MST trigger. It was not part of normal operation, so I will report it separately if needed rather than using it as a workaround or conflating it with this issue. # Attachments 1. The Apport report generated with `ubuntu-bug linux`. 2. Full kernel journals for: the runtime-disconnect boot, the docked boot showing DP-resource/MST-ordering messages, the failed hot-plug path, and the successful alternate-port path. 3. `sudo boltctl list --verbose` (if Bolt is installed) and `lspci -nnk`. 4. Do not use the AMDGPU debugfs MST HPD trigger; it caused a separate diagnostic-only oops in this environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161425/+subscriptions

[Bug 2161423] [NEW] Kernel Regression Report: Internal Display Brightness No Longer Works on HP Envy x360 15-bp1xx (Kernel 7.0.0-28)

Public bug reported: A regression has been introduced in Linux kernel **7.0.0-28-generic** that prevents adjustment of the internal display brightness on an HP Envy x360 15-bp1xx laptop. The issue appeared immediately after updating from kernel **7.0.0-27-generic** to **7.0.0-28-generic**. Under kernel **7.0.0-28**, the GNOME brightness slider functions normally and the kernel exposes the expected `intel_backlight` interface. The reported brightness value changes correctly when the slider is moved or when values are written manually to the sysfs backlight interface. However, the physical brightness of the internal LCD panel never changes. Booting the same system using **kernel 7.0.0-27-generic** restores normal brightness control without any other configuration changes. This strongly indicates a kernel regression introduced between versions 7.0.0-27 and 7.0.0-28. ## Hardware Laptop: * HP Envy x360 Convertible 15-bp1xx Graphics: * Intel UHD Graphics 620 (internal display controller) * NVIDIA GeForce MX150 (Optimus hybrid graphics) Graphics mode: * `prime-select on-demand` NVIDIA driver: * Version 580.159.03 ## Software Ubuntu release: * Ubuntu 26.04 LTS Working kernel: * 7.0.0-27-generic Broken kernel: * 7.0.0-28-generic Backlight device: ``` /sys/class/backlight/intel_backlight ``` Maximum brightness: ``` 1023 ``` Example brightness value: ``` 638 ``` Kernel command line: ``` BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=<UUID> ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ``` No custom backlight-related kernel parameters are present. ## Steps to Reproduce 1. Boot Ubuntu using Linux kernel 7.0.0-28-generic. 2. Open GNOME Settings → Display or use the brightness hotkeys. 3. Move the brightness slider across its full range. Alternatively: ``` echo <value> | sudo tee /sys/class/backlight/intel_backlight/brightness ``` using different values. ## Expected Result The brightness of the internal LCD panel should change according to the requested brightness value. ## Actual Result * The GNOME brightness slider moves normally. * The value in `/sys/class/backlight/intel_backlight/brightness` changes correctly. * Writes to the sysfs backlight interface succeed. * No errors are reported. * The physical brightness of the display remains unchanged. ## Regression Confirmation The issue disappears completely after booting kernel **7.0.0-27-generic**. No hardware changes, firmware changes, BIOS changes, or driver changes are required. The only difference is the kernel version. ## Additional Information * The laptop dual-boots Windows. * Brightness adjustment functions normally under Windows. * `intel_backlight` is detected correctly. * NVIDIA reports the internal display is not directly attached (`Disp.A Off`), consistent with Intel driving the internal panel in Optimus mode. * The issue therefore appears to affect the Intel backlight control path rather than the NVIDIA driver. ## Regression Assessment This appears to be a regression introduced between Linux kernels: * 7.0.0-27-generic (working) * 7.0.0-28-generic (broken) Potential areas worth investigating include: * Intel i915 display/backlight changes * ACPI backlight handling * HP firmware quirks * eDP panel backlight programming The regression is fully reproducible and disappears when reverting to the previous kernel. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: robin 5539 F.... wireplumber /dev/snd/seq: robin 5525 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jul 21 13:16:47 2026 InstallationDate: Installed on 2026-07-19 (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 04f3:0235 Elan Microelectronics Corp. Optical Mouse Bus 001 Device 003: ID 0bda:58e6 Realtek Semiconductor Corp. HP Wide Vision FHD Camera Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: HP HP ENVY x360 Convertible 15-bp1xx 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=/boot/vmlinuz-7.0.0-28-generic root=UUID=8030bc2b-215f-43df-87c0-d9c8fe75e7c5 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: 07/24/2017 dmi.bios.release: 15.22 dmi.bios.vendor: Insyde dmi.bios.version: F.22 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 83C9 dmi.board.vendor: HP dmi.board.version: 32.60 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 32.60 dmi.modalias: dmi:bvnInsyde:bvrF.22:bd07/24/2017:br15.22:efr32.60:svnHP:pnHPENVYx360Convertible15-bp1xx:pvrType1ProductConfigId:rvnHP:rn83C9:rvr32.60:cvnHP:ct10:cvrChassisVersion:sku1ZA17AV:pfa103C_5335KVHPEnvy: dmi.product.family: 103C_5335KV HP Envy dmi.product.name: HP ENVY x360 Convertible 15-bp1xx dmi.product.sku: 1ZA17AV dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP ** 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/2161423 Title: Kernel Regression Report: Internal Display Brightness No Longer Works on HP Envy x360 15-bp1xx (Kernel 7.0.0-28) Status in linux package in Ubuntu: New Bug description: A regression has been introduced in Linux kernel **7.0.0-28-generic** that prevents adjustment of the internal display brightness on an HP Envy x360 15-bp1xx laptop. The issue appeared immediately after updating from kernel **7.0.0-27-generic** to **7.0.0-28-generic**. Under kernel **7.0.0-28**, the GNOME brightness slider functions normally and the kernel exposes the expected `intel_backlight` interface. The reported brightness value changes correctly when the slider is moved or when values are written manually to the sysfs backlight interface. However, the physical brightness of the internal LCD panel never changes. Booting the same system using **kernel 7.0.0-27-generic** restores normal brightness control without any other configuration changes. This strongly indicates a kernel regression introduced between versions 7.0.0-27 and 7.0.0-28. ## Hardware Laptop: * HP Envy x360 Convertible 15-bp1xx Graphics: * Intel UHD Graphics 620 (internal display controller) * NVIDIA GeForce MX150 (Optimus hybrid graphics) Graphics mode: * `prime-select on-demand` NVIDIA driver: * Version 580.159.03 ## Software Ubuntu release: * Ubuntu 26.04 LTS Working kernel: * 7.0.0-27-generic Broken kernel: * 7.0.0-28-generic Backlight device: ``` /sys/class/backlight/intel_backlight ``` Maximum brightness: ``` 1023 ``` Example brightness value: ``` 638 ``` Kernel command line: ``` BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=<UUID> ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ``` No custom backlight-related kernel parameters are present. ## Steps to Reproduce 1. Boot Ubuntu using Linux kernel 7.0.0-28-generic. 2. Open GNOME Settings → Display or use the brightness hotkeys. 3. Move the brightness slider across its full range. Alternatively: ``` echo <value> | sudo tee /sys/class/backlight/intel_backlight/brightness ``` using different values. ## Expected Result The brightness of the internal LCD panel should change according to the requested brightness value. ## Actual Result * The GNOME brightness slider moves normally. * The value in `/sys/class/backlight/intel_backlight/brightness` changes correctly. * Writes to the sysfs backlight interface succeed. * No errors are reported. * The physical brightness of the display remains unchanged. ## Regression Confirmation The issue disappears completely after booting kernel **7.0.0-27-generic**. No hardware changes, firmware changes, BIOS changes, or driver changes are required. The only difference is the kernel version. ## Additional Information * The laptop dual-boots Windows. * Brightness adjustment functions normally under Windows. * `intel_backlight` is detected correctly. * NVIDIA reports the internal display is not directly attached (`Disp.A Off`), consistent with Intel driving the internal panel in Optimus mode. * The issue therefore appears to affect the Intel backlight control path rather than the NVIDIA driver. ## Regression Assessment This appears to be a regression introduced between Linux kernels: * 7.0.0-27-generic (working) * 7.0.0-28-generic (broken) Potential areas worth investigating include: * Intel i915 display/backlight changes * ACPI backlight handling * HP firmware quirks * eDP panel backlight programming The regression is fully reproducible and disappears when reverting to the previous kernel. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: robin 5539 F.... wireplumber /dev/snd/seq: robin 5525 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jul 21 13:16:47 2026 InstallationDate: Installed on 2026-07-19 (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 04f3:0235 Elan Microelectronics Corp. Optical Mouse Bus 001 Device 003: ID 0bda:58e6 Realtek Semiconductor Corp. HP Wide Vision FHD Camera Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: HP HP ENVY x360 Convertible 15-bp1xx 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=/boot/vmlinuz-7.0.0-28-generic root=UUID=8030bc2b-215f-43df-87c0-d9c8fe75e7c5 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: 07/24/2017 dmi.bios.release: 15.22 dmi.bios.vendor: Insyde dmi.bios.version: F.22 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 83C9 dmi.board.vendor: HP dmi.board.version: 32.60 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 32.60 dmi.modalias: dmi:bvnInsyde:bvrF.22:bd07/24/2017:br15.22:efr32.60:svnHP:pnHPENVYx360Convertible15-bp1xx:pvrType1ProductConfigId:rvnHP:rn83C9:rvr32.60:cvnHP:ct10:cvrChassisVersion:sku1ZA17AV:pfa103C_5335KVHPEnvy: dmi.product.family: 103C_5335KV HP Envy dmi.product.name: HP ENVY x360 Convertible 15-bp1xx dmi.product.sku: 1ZA17AV dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161423/+subscriptions

[Bug 2161405] Re: kernel update 7.0.0.-28 stops oracle virtualbox from opening

Probably bug 2160033 What is the output of: apt-cache policy virtualbox-dkms sudo dkms ** Package changed: linux (Ubuntu) => virtualbox (Ubuntu) ** Changed in: virtualbox (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161405 Title: kernel update 7.0.0.-28 stops oracle virtualbox from opening Status in virtualbox package in Ubuntu: Incomplete Bug description: After updating to kernel 7.0.0-28 oracle virtualbox fails to start with the error: Kernel driver not installed (rc=-1908) The VirtualBox Linux kernel driver is either not loaded or not set up correctly. Please try setting it up again by executing '/sbin/vboxconfig' as root. If your system has EFI Secure Boot enabled you may also need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system's documentation for more information. where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT. It seems running sudo /sbin/vboxconfig just loops and returns the same error. A reinstall completely ruins it.... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/2161405/+subscriptions

[Bug 2159015] Re: HWE kernel 6.17: kauditd bypasses systemd-journald and floods virtual console with AppArmor denial records from snap-confined services, rendering virtual console unusable

Hi Michael, System access is not available, once I have the system available and post that will be able to work on this. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159015 Title: HWE kernel 6.17: kauditd bypasses systemd-journald and floods virtual console with AppArmor denial records from snap-confined services, rendering virtual console unusable Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Bug description: On Ubuntu 24.04.4 LTS with HWE kernel 6.17.0-35-generic, the kernel audit daemon (kauditd) bypasses systemd-journald and writes AppArmor denial records directly to the virtual console. This floods the console and makes it completely unusable. Steps to Reproduce: 1. Install Ubuntu 24.04.4 HWE on 17G platform with Nextcloud and Rocketchat-server snap packages installed. 2. Reboot the system. 3. Open the virtual console. Actual Result: Virtual console is flooded with continuous AppArmor denial messages from snap.rocketchat-server.rocketchat-mongo and snap.nextcloud.nextcloud-fixer. Login is not possible. Expected Result: Virtual console should be accessible and usable after reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159015/+subscriptions

[Bug 2160619] Re: USB-C/USB4 dock path instability: port-dependent USB error -71, Thunderbolt disconnects, and AMDGPU DP MST failures

## Update: undocked-boot and USB-C port control tests on 7.0.0-28 I performed a controlled reboot on 2026-07-21 with the dock disconnected. I waited until the graphical desktop was running before connecting the same dock, cable, two DisplayPort monitors, and peripherals. The undocked boot did not produce the previously observed boot-time messages: - `failed to allocate DP resource for port 7` - `DMUB notification skipped due to no handler` - `DM_MST: Differing MST start` However, the post-login result depended on which laptop USB-C port was used. ### Laptop USB-C port 1 → dock rear/upstream port: failed At 09:35:56, the connection failed during the initial USB setup, before the dock, Thunderbolt topology, or displays could enumerate: ```text usb 8-1: new high-speed USB device number 2 using xhci_hcd usb 8-1: Device not responding to setup address. usb 8-1: Device not responding to setup address. usb 8-1: device not accepting address 2, error -71 No subsequent Thunderbolt, USB4, or DP MST topology appeared. Disconnecting the cable produced no device-removal event, consistent with the device never completing enumeration. ### Laptop USB-C port 2 → dock front USB-C port: no upstream event This produced no USB, USB4, Thunderbolt, or DRM hot-plug event. All external DP connectors remained disconnected. This is consistent with the dock’s front USB-C port being downstream/peripheral-facing rather than its host/upstream port. ### Laptop USB-C port 2 → dock rear/upstream port: succeeded Using the same dock, cable, displays, peripherals, running kernel, and desktop session, the dock enumerated through the second laptop USB-C port: [drm] DM_MST: starting TM [drm] DM_MST: DP14, 2-lane link detected usb 7-1: new SuperSpeed Plus Gen 2x1 USB device number 2 usb 7-1: New USB device found, idVendor=8087, idProduct=0b40 usb 7-1: Product: USB3.0 Hub The dock MCU, USB 2/3 hubs, Realtek Ethernet, dock audio, and attached Logitech C270 webcam all enumerated. Ethernet obtained carrier. Display topology discovery logged one error: amdgpu 0000:33:00.0: [drm] *ERROR* Sending link address failed with -5 The driver recovered without disconnecting the dock: [drm] Synaptics Cascaded MST hub [drm] Synaptics Cascaded MST hub [drm] MST_DSC Send DSC enable to synaptics [drm] MST_DSC Send DSC enable to synaptics Both external screens then turned on. The final DRM connector state showed DP-9 and DP-10 connected. This successful attempt did not produce: - USB error -71 - dcn31_program_compbuf_size warning - update_dpia_stream_allocation_table warning - GNOME/Mutter atomic-commit failure - complete dock disconnect/reconnect ## Interpretation These results do not support a purely boot-ordering or purely AMDGPU explanation. Booting undocked avoids the previously observed boot-time DP- resource/MST-ordering messages, but a normal post-login connection can still fail at the earliest USB setup stage on one laptop USB-C path. At that point, Thunderbolt and AMDGPU have not yet discovered the dock. The same equipment works minutes later through the second laptop USB-C port, although that successful path still produces a transient recoverable AMDGPU MST link-address error. The normal-use failure therefore appears port/path-sensitive and may involve the platform USB/XHCI/USB4 path, firmware, signal integrity, or hardware. The available evidence does not yet identify which component is responsible. Separately, the trigger_hpd_mst_set kernel oops remains a definite AMDGPU kernel-driver defect. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160619 Title: USB-C/USB4 dock path instability: port-dependent USB error -71, Thunderbolt disconnects, and AMDGPU DP MST failures Status in linux package in Ubuntu: New Bug description: On a Lenovo laptop with AMD Rembrandt / Radeon 680M, external monitors connected through a Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock often stay dark when the system is booted while already docked. Kernel logs show repeated USB enumeration failures on the dock path, Thunderbolt dock connect/disconnect, amdgpu DP AUX/DPCD/MST link failures, and a warning in dcn31_program_compbuf_size. A manual MST reprobe via /sys/kernel/debug/dri/0000:33:00.0/amdgpu_dm_trigger_hpd_mst caused a reproducible amdgpu kernel oops in trigger_hpd_mst_set.  ## Reproduction steps  1. Connect the laptop to a Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock with two external DP monitors attached.  2. Boot the machine while already docked.  3. Observe that the external monitors sometimes remain dark.  4. Check kernel logs for repeated usb 8-1 enumeration failures, Thunderbolt disconnects, and amdgpu MST / AUX / DPCD errors. Additional diagnostic reproduction:  5. When the docked displays are in a working MST state, write "1" to /sys/kernel/debug/dri/0000:33:00.0/amdgpu_dm_trigger_hpd_mst.  6. Observe a kernel oops in trigger_hpd_mst_set [amdgpu].  ## Expected result The dock should enumerate cleanly during boot, both external monitors should come up reliably, and an MST hotplug reprobe should not crash the kernel.  ## Actual result During docked boot, the dock path repeatedly fails USB enumeration, Thunderbolt disconnects after appearing, amdgpu DP MST link setup fails, and the external monitors may remain dark. A manual MST reprobe can trigger a kernel oops in amdgpu.  ## High-signal details to include  - Kernel: `7.0.0-27-generic`  - GPU: `AMD Rembrandt / Radeon 680M`  - BIOS: `R22ET81W (1.51)`, `2026-04-10`  - Dock: `Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock`  - No dock firmware update was offered by `fwupdmgr`  - No system firmware or EC update was pending  ## Key log lines to mention  These are the most important patterns:   amdgpu ... [drm] DPIA AUX failed on 0x2c0(1), error 7  thunderbolt 0-2: device disconnected  amdgpu ... [drm] *ERROR* dpcd_set_link_settings ...  amdgpu ... [drm] *ERROR* Sending link address failed with -5  WARNING: ... dcn31_program_compbuf_size  [drm:trigger_hpd_mst_set [amdgpu]] *ERROR* DM_MST: Failed to detect dc link!  BUG: unable to handle page fault ...  RIP: trigger_hpd_mst_set+0x13b/0x1b0 [amdgpu]  ## Note The `trigger_hpd_mst_set` reprobe was used only as a diagnostic step. It should not be treated as a safe workaround, because it caused a kernel oops on this system.  usb 8-1: Device not responding to setup address  usb 8-1: device not accepting address ..., error -71  thunderbolt 0-2: Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock 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: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jul 14 14:58:10 2026 InstallationDate: Installed on 2025-03-12 (489 days ago) InstallationMedia: Ubuntu 24.04.2 LTS "Noble Numbat" - Release amd64 (20250215) MachineType: LENOVO 21CRS08P00 ProcEnviron:  LANG=en_US.UTF-8  PATH=(custom, no user)  SHELL=/bin/bash  TERM=xterm  XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb 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: Upgraded to resolute on 2026-05-08 (67 days ago) dmi.bios.date: 04/10/2026 dmi.bios.release: 1.51 dmi.bios.vendor: LENOVO dmi.bios.version: R22ET81W (1.51 ) dmi.board.asset.tag: Not Available dmi.board.name: 21CRS08P00 dmi.board.vendor: LENOVO dmi.board.version: SDK0K17763 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.33 dmi.modalias: dmi:bvnLENOVO:bvrR22ET81W(1.51):bd04/10/2026:br1.51:efr1.33:svnLENOVO:pn21CRS08P00:pvrThinkPadT14sGen3:rvnLENOVO:rn21CRS08P00:rvrSDK0K17763WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21CR_BU_Think_FM_ThinkPadT14sGen3:pfaThinkPadT14sGen3: dmi.product.family: ThinkPad T14s Gen 3 dmi.product.name: 21CRS08P00 dmi.product.sku: LENOVO_MT_21CR_BU_Think_FM_ThinkPad T14s Gen 3 dmi.product.version: ThinkPad T14s Gen 3 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160619/+subscriptions

[Bug 2161223] DpkgList.txt

apport information ** Attachment added: "DpkgList.txt" https://bugs.launchpad.net/bugs/2161223/+attachment/5984645/+files/DpkgList.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161223 Title: Touchpad (ELAN0718) not working on HP Pavilion Gaming Laptop 15 with kernel 7.0.0 (Ubuntu 26.04) Status in linux package in Ubuntu: Incomplete Bug description: HP Pavilion Gaming Laptop 15 (Ryzen 5 4600H, AMD Raven/Picasso platform) Touchpad ACPI ID: ELAN0718 (I2C HID device), also enumerated as legacy PS/2 (ETPS/2 Elantech) via psmouse psmouse/elantech driver loads without errors and creates input device, but produces zero events (confirmed via evtest and raw /dev/input/eventX read) ACPI device ELAN0718:01 exists on i2c bus (i2c-ELAN0718:01) but has no driver bound, i2c_hid_acpi shows 0 usage No physical I2C controller PCI device found matching this bus (only i2c_piix4 SMBus for RAM SPD) Touchpad works fine under Windows on same hardware Tested: i8042 params, psmouse.elantech_smbus=0, manual driver bind attempts — none resolved it Kernel: 7.0.0-28-generic, Ubuntu 26.04 "resolute" --- ProblemType: Bug ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: n7 2083 F.... wireplumber /dev/snd/controlC0: n7 2083 F.... wireplumber /dev/snd/seq: n7 2061 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 26.04 InstallationDate: Installed on 2026-07-18 (2 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP HP Pavilion Gaming Laptop 15-ec0xxx NonfreeKernelModules: nvidia_modeset nvidia 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 amdgpudrmfb 1 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=2c0e3d76-a9b9-4ca3-a4bb-edc2abae6c60 ro quiet splash i8042.reset i8042.nomux i8042.nopnp ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Tags: resolute wayland-session Uname: Linux 7.0.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sudo users _MarkForUpload: True dmi.bios.date: 03/03/2022 dmi.bios.release: 15.13 dmi.bios.vendor: AMI dmi.bios.version: F.13 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 86D5 dmi.board.vendor: HP dmi.board.version: 96.45 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 96.45 dmi.modalias: dmi:bvnAMI:bvrF.13:bd03/03/2022:br15.13:efr96.45:svnHP:pnHPPavilionGamingLaptop15-ec0xxx:pvr:rvnHP:rn86D5:rvr96.45:cvnHP:ct10:cvrChassisVersion:sku8UD79EA#AB8:pfa103C_5335KVHPPavilion: dmi.product.family: 103C_5335KV HP Pavilion dmi.product.name: HP Pavilion Gaming Laptop 15-ec0xxx dmi.product.sku: 8UD79EA#AB8 dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161223/+subscriptions

[Bug 2160752] Re: uvcvideo: unkillable deadlock in status-event/PM path wedges USB stack (RealSense D405)

** Changed in: linux (Ubuntu Resolute) Status: Triaged => In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160752 Title: uvcvideo: unkillable deadlock in status-event/PM path wedges USB stack (RealSense D405) Status in linux package in Ubuntu: New Status in linux source package in Resolute: In Progress Bug description: # uvcvideo: unkillable deadlock in status-event / PM path (kernel 7.0) Draft for: Launchpad (`ubuntu-bug linux`, tag `regression-update`) and linux-media@vger.kernel.org (CC uvcvideo maintainer + granular-PM series author). Status: draft, 2026-07-15. Traces: `uvcvideo-deadlock-traces.txt` (same directory). ## Summary Control access to an Intel RealSense D405 (USB 8086:0b5b) reliably wedges the whole USB host stack on Ubuntu kernel 7.0.0-27-generic (also present, by code inspection, in upstream v7.0.6 and current mainline). The triggering process enters uninterruptible sleep (unkillable, survives SIGKILL), and the device's USB disconnect path then deadlocks the hub workqueue (`usb_hub_wq` in D state), after which no device on that hub can enumerate. Only a reboot recovers. ## Root cause (source analysis, drivers/media/usb/uvc) `uvc_ctrl_set_handle()` takes a PM reference (`uvc_pm_get`) for a pending async control, released by `uvc_ctrl_clear_handle()` -> `uvc_pm_put()` when the control-change status event arrives. That release runs inside `uvc_ctrl_status_event()`, which is invoked from two contexts where dropping the LAST status user deadlocks: 1. From the async worker `uvc_ctrl_status_event_work()`: `uvc_pm_put` -> `uvc_status_put` (takes `status_lock`) -> `uvc_status_stop` -> `cancel_work_sync(&dev->async_ctrl.work)` — cancelling the work item it is currently executing in. Waits for itself forever, holding `status_lock`. 2. From `uvc_status_stop()` itself (the synchronous flush, `if (cancel_work_sync(&w->work)) uvc_ctrl_status_event(...)`): the same put chain then re-acquires `status_lock`, which the caller (`uvc_status_put`/`uvc_status_suspend`) already holds. Self-deadlock on a non-recursive mutex. Every subsequent open/ioctl blocks in `uvc_status_get()` on `status_lock` (observed hung tasks), and `uvc_status_unregister()` -> `uvc_status_suspend()` blocks the USB disconnect path, freezing the hub workqueue. ## Observed impact (hardware reproduction) - Machine: omen rig, Ubuntu resolute, kernel 7.0.0-27-generic, 2x Intel RealSense D405 + 1x D435 on the same bus. - One D405 unit hits the race nearly every time on XU control access (its firmware emits the status event at the fatal moment); the other unit survives identical commands. Reproduced via librealsense enumeration AND via minimal raw UVCIOC_CTRL_QUERY ioctls; also right after a clean boot. - Hung-task stacks captured in `uvcvideo-deadlock-traces.txt` show both sides: `uvc_v4l2_unlocked_ioctl -> uvc_status_get` blocked, and `Workqueue: events uvc_ctrl_status_event_work -> uvc_ctrl_status_event -> uvc_pm_put -> uvc_status_put -> uvc_status_stop` blocked. - No uvcvideo changes between Ubuntu 7.0.0-14 and -27 (changelog); not an Ubuntu-local regression. `uvc_status.c` identical in mainline as of 2026-07-15; no fix or report found on linux-media/patchwork. ## Suggested direction for a fix Dropping the pending-async-control PM reference must not synchronously stop the status URB from the event-delivery contexts. Options: defer the final `uvc_status_stop()` to a separate work item when called from the async worker (`current_work() == &dev->async_ctrl.work`), or drop the reference outside `status_lock` / outside the worker. The synchronous-flush path (2) additionally must not re-enter `uvc_status_put` under `status_lock`. ## Verification (2026-07-15, same machine) - Firmware dependence of the trigger: on camera FW 5.15.1.55 one D405 unit wedged nearly every XU control access and the other rarely; after updating both cameras to FW 5.17.3.10 the deadlock became DETERMINISTIC on both units (first control-change sequence wedges both cameras, reproduced immediately after a clean boot). Newer firmware appears to deliver the async control-change status event more reliably, hitting the race window every time. - Workaround validation: with the patched module (status endpoint never armed, see below), the identical control sequences complete with zero hangs across repeated apply/hammer cycles on both FW versions' event behavior. Side effect observed: async controls (AE/exposure) remain "pending" forever (GET returns EBUSY) since the confirmation event never arrives — consistent with uvc_ctrl_set_handle never being cleared, and benign for operation (SETs land; streaming unaffected). ## Local mitigation deployed on this machine Out-of-tree build of uvcvideo 7.0.0-27 with a `disable_status` module parameter that skips `uvc_status_init()` URB arming entirely (no status events -> no worker -> no deadlock; costs async control-change notifications and camera-button events). Installed under `/lib/modules/7.0.0-27-generic/updates/`, enabled via `/etc/modprobe.d/uvcvideo-rig.conf`. 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/controlC2: robocurve 5721 F.... wireplumber /dev/snd/controlC0: robocurve 5721 F.... wireplumber /dev/snd/controlC1: robocurve 5721 F.... wireplumber /dev/snd/seq: robocurve 5703 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Thu Jul 16 00:03:18 2026 InstallationDate: Installed on 2026-06-29 (16 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP OMEN by HP 45L Gaming Desktop GT22-3xxx ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=tmux-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=1639853a-6154-4c17-954d-08761337d8ae 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: 11/13/2025 dmi.bios.release: 15.32 dmi.bios.vendor: AMI dmi.bios.version: F.20 dmi.board.name: 8D2C dmi.board.vendor: HP dmi.board.version: 00 dmi.chassis.type: 3 dmi.chassis.vendor: HP dmi.ec.firmware.release: 36.15 dmi.modalias: dmi:bvnAMI:bvrF.20:bd11/13/2025:br15.32:efr36.15:svnHP:pnOMENbyHP45LGamingDesktopGT22-3xxx:pvr:rvnHP:rn8D2C:rvr00:cvnHP:ct3:cvr:skuB91WJAA#ABA:pfa103C_5331M5HPOMEN: dmi.product.family: 103C_5331M5 HP OMEN dmi.product.name: OMEN by HP 45L Gaming Desktop GT22-3xxx dmi.product.sku: B91WJAA#ABA dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160752/+subscriptions

[Bug 2161093] Re: Black screen after boot with kernel 7.0.0-28-generic on AMD Radeon RX 580

I would like to add some background information that may or may not be related to this issue. Since my very first Linux installation (about six months ago), I have always needed to boot with the kernel parameter: amdgpu.dc=0 Even before installing Linux, the installer would only start in Safe Graphics mode. Without amdgpu.dc=0, I can see the KDE neon splash screen during boot. Immediately after the splash screen disappears, the screen turns completely black, and the graphical desktop never appears. Because of this, I have been using the amdgpu.dc=0 kernel parameter ever since I started using Linux. I don't know whether this is related to the current kernel issue, but I thought this background information might be useful. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161093 Title: Black screen after boot with kernel 7.0.0-28-generic on AMD Radeon RX 580 Status in linux package in Ubuntu: New Bug description: After installing the latest system updates on KDE neon, my system no longer boots into the graphical desktop when using kernel 7.0.0-28-generic. Hardware: - CPU: AMD Ryzen 5 1600 - GPU: AMD Radeon RX 580 8 GB (Polaris) Symptoms: - GRUB loads normally. - The boot logo is displayed. - After that the screen becomes completely black. - Ctrl+Alt+F1...F6 do not switch to a TTY. - Ctrl+Alt+Del reboots the computer. Booting the previous kernel (6.17.0-40-generic) on the same installation works normally. The issue started immediately after installing system updates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161093/+subscriptions

[Bug 2161312] [NEW] System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works fine on 7.0.0-27

Public bug reported: Hello Here is a bug occurring on my laptop. The analysis is from claude code. I hope it is relevant & complete. Thanks for your help. Summary System hangs permanently when entering suspend (s2idle) on kernel 7.0.0-28-generic; requires a hard power-off to recover. The exact same hardware suspended and resumed reliably dozens of times over 8 days on kernel 7.0.0-27-generic. The regression appeared immediately after the machine booted 7.0.0-28 for the first time — first suspend attempt on the new kernel already failed, and it failed again on the next boot. Hardware Machine: Dell Inspiron 14 5425 CPU: AMD Ryzen 7 5825U with Radeon Graphics GPU: AMD/ATI Barcelo iGPU (integrated, PCI 04:00.0) BIOS: 1.19.0 (2024-09-10) Sleep mode: only s2idle is offered by the platform (/sys/power/mem_sleep → [s2idle], no deep/S3 option available) Software Ubuntu 25.10 (Questing Quokka), KDE Plasma 6.5, Wayland session (kwin_wayland) Working kernel: linux-image-7.0.0-27-generic (7.0.0-27.27) Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28) Steps to reproduce Boot into 7.0.0-28-generic. Trigger suspend (via systemd Suspend action / closing lid / GUI power menu). System freezes during or immediately after suspend entry: keyboard backlight stays lit, no reaction to any key or the power button short-press, screen never turns back on. Only recovery is holding the power button for a hard shutdown. Expected behavior System suspends and resumes normally, as it did consistently on 7.0.0-27-generic. Actual behavior System never comes back from suspend. journalctl shows the boot ending abruptly right after suspend entry, with no PM: suspend exit line and no orderly shutdown sequence — consistent with a full system hang, not a clean poweroff. Evidence from journalctl Working kernel (7.0.0-27), representative sample out of ~40 successful cycles between 2026-07-09 and 2026-07-17: juil. 16 19:31:46 kernel: PM: suspend entry (s2idle) juil. 17 14:48:21 kernel: PM: suspend exit Failing kernel (7.0.0-28), first attempt, boot ends here with no further log lines at all: juil. 20 10:42:38 root[18433]: Dell wakeup sources disabled - ALL including dock disconnect juil. 20 10:42:38 systemd-sleep[18388]: Performing sleep operation 'suspend'... juil. 20 10:42:38 kernel: PM: suspend entry (s2idle) [-- nothing further; next boot is a cold boot, not a resume --] Failing kernel (7.0.0-28), second attempt on a fresh boot, same pattern: juil. 20 12:32:59 systemd-sleep[26074]: Performing sleep operation 'suspend'... juil. 20 12:32:59 kernel: PM: suspend entry (s2idle) [-- nothing further --] Both failing boots are followed by a fresh cold boot (new boot ID in journalctl --list-boots), confirming the machine was hard power-cycled rather than resuming. Workaround Pinning the system to linux-image-7.0.0-27-generic (apt-mark hold) restores reliable suspend/resume. Additional notes A local dell-suspend-fix.service (disables PCI/USB/BT/WMI wakeup sources before sleep, standard workaround for this laptop's dock/eSATA wake-on-disconnect quirk) is present and unchanged across both the working and failing kernel — ruling it out as the cause. Not the known 7.0.0-28.28 AMDGPU/HMM ROCm performance regression (that one is a slowdown in compute workloads, not a hang) — this appears to be a separate, undocumented issue in the same kernel build. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Mon Jul 20 14:19:25 2026 InstallationDate: Installed on 2025-07-09 (376 days ago) InstallationMedia: Kubuntu 25.04 "Plucky Puffin" - Release amd64 (20250417) IwDevWlp3s0Link: Not connected. MachineType: Dell Inc. Inspiron 14 5425 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=b239c123-a9a4-4924-bfc7-38c39f92e79b ro quiet splash acpi_backlight=native resume=UUID=871f8b5f-e842-4660-9c64-7661287c3695 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-07-09 (11 days ago) dmi.bios.date: 09/10/2024 dmi.bios.release: 1.19 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.19.0 dmi.board.name: 0J9C2M dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.19.0 dmi.modalias: dmi:bvnDellInc.:bvr1.19.0:bd09/10/2024:br1.19:svnDellInc.:pnInspiron145425:pvr1.19.0:rvnDellInc.:rn0J9C2M:rvrA00:cvnDellInc.:ct10:cvr1.19.0:sku0B46:pfaInspiron: dmi.product.family: Inspiron dmi.product.name: Inspiron 14 5425 dmi.product.sku: 0B46 dmi.product.version: 1.19.0 dmi.sys.vendor: Dell Inc. ** 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/2161312 Title: System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works fine on 7.0.0-27 Status in linux package in Ubuntu: New Bug description: Hello Here is a bug occurring on my laptop. The analysis is from claude code. I hope it is relevant & complete. Thanks for your help. Summary System hangs permanently when entering suspend (s2idle) on kernel 7.0.0-28-generic; requires a hard power-off to recover. The exact same hardware suspended and resumed reliably dozens of times over 8 days on kernel 7.0.0-27-generic. The regression appeared immediately after the machine booted 7.0.0-28 for the first time — first suspend attempt on the new kernel already failed, and it failed again on the next boot. Hardware Machine: Dell Inspiron 14 5425 CPU: AMD Ryzen 7 5825U with Radeon Graphics GPU: AMD/ATI Barcelo iGPU (integrated, PCI 04:00.0) BIOS: 1.19.0 (2024-09-10) Sleep mode: only s2idle is offered by the platform (/sys/power/mem_sleep → [s2idle], no deep/S3 option available) Software Ubuntu 25.10 (Questing Quokka), KDE Plasma 6.5, Wayland session (kwin_wayland) Working kernel: linux-image-7.0.0-27-generic (7.0.0-27.27) Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28) Steps to reproduce Boot into 7.0.0-28-generic. Trigger suspend (via systemd Suspend action / closing lid / GUI power menu). System freezes during or immediately after suspend entry: keyboard backlight stays lit, no reaction to any key or the power button short-press, screen never turns back on. Only recovery is holding the power button for a hard shutdown. Expected behavior System suspends and resumes normally, as it did consistently on 7.0.0-27-generic. Actual behavior System never comes back from suspend. journalctl shows the boot ending abruptly right after suspend entry, with no PM: suspend exit line and no orderly shutdown sequence — consistent with a full system hang, not a clean poweroff. Evidence from journalctl Working kernel (7.0.0-27), representative sample out of ~40 successful cycles between 2026-07-09 and 2026-07-17: juil. 16 19:31:46 kernel: PM: suspend entry (s2idle) juil. 17 14:48:21 kernel: PM: suspend exit Failing kernel (7.0.0-28), first attempt, boot ends here with no further log lines at all: juil. 20 10:42:38 root[18433]: Dell wakeup sources disabled - ALL including dock disconnect juil. 20 10:42:38 systemd-sleep[18388]: Performing sleep operation 'suspend'... juil. 20 10:42:38 kernel: PM: suspend entry (s2idle) [-- nothing further; next boot is a cold boot, not a resume --] Failing kernel (7.0.0-28), second attempt on a fresh boot, same pattern: juil. 20 12:32:59 systemd-sleep[26074]: Performing sleep operation 'suspend'... juil. 20 12:32:59 kernel: PM: suspend entry (s2idle) [-- nothing further --] Both failing boots are followed by a fresh cold boot (new boot ID in journalctl --list-boots), confirming the machine was hard power-cycled rather than resuming. Workaround Pinning the system to linux-image-7.0.0-27-generic (apt-mark hold) restores reliable suspend/resume. Additional notes A local dell-suspend-fix.service (disables PCI/USB/BT/WMI wakeup sources before sleep, standard workaround for this laptop's dock/eSATA wake-on-disconnect quirk) is present and unchanged across both the working and failing kernel — ruling it out as the cause. Not the known 7.0.0-28.28 AMDGPU/HMM ROCm performance regression (that one is a slowdown in compute workloads, not a hang) — this appears to be a separate, undocumented issue in the same kernel build. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Mon Jul 20 14:19:25 2026 InstallationDate: Installed on 2025-07-09 (376 days ago) InstallationMedia: Kubuntu 25.04 "Plucky Puffin" - Release amd64 (20250417) IwDevWlp3s0Link: Not connected. MachineType: Dell Inc. Inspiron 14 5425 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=b239c123-a9a4-4924-bfc7-38c39f92e79b ro quiet splash acpi_backlight=native resume=UUID=871f8b5f-e842-4660-9c64-7661287c3695 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-07-09 (11 days ago) dmi.bios.date: 09/10/2024 dmi.bios.release: 1.19 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.19.0 dmi.board.name: 0J9C2M dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.19.0 dmi.modalias: dmi:bvnDellInc.:bvr1.19.0:bd09/10/2024:br1.19:svnDellInc.:pnInspiron145425:pvr1.19.0:rvnDellInc.:rn0J9C2M:rvrA00:cvnDellInc.:ct10:cvr1.19.0:sku0B46:pfaInspiron: dmi.product.family: Inspiron dmi.product.name: Inspiron 14 5425 dmi.product.sku: 0B46 dmi.product.version: 1.19.0 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161312/+subscriptions