[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

[Bug 2163288] Lsusb-v.txt

apport information ** Attachment added: "Lsusb-v.txt" https://bugs.launchpad.net/bugs/2163288/+attachment/5991839/+files/Lsusb-v.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163288 Title: HP ZBook X G1i: JHL7540 xHCI dies when Thunderbolt Dock G2 is connected during boot; hot-plug works Status in linux package in Ubuntu: Incomplete Bug description: ubuntu-bug linux was run from the affected system while reproducing the problem, so Apport diagnostic information may already have been uploaded separately. HP ZBook X G1i: HP Thunderbolt Dock G2 JHL7540 xHCI controller dies during cold boot but works when hot-plugged after boot Summary On an HP ZBook X G1i 16-inch Mobile Workstation running Ubuntu 24.04, an HP Thunderbolt Dock G2 works correctly when connected after Ubuntu has finished booting, but its USB controller consistently dies during boot if the dock is already connected when the system starts. DisplayPort output from the dock continues to work, but USB devices and Ethernet attached through the dock do not appear. The affected PCI device is: Intel JHL7540 Thunderbolt 3 USB Controller [Titan Ridge 4C 2018] PCI ID: 8086:15ec Subsystem: HP 103c:0467 The kernel binds xhci_hcd to the device, starts the USB buses, and then reports: xhci_hcd 0000:05:00.0: xHCI host controller not responding, assume dead xhci_hcd 0000:05:00.0: HC died; cleaning up Hardware Laptop: HP ZBook X G1i 16 inch Mobile Workstation PC CPU: Intel Core Ultra 9 285H Dock: HP Thunderbolt Dock G2 Thunderbolt 3 Dock firmware reported by fwupd: 66.00 Dock USB controller: Intel JHL7540 Thunderbolt 3 USB Controller 8086:15ec Subsystem 103c:0467 System BIOS: HP X97 Ver. 01.05.03 USB4 retimer firmware: 26.85 Ubuntu release: Ubuntu 24.04 Kernels tested The problem reproduces identically with: 7.0.0-28-generic 6.17.0-40-generic Therefore it does not appear specific to the 7.0 kernel. Steps to reproduce Connect the HP Thunderbolt Dock G2 to the ZBook. Leave USB mouse, keyboard, and Ethernet connected to the dock. Boot Ubuntu with the dock already physically connected. Log in. Observe that the monitor connected through the dock works. Observe that keyboard, mouse, and Ethernet through the dock do not work. Run: sudo dmesg | grep -iE 'xhci|thunderbolt|usb|05:00.0' Actual result During boot, PCI device 0000:05:00.0 is discovered and xhci_hcd starts normally: pci 0000:05:00.0: [8086:15ec] type 00 class 0x0c0330 PCIe Endpoint xhci_hcd 0000:05:00.0: xHCI Host Controller xhci_hcd 0000:05:00.0: new USB bus registered xhci_hcd 0000:05:00.0: Host supports USB 3.1 Enhanced SuperSpeed Shortly afterward: xhci_hcd 0000:05:00.0: xHCI host controller not responding, assume dead xhci_hcd 0000:05:00.0: HC died; cleaning up The downstream dock USB hubs, keyboard, mouse, audio, and Realtek RTL8153 Ethernet controller therefore do not enumerate. After the failure, the PCI device remains present and reports D0 / runtime active, but memory decoding, bus mastering, and MSI are disabled following the xHCI failure. Expected result The Thunderbolt Dock G2 should initialize during boot in the same way it does when physically connected after Ubuntu has finished booting. USB mouse, keyboard, Ethernet, audio, and other dock USB devices should enumerate normally. Important comparison: hot-plug works If Ubuntu is booted with the dock physically disconnected, and the same dock is connected after login, everything works. During successful hot-plug, the sequence is: thunderbolt 0-1: new device found, vendor=0xf0 device=0x467 thunderbolt 0-1: HP Thunderbolt Dock G2 pci 0000:05:00.0: [8086:15ec] type 00 class 0x0c0330 PCIe Endpoint pci 0000:05:00.0: BAR 0 [mem 0x8c000000-0x8c00ffff]: assigned pci 0000:05:00.0: enabling device xhci_hcd 0000:05:00.0: xHCI Host Controller The downstream USB hierarchy then enumerates successfully, including: 2109:2820 VIA Labs VL820 USB 2 hub 2109:0820 VIA Labs VL820 USB 3 hub 0424:2807 Microchip USB hub 0424:5807 Microchip USB hub 046d:c52b Logitech Unifying Receiver 046d:c31c Logitech keyboard 03f0:0269 HP USB Audio 03f0:0667 HP/Cypress device 0bda:8153 Realtek RTL8153 Gigabit Ethernet Mouse, keyboard, audio, and Ethernet all work normally in this state. Thunderbolt authorization / DMA protection Thunderbolt authorization was investigated separately. BIOS DMA Protection is currently enabled for Thunderbolt devices. Both Thunderbolt domains report: iommu_dma_protection = 1 The connected G2 dock is enrolled with boltd and automatically shows status "authorized". The Thunderbolt link reports 40 Gb/s in both directions. Therefore the failure still occurs with Thunderbolt authorization and IOMMU DMA protection functioning normally. Additional testing The following tests did NOT resolve the failure: Updating system BIOS from HP X97 01.04.03 to X97 01.05.03. Booting Linux 6.17.0-40-generic instead of 7.0.0-28-generic. Testing with intel_iommu=off. PCI remove/rescan of 0000:05:00.0. Thunderbolt device deauthorization and reauthorization. PCI remove/rescan produces: pci 0000:05:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0xffffffff xhci_hcd 0000:05:00.0: Host halt failed, -19 xhci_hcd 0000:05:00.0: can't setup: -19 xhci_hcd 0000:05:00.0: init 0000:05:00.0 fail, -19 Deauthorizing and reauthorizing the Thunderbolt device does not remove/reset the 05:00.0 PCI endpoint deeply enough to recover it. Only physically disconnecting the dock and reconnecting it after Ubuntu is running successfully resets/reinitializes the JHL7540 xHCI controller. Other observations During a successful hot-plug, 0000:05:00.0 reports: Power state: D0 MSI: enabled Mem+ BusMaster+ Kernel driver in use: xhci_hcd PCIe link: Speed 2.5GT/s Width x4 No AER errors are reported. During the failed cold-boot state, the PCI endpoint remains visible but after the xHCI driver cleanup it shows: Mem- BusMaster- MSI disabled The physical Thunderbolt link itself remains connected/authorized. Workaround Boot Ubuntu with the HP Thunderbolt Dock G2 physically disconnected. After Ubuntu finishes booting, connect the Thunderbolt cable. The dock then works normally. Suspected area This appears to be a cold-boot initialization / reset / sequencing issue involving the Intel JHL7540 Titan Ridge xHCI endpoint behind the Thunderbolt PCIe tunnel on the HP ZBook X G1i USB4/Thunderbolt platform. The same controller works correctly when the Thunderbolt tunnel and PCI device are created dynamically after the OS is fully running. --- ProblemType: Bug ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: hirschch@corp.sarcos.com 3432 F.... pipewire hirschch@corp.sarcos.com 3437 F.... wireplumber /dev/snd/controlC0: hirschch@corp.sarcos.com 3437 F.... wireplumber /dev/snd/seq: hirschch@corp.sarcos.com 3432 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 24.04 InstallationDate: Installed on 2026-07-16 (28 days ago) InstallationMedia: Ubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) MachineType: HP HP ZBook X G1i 16 inch Mobile Workstation PC Package: linux (not installed) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-28-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=off quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12 RelatedPackageVersions: linux-restricted-modules-7.0.0-28-generic N/A linux-backports-modules-7.0.0-28-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 Tags: noble wayland-session Uname: Linux 7.0.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm audio cdrom dip lpadmin lxd netdev plugdev sudo users video _MarkForUpload: True dmi.bios.date: 05/04/2026 dmi.bios.release: 5.3 dmi.bios.vendor: HP dmi.bios.version: X97 Ver. 01.05.03 dmi.board.name: 8E1D dmi.board.vendor: HP dmi.board.version: KBC Version 63.24.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 99.36 dmi.modalias: dmi:bvnHP:bvrX97Ver.01.05.03:bd05/04/2026:br5.3:efr99.36:svnHP:pnHPZBookXG1i16inchMobileWorkstationPC:pvrSBKPFV3:rvnHP:rn8E1D:rvrKBCVersion63.24.00:cvnHP:ct10:cvr:skuC44ZLUA#ABA:pfa103C_5336ANHPZBook: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook X G1i 16 inch Mobile Workstation PC dmi.product.sku: C44ZLUA#ABA dmi.product.version: SBKPFV3 dmi.sys.vendor: HP --- ProblemType: Bug ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: hirschch@corp.sarcos.com 3368 F.... pipewire hirschch@corp.sarcos.com 3371 F.... wireplumber /dev/snd/controlC0: hirschch@corp.sarcos.com 3371 F.... wireplumber /dev/snd/seq: hirschch@corp.sarcos.com 3368 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 24.04 InstallationDate: Installed on 2026-07-16 (28 days ago) InstallationMedia: Ubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) MachineType: HP HP ZBook X G1i 16 inch Mobile Workstation PC Package: linux (not installed) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-28-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=off quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12 RelatedPackageVersions: linux-restricted-modules-7.0.0-28-generic N/A linux-backports-modules-7.0.0-28-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 Tags: noble Uname: Linux 7.0.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 05/04/2026 dmi.bios.release: 5.3 dmi.bios.vendor: HP dmi.bios.version: X97 Ver. 01.05.03 dmi.board.name: 8E1D dmi.board.vendor: HP dmi.board.version: KBC Version 63.24.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 99.36 dmi.modalias: dmi:bvnHP:bvrX97Ver.01.05.03:bd05/04/2026:br5.3:efr99.36:svnHP:pnHPZBookXG1i16inchMobileWorkstationPC:pvrSBKPFV3:rvnHP:rn8E1D:rvrKBCVersion63.24.00:cvnHP:ct10:cvr:skuC44ZLUA#ABA:pfa103C_5336ANHPZBook: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook X G1i 16 inch Mobile Workstation PC dmi.product.sku: C44ZLUA#ABA dmi.product.version: SBKPFV3 dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163288/+subscriptions