[Bug 2163551] [NEW] Intel Raptor Lake xHCI stalls with stale USB devices; USB input and external display freeze, i8042 keyboard also stops responding

Public bug reported: System: Ubuntu desktop on ASUS laptop Kernel: 7.0.0-29-generic Summary: During normal desktop use, USB input stopped functioning. The external USB keyboard and USB wireless mouse both stopped responding, while the built-in I2C touchpad continued to work. At approximately 2026-08-14 19:27 EDT I captured the system while it was in the failed state. The affected USB devices were still enumerated by lsusb and registered as Linux input devices with usbhid bound: - Intel Raptor Lake USB 3.2 Gen 2x2 xHCI controller: 0000:00:14.0 - USB wireless mouse: usb-0000:00:14.0-6, /dev/input/event12 - USB keyboard: usb-0000:00:14.0-1.2.4, /dev/input/event6 Both event devices remained present but produced no input events. Testing the raw event devices with: sudo timeout 10s od -An -tx1 /dev/input/event12 sudo timeout 10s od -An -tx1 /dev/input/event6 produced no data while moving/clicking the mouse or pressing keyboard keys. I then physically unplugged USB devices, including an external USB optical drive and other peripherals. The disconnected devices continued to appear in lsusb. This suggests that the kernel USB topology had become stale and disconnect events were no longer being processed. A second external monitor also froze, continuing to display its last image. The external displays are connected through a USB/USB-C HDMI adapter/dock. The built-in touchpad continued working throughout. It is an I2C HID device and is not connected through xHCI. Recovery test: I unbound and rebound the Intel xHCI controller: echo -n '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind sleep 3 echo -n '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind After rebinding xhci_hcd: - the USB mouse immediately worked again - USB devices could be reconnected normally - the external USB keyboard worked again - the previously frozen second monitor began working again However, the laptop's built-in keyboard remained nonfunctional. The built-in keyboard is separately registered as: AT Raw Set 2 keyboard /sys/devices/platform/i8042/serio0/ driver: /sys/bus/serio/drivers/atkbd It also produced no usable keyboard input. Unbinding and rebinding atkbd: echo -n serio0 | sudo tee /sys/bus/serio/drivers/atkbd/unbind sleep 2 echo -n serio0 | sudo tee /sys/bus/serio/drivers/atkbd/bind did NOT restore the laptop keyboard. The I2C touchpad remained functional. A search of the kernel journal during the failure for: i8042|serio|atkbd|keyboard|xhci|usb|hid|irq|interrupt|ACPI|timeout|error produced no messages. Expected result: USB devices should continue processing input and disconnect events. The built-in keyboard should remain functional. External displays should not freeze. Actual result: The Intel xHCI/USB path stopped processing input/disconnect activity while devices remained enumerated. An external display froze simultaneously. Resetting xhci_hcd restored the USB devices and external display, but the separate i8042/atkbd laptop keyboard remained nonfunctional. Additional observation: I have previously experienced external-display corruption when monitors are connected through the same USB/USB-C HDMI adapter/dock. I do not yet know whether those incidents have the same root cause, but I am including this as a potentially relevant correlation. Reproducibility: Not yet intentionally reproduced. This occurred during normal use with multiple USB peripherals/hubs and external monitors attached. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-29-generic 7.0.0-29.29 ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12 Uname: Linux 7.0.0-29-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 19:43:44 2026 IwDevWlo1Link: Not connected. MachineType: ASUSTeK COMPUTER INC. ROG Strix G18 G814JVR_G814JVR ProcFB: 0 i915drmfb 1 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-29-generic root=ZFS=UbuntuZFS/root 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-06-05 (70 days ago) WifiSyslog: dmi.bios.date: 10/24/2024 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: G814JVR.320 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: G814JVR dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 0.49 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrG814JVR.320:bd10/24/2024:br5.27:efr0.49:svnASUSTeKCOMPUTERINC.:pnROGStrixG18G814JVR_G814JVR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG814JVR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaROGStrixG18: dmi.product.family: ROG Strix G18 dmi.product.name: ROG Strix G18 G814JVR_G814JVR dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session ** Attachment added: "full-journal.txt" https://bugs.launchpad.net/bugs/2163551/+attachment/5992266/+files/full-journal.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163551 Title: Intel Raptor Lake xHCI stalls with stale USB devices; USB input and external display freeze, i8042 keyboard also stops responding Status in linux package in Ubuntu: New Bug description: System: Ubuntu desktop on ASUS laptop Kernel: 7.0.0-29-generic Summary: During normal desktop use, USB input stopped functioning. The external USB keyboard and USB wireless mouse both stopped responding, while the built-in I2C touchpad continued to work. At approximately 2026-08-14 19:27 EDT I captured the system while it was in the failed state. The affected USB devices were still enumerated by lsusb and registered as Linux input devices with usbhid bound: - Intel Raptor Lake USB 3.2 Gen 2x2 xHCI controller: 0000:00:14.0 - USB wireless mouse: usb-0000:00:14.0-6, /dev/input/event12 - USB keyboard: usb-0000:00:14.0-1.2.4, /dev/input/event6 Both event devices remained present but produced no input events. Testing the raw event devices with: sudo timeout 10s od -An -tx1 /dev/input/event12 sudo timeout 10s od -An -tx1 /dev/input/event6 produced no data while moving/clicking the mouse or pressing keyboard keys. I then physically unplugged USB devices, including an external USB optical drive and other peripherals. The disconnected devices continued to appear in lsusb. This suggests that the kernel USB topology had become stale and disconnect events were no longer being processed. A second external monitor also froze, continuing to display its last image. The external displays are connected through a USB/USB-C HDMI adapter/dock. The built-in touchpad continued working throughout. It is an I2C HID device and is not connected through xHCI. Recovery test: I unbound and rebound the Intel xHCI controller: echo -n '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind sleep 3 echo -n '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind After rebinding xhci_hcd: - the USB mouse immediately worked again - USB devices could be reconnected normally - the external USB keyboard worked again - the previously frozen second monitor began working again However, the laptop's built-in keyboard remained nonfunctional. The built-in keyboard is separately registered as: AT Raw Set 2 keyboard /sys/devices/platform/i8042/serio0/ driver: /sys/bus/serio/drivers/atkbd It also produced no usable keyboard input. Unbinding and rebinding atkbd: echo -n serio0 | sudo tee /sys/bus/serio/drivers/atkbd/unbind sleep 2 echo -n serio0 | sudo tee /sys/bus/serio/drivers/atkbd/bind did NOT restore the laptop keyboard. The I2C touchpad remained functional. A search of the kernel journal during the failure for: i8042|serio|atkbd|keyboard|xhci|usb|hid|irq|interrupt|ACPI|timeout|error produced no messages. Expected result: USB devices should continue processing input and disconnect events. The built-in keyboard should remain functional. External displays should not freeze. Actual result: The Intel xHCI/USB path stopped processing input/disconnect activity while devices remained enumerated. An external display froze simultaneously. Resetting xhci_hcd restored the USB devices and external display, but the separate i8042/atkbd laptop keyboard remained nonfunctional. Additional observation: I have previously experienced external-display corruption when monitors are connected through the same USB/USB-C HDMI adapter/dock. I do not yet know whether those incidents have the same root cause, but I am including this as a potentially relevant correlation. Reproducibility: Not yet intentionally reproduced. This occurred during normal use with multiple USB peripherals/hubs and external monitors attached. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-29-generic 7.0.0-29.29 ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12 Uname: Linux 7.0.0-29-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 19:43:44 2026 IwDevWlo1Link: Not connected. MachineType: ASUSTeK COMPUTER INC. ROG Strix G18 G814JVR_G814JVR ProcFB: 0 i915drmfb 1 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-29-generic root=ZFS=UbuntuZFS/root 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-06-05 (70 days ago) WifiSyslog: dmi.bios.date: 10/24/2024 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: G814JVR.320 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: G814JVR dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 0.49 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrG814JVR.320:bd10/24/2024:br5.27:efr0.49:svnASUSTeKCOMPUTERINC.:pnROGStrixG18G814JVR_G814JVR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG814JVR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaROGStrixG18: dmi.product.family: ROG Strix G18 dmi.product.name: ROG Strix G18 G814JVR_G814JVR dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163551/+subscriptions

[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-gcp-6.8/6.8.0-1067.75~22.04.1)

All autopkgtests for the newly accepted linux-restricted-modules-gcp-6.8 (6.8.0-1067.75~22.04.1) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-470-server/470.256.02-0ubuntu0.22.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules-gcp-6.8 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions

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

Hello Tyler, or anyone else affected, Accepted audit into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/audit/1:3.1.2-2.1ubuntu0.1 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- noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-noble. 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. ** Changed in: audit (Ubuntu Noble) Status: In Progress => Fix Committed ** Tags added: verification-needed-noble ** Changed in: audit (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed-jammy -- 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: Fix Released Status in linux package in Ubuntu: Invalid Status in audit source package in Jammy: Fix Committed Status in audit source package in Noble: Fix Committed Status in audit source package in Questing: Won't Fix Status in audit source package in Resolute: Fix Committed Status in audit source package in Stonking: Fix Released 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 AppArmor can't move their 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].  * Upstream `auditd` (audit-userspace) doesn't have anything to fix because it's AppArmor that's sending the events down the wrong channel [6].  * 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 [6] Upstream audit-userspace bug report: https://github.com/linux-audit/audit-userspace/issues/351 [ 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 2161635] Re: shutdown hang. power and fans remain on forever

same bug ( shutdown hang. power and fans remain on forever ) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161635 Title: shutdown hang. power and fans remain on forever Status in linux package in Ubuntu: Confirmed Bug description: Intermittent shutdown hang — fans and power remain on for several minutes after shutdown is initiated, requiring a forced power-off. Appears to correlate with upgrade from kernel `7.0.0-27-generic` to `7.0.0-28-generic`. ## System Information - **Laptop:** Lenovo IdeaPad L340-15API, Type 81LW - **CPU/APU:** AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (Picasso/Raven2, VBIOS 113-PICASSO-114) - **BIOS/UEFI:** ARCN37WW, dated 05/14/2021 — confirmed to be the latest version available from Lenovo for this model - **OS:** Kubuntu 26.04 LTS, KDE Plasma 6.6.5, Wayland session only (no X11) - **Kernel at time of both incidents:** `7.0.0-28-generic` - **Kernel previously in use for ~3 weeks with no incident:** `7.0.0-27-generic` ## Symptom A normal shutdown is initiated (via the desktop environment's shutdown menu). All applications and the session close normally, and the screen goes blank as expected. However, the laptop's fans and power/status continue running for an extended period afterward (~10 minutes observed) with no display output. The system does not respond to the power button being pressed briefly; holding it for ~10 seconds forces a full power-off. This has occurred at least five times, on separate dates, all while running kernel `7.0.0-28-generic`. It is intermittent and has not been reproduced on demand. ## Timeline / Possible Regression - Kernel upgraded from `7.0.0-27-generic` to `7.0.0-28-generic`: approximately 6 days before the first observed hang - No shutdown hang was observed at any point during the ~3 weeks of normal use on `7.0.0-27-generic` - All observed hangs occurred while running `7.0.0-28-generic` ## Log Evidence In all two incidents that was observed, the OS-level shutdown sequence completed fully and normally — `systemd-shutdown` reached its final logged steps (syncing filesystems, sending SIGTERM to remaining processes, journal stopping) in well under two seconds, with no hung services, timeouts, or errors within the shutdown sequence itself: ```markup systemd[1]: Reached target poweroff.target - System Power Off. systemd[1]: Shutting down. systemd-shutdown[1]: Syncing filesystems and block devices. systemd-shutdown[1]: Sending SIGTERM to remaining processes… systemd-journald[XXX]: Journal stopped ``` No further OS-level logging exists beyond this point in either incident, since journald stops at this stage by design. This indicates the hang occurs after the kernel/OS has finished its shutdown work and handed off control to firmware/hardware to actually power off — i.e., after the point where OS logging can capture anything further. **An anomaly present in both incidents' boot logs** (occurring at boot time, not at shutdown time, in each of the two affected boots): ```markup acpi PNP0C02:01: Could not reserve [io 0x0cf9] ``` Port `0xCF9` is the standard ACPI reset/power-off control register. The kernel reports being unable to reserve this I/O port at boot in both of the affected boots. It has not been confirmed whether this is causally related to the later shutdown hang, or a separate, possibly benign condition that happens to co-occur; it is the only anomaly of any kind found in either boot's logs relating to ACPI/power management. **Incident #2 additionally showed** a non-fatal timeout during the shutdown sequence: ```markup systemd[1]: user@1000.service: State 'stop-sigterm' timed out. Killing. systemd[1]: user@1000.service: Killing process 1410 (systemd) with signal SIGKILL. systemd[1]: user@1000.service: Killing process 1924 (obexd) with signal SIGKILL. systemd[1]: user@1000.service: Failed with result 'timeout'. ``` `obexd` is the Bluetooth OBEX object-exchange daemon. This timeout added a delay of several seconds to the shutdown sequence but did not by itself account for the full multi-minute hang, since the OS-level shutdown sequence still completed normally afterward (reaching `poweroff.target` as shown above). Checking a separate, unrelated boot (a normal desktop logout/login cycle, not a shutdown-hang incident) showed the same `user@1000.service`/`obexd` stop completing cleanly and quickly with no timeout, so this specific timeout was not confirmed to be a consistent, repeatable pattern. ## What Has Been Checked and Ruled out - USB and Ethernet Wake-on-LAN settings (`enp3s0`, and the USB interfaces associated with the wifi/Bluetooth combo chip, Qualcomm Atheros QCA9377) — checked directly via sysfs and already found to be `disabled` - A `powertop` report flagged several devices' wakeup settings as suboptimal for battery-life purposes — determined on inspection to be an unrelated battery-tuning recommendation, not connected to the shutdown hang - A manually-installed GRUB boot theme present on the system — confirmed to be cosmetic only (fonts and images, no scripts or kernel parameter changes) and unrelated - BIOS confirmed to already be at the latest version available from Lenovo for this model - Secure Boot was disabled during troubleshooting; no mechanism was identified connecting Secure Boot state to this issue, and no kernel modules or packages were found to have been blocked or held back as a result of it having previously been enabled - A BIOS setting called "Flip to Boot," reported elsewhere by other Lenovo IdeaPad owners as a fix for an outwardly identical symptom, was searched for in this laptop's BIOS but is not present as an available option on this model/BIOS revision - Kernel boot parameter `reboot=acpi` was tried as a mitigation (to prefer the ACPI-defined reset method) — this did **not** prevent recurrence; the hang occurred again with this parameter active, and the `0xCF9` reservation anomaly was still present in that boot's log, unchanged - Kernel boot parameter `amdgpu.gpu_recovery=1` was also in place during both incidents (added in response to a separate, unrelated `amdgpu` PSP firmware issue on this same machine) — did not appear to have any effect on this shutdown-hang issue either way ## Filesystem/data Safety Note In both observed incidents, disks were confirmed fully synced and filesystems unmounted (per the log excerpt above) before the hang began. Forcing a power-off via the power button at this stage has not resulted in any observed filesystem corruption or data loss. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161635/+subscriptions

[Bug 2163506] Re: Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) doesnt work after upgrading to Ubuntu 24.04

## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, ealthy, but no application (ffmpeg, v4l2-ctl rawstream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally undeUbuntu 22.04 on this same machine, before upgradin ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS (previously worked fine o) - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **identical failure on both**, confirmed with matched usbmon captures on each (see below). This rules ouegression between 6.8 and 6.14; the break happenedsomewhere between 22.04's kernel/driver stack and 24.04's. - Camera: Chicony Electronics Integrated Camera, U bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth format-negotiation failure, not the focus of thisreport) - Camera exposes 3 vendor Extension Units (XUs) r, which are typically used by the OEM Windowsdriver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386f - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f4 ## Possible IPU6 connection This machine also has an Intel IPU6 MIPI camera stack path available (`linux-modules-ipu6-generic-hwe-24.04` / `linux-modules-ipu6-6.14.0-37-generic` packages exring earlier troubleshooting the reporter installed and then removed/purged these IPU6 packages, without effect on the UVC camera's frame delivery either way (tested with them absent). It's possible the working 22.04 setup relr-init path (or an older `uvcvideo` with adevice-specific quirk/XU sequence) that isn't present in 24.04's stack — worth checking whether `linux-modules-ipu6-generic-hwe-24.04` (properly is the behavior, though it was not observed to helpin this case. Separately, and not the cause of the camera bug itself: removing the IPU6 packages had an unrelated destructive side effect — `linux-modules-extra-6.14.0-37-generic` (containinGPU/other drivers) was left uninstalled, breakingWiFi, touchpad, and display scaling specifically on 6.14 until reinstalled. That has been resolved and is mentioned only for completeness/context. ## Steps to reproduce v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap --stream-count=5 --stream-to=/tmp/ Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device,iption, but gets EOF with no decodable frame.Identical result on both 6.8.0-137-generic and 6.14.0-37-generic. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` whioth kernels. USB control-plane traffic (formatprobe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for theentire capture with no errors, on **both** kernel C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... Every isochronous packet descriptor completes withual_length=12 bytes** — exactly the size of a bareUVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across hundreds of isochronous packets captured on each kernel; no URcol errors anywhere in dmesg on either kernel. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163506 Title: Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) doesnt work after upgrading to Ubuntu 24.04 Status in linux package in Ubuntu: New Bug description: ## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, USB traffic looks nominally healthy, but no application (ffmpeg, v4l2-ctl raw stream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally before upgrading this machine from Ubuntu 22.04 to 24.04. ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **both affected** - Camera: Chicony Electronics Integrated Camera, USB ID 04f2:b6cb, bcdUVC 1.10, bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth — reproduces its own distinct format-negotiation failure, not the focus of this report) - Camera exposes 3 vendor Extension Units (XUs) in its VideoControl descriptor, which are typically used by the OEM Windows driver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386fb938} - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f43bc8} ## Steps to reproduce ``` v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV \ --stream-mmap --stream-count=5 --stream-to=/tmp/raw_test.yuv ``` Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device, receives format/stream description, but gets EOF with no decodable frame. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` while streaming was active. USB control-plane traffic (format probe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for the entire capture with no errors: ``` C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... ``` Every isochronous packet descriptor completes with status 0 (success) but **actual_length=12 bytes** — exactly the size of a bare UVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across ~475 isochronous packets captured; no URB errors, no babble, no protocol errors anywhere in dmesg. ## What's been ruled out - USB autosuspend (device was suspending; disabling via udev `power/control=on` fixed an earlier separate symptom — the browser's "camera not found" error disappeared once the device reliably stays powered — but did not fix frame delivery) - `uvcvideo quirks=128` (UVC_QUIRK_FIX_BANDWIDTH) — no effect - `power_line_frequency` control (known bug class on other Lenovo-integrated cameras, see kernel patch "media: uvcvideo: Fix power line control for Lenovo Integrated Camera" for Shine-Optics 3277:009e) — set explicitly via v4l2-ctl, no effect - Lenovo EC camera-power gate (`/sys/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:00/camera_power`) — toggled off/on, no effect, reads `1` (enabled) - No physical privacy shutter on this model; no dedicated Fn camera-toggle hotkey found - No pending firmware updates for "Integrated Camera" via fwupd/LVFS - Fresh `modprobe -r uvcvideo && modprobe uvcvideo` before each test to rule out stale driver state - GNOME camera privacy toggle off (not blocking), correct udev ACL for /dev/video0, no other process holding the device open, no `/etc/modprobe.d` blacklist affecting uvcvideo/i2c_hid/psmouse ## Working theory The three vendor Extension Units suggest the OEM Windows driver performs a proprietary init/wake sequence on the sensor via one of these XUs before it will actually output pixel data. `uvcvideo`'s generic UVC negotiation (probe/commit/altsetting) succeeds because that part of the protocol is standard, but without the correct XU command sequence the sensor silently stays in a "streaming but dark" state — it acknowledges the stream request and sends header-only payloads, but never activates actual pixel readout. Since this camera reportedly worked under this same laptop before upgrading Ubuntu 22.04 → 24.04, something changed (kernel version, uvcvideo driver behavior, or firmware quirk table) between the two setups; a bisect against the 22.04 kernel/driver version would help narrow this down further. ## Requested - Guidance on whether a uvcvideo quirk/XU-init patch is feasible for this device, similar to the existing "Fix power line control for Lenovo Integrated Camera" precedent - Any pointers to existing bug reports for Chicony 04f2:b6cb or Lenovo model 82NC camera issues ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-137-generic 6.8.0-137.137 ProcVersionSignature: Ubuntu 6.8.0-137.137-generic 6.8.12 Uname: Linux 6.8.0-137-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: raghu 3845 F.... pipewire raghu 3849 F.... wireplumber /dev/snd/seq: raghu 3845 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 20:28:25 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2023-05-23 (1179 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) MachineType: LENOVO 82NC ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_px4ncd@/vmlinuz-6.8.0-137-generic root=ZFS=rpool/ROOT/ubuntu_px4ncd ro quiet splash i8042.direct i8042.dumbkbd RelatedPackageVersions: linux-restricted-modules-6.8.0-137-generic N/A linux-backports-modules-6.8.0-137-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/21/2022 dmi.bios.release: 1.69 dmi.bios.vendor: LENOVO dmi.bios.version: FJCN69WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 Pro 14IHU5 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrFJCN69WW:bd03/21/2022:br1.69:efr1.31:svnLENOVO:pn82NC:pvrYogaSlim7Pro14IHU5:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrYogaSlim7Pro14IHU5:skuLENOVO_MT_82NC_BU_idea_FM_YogaSlim7Pro14IHU5: dmi.product.family: Yoga Slim 7 Pro 14IHU5 dmi.product.name: 82NC dmi.product.sku: LENOVO_MT_82NC_BU_idea_FM_Yoga Slim 7 Pro 14IHU5 dmi.product.version: Yoga Slim 7 Pro 14IHU5 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163506/+subscriptions

[Bug 2163509] [NEW] Lenovo Legion 5 Pro (83LT) – AMDGPU DMCUB error and NVIDIA SBIOS power-management errors on Ubuntu 26.04

Public bug reported: I am using a Lenovo Legion 5 Pro (83LT) with a Ryzen 7 8745HX, integrated AMD Radeon 610M, and NVIDIA GeForce RTX 5060 Laptop GPU. On a fresh Ubuntu 26.04 installation, the system consistently reports an AMDGPU DMCUB error during boot: amdgpu 0000:05:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data The AMDGPU firmware itself loads successfully: Loading DMUB firmware via PSP: version=0x05002E00 DMUB hardware initialized: version=0x05002E00 Using ACPI provided EDID for eDP-2 The system also reports NVIDIA SBIOS/platform power-management errors: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed [NV_ERR_INVALID_DATA] PlatformRequestHandler failed to get target temp from SBIOS PlatformRequestHandler failed to get platform power mode from SBIOS There is also an ACPI BIOS error: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.PB2], AE_NOT_FOUND and: ACPI Error: AE_NOT_FOUND, During name lookup/catalog The system is running: Ubuntu 26.04 (Resolute) Kernel: 7.0.0-29-generic GNOME Shell: 50.1 Wayland NVIDIA driver: 595.84 Mesa: 26.0.3 Both GPUs are detected correctly: NVIDIA GeForce RTX 5060 Laptop GPU Kernel driver: nvidia AMD Radeon 610M Kernel driver: amdgpu nvidia-smi works correctly and the NVIDIA GPU is available to GNOME Shell. The system is generally functional, but GNOME applications such as GNOME Control Center experience noticeable startup delays. gnome-control- center initially took approximately 7 seconds to start. After troubleshooting Bluetooth/OBEX, this decreased to approximately 2.6 seconds, but the underlying graphics/firmware errors remain. A full system health check showed: NVMe SMART: PASSED No failed systemd services RAM and storage resources are healthy NVIDIA GPU detected and operational AMDGPU loaded correctly Bluetooth controller operational NetworkManager operational I would like to determine whether the DMCUB error, ACPI BIOS error, and NVIDIA SBIOS power-management errors are caused by Lenovo firmware/BIOS compatibility with the current Ubuntu kernel and drivers, and whether a BIOS/firmware or kernel/driver fix is required. I can provide the complete system diagnostic report if required. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-29-generic 7.0.0-29.29 ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12 Uname: Linux 7.0.0-29-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: pranav 4706 F.... wireplumber /dev/snd/controlC0: pranav 4706 F.... wireplumber /dev/snd/seq: pranav 4688 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 21:08:25 2026 InstallationDate: Installed on 2026-07-27 (18 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 83LT ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-29-generic root=UUID=a028c422-b500-4883-999f-959a535d3659 ro quiet splash nvidia.NVreg_DynamicPowerManagement=0x00 nvidia.NVreg_EnableGpuFirmware=0 acpi_osi=Linux pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/25/2025 dmi.bios.release: 1.32 dmi.bios.vendor: LENOVO dmi.bios.version: RLCN32WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion Pro 5 16ADR10 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrRLCN32WW:bd11/25/2025:br1.32:efr1.31:svnLENOVO:pn83LT:pvrLegionPro516ADR10:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrLegionPro516ADR10:skuLENOVO_MT_83LT_BU_idea_FM_LegionPro516ADR10:pfaLegionPro516ADR10: dmi.product.family: Legion Pro 5 16ADR10 dmi.product.name: 83LT dmi.product.sku: LENOVO_MT_83LT_BU_idea_FM_Legion Pro 5 16ADR10 dmi.product.version: Legion Pro 5 16ADR10 dmi.sys.vendor: LENOVO ** 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/2163509 Title: Lenovo Legion 5 Pro (83LT) – AMDGPU DMCUB error and NVIDIA SBIOS power-management errors on Ubuntu 26.04 Status in linux package in Ubuntu: New Bug description: I am using a Lenovo Legion 5 Pro (83LT) with a Ryzen 7 8745HX, integrated AMD Radeon 610M, and NVIDIA GeForce RTX 5060 Laptop GPU. On a fresh Ubuntu 26.04 installation, the system consistently reports an AMDGPU DMCUB error during boot: amdgpu 0000:05:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data The AMDGPU firmware itself loads successfully: Loading DMUB firmware via PSP: version=0x05002E00 DMUB hardware initialized: version=0x05002E00 Using ACPI provided EDID for eDP-2 The system also reports NVIDIA SBIOS/platform power-management errors: NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data passed [NV_ERR_INVALID_DATA] PlatformRequestHandler failed to get target temp from SBIOS PlatformRequestHandler failed to get platform power mode from SBIOS There is also an ACPI BIOS error: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.PB2], AE_NOT_FOUND and: ACPI Error: AE_NOT_FOUND, During name lookup/catalog The system is running: Ubuntu 26.04 (Resolute) Kernel: 7.0.0-29-generic GNOME Shell: 50.1 Wayland NVIDIA driver: 595.84 Mesa: 26.0.3 Both GPUs are detected correctly: NVIDIA GeForce RTX 5060 Laptop GPU Kernel driver: nvidia AMD Radeon 610M Kernel driver: amdgpu nvidia-smi works correctly and the NVIDIA GPU is available to GNOME Shell. The system is generally functional, but GNOME applications such as GNOME Control Center experience noticeable startup delays. gnome- control-center initially took approximately 7 seconds to start. After troubleshooting Bluetooth/OBEX, this decreased to approximately 2.6 seconds, but the underlying graphics/firmware errors remain. A full system health check showed: NVMe SMART: PASSED No failed systemd services RAM and storage resources are healthy NVIDIA GPU detected and operational AMDGPU loaded correctly Bluetooth controller operational NetworkManager operational I would like to determine whether the DMCUB error, ACPI BIOS error, and NVIDIA SBIOS power-management errors are caused by Lenovo firmware/BIOS compatibility with the current Ubuntu kernel and drivers, and whether a BIOS/firmware or kernel/driver fix is required. I can provide the complete system diagnostic report if required. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-29-generic 7.0.0-29.29 ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12 Uname: Linux 7.0.0-29-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: pranav 4706 F.... wireplumber /dev/snd/controlC0: pranav 4706 F.... wireplumber /dev/snd/seq: pranav 4688 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 21:08:25 2026 InstallationDate: Installed on 2026-07-27 (18 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 83LT ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-29-generic root=UUID=a028c422-b500-4883-999f-959a535d3659 ro quiet splash nvidia.NVreg_DynamicPowerManagement=0x00 nvidia.NVreg_EnableGpuFirmware=0 acpi_osi=Linux pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/25/2025 dmi.bios.release: 1.32 dmi.bios.vendor: LENOVO dmi.bios.version: RLCN32WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion Pro 5 16ADR10 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrRLCN32WW:bd11/25/2025:br1.32:efr1.31:svnLENOVO:pn83LT:pvrLegionPro516ADR10:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrLegionPro516ADR10:skuLENOVO_MT_83LT_BU_idea_FM_LegionPro516ADR10:pfaLegionPro516ADR10: dmi.product.family: Legion Pro 5 16ADR10 dmi.product.name: 83LT dmi.product.sku: LENOVO_MT_83LT_BU_idea_FM_Legion Pro 5 16ADR10 dmi.product.version: Legion Pro 5 16ADR10 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163509/+subscriptions

[Bug 2163508] Re: ice: E810 interface fails to initialize (ice_init_hw failed: -5) during NVM read

** Patch added: "jammy-patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163508/+attachment/5992181/+files/0001-J-ice-acquire-NVM-lock-around-each-flash-read.patch -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163508 Title: ice: E810 interface fails to initialize (ice_init_hw failed: -5) during NVM read Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Status in linux source package in Noble: New Status in linux source package in Resolute: New Status in linux source package in Stonking: New Bug description: [ Impact ] * When Intel's E810 driver (ice) initializes, one of the critical steps is to read the size of the NVM. This process is as follows: 1) driver acquires the NVM lock (a shared resource across all PFs and FW components) 2) driver keeps reading the NVM through AdminQueue commands until FW signals the end of the read 3) driver releases the NVM lock It is possible that while the driver is reading the NVM (step 2) FW returns an EBUSY status. This status is not handled by the driver and leads to a critical error that stops further initialization. As a result the interface is not brought up. * The root cause is in how the driver acquires the NVM lock. One of the required arguments is a timeout specifying how long the lock is valid. When that timeout expires, FW frees the lock internally and allows a different component to grab it - a different driver, a different PF, or a different FW component. In that case, if the driver that originally acquired the lock keeps reading the NVM (step 2), it will eventually receive an EBUSY status from FW. * The maximum timeout for this lock is 3000ms, and the ice driver currently does not respect it. It is rare but possible that reading a large NVM sector takes more than 3s. This is especially visible with some Dell-branded E810 NVMs. * The fix changes how the ice driver acquires the NVM lock: instead of acquiring it once at the beginning of the bulk read and releasing it at the end, the driver now requests the lock before each and every NVM read. This adds a small, measurable overhead to driver initialization time - under 50ms per PF initialization with full debug logs enabled. * The fix is approved by Intel and is currently in net-dev review. [TODO: update once the patch reaches linux-next] https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ [ Test Plan ] * The issue can be reproduced when the ice driver is initializing and reading the NVM takes more than 3s. I have not found a way to reproduce it locally, nor to force the FW to slow down its responses. * The issue was reported on a system using a Dell-branded 4.60 0x8001f4f3 NVM. The driver responds with the following error: [Sun Apr 19 21:37:37 2026] ice 0000:41:00.0: ice_init_hw failed: -5 [Sun Apr 19 21:37:37 2026] ice: probe of 0000:41:00.0 failed with error -5 After this, the 0000:41:00.0 interface is not initialized. * With debug logs enabled (ice.dyndbg=+p), the following pattern can be observed: [ 102.699610] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2003, datalen 0x0000, retval 0x0000 <- Lock acquired, timeout 3s [ 102.699634] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 103.020213] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3003, datalen 0x0001, retval 0x0000 <- Read operation ends [ 104.648070] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 105.434810] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000E <- Read operation ends [ 106.820932] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- This read is executed after the lock has already expired [ 109.603077] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000C <- We receive EBUSY * Regression testing was based on rebooting the system and verifying that all interfaces initialized properly. [ Where problems could occur ] * This change alters the NVM locking granularity in the ice driver: the lock is now acquired and released per firmware read command rather than once for the whole bulk read. A regression would be confined to the ice driver's NVM/flash access paths (flash-size discovery during init, devlink NVM snapshots, ethtool/devlink flash logging). * Acquiring and releasing the lock more frequently increases the number of AdminQueue commands issued during initialization. If FW is slow to grant the lock, or another PF/FW component holds it, initialization could take longer or, in the worst case, fail to acquire the lock. This would show up as slower probe times or, in the unlikely event of a locking mistake, contention with concurrent NVM operations. * A regression would most likely manifest as NVM read failures during driver probe (interface failing to initialize), or as failures reading the flash via devlink/ethtool. It does not affect the data path. [ Other Info ] * SRU for: Ubuntu 22.04 LTS (Jammy) - linux 5.15 Ubuntu 24.04 LTS (Noble) - linux 6.8 Ubuntu 26.04 (Resolute) - linux 7.0 Ubuntu 26.10 (Stonking) - linux 7.1 * Fix details: - Move the NVM lock acquire/release into ice_read_flat_nvm() so the lock brackets each individual ice_aq_read_nvm() command instead of the whole multi-sector read. This guarantees the lock is never held across more than one firmware read, so firmware never reclaims it mid-read. - Because ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, an optional read_aq_err output parameter is added to ice_read_flat_nvm() to capture the failing read's AQ error before the release. Callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status; others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. - Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") * Stonking backport notes: the commit applies as a clean cherry-pick. The 7.1 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Resolute backport notes: the commit applies as a clean cherry-pick. The 7.0 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Noble backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 6.8 tree: - 6.8 still uses the ice_aq_* API rather than upstream's libie_aq_* types (enum ice_aq_err, ICE_AQ_RC_*, ice_aq_str); - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * Jammy backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 5.15 tree: - 5.15 uses enum ice_status, ICE_ERR_AQ_ERROR and enum ice_aq_err rather than upstream's int and libie_aq_* types; - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - the ice_devlink_nvm_snapshot() is the single-read (non-block-loop) form, so different changes were required; - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * There was a different attempt to fix the issue focusing on retrying the read instead of acquiring the lock on every read. It was rejected because of the race conditions it could introduce: https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260617120753.1785565-1-robert.malz@canonical.com/ * The patch is currently in net-dev tree review: https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163508/+subscriptions

[Bug 2163508] [NEW] ice: E810 interface fails to initialize (ice_init_hw failed: -5) during NVM read

Public bug reported: [ Impact ] * When Intel's E810 driver (ice) initializes, one of the critical steps is to read the size of the NVM. This process is as follows: 1) driver acquires the NVM lock (a shared resource across all PFs and FW components) 2) driver keeps reading the NVM through AdminQueue commands until FW signals the end of the read 3) driver releases the NVM lock It is possible that while the driver is reading the NVM (step 2) FW returns an EBUSY status. This status is not handled by the driver and leads to a critical error that stops further initialization. As a result the interface is not brought up. * The root cause is in how the driver acquires the NVM lock. One of the required arguments is a timeout specifying how long the lock is valid. When that timeout expires, FW frees the lock internally and allows a different component to grab it - a different driver, a different PF, or a different FW component. In that case, if the driver that originally acquired the lock keeps reading the NVM (step 2), it will eventually receive an EBUSY status from FW. * The maximum timeout for this lock is 3000ms, and the ice driver currently does not respect it. It is rare but possible that reading a large NVM sector takes more than 3s. This is especially visible with some Dell-branded E810 NVMs. * The fix changes how the ice driver acquires the NVM lock: instead of acquiring it once at the beginning of the bulk read and releasing it at the end, the driver now requests the lock before each and every NVM read. This adds a small, measurable overhead to driver initialization time - under 50ms per PF initialization with full debug logs enabled. * The fix is approved by Intel and is currently in net-dev review. [TODO: update once the patch reaches linux-next] https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ [ Test Plan ] * The issue can be reproduced when the ice driver is initializing and reading the NVM takes more than 3s. I have not found a way to reproduce it locally, nor to force the FW to slow down its responses. * The issue was reported on a system using a Dell-branded 4.60 0x8001f4f3 NVM. The driver responds with the following error: [Sun Apr 19 21:37:37 2026] ice 0000:41:00.0: ice_init_hw failed: -5 [Sun Apr 19 21:37:37 2026] ice: probe of 0000:41:00.0 failed with error -5 After this, the 0000:41:00.0 interface is not initialized. * With debug logs enabled (ice.dyndbg=+p), the following pattern can be observed: [ 102.699610] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2003, datalen 0x0000, retval 0x0000 <- Lock acquired, timeout 3s [ 102.699634] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 103.020213] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3003, datalen 0x0001, retval 0x0000 <- Read operation ends [ 104.648070] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 105.434810] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000E <- Read operation ends [ 106.820932] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- This read is executed after the lock has already expired [ 109.603077] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000C <- We receive EBUSY * Regression testing was based on rebooting the system and verifying that all interfaces initialized properly. [ Where problems could occur ] * This change alters the NVM locking granularity in the ice driver: the lock is now acquired and released per firmware read command rather than once for the whole bulk read. A regression would be confined to the ice driver's NVM/flash access paths (flash-size discovery during init, devlink NVM snapshots, ethtool/devlink flash logging). * Acquiring and releasing the lock more frequently increases the number of AdminQueue commands issued during initialization. If FW is slow to grant the lock, or another PF/FW component holds it, initialization could take longer or, in the worst case, fail to acquire the lock. This would show up as slower probe times or, in the unlikely event of a locking mistake, contention with concurrent NVM operations. * A regression would most likely manifest as NVM read failures during driver probe (interface failing to initialize), or as failures reading the flash via devlink/ethtool. It does not affect the data path. [ Other Info ] * SRU for: Ubuntu 22.04 LTS (Jammy) - linux 5.15 Ubuntu 24.04 LTS (Noble) - linux 6.8 Ubuntu 26.04 (Resolute) - linux 7.0 Ubuntu 26.10 (Stonking) - linux 7.1 * Fix details: - Move the NVM lock acquire/release into ice_read_flat_nvm() so the lock brackets each individual ice_aq_read_nvm() command instead of the whole multi-sector read. This guarantees the lock is never held across more than one firmware read, so firmware never reclaims it mid-read. - Because ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, an optional read_aq_err output parameter is added to ice_read_flat_nvm() to capture the failing read's AQ error before the release. Callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status; others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. - Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") * Stonking backport notes: the commit applies as a clean cherry-pick. The 7.1 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Resolute backport notes: the commit applies as a clean cherry-pick. The 7.0 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Noble backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 6.8 tree: - 6.8 still uses the ice_aq_* API rather than upstream's libie_aq_* types (enum ice_aq_err, ICE_AQ_RC_*, ice_aq_str); - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * Jammy backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 5.15 tree: - 5.15 uses enum ice_status, ICE_ERR_AQ_ERROR and enum ice_aq_err rather than upstream's int and libie_aq_* types; - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - the ice_devlink_nvm_snapshot() is the single-read (non-block-loop) form, so different changes were required; - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * There was a different attempt to fix the issue focusing on retrying the read instead of acquiring the lock on every read. It was rejected because of the race conditions it could introduce: https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260617120753.1785565-1-robert.malz@canonical.com/ * The patch is currently in net-dev tree review: https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Robert Malz (rmalz) Status: New ** Affects: linux (Ubuntu Jammy) Importance: Undecided Assignee: Robert Malz (rmalz) Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Assignee: Robert Malz (rmalz) Status: New ** Affects: linux (Ubuntu Resolute) Importance: Undecided Assignee: Robert Malz (rmalz) Status: New ** Affects: linux (Ubuntu Stonking) Importance: Undecided Assignee: Robert Malz (rmalz) Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Robert Malz (rmalz) ** Changed in: linux (Ubuntu Noble) Assignee: (unassigned) => Robert Malz (rmalz) ** Changed in: linux (Ubuntu Resolute) Assignee: (unassigned) => Robert Malz (rmalz) ** Changed in: linux (Ubuntu Stonking) Assignee: (unassigned) => Robert Malz (rmalz) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163508 Title: ice: E810 interface fails to initialize (ice_init_hw failed: -5) during NVM read Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Status in linux source package in Noble: New Status in linux source package in Resolute: New Status in linux source package in Stonking: New Bug description: [ Impact ] * When Intel's E810 driver (ice) initializes, one of the critical steps is to read the size of the NVM. This process is as follows: 1) driver acquires the NVM lock (a shared resource across all PFs and FW components) 2) driver keeps reading the NVM through AdminQueue commands until FW signals the end of the read 3) driver releases the NVM lock It is possible that while the driver is reading the NVM (step 2) FW returns an EBUSY status. This status is not handled by the driver and leads to a critical error that stops further initialization. As a result the interface is not brought up. * The root cause is in how the driver acquires the NVM lock. One of the required arguments is a timeout specifying how long the lock is valid. When that timeout expires, FW frees the lock internally and allows a different component to grab it - a different driver, a different PF, or a different FW component. In that case, if the driver that originally acquired the lock keeps reading the NVM (step 2), it will eventually receive an EBUSY status from FW. * The maximum timeout for this lock is 3000ms, and the ice driver currently does not respect it. It is rare but possible that reading a large NVM sector takes more than 3s. This is especially visible with some Dell-branded E810 NVMs. * The fix changes how the ice driver acquires the NVM lock: instead of acquiring it once at the beginning of the bulk read and releasing it at the end, the driver now requests the lock before each and every NVM read. This adds a small, measurable overhead to driver initialization time - under 50ms per PF initialization with full debug logs enabled. * The fix is approved by Intel and is currently in net-dev review. [TODO: update once the patch reaches linux-next] https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ [ Test Plan ] * The issue can be reproduced when the ice driver is initializing and reading the NVM takes more than 3s. I have not found a way to reproduce it locally, nor to force the FW to slow down its responses. * The issue was reported on a system using a Dell-branded 4.60 0x8001f4f3 NVM. The driver responds with the following error: [Sun Apr 19 21:37:37 2026] ice 0000:41:00.0: ice_init_hw failed: -5 [Sun Apr 19 21:37:37 2026] ice: probe of 0000:41:00.0 failed with error -5 After this, the 0000:41:00.0 interface is not initialized. * With debug logs enabled (ice.dyndbg=+p), the following pattern can be observed: [ 102.699610] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2003, datalen 0x0000, retval 0x0000 <- Lock acquired, timeout 3s [ 102.699634] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 103.020213] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3003, datalen 0x0001, retval 0x0000 <- Read operation ends [ 104.648070] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- Read operation starts [ 105.434810] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000E <- Read operation ends [ 106.820932] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3000, datalen 0x0001, retval 0x0000 <- This read is executed after the lock has already expired [ 109.603077] ice 0000:05:00.0: CQ CMD: opcode 0x0701, flags 0x3007, datalen 0x0001, retval 0x000C <- We receive EBUSY * Regression testing was based on rebooting the system and verifying that all interfaces initialized properly. [ Where problems could occur ] * This change alters the NVM locking granularity in the ice driver: the lock is now acquired and released per firmware read command rather than once for the whole bulk read. A regression would be confined to the ice driver's NVM/flash access paths (flash-size discovery during init, devlink NVM snapshots, ethtool/devlink flash logging). * Acquiring and releasing the lock more frequently increases the number of AdminQueue commands issued during initialization. If FW is slow to grant the lock, or another PF/FW component holds it, initialization could take longer or, in the worst case, fail to acquire the lock. This would show up as slower probe times or, in the unlikely event of a locking mistake, contention with concurrent NVM operations. * A regression would most likely manifest as NVM read failures during driver probe (interface failing to initialize), or as failures reading the flash via devlink/ethtool. It does not affect the data path. [ Other Info ] * SRU for: Ubuntu 22.04 LTS (Jammy) - linux 5.15 Ubuntu 24.04 LTS (Noble) - linux 6.8 Ubuntu 26.04 (Resolute) - linux 7.0 Ubuntu 26.10 (Stonking) - linux 7.1 * Fix details: - Move the NVM lock acquire/release into ice_read_flat_nvm() so the lock brackets each individual ice_aq_read_nvm() command instead of the whole multi-sector read. This guarantees the lock is never held across more than one firmware read, so firmware never reclaims it mid-read. - Because ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, an optional read_aq_err output parameter is added to ice_read_flat_nvm() to capture the failing read's AQ error before the release. Callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status; others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. - Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") * Stonking backport notes: the commit applies as a clean cherry-pick. The 7.1 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Resolute backport notes: the commit applies as a clean cherry-pick. The 7.0 tree already carries the upstream libie_aq_* API (enum libie_aq_err, LIBIE_AQ_RC_*, libie_aq_str) and the devlink/devlink.c layout that the upstream patch targets, so no adaptations were required. The four modified files (devlink/devlink.c, ice_ethtool.c, ice_nvm.c, ice_nvm.h) patched without offset or fuzz, and the affected objects build cleanly. * Noble backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 6.8 tree: - 6.8 still uses the ice_aq_* API rather than upstream's libie_aq_* types (enum ice_aq_err, ICE_AQ_RC_*, ice_aq_str); - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * Jammy backport notes: the commit is a backport (not a clean cherry-pick). The following adaptations were required for the 5.15 tree: - 5.15 uses enum ice_status, ICE_ERR_AQ_ERROR and enum ice_aq_err rather than upstream's int and libie_aq_* types; - devlink changes are in ice_devlink.c instead of devlink/devlink.c; - the ice_get_eeprom() aq_err is logged via ice_aq_str(); - the ice_devlink_nvm_snapshot() is the single-read (non-block-loop) form, so different changes were required; - in the new lock-acquire failure path of ice_read_flat_nvm() the aq_err is logged with %d on hw->adminq.sq_last_status * There was a different attempt to fix the issue focusing on retrying the read instead of acquiring the lock on every read. It was rejected because of the race conditions it could introduce: https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260617120753.1785565-1-robert.malz@canonical.com/ * The patch is currently in net-dev tree review: https://lore.kernel.org/netdev/20260812000918.220714-4-anthony.l.nguyen@intel.com/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163508/+subscriptions

[Bug 2163506] [NEW] Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) doesnt work after upgrading to Ubuntu 24.04

Public bug reported: ## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, USB traffic looks nominally healthy, but no application (ffmpeg, v4l2-ctl raw stream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally before upgrading this machine from Ubuntu 22.04 to 24.04. ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **both affected** - Camera: Chicony Electronics Integrated Camera, USB ID 04f2:b6cb, bcdUVC 1.10, bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth — reproduces its own distinct format-negotiation failure, not the focus of this report) - Camera exposes 3 vendor Extension Units (XUs) in its VideoControl descriptor, which are typically used by the OEM Windows driver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386fb938} - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f43bc8} ## Steps to reproduce ``` v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV \ --stream-mmap --stream-count=5 --stream-to=/tmp/raw_test.yuv ``` Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device, receives format/stream description, but gets EOF with no decodable frame. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` while streaming was active. USB control-plane traffic (format probe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for the entire capture with no errors: ``` C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... ``` Every isochronous packet descriptor completes with status 0 (success) but **actual_length=12 bytes** — exactly the size of a bare UVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across ~475 isochronous packets captured; no URB errors, no babble, no protocol errors anywhere in dmesg. ## What's been ruled out - USB autosuspend (device was suspending; disabling via udev `power/control=on` fixed an earlier separate symptom — the browser's "camera not found" error disappeared once the device reliably stays powered — but did not fix frame delivery) - `uvcvideo quirks=128` (UVC_QUIRK_FIX_BANDWIDTH) — no effect - `power_line_frequency` control (known bug class on other Lenovo-integrated cameras, see kernel patch "media: uvcvideo: Fix power line control for Lenovo Integrated Camera" for Shine-Optics 3277:009e) — set explicitly via v4l2-ctl, no effect - Lenovo EC camera-power gate (`/sys/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:00/camera_power`) — toggled off/on, no effect, reads `1` (enabled) - No physical privacy shutter on this model; no dedicated Fn camera-toggle hotkey found - No pending firmware updates for "Integrated Camera" via fwupd/LVFS - Fresh `modprobe -r uvcvideo && modprobe uvcvideo` before each test to rule out stale driver state - GNOME camera privacy toggle off (not blocking), correct udev ACL for /dev/video0, no other process holding the device open, no `/etc/modprobe.d` blacklist affecting uvcvideo/i2c_hid/psmouse ## Working theory The three vendor Extension Units suggest the OEM Windows driver performs a proprietary init/wake sequence on the sensor via one of these XUs before it will actually output pixel data. `uvcvideo`'s generic UVC negotiation (probe/commit/altsetting) succeeds because that part of the protocol is standard, but without the correct XU command sequence the sensor silently stays in a "streaming but dark" state — it acknowledges the stream request and sends header-only payloads, but never activates actual pixel readout. Since this camera reportedly worked under this same laptop before upgrading Ubuntu 22.04 → 24.04, something changed (kernel version, uvcvideo driver behavior, or firmware quirk table) between the two setups; a bisect against the 22.04 kernel/driver version would help narrow this down further. ## Requested - Guidance on whether a uvcvideo quirk/XU-init patch is feasible for this device, similar to the existing "Fix power line control for Lenovo Integrated Camera" precedent - Any pointers to existing bug reports for Chicony 04f2:b6cb or Lenovo model 82NC camera issues ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-137-generic 6.8.0-137.137 ProcVersionSignature: Ubuntu 6.8.0-137.137-generic 6.8.12 Uname: Linux 6.8.0-137-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: raghu 3845 F.... pipewire raghu 3849 F.... wireplumber /dev/snd/seq: raghu 3845 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 20:28:25 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2023-05-23 (1179 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) MachineType: LENOVO 82NC ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_px4ncd@/vmlinuz-6.8.0-137-generic root=ZFS=rpool/ROOT/ubuntu_px4ncd ro quiet splash i8042.direct i8042.dumbkbd RelatedPackageVersions: linux-restricted-modules-6.8.0-137-generic N/A linux-backports-modules-6.8.0-137-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/21/2022 dmi.bios.release: 1.69 dmi.bios.vendor: LENOVO dmi.bios.version: FJCN69WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 Pro 14IHU5 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrFJCN69WW:bd03/21/2022:br1.69:efr1.31:svnLENOVO:pn82NC:pvrYogaSlim7Pro14IHU5:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrYogaSlim7Pro14IHU5:skuLENOVO_MT_82NC_BU_idea_FM_YogaSlim7Pro14IHU5: dmi.product.family: Yoga Slim 7 Pro 14IHU5 dmi.product.name: 82NC dmi.product.sku: LENOVO_MT_82NC_BU_idea_FM_Yoga Slim 7 Pro 14IHU5 dmi.product.version: Yoga Slim 7 Pro 14IHU5 dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug noble -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163506 Title: Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) doesnt work after upgrading to Ubuntu 24.04 Status in linux package in Ubuntu: New Bug description: ## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, USB traffic looks nominally healthy, but no application (ffmpeg, v4l2-ctl raw stream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally before upgrading this machine from Ubuntu 22.04 to 24.04. ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **both affected** - Camera: Chicony Electronics Integrated Camera, USB ID 04f2:b6cb, bcdUVC 1.10, bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth — reproduces its own distinct format-negotiation failure, not the focus of this report) - Camera exposes 3 vendor Extension Units (XUs) in its VideoControl descriptor, which are typically used by the OEM Windows driver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386fb938} - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f43bc8} ## Steps to reproduce ``` v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV \ --stream-mmap --stream-count=5 --stream-to=/tmp/raw_test.yuv ``` Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device, receives format/stream description, but gets EOF with no decodable frame. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` while streaming was active. USB control-plane traffic (format probe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for the entire capture with no errors: ``` C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... ``` Every isochronous packet descriptor completes with status 0 (success) but **actual_length=12 bytes** — exactly the size of a bare UVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across ~475 isochronous packets captured; no URB errors, no babble, no protocol errors anywhere in dmesg. ## What's been ruled out - USB autosuspend (device was suspending; disabling via udev `power/control=on` fixed an earlier separate symptom — the browser's "camera not found" error disappeared once the device reliably stays powered — but did not fix frame delivery) - `uvcvideo quirks=128` (UVC_QUIRK_FIX_BANDWIDTH) — no effect - `power_line_frequency` control (known bug class on other Lenovo-integrated cameras, see kernel patch "media: uvcvideo: Fix power line control for Lenovo Integrated Camera" for Shine-Optics 3277:009e) — set explicitly via v4l2-ctl, no effect - Lenovo EC camera-power gate (`/sys/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:00/camera_power`) — toggled off/on, no effect, reads `1` (enabled) - No physical privacy shutter on this model; no dedicated Fn camera-toggle hotkey found - No pending firmware updates for "Integrated Camera" via fwupd/LVFS - Fresh `modprobe -r uvcvideo && modprobe uvcvideo` before each test to rule out stale driver state - GNOME camera privacy toggle off (not blocking), correct udev ACL for /dev/video0, no other process holding the device open, no `/etc/modprobe.d` blacklist affecting uvcvideo/i2c_hid/psmouse ## Working theory The three vendor Extension Units suggest the OEM Windows driver performs a proprietary init/wake sequence on the sensor via one of these XUs before it will actually output pixel data. `uvcvideo`'s generic UVC negotiation (probe/commit/altsetting) succeeds because that part of the protocol is standard, but without the correct XU command sequence the sensor silently stays in a "streaming but dark" state — it acknowledges the stream request and sends header-only payloads, but never activates actual pixel readout. Since this camera reportedly worked under this same laptop before upgrading Ubuntu 22.04 → 24.04, something changed (kernel version, uvcvideo driver behavior, or firmware quirk table) between the two setups; a bisect against the 22.04 kernel/driver version would help narrow this down further. ## Requested - Guidance on whether a uvcvideo quirk/XU-init patch is feasible for this device, similar to the existing "Fix power line control for Lenovo Integrated Camera" precedent - Any pointers to existing bug reports for Chicony 04f2:b6cb or Lenovo model 82NC camera issues ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-137-generic 6.8.0-137.137 ProcVersionSignature: Ubuntu 6.8.0-137.137-generic 6.8.12 Uname: Linux 6.8.0-137-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: raghu 3845 F.... pipewire raghu 3849 F.... wireplumber /dev/snd/seq: raghu 3845 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 20:28:25 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2023-05-23 (1179 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) MachineType: LENOVO 82NC ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_px4ncd@/vmlinuz-6.8.0-137-generic root=ZFS=rpool/ROOT/ubuntu_px4ncd ro quiet splash i8042.direct i8042.dumbkbd RelatedPackageVersions: linux-restricted-modules-6.8.0-137-generic N/A linux-backports-modules-6.8.0-137-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/21/2022 dmi.bios.release: 1.69 dmi.bios.vendor: LENOVO dmi.bios.version: FJCN69WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 Pro 14IHU5 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrFJCN69WW:bd03/21/2022:br1.69:efr1.31:svnLENOVO:pn82NC:pvrYogaSlim7Pro14IHU5:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrYogaSlim7Pro14IHU5:skuLENOVO_MT_82NC_BU_idea_FM_YogaSlim7Pro14IHU5: dmi.product.family: Yoga Slim 7 Pro 14IHU5 dmi.product.name: 82NC dmi.product.sku: LENOVO_MT_82NC_BU_idea_FM_Yoga Slim 7 Pro 14IHU5 dmi.product.version: Yoga Slim 7 Pro 14IHU5 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163506/+subscriptions