[Bug 2167799] Re: Can't turn on Bluetooth

*** This bug is a duplicate of bug 2165873 *** https://bugs.launchpad.net/bugs/2165873 ** This bug has been marked a duplicate of bug 2165873 Bluetooth fails to initialize due to a kernel NULL pointer error -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167799 Title: Can't turn on Bluetooth Status in linux package in Ubuntu: New Bug description: [Expected Behavior] Bluetooth should turn on and be able to discover devices. It works perfectly on the older kernel version [Ubuntu, with Linux: 6.8.0-138]. [Actual Behavior] After the recent September update to kernel [Ubuntu, with Linux: 6.8.0-139], Bluetooth cannot be enabled. The toggle in the settings automatically switches back to "Off". [Steps to Reproduce] 1. Boot into the latest kernel ([6.8.0-139]). 2. Open Settings -> Bluetooth. 3. Try to turn Bluetooth on. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ni 2713 F.... wireplumber /dev/snd/controlC0: ni 2713 F.... wireplumber /dev/snd/seq: ni 2708 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 20:03:18 2026 InstallationDate: Installed on 2025-11-08 (316 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. ASUS TUF Gaming A15 FA506NFR_FA506NFR ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-139-generic root=UUID=760880b1-41ea-410f-8a9e-bfc6f193138b ro quiet splash pcie_aspm=off vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60.0ubuntu3.1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2025-11-08 (316 days ago) dmi.bios.date: 03/21/2024 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: FA506NFR.300 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: FA506NFR 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: 3.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrFA506NFR.300:bd03/21/2024:br5.24:efr3.0:svnASUSTeKCOMPUTERINC.:pnASUSTUFGamingA15FA506NFR_FA506NFR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnFA506NFR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku: dmi.product.family: ASUS TUF Gaming A15 dmi.product.name: ASUS TUF Gaming A15 FA506NFR_FA506NFR 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/2167799/+subscriptions

[Bug 2159589] Re: Bluetooth turns back on automatically after being turned off in GNOME

[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159589 Title: Bluetooth turns back on automatically after being turned off in GNOME Status in linux package in Ubuntu: Expired Bug description: On Ubuntu 26.04 LTS, Bluetooth cannot remain turned off. When I turn Bluetooth off using either GNOME Quick Settings or Settings, it turns off briefly but then automatically turns itself back on. The Bluetooth controller confirms this behavior: immediately after turning it off, bluetoothctl show reports: Powered: no PowerState: off After a short time, without any user action, it changes back to: Powered: yes PowerState: on The Bluetooth adapter is a MediaTek device, USB ID 0e8d:e025, on a Lenovo ThinkPad P16s Gen 4 AMD. The kernel log also showed errors during the Bluetooth power-off sequence, including: Bluetooth: hci0: command 0x2039 tx timeout Bluetooth: hci0: failed to reset (-19) Bluetooth: hci0: Error when powering off device on rfkill (-110) Expected behavior: When Bluetooth is turned off in GNOME Quick Settings or Settings, it should remain off until the user turns it on again. Actual behavior: Bluetooth turns itself back on automatically after being turned off. This occurs consistently after a fresh installation of Ubuntu 26.04 LTS. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jul 5 14:09:07 2026 InstallationDate: Installed on 2026-07-05 (0 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 21RX001LGE 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=/vmlinuz-7.0.0-27-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/29/2025 dmi.bios.release: 1.15 dmi.bios.vendor: LENOVO dmi.bios.version: R2XET35W (1.15 ) dmi.board.asset.tag: Not Available dmi.board.name: 21RX001LGE dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.8 dmi.modalias: dmi:bvnLENOVO:bvrR2XET35W(1.15):bd08/29/2025:br1.15:efr1.8:svnLENOVO:pn21RX001LGE:pvrThinkPadP16sGen4AMD:rvnLENOVO:rn21RX001LGE:rvrNotDefined:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21RX_BU_Think_FM_ThinkPadP16sGen4AMD:pfaThinkPadP16sGen4AMD: dmi.product.family: ThinkPad P16s Gen 4 AMD dmi.product.name: 21RX001LGE dmi.product.sku: LENOVO_MT_21RX_BU_Think_FM_ThinkPad P16s Gen 4 AMD dmi.product.version: ThinkPad P16s Gen 4 AMD dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159589/+subscriptions

[Bug 2031382] Re: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work)

** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Zixing Liu (liushuyu-011) ** Description changed: + SRU Justification: + + [Impact] + On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. + + [Fix] + Partially reverting commit <> workaround the issue. + + [Test Plan] + Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. + + [Where problems could occur] + The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. + + [Other Info] + Original bug report: + Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c ** Description changed: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. [Fix] - Partially reverting commit <> workaround the issue. + Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c ** Description changed: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. + + On Ubuntu Jammy, since we are using linux-klibc-dev package from 5.15 kernel + the new ioprio level checking logic (added in upstream commit 893e5d32d5832674bcf6465f27958e883b72b346) resided in the 6.8 linux-klibc-dev headers + will not be triggered. [Fix] Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2031382 Title: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: New Bug description: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. On Ubuntu Jammy, since we are using linux-klibc-dev package from 5.15 kernel the new ioprio level checking logic (added in upstream commit 893e5d32d5832674bcf6465f27958e883b72b346) resided in the 6.8 linux-klibc-dev headers will not be triggered. [Fix] Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2031382/+subscriptions

[Bug 1968040] Re: [i915] Blanked screen doesn't wake up after locking [drmModeAtomicCommit: Argument invalide] [drmModeAtomicCommit: Invalid argument]

** Tags added: noble -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1968040 Title: [i915] Blanked screen doesn't wake up after locking [drmModeAtomicCommit: Argument invalide] [drmModeAtomicCommit: Invalid argument] Status in GNOME Shell: New Status in Mutter: New Status in linux package in Ubuntu: Confirmed Status in linux-hwe-5.19 package in Ubuntu: Confirmed Status in linux-hwe-6.8 package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Confirmed Bug description: [ Workaround for 24.04 and later ] Add to /etc/environment:   MUTTER_DEBUG_FORCE_KMS_MODE=simple and then reboot. [ Workaround for 22.04 ] Add to /etc/environment:   MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 and then reboot. [ Upstream bugs ] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5098 https://gitlab.gnome.org/GNOME/mutter/-/issues/2268 https://gitlab.gnome.org/GNOME/mutter/-/issues/2749 [ Original report ] (initially reported as a comment on bug #1965085, and split into a separate bug report) After I lock my screen and let it blank, moving the mouse or pressing any key on the keyboard won't wake it up. The only reliable workaround I've found is to press Ctrl+Alt+F1. That's on a fully up-to-date jammy, my hardware is an Intel NUC with a single Samsung monitor connected with a standard HDMI cable. This is a regression that started happening yesterday (2022-04-05) if I can remember correctly (I do apply pending updates at least once daily). ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gdm3 42.0-1ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu80 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Apr 6 15:19:30 2022 InstallationDate: Installed on 2020-09-16 (566 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200910) SourcePackage: gdm3 UpgradeStatus: Upgraded to jammy on 2022-03-19 (17 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1968040/+subscriptions

[Bug 2167785] Re: ethernet connection breaks after wakeup

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167785 Title: ethernet connection breaks after wakeup Status in linux package in Ubuntu: New Bug description: Intel I226-V Ethernet fails after suspend/resume on Ubuntu 26.04. Hardware: Intel I226-V [8086:125c], rev 06 Driver: igc Kernel: 7.0.0-31-generic Steps: 1. Ethernet works normally. 2. Suspend system. 3. Resume. 4. eno2 becomes unavailable and Ethernet does not reconnect. 5. Reloading the igc module restores the interface: sudo modprobe -r igc sudo modprobe igc After reload, carrier returns, NetworkManager obtains DHCP address 192.168.1.10, and Ethernet works normally. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 09:57:59 2026 InstallationDate: Installed on 2026-09-18 (2 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlo1Link: Not connected. MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=6f7598f7-82dc-4ea2-9204-aa3d9d9687ee ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/28/2023 dmi.bios.release: 4.4 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0404 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z790-F GAMING WIFI II dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0404:bd09/28/2023:br4.4:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ790-FGAMINGWIFIII:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167785/+subscriptions

[Bug 2167799] Re: Can't turn on Bluetooth

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167799 Title: Can't turn on Bluetooth Status in linux package in Ubuntu: New Bug description: [Expected Behavior] Bluetooth should turn on and be able to discover devices. It works perfectly on the older kernel version [Ubuntu, with Linux: 6.8.0-138]. [Actual Behavior] After the recent September update to kernel [Ubuntu, with Linux: 6.8.0-139], Bluetooth cannot be enabled. The toggle in the settings automatically switches back to "Off". [Steps to Reproduce] 1. Boot into the latest kernel ([6.8.0-139]). 2. Open Settings -> Bluetooth. 3. Try to turn Bluetooth on. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ni 2713 F.... wireplumber /dev/snd/controlC0: ni 2713 F.... wireplumber /dev/snd/seq: ni 2708 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 20:03:18 2026 InstallationDate: Installed on 2025-11-08 (316 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. ASUS TUF Gaming A15 FA506NFR_FA506NFR ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-139-generic root=UUID=760880b1-41ea-410f-8a9e-bfc6f193138b ro quiet splash pcie_aspm=off vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60.0ubuntu3.1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2025-11-08 (316 days ago) dmi.bios.date: 03/21/2024 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: FA506NFR.300 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: FA506NFR 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: 3.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrFA506NFR.300:bd03/21/2024:br5.24:efr3.0:svnASUSTeKCOMPUTERINC.:pnASUSTUFGamingA15FA506NFR_FA506NFR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnFA506NFR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku: dmi.product.family: ASUS TUF Gaming A15 dmi.product.name: ASUS TUF Gaming A15 FA506NFR_FA506NFR 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/2167799/+subscriptions

[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

I verified this bug and reviewed the patch submitted to linux-fsdevel by Kentaro Shiomi. The root cause is clear: in fs/vboxsf/file.c, vboxsf_write_end() initialises 'nwritten = len' instead of 'copied'. When writing from un- faulted pages (like direct mmap or shared memory used by virtiofsd), copy_page_from_iter_atomic() copies 0 bytes. Because vboxsf_write_end() reports status = len back to VFS, generic_perform_write() thinks the data was written, never calls fault_in_iov_iter_readable(), and enters an endless loop filling the file with zeroes. I tested the patch logic against the Ubuntu kernel trees: 1. Resolute (7.0 / master): Uses the folio write_end signature. 2. Noble 24.04 LTS (6.8): Uses the page write_end signature. 3. Jammy 22.04 LTS (5.15): Same page write_end signature. The patch applies and builds cleanly with zero warnings. I updated the bug description above with the formal SRU justification and a minimal Python reproducer to help the kernel team track this for the next SRU cycle. I am also attaching the DEP-3 formatted patches for both Resolute and Noble. ** Patch added: "DEP-3 patch for Ubuntu 26.04 Resolute (Linux 7.0 / folio write_end)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+attachment/6001322/+files/lp2167772_vboxsf_resolute_7.0.patch -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification: [ Impact ] In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to a file from memory pages that have not been faulted into the process page table causes the write path to enter an infinite loop. The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 Furthermore, if the target page/folio is already marked uptodate in the page cache, un-copied ranges are not zeroed, which causes vboxsf to write stale page cache contents to the host, resulting in silent data corruption. This condition is reliably triggered by applications that write directly from an mmap of another file or from shared memory without touching the pages first. For example, virtiofsd (used in nested virtualisation workloads, container runtimes, and developer sandboxes) operates in this manner and triggers the failure immediately. [ Fix ] In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: u32 nwritten = len; When a short copy occurs (copied < len, or copied == 0 due to an un- faulted page), the driver incorrectly wrote 'len' bytes to the host and returned 'len' to the VFS write loop. As a result, generic_perform_write() never invoked fault_in_iov_iter_readable(), advanced the file position by 'len' without advancing the user iterator, and looped endlessly. The fix applies two changes: 1. Initialise nwritten with the actually copied byte count: u32 nwritten = copied; 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. [ Test Plan ] A minimal test using Python writes from an un-faulted mmap buffer into a vboxsf mount: 1. Mount a VirtualBox shared folder: sudo mount -t vboxsf shared_folder /mnt/shared 2. Run the reproducer: python3 -c ' import mmap, os with open("/tmp/src.bin", "wb") as f: f.write(b"A" * 65536) with open("/tmp/src.bin", "rb") as f: mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) with open("/mnt/shared/test.bin", "wb") as out: out.write(mm[:4096]) print("Written:", os.path.getsize("/mnt/shared/test.bin")) ' Verification criteria: - Unpatched kernel: The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". - Patched kernel: The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. [ Where problems could occur ] The change is strictly isolated to the write_end handler in fs/vboxsf/file.c. In the standard case where copied == len, behavior is completely identical. In the case where copied < len or copied == 0, the driver now accurately conforms to the VFS address_space_operations contract by reporting actual progress instead of fabricating a successful write. Potential regression risk is very low. If any side effects were to occur, they would be strictly confined to writes on vboxsf mount points and would not impact other filesystems or core kernel memory management. [ Other Info ] The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: - Resolute (7.0 kernel, folio-based) - Noble (6.8 kernel, page-based) - Jammy (5.15 kernel, page-based) Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions

[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

** Description changed: - [Summary] - Writing to a VirtualBox shared folder (vboxsf) from pages that have not been - faulted in makes the in-kernel vboxsf driver loop forever: the target file - keeps growing with zeroed data until the disk is full, the writing process - only dies on SIGKILL, and the log fills up with + SRU Justification: + [ Impact ] + + In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to + a file from memory pages that have not been faulted into the process + page table causes the write path to enter an infinite loop. + + The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 - In my case ~16 GB of logs were written before the guest ran out of - space. + Furthermore, if the target page/folio is already marked uptodate in the + page cache, un-copied ranges are not zeroed, which causes vboxsf to + write stale page cache contents to the host, resulting in silent data + corruption. - [Root cause] - vboxsf_write_end() ignores "copied": it writes the full requested length to - the host and returns that length even when copied == 0, so - generic_perform_write() never faults the source pages in, advances pos and - loops forever. The same accounting bug can silently corrupt data when the - folio is already uptodate. + This condition is reliably triggered by applications that write directly + from an mmap of another file or from shared memory without touching the + pages first. For example, virtiofsd (used in nested virtualisation + workloads, container runtimes, and developer sandboxes) operates in this + manner and triggers the failure immediately. - [Upstream] - Patch submitted to the vboxsf maintainer and linux-fsdevel on 2026-09-19: - https://lore.kernel.org/linux-fsdevel/20260919174136.3325-1-k.shiomi@techhowto.blog/ + [ Fix ] - A DKMS package with the patch (and a guard that refuses to mount shared - folders unless the patched module is loaded) is available at - https://github.com/kentaro-shiomi/virtualbox-vboxsf-endless-write-loop-fix + In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: + u32 nwritten = len; - [Trigger] - Programs that write straight from an mmap of another file or from shared - memory without reading it first. virtiofsd does exactly this, so running a - nested VM whose working directory lives on a vboxsf mount hits it immediately. - Ordinary applications write from buffers they have just filled and are not - affected. + When a short copy occurs (copied < len, or copied == 0 due to an un- + faulted page), the driver incorrectly wrote 'len' bytes to the host and + returned 'len' to the VFS write loop. As a result, + generic_perform_write() never invoked fault_in_iov_iter_readable(), + advanced the file position by 'len' without advancing the user iterator, + and looped endlessly. - [Environment] - Ubuntu 26.04.1, kernel 7.0.0-31-generic, guest of VirtualBox 7.2.16 on a - Windows 11 host. The faulty code is identical in Linux v7.0 and in master as - of 2026-09. + The fix applies two changes: + 1. Initialise nwritten with the actually copied byte count: + u32 nwritten = copied; + 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. + + [ Test Plan ] + + A minimal test using Python writes from an un-faulted mmap buffer into a + vboxsf mount: + + 1. Mount a VirtualBox shared folder: + sudo mount -t vboxsf shared_folder /mnt/shared + + 2. Run the reproducer: + python3 -c ' + import mmap, os + with open("/tmp/src.bin", "wb") as f: + f.write(b"A" * 65536) + with open("/tmp/src.bin", "rb") as f: + mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) + with open("/mnt/shared/test.bin", "wb") as out: + out.write(mm[:4096]) + print("Written:", os.path.getsize("/mnt/shared/test.bin")) + ' + + Verification criteria: + - Unpatched kernel: + The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". + - Patched kernel: + The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. + + [ Where problems could occur ] + + The change is strictly isolated to the write_end handler in + fs/vboxsf/file.c. + + In the standard case where copied == len, behavior is completely + identical. In the case where copied < len or copied == 0, the driver now + accurately conforms to the VFS address_space_operations contract by + reporting actual progress instead of fabricating a successful write. + + Potential regression risk is very low. If any side effects were to + occur, they would be strictly confined to writes on vboxsf mount points + and would not impact other filesystems or core kernel memory management. + + [ Other Info ] + + The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. + The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: + - Resolute (7.0 kernel, folio-based) + - Noble (6.8 kernel, page-based) + - Jammy (5.15 kernel, page-based) + Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: New Bug description: SRU Justification: [ Impact ] In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to a file from memory pages that have not been faulted into the process page table causes the write path to enter an infinite loop. The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 Furthermore, if the target page/folio is already marked uptodate in the page cache, un-copied ranges are not zeroed, which causes vboxsf to write stale page cache contents to the host, resulting in silent data corruption. This condition is reliably triggered by applications that write directly from an mmap of another file or from shared memory without touching the pages first. For example, virtiofsd (used in nested virtualisation workloads, container runtimes, and developer sandboxes) operates in this manner and triggers the failure immediately. [ Fix ] In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: u32 nwritten = len; When a short copy occurs (copied < len, or copied == 0 due to an un- faulted page), the driver incorrectly wrote 'len' bytes to the host and returned 'len' to the VFS write loop. As a result, generic_perform_write() never invoked fault_in_iov_iter_readable(), advanced the file position by 'len' without advancing the user iterator, and looped endlessly. The fix applies two changes: 1. Initialise nwritten with the actually copied byte count: u32 nwritten = copied; 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. [ Test Plan ] A minimal test using Python writes from an un-faulted mmap buffer into a vboxsf mount: 1. Mount a VirtualBox shared folder: sudo mount -t vboxsf shared_folder /mnt/shared 2. Run the reproducer: python3 -c ' import mmap, os with open("/tmp/src.bin", "wb") as f: f.write(b"A" * 65536) with open("/tmp/src.bin", "rb") as f: mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) with open("/mnt/shared/test.bin", "wb") as out: out.write(mm[:4096]) print("Written:", os.path.getsize("/mnt/shared/test.bin")) ' Verification criteria: - Unpatched kernel: The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". - Patched kernel: The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. [ Where problems could occur ] The change is strictly isolated to the write_end handler in fs/vboxsf/file.c. In the standard case where copied == len, behavior is completely identical. In the case where copied < len or copied == 0, the driver now accurately conforms to the VFS address_space_operations contract by reporting actual progress instead of fabricating a successful write. Potential regression risk is very low. If any side effects were to occur, they would be strictly confined to writes on vboxsf mount points and would not impact other filesystems or core kernel memory management. [ Other Info ] The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: - Resolute (7.0 kernel, folio-based) - Noble (6.8 kernel, page-based) - Jammy (5.15 kernel, page-based) Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions

[Bug 2167785] [NEW] ethernet connection breaks after wakeup

Public bug reported: Intel I226-V Ethernet fails after suspend/resume on Ubuntu 26.04. Hardware: Intel I226-V [8086:125c], rev 06 Driver: igc Kernel: 7.0.0-31-generic Steps: 1. Ethernet works normally. 2. Suspend system. 3. Resume. 4. eno2 becomes unavailable and Ethernet does not reconnect. 5. Reloading the igc module restores the interface: sudo modprobe -r igc sudo modprobe igc After reload, carrier returns, NetworkManager obtains DHCP address 192.168.1.10, and Ethernet works normally. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 09:57:59 2026 InstallationDate: Installed on 2026-09-18 (2 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlo1Link: Not connected. MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=6f7598f7-82dc-4ea2-9204-aa3d9d9687ee ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/28/2023 dmi.bios.release: 4.4 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0404 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z790-F GAMING WIFI II dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0404:bd09/28/2023:br4.4:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ790-FGAMINGWIFIII:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS ** 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/2167785 Title: ethernet connection breaks after wakeup Status in linux package in Ubuntu: New Bug description: Intel I226-V Ethernet fails after suspend/resume on Ubuntu 26.04. Hardware: Intel I226-V [8086:125c], rev 06 Driver: igc Kernel: 7.0.0-31-generic Steps: 1. Ethernet works normally. 2. Suspend system. 3. Resume. 4. eno2 becomes unavailable and Ethernet does not reconnect. 5. Reloading the igc module restores the interface: sudo modprobe -r igc sudo modprobe igc After reload, carrier returns, NetworkManager obtains DHCP address 192.168.1.10, and Ethernet works normally. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 09:57:59 2026 InstallationDate: Installed on 2026-09-18 (2 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlo1Link: Not connected. MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=6f7598f7-82dc-4ea2-9204-aa3d9d9687ee ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/28/2023 dmi.bios.release: 4.4 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0404 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z790-F GAMING WIFI II dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0404:bd09/28/2023:br4.4:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ790-FGAMINGWIFIII:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167785/+subscriptions

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

## Update (2026-09-20): failure rate has jumped — 5 hangs in 8 days, 0 in the previous 4 weeks; two more silent freezes on plain s2idle suspend entry Two more hangs on 2026-09-19, both on a plain suspend (no hibernate involved in the failing step), same signature as before: journal ends right after "PM: suspend entry (s2idle)", keyboard backlight stays lit, no reaction to any key/power short-press, hard power-off required. Next boot: dirty EFI partition, systemd-journald "corrupted or uncleanly shut down", orphan inode cleanup. - 10:12:39 — second suspend request issued 6 s after a very short first suspend (woken immediately by AC plug-in). It was a suspend-then-hibernate request (default 2h delay); the machine froze on s2idle entry itself, not at the RTC wake. - 20:42:03 — suspend requested 16 s after a successful 1h42 suspend/resume. Machine stayed frozen ~9.5 h until a forced reboot. ## Statistics (journal analysis, 450 suspend/hibernate entry/exit events since 2026-08-15) - Suspend/hibernate entries issued < 60 s after a resume: 104, of which 2 failed (both on 2026-09-19). - All other entries: 123, of which 3 failed (2026-09-12 hibernate, 2026-09-14 suspend, 2026-09-16 hibernate). - So a quick re-suspend after a resume is NOT the trigger (~2% failure rate in both groups). - However, there were **zero failures from 2026-08-15 to 2026-09-11, then 5 failures between 2026-09-12 and 2026-09-19** (roughly one per day). They happen on 7.0.0-27 and 7.0.0-31, before and after the BIOS update to 1.29.0. No firmware, graphics stack or systemd package was updated before the first failure of the series (packages updated 08-09/09: libc, perl, gnupg, curl...; 13/09: kernel 7.0.0-31, wireless-regdb). I cannot find what changed around 2026-09-12. The failures leave no usable trace (kernel is frozen before it can log; last minutes of journal are lost on power-off), so I cannot narrow the cause further from logs alone. Happy to test patches/parameters or run a debug kernel if useful (netconsole/serial capture is possible if requested). ## Hardware/software (unchanged) Dell Inspiron 14 5425, AMD Ryzen 7 5825U, AMD Barcelo iGPU (amdgpu), BIOS 1.29.0, kernel 7.0.0-31-generic, Ubuntu, KDE Plasma 6.5, Wayland. `HibernateMode=shutdown` workaround applied since 2026-09-16. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161312 Title: System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works fine on 7.0.0-27 Status in linux package in Ubuntu: New Bug description: Hello Here is a bug occurring on my laptop. The analysis is from claude code. I hope it is relevant & complete. Thanks for your help. Summary System hangs permanently when entering suspend (s2idle) on kernel 7.0.0-28-generic; requires a hard power-off to recover. The exact same hardware suspended and resumed reliably dozens of times over 8 days on kernel 7.0.0-27-generic. The regression appeared immediately after the machine booted 7.0.0-28 for the first time — first suspend attempt on the new kernel already failed, and it failed again on the next boot. Hardware Machine: Dell Inspiron 14 5425 CPU: AMD Ryzen 7 5825U with Radeon Graphics GPU: AMD/ATI Barcelo iGPU (integrated, PCI 04:00.0) BIOS: 1.19.0 (2024-09-10) Sleep mode: only s2idle is offered by the platform (/sys/power/mem_sleep → [s2idle], no deep/S3 option available) Software Ubuntu 25.10 (Questing Quokka), KDE Plasma 6.5, Wayland session (kwin_wayland) Working kernel: linux-image-7.0.0-27-generic (7.0.0-27.27) Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28) Steps to reproduce Boot into 7.0.0-28-generic. Trigger suspend (via systemd Suspend action / closing lid / GUI power menu). System freezes during or immediately after suspend entry: keyboard backlight stays lit, no reaction to any key or the power button short-press, screen never turns back on. Only recovery is holding the power button for a hard shutdown. Expected behavior System suspends and resumes normally, as it did consistently on 7.0.0-27-generic. Actual behavior System never comes back from suspend. journalctl shows the boot ending abruptly right after suspend entry, with no PM: suspend exit line and no orderly shutdown sequence — consistent with a full system hang, not a clean poweroff. Evidence from journalctl Working kernel (7.0.0-27), representative sample out of ~40 successful cycles between 2026-07-09 and 2026-07-17: juil. 16 19:31:46 kernel: PM: suspend entry (s2idle) juil. 17 14:48:21 kernel: PM: suspend exit Failing kernel (7.0.0-28), first attempt, boot ends here with no further log lines at all: juil. 20 10:42:38 root[18433]: Dell wakeup sources disabled - ALL including dock disconnect juil. 20 10:42:38 systemd-sleep[18388]: Performing sleep operation 'suspend'... juil. 20 10:42:38 kernel: PM: suspend entry (s2idle) [-- nothing further; next boot is a cold boot, not a resume --] Failing kernel (7.0.0-28), second attempt on a fresh boot, same pattern: juil. 20 12:32:59 systemd-sleep[26074]: Performing sleep operation 'suspend'... juil. 20 12:32:59 kernel: PM: suspend entry (s2idle) [-- nothing further --] Both failing boots are followed by a fresh cold boot (new boot ID in journalctl --list-boots), confirming the machine was hard power-cycled rather than resuming. Workaround Pinning the system to linux-image-7.0.0-27-generic (apt-mark hold) restores reliable suspend/resume. Additional notes A local dell-suspend-fix.service (disables PCI/USB/BT/WMI wakeup sources before sleep, standard workaround for this laptop's dock/eSATA wake-on-disconnect quirk) is present and unchanged across both the working and failing kernel — ruling it out as the cause. Not the known 7.0.0-28.28 AMDGPU/HMM ROCm performance regression (that one is a slowdown in compute workloads, not a hang) — this appears to be a separate, undocumented issue in the same kernel build. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Mon Jul 20 14:19:25 2026 InstallationDate: Installed on 2025-07-09 (376 days ago) InstallationMedia: Kubuntu 25.04 "Plucky Puffin" - Release amd64 (20250417) IwDevWlp3s0Link: Not connected. MachineType: Dell Inc. Inspiron 14 5425 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=b239c123-a9a4-4924-bfc7-38c39f92e79b ro quiet splash acpi_backlight=native resume=UUID=871f8b5f-e842-4660-9c64-7661287c3695 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-07-09 (11 days ago) dmi.bios.date: 09/10/2024 dmi.bios.release: 1.19 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.19.0 dmi.board.name: 0J9C2M dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.19.0 dmi.modalias: dmi:bvnDellInc.:bvr1.19.0:bd09/10/2024:br1.19:svnDellInc.:pnInspiron145425:pvr1.19.0:rvnDellInc.:rn0J9C2M:rvrA00:cvnDellInc.:ct10:cvr1.19.0:sku0B46:pfaInspiron: dmi.product.family: Inspiron dmi.product.name: Inspiron 14 5425 dmi.product.sku: 0B46 dmi.product.version: 1.19.0 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161312/+subscriptions

[Bug 2167764] Re: thunderbolt.host_reset=1 default tears down pre-boot UEFI PCIe tunnels, breaking external NVMe direct boot over USB4

** Description changed: Package: linux (Ubuntu) Source Package: linux - Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS / 24.04 HWE / 24.10) + Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS Resolute / 24.04 HWE) Upstream Subsystem: drivers/thunderbolt/ (Native Host Interface & Software Connection Manager) - Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Ryzen 6000/7000/8000 USB4 routers, ASMedia ASM2464PD, Intel Goshen Ridge / Titan Ridge bridges, and external PCIe NVMe direct-boot topologies. + Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Hawk Point / Phoenix USB4 Host Interface [1022:1502 / 1022:1669], ASMedia ASM2464PD, and external PCIe NVMe direct-boot topologies. + Related Bug Trackers: Launchpad Bug #2078573 (Dell Latitude 5550), Bug #2159575 (ASUS Zenbook 14, dracut), Bug #2167764. + Upstream Commits: 59a54c5f3dbd & 0fc70886569c (Stable backport cc4c94a5f6c4). + Related Issue: CVE-2024-53194 (Use-after-free in pciehp on hot remove). ================================================================================ - 1. SUMMARY OF THE DEFECT + 1. SUMMARY OF THE OBSERVATION ================================================================================ - When direct-booting Linux from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and builds the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. + When booting Linux directly from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and establishes the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. However, during early kernel initialization inside the initramfs, - thunderbolt.ko issues an unconditional Host Router Reset - (host_reset=true). This severs the pre-boot PCIe tunnel mid-boot, - causing nvme_probe() to encounter Master Abort (0xFFFFFFFF) and return - terminal error -ENODEV. Because the Linux driver core does not re-probe - devices that failed with -ENODEV, the root filesystem device disappears - permanently from the kernel bus, causing an initramfs timeout and - emergency rescue shell drop ("Gave up waiting for root file system - device"). + thunderbolt.ko issues a Host Router Reset (host_reset=true). This drops + the pre-boot PCIe tunnel mid-boot, causing nvme_probe() to encounter + Master Abort (0xFFFFFFFF) and return terminal error -ENODEV. Because the + storage controller is disconnected during initial bus enumeration, the + root filesystem is not discovered, dropping the system into an emergency + rescue shell ("Gave up waiting for root file system device" / "Warning: + /dev/disk/by-uuid/<UUID> does not exist"). ================================================================================ - 2. FORENSIC ROOT CAUSE: THE TEARDOWN CASCADE + 2. TECHNICAL SEQUENCE DURING EARLY BOOT ================================================================================ - Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c isolates the exact sequence: - + Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c details the timing: 1. nhi_probe() (drivers/thunderbolt/nhi.c:1249): - Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898): - iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); - This asserts a hardware Host Router Reset. Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is de-asserted, physically cutting the PCIe tunnel. - + Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898). Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is cleared, dropping the pre-boot PCIe tunnel. The Root Port clears Presence Detect State (PDS) and DL_Active. 2. tb_start() (drivers/thunderbolt/tb.c:3066-3070): - nhi_probe() invokes tb_domain_add(tb, host_reset), which calls tb_start(tb, reset = true). - tb_start() enforces: - if (reset && tb_switch_is_usb4(tb->root_switch)) { - discover = false; - if (usb4_switch_version(tb->root_switch) == 1) - tb_switch_reset(tb->root_switch); - } - Because discover is set to false, tb_discover_tunnels() and tb_scan_switch() are completely bypassed. - - 3. Asynchronous Driver Collision (drivers/nvme/host/pci.c): - Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot ACPI/PCI address. Because the tunnel has been severed: - nvme 0000:06:00.0: Unable to change power state from D3cold to D0, device inaccessible - nvme 0000:06:00.0: error -ENODEV: probe failed - Under Linux driver core semantics, an endpoint that fails probe with -ENODEV is never re-probed. Even when thunderbolt.ko eventually re-enumerates the enclosure seconds later, it generates thunderbolt bus uevents, not PCI bus uevents. The root partition UUID is never detected by dracut/systemd, rendering 'rootdelay=' parameters ineffective. + Because reset == true, tb_start() sets discover = false, bypassing native tunnel discovery (tb_discover_tunnels()). + 3. Driver Probing Timing (drivers/nvme/host/pci.c): + Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot address while the link is down. It receives Master Abort and returns terminal error -ENODEV. Under standard Linux driver core semantics, an endpoint that fails probing with -ENODEV is not automatically re-probed. ================================================================================ - 3. EMPIRICAL HARDWARE PROOF: BUILT-IN ADOPTION ALREADY EXISTS + 3. OBSERVATIONS ON USERSPACE AUTHORIZATION VS. IN-KERNEL TUNNEL PRESERVATION ================================================================================ - Empirical testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASM2464PD) proves that the Thunderbolt driver ALREADY POSSESSES complete architectural infrastructure to support pre-boot boot tunnels. + In Launchpad Bug #2078573, an initial hypothesis was considered where userspace tooling (such as boltd or udev rules inside the initramfs) might handle re-authorizing the device after the reset. - When booted with 'thunderbolt.host_reset=0': - - nhi_reset() is bypassed: the hardware PCIe tunnel remains uninterrupted. - - tb_start() retains discover = true. - - tb_discover_tunnels() executes tb_tunnel_discover_pci(), locates the active pre-boot PCIe tunnel, and marks intermediate switches as parent->boot = true. - - In tb_scan_finalize_switch(), sw->boot triggers automated switch authorization (sw->authorized = 1) before userspace uevents fire. - - Live sysfs telemetry confirms pre-boot adoption: - $ cat /sys/bus/thunderbolt/devices/0-1/boot - 1 - $ cat /sys/bus/thunderbolt/devices/0-1/authorized - 1 - - Performance & Flash Endurance when tunnel is preserved: - - PCIe Gen 4.0 x4 at 16.0 GT/s (~64 Gbps physical link). - - Buffered disk read: 3,587.60 MB/s; Direct sequential write: 2,024.33 MB/s. - - Host Memory Buffer (HMB): 64 MB host DDR5 RAM allocated via Intel VT-d IOMMU (Write Amplification Factor drops from 6.80 under UASP to 1.88 under native NVMe, extending NAND endurance by 72%). - - The default 'host_reset=true' policy simply short-circuits this - functional subsystem. + However, subsequent testing from duplicate Bug #2159575 (ASUS Zenbook 14 running Ubuntu 26.04 LTS Resolute on dracut) provides useful insights: + 1. Testing on Dracut: When testing Ubuntu 26.04 with dracut 110-11, the same early boot timeout occurred out of the box, showing that initramfs tooling updates alone do not resolve the timing race. + 2. PCI Driver Core Probe Lifecycle: In the initramfs emergency shell of Bug #2159575, reporter Lucas observed that manually authorizing the switch (echo 1 > /sys/bus/thunderbolt/.../authorized) did not bring up the NVMe device until followed by an explicit 'echo 1 > /sys/bus/pci/rescan'. Because bolt focuses strictly on domain security (/sys/bus/thunderbolt) and does not issue PCI bus rescans, handling this in userspace requires coordinating udev rules, D-Bus, and secondary bus rescans during early boot. + 3. In-Tree Discovery Logic: drivers/thunderbolt/tb.c already contains native infrastructure to discover pre-boot tunnels (tb_discover_tunnels()), which marks sw->boot = true and auto-authorizes devices in-kernel (sw->authorized = 1). When booted with 'thunderbolt.host_reset=0', this discovery path executes naturally, preserving the boot device without requiring userspace services. ================================================================================ - 4. UPSTREAM COMMIT GENEALOGY & MAINTAINER ASSUMPTIONS + 4. HARDWARE VERIFICATION & SILICON TELEMETRY ================================================================================ - - Commit 0fc70886569c (Mika Westerberg, Dec 2022): Introduced USB4 v2 host router reset via REG_RESET_HRR. - - Commit 59a54c5f3dbd (Sanath S / Mario Limonciello, Jan 2024): Defaulted host_reset to true to clear suboptimal boot firmware DisplayPort bandwidth tunnels (HBR2 vs HBR3) and reclaim exhausted AMD PCIe BAR space for docking stations. - - Commit 6faa39eea953 (Mika Westerberg, Feb 2024): Cemented 'discover = false' for USB4 host routers. - - Upstream maintainers operated under the unexamined assumption that all - USB4 devices are secondary, hotpluggable peripherals mounted after the - OS has booted from internal storage. They were unaware that the running - root filesystem could reside on the pre-boot PCIe tunnel. - - Related Vulnerability: CVE-2024-53194 documents how commits 0fc70886569c - and 59a54c5f3dbd cause unexpected PCIe presence drops triggering use- - after-free crashes in pciehp. + Testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASMedia ASM2464PD) confirms that preserving pre-boot tunnels maintains complete stability: + - With 'thunderbolt.host_reset=0': + * nhi_reset() is bypassed; hardware PCIe tunnel remains uninterrupted. + * tb_start() retains discover = true. + * tb_discover_tunnels() detects the pre-boot PCIe tunnel, sets parent->boot = true, and auto-authorizes the switch (sw->authorized = 1). + - Telemetry: + $ cat /sys/bus/thunderbolt/devices/0-1/boot -> 1 + $ cat /sys/bus/thunderbolt/devices/0-1/authorized -> 1 + - Performance: + * PCIe Gen 4 x4 link at 16.0 GT/s (~64 Gbps physical link). + * Buffered read: 3,587.60 MB/s; Direct write: 2,024.33 MB/s. + * Host Memory Buffer (HMB): 64 MB host DDR5 RAM cleanly allocated via Intel VT-d IOMMU (WAF dropped from 6.80 to 1.88, significantly extending NAND lifespan). ================================================================================ - 5. TESTED WORKAROUND (IMMEDIATE MITIGATION FOR USERS) + 5. PROPOSED UPSTREAM LINUX KERNEL PATCH ================================================================================ - Affected users direct-booting over USB4/TB4 can immediately work around the failure without recompiling the kernel by appending the following to GRUB_CMDLINE_LINUX in /etc/default/grub (or /etc/default/grub.d/99-usb4.cfg): + To allow the driver to distinguish between hotpluggable accessories (which benefit from a clean reset for DisplayPort renegotiation or MMIO allocation) and active boot storage (which must not be severed), drivers/thunderbolt/ can check whether an active pre-boot PCIe tunnel is present before issuing the reset: - thunderbolt.host_reset=0 thunderbolt.clx=0 pcie_port_pm=off - - Notes on parameters: - - thunderbolt.host_reset=0: Preserves the pre-boot UEFI PCIe tunnel across kernel handover. - - thunderbolt.clx=0 & pcie_port_pm=off: Prevents low-power link state retraining drops during early initqueue settling (may increase idle power draw by 1–3W on battery). - - ASM2464PD Retimer Cold Reset: If transitioning between ports or warm reboots fails to detect the drive in BIOS, a 30-second flea-power discharge (unplug AC, hold power button 30s) resets the high-speed retimer PHY state. - - ================================================================================ - 6. PROPOSED UPSTREAM LINUX KERNEL PATCH - ================================================================================ - We propose a two-tier safety guard in drivers/thunderbolt/: - 1. In nhi.c (nhi_has_active_boot_device()): Before issuing REG_RESET_HRR, check if sibling PCIe bridges on the root bus (external-facing or Thunderbolt ports) have active child devices populated by boot firmware. If active downstream devices exist, skip nhi_reset() and clear host_reset. - 2. In tb.c (tb_switch_has_active_pcie_tunnel()): In tb_start(), inspect whether any PCIe downstream adapter is enabled by boot firmware (tb_pci_port_is_enabled()). If active PCIe boot tunnels exist, do not set discover = false and do not reset the router. Allow tb_discover_tunnels() to adopt and authorize the boot storage. - - Engineering Suite & LKML Proposal Repository: - - GitHub: https://github.com/StickwoodJr/usb4-nvme-direct-boot - - Full Patch: https://github.com/StickwoodJr/usb4-nvme-direct-boot/blob/main/patches/0001-thunderbolt-preserve-pre-boot-pcie-tunnels.patch - - Automated Patch Verification Tool: scripts/apply_kernel_patch.sh (--check / --apply / --reverse) - - ```diff --- a/drivers/thunderbolt/nhi.c +++ b/drivers/thunderbolt/nhi.c @@ -1158,6 +1158,11 @@ static void nhi_reset(struct tb_nhi *nhi) return; } + if (nhi_has_active_boot_device(nhi)) { + dev_info(nhi->dev, "preserving pre-boot PCIe tunnel for active boot device\n"); + return; + } + iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); msleep(100); - + } --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -3059,6 +3077,11 @@ static int tb_start(struct tb *tb, bool reset) tb_switch_tmu_enable(tb->root_switch); + if (tb_switch_has_active_pcie_tunnel(tb->root_switch)) { + tb_info(tb, "active PCIe boot tunnel detected, preserving topology\n"); + reset = false; + } + if (reset && tb_switch_is_usb4(tb->root_switch)) { discover = false; + if (usb4_switch_version(tb->root_switch) == 1) + + Reference standalone patch, tests, and packaging: + https://github.com/StickwoodJr/usb4-nvme-direct-boot + + ================================================================================ + 6. SUGGESTIONS FOR THE UBUNTU KERNEL TEAM + ================================================================================ + 1. Re-evaluate Launchpad Bug #2078573 under linux (Ubuntu): + Consider re-opening the kernel task in light of the -ENODEV probe timing findings and dracut test results, which indicate that kernel-side tunnel preservation is more robust than userspace initramfs hooks. + 2. Consider In-Kernel Tunnel Preservation: + Evaluate adopting conditional checks for active boot tunnels or documenting thunderbolt.host_reset=0 as the recommended setting for external direct-boot environments. + 3. Documentation: + Help provide guidance in Ubuntu release notes or documentation for users running external direct-boot NVMe configurations over USB4 / Thunderbolt. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167764 Title: thunderbolt.host_reset=1 default tears down pre-boot UEFI PCIe tunnels, breaking external NVMe direct boot over USB4 Status in linux package in Ubuntu: New Bug description: Package: linux (Ubuntu) Source Package: linux Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS Resolute / 24.04 HWE) Upstream Subsystem: drivers/thunderbolt/ (Native Host Interface & Software Connection Manager) Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Hawk Point / Phoenix USB4 Host Interface [1022:1502 / 1022:1669], ASMedia ASM2464PD, and external PCIe NVMe direct-boot topologies. Related Bug Trackers: Launchpad Bug #2078573 (Dell Latitude 5550), Bug #2159575 (ASUS Zenbook 14, dracut), Bug #2167764. Upstream Commits: 59a54c5f3dbd & 0fc70886569c (Stable backport cc4c94a5f6c4). Related Issue: CVE-2024-53194 (Use-after-free in pciehp on hot remove). ================================================================================ 1. SUMMARY OF THE OBSERVATION ================================================================================ When booting Linux directly from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and establishes the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. However, during early kernel initialization inside the initramfs, thunderbolt.ko issues a Host Router Reset (host_reset=true). This drops the pre-boot PCIe tunnel mid-boot, causing nvme_probe() to encounter Master Abort (0xFFFFFFFF) and return terminal error -ENODEV. Because the storage controller is disconnected during initial bus enumeration, the root filesystem is not discovered, dropping the system into an emergency rescue shell ("Gave up waiting for root file system device" / "Warning: /dev/disk/by-uuid/<UUID> does not exist"). ================================================================================ 2. TECHNICAL SEQUENCE DURING EARLY BOOT ================================================================================ Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c details the timing: 1. nhi_probe() (drivers/thunderbolt/nhi.c:1249): Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898). Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is cleared, dropping the pre-boot PCIe tunnel. The Root Port clears Presence Detect State (PDS) and DL_Active. 2. tb_start() (drivers/thunderbolt/tb.c:3066-3070): Because reset == true, tb_start() sets discover = false, bypassing native tunnel discovery (tb_discover_tunnels()). 3. Driver Probing Timing (drivers/nvme/host/pci.c): Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot address while the link is down. It receives Master Abort and returns terminal error -ENODEV. Under standard Linux driver core semantics, an endpoint that fails probing with -ENODEV is not automatically re-probed. ================================================================================ 3. OBSERVATIONS ON USERSPACE AUTHORIZATION VS. IN-KERNEL TUNNEL PRESERVATION ================================================================================ In Launchpad Bug #2078573, an initial hypothesis was considered where userspace tooling (such as boltd or udev rules inside the initramfs) might handle re-authorizing the device after the reset. However, subsequent testing from duplicate Bug #2159575 (ASUS Zenbook 14 running Ubuntu 26.04 LTS Resolute on dracut) provides useful insights: 1. Testing on Dracut: When testing Ubuntu 26.04 with dracut 110-11, the same early boot timeout occurred out of the box, showing that initramfs tooling updates alone do not resolve the timing race. 2. PCI Driver Core Probe Lifecycle: In the initramfs emergency shell of Bug #2159575, reporter Lucas observed that manually authorizing the switch (echo 1 > /sys/bus/thunderbolt/.../authorized) did not bring up the NVMe device until followed by an explicit 'echo 1 > /sys/bus/pci/rescan'. Because bolt focuses strictly on domain security (/sys/bus/thunderbolt) and does not issue PCI bus rescans, handling this in userspace requires coordinating udev rules, D-Bus, and secondary bus rescans during early boot. 3. In-Tree Discovery Logic: drivers/thunderbolt/tb.c already contains native infrastructure to discover pre-boot tunnels (tb_discover_tunnels()), which marks sw->boot = true and auto-authorizes devices in-kernel (sw->authorized = 1). When booted with 'thunderbolt.host_reset=0', this discovery path executes naturally, preserving the boot device without requiring userspace services. ================================================================================ 4. HARDWARE VERIFICATION & SILICON TELEMETRY ================================================================================ Testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASMedia ASM2464PD) confirms that preserving pre-boot tunnels maintains complete stability: - With 'thunderbolt.host_reset=0': * nhi_reset() is bypassed; hardware PCIe tunnel remains uninterrupted. * tb_start() retains discover = true. * tb_discover_tunnels() detects the pre-boot PCIe tunnel, sets parent->boot = true, and auto-authorizes the switch (sw->authorized = 1). - Telemetry: $ cat /sys/bus/thunderbolt/devices/0-1/boot -> 1 $ cat /sys/bus/thunderbolt/devices/0-1/authorized -> 1 - Performance: * PCIe Gen 4 x4 link at 16.0 GT/s (~64 Gbps physical link). * Buffered read: 3,587.60 MB/s; Direct write: 2,024.33 MB/s. * Host Memory Buffer (HMB): 64 MB host DDR5 RAM cleanly allocated via Intel VT-d IOMMU (WAF dropped from 6.80 to 1.88, significantly extending NAND lifespan). ================================================================================ 5. PROPOSED UPSTREAM LINUX KERNEL PATCH ================================================================================ To allow the driver to distinguish between hotpluggable accessories (which benefit from a clean reset for DisplayPort renegotiation or MMIO allocation) and active boot storage (which must not be severed), drivers/thunderbolt/ can check whether an active pre-boot PCIe tunnel is present before issuing the reset: --- a/drivers/thunderbolt/nhi.c +++ b/drivers/thunderbolt/nhi.c @@ -1158,6 +1158,11 @@ static void nhi_reset(struct tb_nhi *nhi) return; } + if (nhi_has_active_boot_device(nhi)) { + dev_info(nhi->dev, "preserving pre-boot PCIe tunnel for active boot device\n"); + return; + } + iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); msleep(100); } --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -3059,6 +3077,11 @@ static int tb_start(struct tb *tb, bool reset) tb_switch_tmu_enable(tb->root_switch); + if (tb_switch_has_active_pcie_tunnel(tb->root_switch)) { + tb_info(tb, "active PCIe boot tunnel detected, preserving topology\n"); + reset = false; + } + if (reset && tb_switch_is_usb4(tb->root_switch)) { discover = false; if (usb4_switch_version(tb->root_switch) == 1) Reference standalone patch, tests, and packaging: https://github.com/StickwoodJr/usb4-nvme-direct-boot ================================================================================ 6. SUGGESTIONS FOR THE UBUNTU KERNEL TEAM ================================================================================ 1. Re-evaluate Launchpad Bug #2078573 under linux (Ubuntu): Consider re-opening the kernel task in light of the -ENODEV probe timing findings and dracut test results, which indicate that kernel-side tunnel preservation is more robust than userspace initramfs hooks. 2. Consider In-Kernel Tunnel Preservation: Evaluate adopting conditional checks for active boot tunnels or documenting thunderbolt.host_reset=0 as the recommended setting for external direct-boot environments. 3. Documentation: Help provide guidance in Ubuntu release notes or documentation for users running external direct-boot NVMe configurations over USB4 / Thunderbolt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167764/+subscriptions

[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: New Bug description: [Summary] Writing to a VirtualBox shared folder (vboxsf) from pages that have not been faulted in makes the in-kernel vboxsf driver loop forever: the target file keeps growing with zeroed data until the disk is full, the writing process only dies on SIGKILL, and the log fills up with WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 In my case ~16 GB of logs were written before the guest ran out of space. [Root cause] vboxsf_write_end() ignores "copied": it writes the full requested length to the host and returns that length even when copied == 0, so generic_perform_write() never faults the source pages in, advances pos and loops forever. The same accounting bug can silently corrupt data when the folio is already uptodate. [Upstream] Patch submitted to the vboxsf maintainer and linux-fsdevel on 2026-09-19: https://lore.kernel.org/linux-fsdevel/20260919174136.3325-1-k.shiomi@techhowto.blog/ A DKMS package with the patch (and a guard that refuses to mount shared folders unless the patched module is loaded) is available at https://github.com/kentaro-shiomi/virtualbox-vboxsf-endless-write-loop-fix [Trigger] Programs that write straight from an mmap of another file or from shared memory without reading it first. virtiofsd does exactly this, so running a nested VM whose working directory lives on a vboxsf mount hits it immediately. Ordinary applications write from buffers they have just filled and are not affected. [Environment] Ubuntu 26.04.1, kernel 7.0.0-31-generic, guest of VirtualBox 7.2.16 on a Windows 11 host. The faulty code is identical in Linux v7.0 and in master as of 2026-09. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions

[Bug 2159581] Re: Audio regression: No internal speaker sound over sof-soundwire (headphone jack works) on Intel Panther Lake layout

[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159581 Title: Audio regression: No internal speaker sound over sof-soundwire (headphone jack works) on Intel Panther Lake layout Status in linux package in Ubuntu: Expired Bug description: SoundWire subsystem detects internal endpoints cleanly as "Speakers - sof-soundwire". Userspace audio mixers fluctuate dynamically showing active playback, but the physical internal speaker amplifiers remain completely silent. The onboard headphone jack (HDA) works flawlessly. System is running Ubuntu 26.04 with kernel 7.0.0-generic. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: fpm 4351 F.... wireplumber /dev/snd/seq: fpm 4331 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jul 4 19:06:12 2026 InstallationDate: Installed on 2026-07-04 (0 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: Micro-Star International Co., Ltd. Prestige 16 AI+ C3MTG ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 xedrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=51afb7b2-3a6b-47e2-bef2-80c2eea73664 ro quiet splash xe.force_probe=b080 xe.enable_psr=0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/25/2026 dmi.bios.release: 1.21 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E2622IMS.115 dmi.board.asset.tag: Default string dmi.board.name: MS-2622 dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: REV:1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE2622IMS.115:bd03/25/2026:br1.21:svnMicro-StarInternationalCo.,Ltd.:pnPrestige16AI+C3MTG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-2622:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct10:cvrN/A:sku2622.1:pfaPrestige: dmi.product.family: Prestige dmi.product.name: Prestige 16 AI+ C3MTG dmi.product.sku: 2622.1 dmi.product.version: REV:1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159581/+subscriptions