I can confirm this regression on an ASUS X302LA (Intel Broadwell, 5th generation). Linux Mint 22.3 (based on Ubuntu 24.04). Kernel 6.17.0-35 resumes correctly from suspend. Kernel 7.0.0-28 resumes with a black internal display while the system continues to run normally. An external HDMI monitor works correctly after resume. Using mem_sleep=s2idle avoids the problem, while deep reproduces it every time. I also tested i915.enable_psr=0 and i915.enable_dc=0 without improvement. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161243 Title: System fails to resume from suspend (black screen) on kernel 7.0.0-28-generic; works correctly on 7.0.0-27-generic Status in linux package in Ubuntu: Confirmed Bug description: ThinkPad X1 Carbon 5th gen (Intel Kaby Lake iGPU, device ID 5916, i915 driver), Ubuntu 26.04, GNOME Shell 50.1 on Wayland. After suspend (mem_sleep = deep/S3), the system fails to wake: screen remains black, but the system is otherwise alive — keyboard backlight and fan resume, Caps Lock LED responds correctly to keypresses. VT switching (Ctrl+Alt+F3 → F1) does not restore display output. journalctl shows a clean suspend/resume cycle with no errors: PM: suspend entry (deep) ... ACPI: PM: Low-level resume complete PM: suspend exit No i915/DRM errors appear in logs around resume. Steps to reproduce: Suspend the system (lid close or systemctl suspend) Attempt to resume Expected: Display returns after resume Actual: Screen stays black; hard power-off required Regression testing: Kernel 7.0.0-28-generic: fails to resume, every time Kernel 7.0.0-27-generic: resumes correctly, every time (confirmed via GRUB advanced boot, multiple suspend/resume cycles) This strongly suggests a regression introduced between -27 and -28 affecting i915/display resume on this platform, not a hardware, ACPI, or compositor issue. Also tried, no effect: i915.enable_dc=0 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 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: 2446 F.... wireplumber /dev/snd/seq: 2442 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Jul 19 08:34:05 2026 HibernationDevice: RESUME=UUID=45c7e173-c4f1-4da8-a583-246c71246f4a Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0a2b Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 13d3:5682 IMC Networks SunplusIT Integrated Camera Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: LENOVO 20HRCTO1WW ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=5008e1f7-16e4-4c95-9559-0993912a6970 ro quiet splash i915.enable_dc=0 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-05-25 (55 days ago) dmi.bios.date: 07/22/2024 dmi.bios.release: 1.63 dmi.bios.vendor: LENOVO dmi.bios.version: N1MET78W (1.63 ) dmi.board.asset.tag: Not Available dmi.board.name: 20HRCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrN1MET78W(1.63):bd07/22/2024:br1.63:efr1.22:svnLENOVO:pn20HRCTO1WW:pvrThinkPadX1Carbon5th:rvnLENOVO:rn20HRCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20HR_BU_Think_FM_ThinkPadX1Carbon5th:pfaThinkPadX1Carbon5th: dmi.product.family: ThinkPad X1 Carbon 5th dmi.product.name: 20HRCTO1WW dmi.product.sku: LENOVO_MT_20HR_BU_Think_FM_ThinkPad X1 Carbon 5th dmi.product.version: ThinkPad X1 Carbon 5th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161243/+subscriptions
четверг
[Bug 2156972] Re: Camera output is vague and color is abnormal
Verified linux-oem-7.0/7.0.0-1010.10. ** Tags removed: verification-needed-resolute-linux-oem-7.0 ** Tags added: verification-done-resolute-linux-oem-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156972 Title: Camera output is vague and color is abnormal Status in HWE Next: New Status in linux package in Ubuntu: In Progress Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Released Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Questing: Won't Fix Status in linux-oem-6.17 source package in Questing: Invalid Status in linux-oem-7.0 source package in Questing: Invalid Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux-oem-7.0 source package in Resolute: Fix Committed Status in linux source package in Stonking: In Progress Status in linux-oem-6.17 source package in Stonking: Invalid Status in linux-oem-7.0 source package in Stonking: Invalid Bug description: [SRU Justification] [Impact] The camera output is abnormal, and it takes longer time to start the camera. kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Payload checksum (CRC) error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Payload checksum (CRC) error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected [Fix] Upstream commit 477620dccf3e ("media: intel/ipu6: Improve DWC PHY HSFREQRANGE band selection for overlapping ranges") in v7.2-rc1 fixes commit 1e7eeb301696 ("media: intel/ipu6: add the CSI2 DPHY implementation") from v6.10. [Test Plan] 1. capture video stream and verify the video quality. $ gst-launch-1.0 v4l2src ! videoconvert ! avimux ! filesink location=out.avi 2. check no error found in dmesg $ sudo dmesg |grep intel_ipu6_isys [Where problems could occur] The regression can be considered as low, because the patch is meant to locate a band with higher osc_freq_target for best hardware utilization. No other part is touched. [Other Info] While this affects kernels >= v6.10, nominate for all the newer kernels. And since this is already in v7.2-rc1, skip Unstable. ========== original bug report ========== The camera output is abnormal, and it takes longer time to start the camera. I record the video by command: $ gst-launch-1.0 v4l2src ! videoconvert ! avimux ! filesink location=out.avi Some errors reported in the driver: kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Payload checksum (CRC) error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Payload checksum (CRC) error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Single packet header error corrected Proposed fix was in https://github.com/intel/ipu6-drivers/pull/447. This affects kernel v6.10 and up, which added D-PHY implementation in commit 1e7eeb301696 ("media: intel/ipu6: add the CSI2 DPHY implementation"). It's then submitted into upstream as commit 477620dccf3e ("media: intel/ipu6: Improve DWC PHY HSFREQRANGE band selection for overlapping ranges") in v7.2-rc1. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2156972/+subscriptions
[Bug 2161016] Re: [i915] External monitor no signal after resume (still appears connected, cursor moves there)
Update: Just now after resume the external Dell was stuck at 1024×768. Higher resolutions were not offered in Displays Settings. Toggling the display Off/On there did not restore the correct modes. Unplugging the cable and plugging it back in immediately restored the full resolution list and correct mode. I guess there is a resume-time link/EDID failure and the original “no signal but still connected” symptom was just a different manifestation. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161016 Title: [i915] External monitor no signal after resume (still appears connected, cursor moves there) Status in linux package in Ubuntu: New Bug description: Ubuntu 26.04, Wayland, Framework (Intel i915). After resume from sleep the external monitor shows no signal. GNOME still treats it as connected: cursor can be moved onto the external area and it appears in Displays Settings. Toggling the external display Off then On in Settings restores the image. I don't know how to easily reproduce it, but it just happened. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-134-generic 6.8.0-134.134 ProcVersionSignature: Ubuntu 6.8.0-134.134-generic 6.8.12 Uname: Linux 6.8.0-134-generic x86_64 ApportVersion: 2.28.2-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: beej 2915 F.... wireplumber /dev/snd/seq: beej 2910 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 16 15:22:50 2026 InstallationDate: Installed on 2023-09-13 (1037 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) MachineType: Framework Laptop ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-134-generic root=UUID=205f6f4d-6fcb-4438-8a9b-d2a2f2607288 ro quiet splash i915.enable_psr=0 vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-134-generic N/A linux-backports-modules-6.8.0-134-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/27/2022 dmi.bios.release: 3.17 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 03.17 dmi.board.asset.tag: * dmi.board.name: FRANBMCP0B dmi.board.vendor: Framework dmi.board.version: AB dmi.chassis.asset.tag: FRANBMCPAB139100ME dmi.chassis.type: 10 dmi.chassis.vendor: Framework dmi.chassis.version: AB dmi.modalias: dmi:bvnINSYDECorp.:bvr03.17:bd10/27/2022:br3.17:svnFramework:pnLaptop:pvrAB:rvnFramework:rnFRANBMCP0B:rvrAB:cvnFramework:ct10:cvrAB:skuFRANBMCP0B: dmi.product.family: FRANBMCP dmi.product.name: Laptop dmi.product.sku: FRANBMCP0B dmi.product.version: AB dmi.sys.vendor: Framework To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161016/+subscriptions
[Bug 2162139] [NEW] smsdvb generates an unbounded invalid sysfs_emit_at WARN storm with PX-S1UD (regression in Linux 6.6)
Public bug reported: # Summary Using a PLEX PX-S1UD ISDB-T USB tuner with Ubuntu's generic kernel causes `smsdvb` to repeatedly call `sysfs_emit_at()` with a non-page-aligned driver-owned debugfs buffer. Each ISDB-T statistics response produces kernel WARN traces. During normal Mirakurun operation this grew `/var/log/syslog` and `/var/log/kern.log` to about 101 GB each and filled the root filesystem. This is an upstream regression introduced by: ``` 2f7d0c94396e ("media: siano: Convert to use sysfs_emit_at() API") ``` Linux v6.5 uses `scnprintf()` in `smsdvb-debugfs.c`; v6.6 and later use `sysfs_emit_at()`. The current upstream source still contains the problematic calls. # Environment ``` Ubuntu 26.04 LTS (resolute) Ubuntu 7.0.0-28.28-generic 7.0.12 CONFIG_SMS_SIANO_DEBUGFS=y CONFIG_DEBUG_FS=y USB 3275:0080 VidzMedia/PLEX PX-S1UD Digital TV Tuner ``` The same `CONFIG_SMS_SIANO_DEBUGFS=y` setting is present in the official Ubuntu 22.04/5.15 and Ubuntu 24.04/6.8 generic kernel packages. The regression is caused by the upstream code change, not a recent Ubuntu config change. # Steps to reproduce 1. Boot an Ubuntu generic kernel based on Linux 6.6 or later with `CONFIG_SMS_SIANO_DEBUGFS=y`. 2. Connect a PLEX PX-S1UD (`3275:0080`). 3. Tune any Japanese ISDB-T channel, for example with `dvbv5-zap`, Mirakurun, or another DVB application. 4. Observe the kernel log with `journalctl -kf`. # Actual result The kernel repeatedly emits warnings similar to: ``` invalid sysfs_emit_at: buf:... at:0 WARNING: fs/sysfs/file.c:781 at sysfs_emit_at+0x... ... smsdvb_print_isdb_stats_ex+0x... [smsdvb] smsdvb_update_isdbt_stats_ex+0x... [smsdvb] smsdvb_onresponse+0x... [smsdvb] smscore_onresponse+0x... [smsmdtv] smsusb_onresponse+0x... [smsusb] ``` The issue was reproduced again on the affected system with a controlled three-second stream request. That produced 536 `invalid sysfs_emit_at` warnings and 4.1 MB of kernel log, approximately 179 warnings and 1.4 MB per second. The captured log is attached as `smsdvb-repro-kernel.log`. On the affected machine, normal operation over approximately four days produced: ``` /var/log/syslog approximately 101 GB /var/log/kern.log approximately 101 GB root filesystem 100% full ``` # Expected result Receiving ISDB-T statistics must not generate any kernel warning. The debugfs statistics buffer should be formatted successfully and `stats_count` should become nonzero. # Root cause `struct smsdvb_debugfs` contains: ```c char stats_data[PAGE_SIZE]; ``` This is a driver-owned array embedded in a dynamically allocated structure, not the page-aligned buffer supplied to a sysfs `show()` callback. Commit `2f7d0c94396e` mechanically replaced calls such as: ```c n += scnprintf(&buf[n], PAGE_SIZE - n, ...); ``` with: ```c n += sysfs_emit_at(buf, n, ...); ``` `sysfs_emit_at()` rejects this buffer because `offset_in_page(buf)` is nonzero and returns zero. Consequently `n` and `debug_data->stats_count` remain zero. Every subsequent statistics response retries all formatting calls and emits another set of WARN traces, creating an unbounded warning storm. # Suggested fix Revert the conversions in `drivers/media/common/siano/smsdvb-debugfs.c` from `sysfs_emit_at(buf, n, ...)` to the previous bounded debugfs-buffer form: ```c scnprintf(&buf[n], PAGE_SIZE - n, ...) ``` Alternatively, use another bounded formatter intended for a driver-owned buffer. Disabling `CONFIG_SMS_SIANO_DEBUGFS` avoids the faulty path but does not fix the upstream regression. # References - Culprit commit: https://github.com/torvalds/linux/commit/2f7d0c94396e8df1db6a5bc3b6ea272d640e874d - Current affected source: https://github.com/torvalds/linux/blob/master/drivers/media/common/siano/smsdvb-debugfs.c - Independent PX-S1UD report on kernel 6.8, with kernel 6.5 used as a workaround: https://mao.5ch.io/test/read.cgi/linux/1695289122/476-n 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.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: ubuntu 1831 F.... wireplumber /dev/snd/seq: ubuntu 1809 F.... pipewire CasperMD5CheckResult: pass Date: Thu Jul 30 20:23:36 2026 InstallationDate: Installed on 2026-07-25 (5 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp2s0Link: Not connected. IwDevWlx40a5ef5c6f92Link: Not connected. MachineType: Intel(R) Client Systems NUC6CAYH ProcEnviron: LANG=ja_JP.UTF-8 LC_CTYPE=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=dumb ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=61cdc8d6-b16d-4d3e-a62f-d592da5c77c0 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/08/2021 dmi.bios.release: 5.6 dmi.bios.vendor: Intel Corp. dmi.bios.version: AYAPLCEL.86A.0071.2021.1208.1638 dmi.board.name: NUC6CAYB dmi.board.vendor: Intel Corporation dmi.board.version: J23203-409 dmi.chassis.type: 35 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 2.0 dmi.ec.firmware.release: 22.0 dmi.modalias: dmi:bvnIntelCorp.:bvrAYAPLCEL.86A.0071.2021.1208.1638:bd12/08/2021:br5.6:efr22.0:svnIntel(R)ClientSystems:pnNUC6CAYH:pvrJ26845-410:rvnIntelCorporation:rnNUC6CAYB:rvrJ23203-409:cvnIntelCorporation:ct35:cvr2.0:sku:pfaAY: dmi.product.family: AY dmi.product.name: NUC6CAYH dmi.product.version: J26845-410 dmi.sys.vendor: Intel(R) Client Systems ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute ** Attachment added: "Controlled 3-second PX-S1UD reproduction: 536 WARNs, 4.1 MB" https://bugs.launchpad.net/bugs/2162139/+attachment/5987930/+files/smsdvb-repro-kernel.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162139 Title: smsdvb generates an unbounded invalid sysfs_emit_at WARN storm with PX-S1UD (regression in Linux 6.6) Status in linux package in Ubuntu: New Bug description: # Summary Using a PLEX PX-S1UD ISDB-T USB tuner with Ubuntu's generic kernel causes `smsdvb` to repeatedly call `sysfs_emit_at()` with a non-page-aligned driver-owned debugfs buffer. Each ISDB-T statistics response produces kernel WARN traces. During normal Mirakurun operation this grew `/var/log/syslog` and `/var/log/kern.log` to about 101 GB each and filled the root filesystem. This is an upstream regression introduced by: ``` 2f7d0c94396e ("media: siano: Convert to use sysfs_emit_at() API") ``` Linux v6.5 uses `scnprintf()` in `smsdvb-debugfs.c`; v6.6 and later use `sysfs_emit_at()`. The current upstream source still contains the problematic calls. # Environment ``` Ubuntu 26.04 LTS (resolute) Ubuntu 7.0.0-28.28-generic 7.0.12 CONFIG_SMS_SIANO_DEBUGFS=y CONFIG_DEBUG_FS=y USB 3275:0080 VidzMedia/PLEX PX-S1UD Digital TV Tuner ``` The same `CONFIG_SMS_SIANO_DEBUGFS=y` setting is present in the official Ubuntu 22.04/5.15 and Ubuntu 24.04/6.8 generic kernel packages. The regression is caused by the upstream code change, not a recent Ubuntu config change. # Steps to reproduce 1. Boot an Ubuntu generic kernel based on Linux 6.6 or later with `CONFIG_SMS_SIANO_DEBUGFS=y`. 2. Connect a PLEX PX-S1UD (`3275:0080`). 3. Tune any Japanese ISDB-T channel, for example with `dvbv5-zap`, Mirakurun, or another DVB application. 4. Observe the kernel log with `journalctl -kf`. # Actual result The kernel repeatedly emits warnings similar to: ``` invalid sysfs_emit_at: buf:... at:0 WARNING: fs/sysfs/file.c:781 at sysfs_emit_at+0x... ... smsdvb_print_isdb_stats_ex+0x... [smsdvb] smsdvb_update_isdbt_stats_ex+0x... [smsdvb] smsdvb_onresponse+0x... [smsdvb] smscore_onresponse+0x... [smsmdtv] smsusb_onresponse+0x... [smsusb] ``` The issue was reproduced again on the affected system with a controlled three-second stream request. That produced 536 `invalid sysfs_emit_at` warnings and 4.1 MB of kernel log, approximately 179 warnings and 1.4 MB per second. The captured log is attached as `smsdvb-repro-kernel.log`. On the affected machine, normal operation over approximately four days produced: ``` /var/log/syslog approximately 101 GB /var/log/kern.log approximately 101 GB root filesystem 100% full ``` # Expected result Receiving ISDB-T statistics must not generate any kernel warning. The debugfs statistics buffer should be formatted successfully and `stats_count` should become nonzero. # Root cause `struct smsdvb_debugfs` contains: ```c char stats_data[PAGE_SIZE]; ``` This is a driver-owned array embedded in a dynamically allocated structure, not the page-aligned buffer supplied to a sysfs `show()` callback. Commit `2f7d0c94396e` mechanically replaced calls such as: ```c n += scnprintf(&buf[n], PAGE_SIZE - n, ...); ``` with: ```c n += sysfs_emit_at(buf, n, ...); ``` `sysfs_emit_at()` rejects this buffer because `offset_in_page(buf)` is nonzero and returns zero. Consequently `n` and `debug_data->stats_count` remain zero. Every subsequent statistics response retries all formatting calls and emits another set of WARN traces, creating an unbounded warning storm. # Suggested fix Revert the conversions in `drivers/media/common/siano/smsdvb-debugfs.c` from `sysfs_emit_at(buf, n, ...)` to the previous bounded debugfs-buffer form: ```c scnprintf(&buf[n], PAGE_SIZE - n, ...) ``` Alternatively, use another bounded formatter intended for a driver-owned buffer. Disabling `CONFIG_SMS_SIANO_DEBUGFS` avoids the faulty path but does not fix the upstream regression. # References - Culprit commit: https://github.com/torvalds/linux/commit/2f7d0c94396e8df1db6a5bc3b6ea272d640e874d - Current affected source: https://github.com/torvalds/linux/blob/master/drivers/media/common/siano/smsdvb-debugfs.c - Independent PX-S1UD report on kernel 6.8, with kernel 6.5 used as a workaround: https://mao.5ch.io/test/read.cgi/linux/1695289122/476-n 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.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: ubuntu 1831 F.... wireplumber /dev/snd/seq: ubuntu 1809 F.... pipewire CasperMD5CheckResult: pass Date: Thu Jul 30 20:23:36 2026 InstallationDate: Installed on 2026-07-25 (5 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp2s0Link: Not connected. IwDevWlx40a5ef5c6f92Link: Not connected. MachineType: Intel(R) Client Systems NUC6CAYH ProcEnviron: LANG=ja_JP.UTF-8 LC_CTYPE=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=dumb ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=61cdc8d6-b16d-4d3e-a62f-d592da5c77c0 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/08/2021 dmi.bios.release: 5.6 dmi.bios.vendor: Intel Corp. dmi.bios.version: AYAPLCEL.86A.0071.2021.1208.1638 dmi.board.name: NUC6CAYB dmi.board.vendor: Intel Corporation dmi.board.version: J23203-409 dmi.chassis.type: 35 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 2.0 dmi.ec.firmware.release: 22.0 dmi.modalias: dmi:bvnIntelCorp.:bvrAYAPLCEL.86A.0071.2021.1208.1638:bd12/08/2021:br5.6:efr22.0:svnIntel(R)ClientSystems:pnNUC6CAYH:pvrJ26845-410:rvnIntelCorporation:rnNUC6CAYB:rvrJ23203-409:cvnIntelCorporation:ct35:cvr2.0:sku:pfaAY: dmi.product.family: AY dmi.product.name: NUC6CAYH dmi.product.version: J26845-410 dmi.sys.vendor: Intel(R) Client Systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162139/+subscriptions
[Bug 2149877] Re: Intermittent micro‑stutters affecting mouse and audio after updating to Linux 7.0.0‑14‑generic on AMD system
On kernel 7.0.0-28 I'm seeing gaps, though I wasn't playing audio - so just big gaps in being able to use mouse and touchpad. Not sure if it's relevant, but the computer has been on overnight and I'm back on it over night, one stutter just typing this was over 5 seconds. This computer is has newer Ryzen AI chip, I see the same symptoms in another which a much older Vega 9 since I upgraded it to 26.04. I thought I'd start playing audio to see if I could hear any gaps, I've had no stutters since I started playing audio. First 15 minutes of using this laptop this morning (no audio playing): gaps in keyboard and mouse once or twice a minute for up to 5 minutes. Since then with audio playing: none yet. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2149877 Title: Intermittent micro‑stutters affecting mouse and audio after updating to Linux 7.0.0‑14‑generic on AMD system Status in linux package in Ubuntu: Fix Released Status in linux source package in Resolute: Fix Released Bug description: For the past few days I have been experiencing intermittent micro‑stutters in Ubuntu 26.04. The mouse cursor freezes for about half a second, and occasionally the system audio also cuts out briefly. This happens irregularly but repeatedly. The issue started after updating to Linux 7.0.0‑14‑generic. Around the same time, linux‑firmware was also updated, so I cannot determine which change might be responsible. On my laptop (Intel + Nvidia) I cannot reproduce the issue, but another user with AMD hardware reported similar symptoms on Discourse. Affected hardware: · CPU: AMD Ryzen 5 9600X (12) @ 5.49 GHz · GPU: AMD Radeon RX 9060 XT · OS: Ubuntu 26.04 Observed behaviour: · Mouse cursor freezes for ~0.5 seconds (“micro‑stutter”). · Occasional short audio dropouts. · I have not noticed the issue while gaming, although another user claims it also happens there. I would appreciate guidance on additional tools or diagnostics that could help identify the root cause. At the moment, the only evidence I can provide is the observed behaviour described above. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2149877/+subscriptions
[Bug 2150732] Re: Screen stays black after resuming from sleep
For what it's worth, this issue still presents in 7.0.0-28.28. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150732 Title: Screen stays black after resuming from sleep Status in linux package in Ubuntu: Confirmed Bug description: After a "long" sleep (let's say more than 10 mins, but this is not clearly defined yet) when waking up, the screen stays black. I can confirm the system is responsive, the fingerprint sensor activates, it connects to the WiFi properly, it's really just the graphics part. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-14-generic 7.0.0-14.14 ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0 Uname: Linux 7.0.0-14-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: a.dubois 5856 F.... pipewire a.dubois 5867 F.... wireplumber /dev/snd/seq: a.dubois 5856 F.... pipewire CasperMD5CheckMismatches: ./boot/grub/i386-pc/eltorito.img CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Thu Apr 30 12:07:57 2026 InstallationDate: Installed on 2026-02-27 (62 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) MachineType: LENOVO 21KWS15400 ProcEnviron: LANG=fr_FR.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-04-24 (6 days ago) dmi.bios.date: 03/02/2026 dmi.bios.release: 1.20 dmi.bios.vendor: LENOVO dmi.bios.version: N48ET33W (1.20 ) dmi.board.asset.tag: Not Available dmi.board.name: 21KWS15400 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76530 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.15 dmi.modalias: dmi:bvnLENOVO:bvrN48ET33W(1.20):bd03/02/2026:br1.20:efr1.15:svnLENOVO:pn21KWS15400:pvrThinkPadP1Gen7:rvnLENOVO:rn21KWS15400:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21KW_BU_Think_FM_ThinkPadP1Gen7:pfaThinkPadP1Gen7: dmi.product.family: ThinkPad P1 Gen 7 dmi.product.name: 21KWS15400 dmi.product.sku: LENOVO_MT_21KW_BU_Think_FM_ThinkPad P1 Gen 7 dmi.product.version: ThinkPad P1 Gen 7 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150732/+subscriptions
среда
[Bug 2162012] Re: Backport: "firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits"
Submitted to kteam mailing list: "[SRU][R/N:hwe-7.0][PATCH 0/1] firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits" I checked and confirmed that the first two patches are not in N:hwe-6.17, so I believe that tree should be unaffected. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162012 Title: Backport: "firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits" Status in linux package in Ubuntu: New Status in linux-hwe-7.0 package in Ubuntu: New Status in linux-nvidia-7.0 package in Ubuntu: In Progress Status in linux-nvidia-bos package in Ubuntu: In Progress Status in linux-hwe-7.0 source package in Noble: In Progress Status in linux-nvidia-7.0 source package in Noble: New Status in linux-nvidia-bos source package in Noble: New Status in linux source package in Resolute: In Progress Status in linux-hwe-7.0 source package in Resolute: In Progress Status in linux-nvidia-7.0 source package in Resolute: New Status in linux-nvidia-bos source package in Resolute: New Status in linux source package in Stonking: New Status in linux-hwe-7.0 source package in Stonking: New Status in linux-nvidia-7.0 source package in Stonking: In Progress Status in linux-nvidia-bos source package in Stonking: In Progress Bug description: [ Summary ] A recent stable-update pulled two v7.1 FF-A commits into the linux-nvidia 7.0 branches, but not the third commit in the chain. The result is that FF-A fails to initialise on 64K page kernels whose firmware rejects a 64K RX/TX buffer, taking every FF-A device with it. This backports the missing fix. ### The regression Stable-updates applied these two, both of which first shipped upstream in **v7.1**: | Backport | Upstream | BugLink | |---|---|---| | `7bfaed6b412b` firmware: arm_ffa: Use the correct buffer size during RXTX_MAP | `83210251fd70` | LP #2156385 | | `105dac1d2c92` firmware: arm_ffa: Align RxTx buffer size before mapping | `0399e3f872ca` | LP #2156390 | The first makes the driver advertise `PAGE_ALIGN(rxtx_bufsz)` to firmware; the second is its follow-up fix. Both landed in `Ubuntu-nvidia-bos-7.0.0-2016.16`, the most recent tag on this branch. Earlier tags are not affected. The third commit in the chain, which fixes the fallout from the first, only landed upstream in **v7.2-rc4**: 53716a4d745f firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits [ Impact ] On a 64K page kernel the driver takes the firmware advertised minimum RX/TX buffer size, rounds it up to `PAGE_SIZE`, and asks firmware to map that. FF-A implementations before v1.2 advertise no maximum and may simply reject the rounded up size. There is no clamp and no retry, so probe fails: ARM FF-A: Driver version 1.2 ARM FF-A: Firmware version 1.1 found ARM FF-A: failed to register FFA RxTx buffers and no FF-A devices are registered at all. Anything sitting on FF-A goes with it, including TPM over FF-A. Trigger is `PAGE_SIZE` greater than the advertised minimum, so the 64K flavours. Platforms with FF-A v1.2 or later firmware are unaffected, since the advertised maximum is then respected. [ Fix ] Backport of `53716a4d745f`. It decodes the maximum buffer size that FF-A v1.2+ reports, clamps the page aligned minimum to it, and where no maximum is advertised retries `RXTX_MAP` at the advertised minimum if the rounded size is rejected with `INVALID_PARAMETERS`. [ Test Plan ] Tested on an Arm server reporting FF-A firmware version 1.1, running a 64K page kernel built from this branch's own `nvidia-bos-64k` flavour annotations. Before, on the unmodified branch tip: ARM FF-A: failed to register FFA RxTx buffers /sys/bus/arm_ffa/devices/ -> empty After, with this commit applied: ARM FF-A: Firmware version 1.1 found ARM FF-A: Failed to create IRQ mapping! /sys/bus/arm_ffa/devices/ -> arm-ffa-1 .. arm-ffa-5 All five partitions enumerate again. The remaining "Failed to create IRQ mapping" line is pre-existing and also present on the distro kernel that predates the regression. No new BUG, WARNING or call traces. [ Where Problems Could Occur ] A regression in this fix could cause issues with the ARM FF-A driver's partition enumeration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162012/+subscriptions
[Bug 2162012] Re: Backport: "firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits"
** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-nvidia-bos (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-nvidia-7.0 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-nvidia-bos (Ubuntu Stonking) Importance: Undecided Assignee: Mitchell Augustin (mitchellaugustin) Status: In Progress ** Also affects: linux-nvidia-7.0 (Ubuntu Stonking) Importance: Undecided Assignee: Mitchell Augustin (mitchellaugustin) Status: In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162012 Title: Backport: "firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits" Status in linux package in Ubuntu: New Status in linux-nvidia-7.0 package in Ubuntu: In Progress Status in linux-nvidia-bos package in Ubuntu: In Progress Status in linux source package in Resolute: New Status in linux-nvidia-7.0 source package in Resolute: New Status in linux-nvidia-bos source package in Resolute: New Status in linux source package in Stonking: New Status in linux-nvidia-7.0 source package in Stonking: In Progress Status in linux-nvidia-bos source package in Stonking: In Progress Bug description: ### Summary A recent stable-update pulled two v7.1 FF-A commits into the linux-nvidia 7.0 branches, but not the third commit in the chain. The result is that FF-A fails to initialise on 64K page kernels whose firmware rejects a 64K RX/TX buffer, taking every FF-A device with it. This backports the missing fix. ### The regression Stable-updates applied these two, both of which first shipped upstream in **v7.1**: | Backport | Upstream | BugLink | |---|---|---| | `7bfaed6b412b` firmware: arm_ffa: Use the correct buffer size during RXTX_MAP | `83210251fd70` | LP #2156385 | | `105dac1d2c92` firmware: arm_ffa: Align RxTx buffer size before mapping | `0399e3f872ca` | LP #2156390 | The first makes the driver advertise `PAGE_ALIGN(rxtx_bufsz)` to firmware; the second is its follow-up fix. Both landed in `Ubuntu-nvidia-bos-7.0.0-2016.16`, the most recent tag on this branch. Earlier tags are not affected. The third commit in the chain, which fixes the fallout from the first, only landed upstream in **v7.2-rc4**: 53716a4d745f firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits ### Symptom On a 64K page kernel the driver takes the firmware advertised minimum RX/TX buffer size, rounds it up to `PAGE_SIZE`, and asks firmware to map that. FF-A implementations before v1.2 advertise no maximum and may simply reject the rounded up size. There is no clamp and no retry, so probe fails: ARM FF-A: Driver version 1.2 ARM FF-A: Firmware version 1.1 found ARM FF-A: failed to register FFA RxTx buffers and no FF-A devices are registered at all. Anything sitting on FF-A goes with it, including TPM over FF-A. Trigger is `PAGE_SIZE` greater than the advertised minimum, so the 64K flavours. Platforms with FF-A v1.2 or later firmware are unaffected, since the advertised maximum is then respected. ### The fix Backport of `53716a4d745f`. It decodes the maximum buffer size that FF-A v1.2+ reports, clamps the page aligned minimum to it, and where no maximum is advertised retries `RXTX_MAP` at the advertised minimum if the rounded size is rejected with `INVALID_PARAMETERS`. ### Testing Tested on an Arm server reporting FF-A firmware version 1.1, running a 64K page kernel built from this branch's own `nvidia-bos-64k` flavour annotations. Before, on the unmodified branch tip: ARM FF-A: failed to register FFA RxTx buffers /sys/bus/arm_ffa/devices/ -> empty After, with this commit applied: ARM FF-A: Firmware version 1.1 found ARM FF-A: Failed to create IRQ mapping! /sys/bus/arm_ffa/devices/ -> arm-ffa-1 .. arm-ffa-5 All five partitions enumerate again. The remaining "Failed to create IRQ mapping" line is pre-existing and also present on the distro kernel that predates the regression. No new BUG, WARNING or call traces. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162012/+subscriptions
[Bug 2162066] [NEW] Kernel panic during shutdown: list_del corruption in list_lru_del_obj followed by stack corruption in list_lru_walk_node on 7.0.0-28-generic
Public bug reported: Expected result: Selecting Shut Down from the KDE Plasma application menu should cleanly terminate running processes and power off the computer. Actual result: After selecting Shut Down from the KDE Plasma application menu, the kernel reported repeated list_del corruption while cleaning up processes. The trace included list_lru_del_obj, d_lru_del, shrink_dcache_tree, proc_flush_pid, and release_task. The shutdown sequence then ended in a kernel panic displaying: stack-protector: Kernel stack is corrupted in: list_lru_walk_node+0x200/0x200 The computer did not power off and required a manual reboot/power cycle. 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.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: jay 2067 F.... wireplumber /dev/snd/controlC0: jay 2067 F.... wireplumber /dev/snd/seq: jay 2064 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Wed Jul 29 09:35:39 2026 InstallationDate: Installed on 2026-07-01 (28 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) MachineType: Micro-Star International Co., Ltd. MS-7C91 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=6a5f5940-762e-4f55-b481-067ca3db5b2c ro quiet splash nvme_core.default_ps_max_latency_us=0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/19/2023 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: A.F0 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: MAG B550 TOMAHAWK (MS-7C91) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 2.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 2.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrA.F0:bd10/19/2023:br5.17:svnMicro-StarInternationalCo.,Ltd.:pnMS-7C91:pvr2.0:rvnMicro-StarInternationalCo.,Ltd.:rnMAGB550TOMAHAWK(MS-7C91):rvr2.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr2.0:skuTobefilledbyO.E.M.:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7C91 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 2.0 dmi.sys.vendor: Micro-Star International Co., Ltd. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162066 Title: Kernel panic during shutdown: list_del corruption in list_lru_del_obj followed by stack corruption in list_lru_walk_node on 7.0.0-28-generic Status in linux package in Ubuntu: New Bug description: Expected result: Selecting Shut Down from the KDE Plasma application menu should cleanly terminate running processes and power off the computer. Actual result: After selecting Shut Down from the KDE Plasma application menu, the kernel reported repeated list_del corruption while cleaning up processes. The trace included list_lru_del_obj, d_lru_del, shrink_dcache_tree, proc_flush_pid, and release_task. The shutdown sequence then ended in a kernel panic displaying: stack-protector: Kernel stack is corrupted in: list_lru_walk_node+0x200/0x200 The computer did not power off and required a manual reboot/power cycle. 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.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: jay 2067 F.... wireplumber /dev/snd/controlC0: jay 2067 F.... wireplumber /dev/snd/seq: jay 2064 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Wed Jul 29 09:35:39 2026 InstallationDate: Installed on 2026-07-01 (28 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) MachineType: Micro-Star International Co., Ltd. MS-7C91 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=6a5f5940-762e-4f55-b481-067ca3db5b2c ro quiet splash nvme_core.default_ps_max_latency_us=0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/19/2023 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: A.F0 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: MAG B550 TOMAHAWK (MS-7C91) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 2.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 2.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrA.F0:bd10/19/2023:br5.17:svnMicro-StarInternationalCo.,Ltd.:pnMS-7C91:pvr2.0:rvnMicro-StarInternationalCo.,Ltd.:rnMAGB550TOMAHAWK(MS-7C91):rvr2.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr2.0:skuTobefilledbyO.E.M.:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7C91 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 2.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/2162066/+subscriptions
[Bug 2162061] Re: ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop
Update: Found the root cause and workaround. The issue is caused by the ELAN0415 I2C HID touchpad waking the laptop during s2idle suspend. The wake source was identified as: ``` i2c-ELAN0415:00 ``` Disabling ACPI wake device GP17 did not solve the issue. Workaround: Created a systemd sleep hook: ``` /lib/systemd/system-sleep/elan-suspend-fix ``` Script: ```bash #!/bin/bash case "$1" in pre) echo i2c-ELAN0415:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind ;; post) sleep 2 echo i2c-ELAN0415:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/bind ;; esac ``` After applying this workaround: - Suspend works correctly - Laptop no longer immediately wakes - ELAN touchpad works after resume Tested on: Acer TravelLite TL14-42M AMD Ryzen 7 7730U Ubuntu 24.04.4 LTS Kernel 6.17.0-1030-oem The issue appears to be related to ELAN0415 I2C HID wake handling during s2idle suspend. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162061 Title: ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop Status in linux package in Ubuntu: New Bug description: ## Problem On my Acer TravelLite TL14-42M laptop, Ubuntu suspend immediately wakes up after 1-2 seconds. Running: systemctl suspend The laptop enters suspend successfully but wakes immediately. Windows dual boot on the same hardware suspends correctly. ## Hardware Laptop: Acer TravelLite TL14-42M CPU: AMD Ryzen 7 7730U BIOS: 1.07.06RAC1 OS: Ubuntu 24.04.4 LTS Kernel: 6.17.0-1030-oem ## Suspend mode cat /sys/power/mem_sleep Output: [s2idle] ## Investigation Using: cat /sys/kernel/debug/wakeup_sources The wakeup source was identified as: i2c-ELAN0415:00 The device is: ELAN0415 I2C HID touchpad ## Workaround The issue can be fixed by unbinding the touchpad before suspend and rebinding after resume: Before suspend: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind After resume: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind I created a systemd sleep hook which performs this automatically. After applying this workaround, suspend works correctly. ## Additional logs Wakeup source before fix: i2c-ELAN0415:00 The issue is reproducible on the OEM kernel as well: 6.17.0-1030-oem The AMD S0ix state reports successful entry and exit, so the problem appears related to the ELAN I2C HID touchpad wake handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162061/+subscriptions
[Bug 2162061] Re: ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop
Update: The issue is not present after applying a systemd sleep hook that unbinds and rebinds the ELAN0415 I2C HID device. Sleep hook: Before suspend: echo i2c-ELAN0415:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind After resume: echo i2c-ELAN0415:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/bind The workaround restores normal suspend/resume behavior. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162061 Title: ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop Status in linux package in Ubuntu: New Bug description: ## Problem On my Acer TravelLite TL14-42M laptop, Ubuntu suspend immediately wakes up after 1-2 seconds. Running: systemctl suspend The laptop enters suspend successfully but wakes immediately. Windows dual boot on the same hardware suspends correctly. ## Hardware Laptop: Acer TravelLite TL14-42M CPU: AMD Ryzen 7 7730U BIOS: 1.07.06RAC1 OS: Ubuntu 24.04.4 LTS Kernel: 6.17.0-1030-oem ## Suspend mode cat /sys/power/mem_sleep Output: [s2idle] ## Investigation Using: cat /sys/kernel/debug/wakeup_sources The wakeup source was identified as: i2c-ELAN0415:00 The device is: ELAN0415 I2C HID touchpad ## Workaround The issue can be fixed by unbinding the touchpad before suspend and rebinding after resume: Before suspend: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind After resume: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind I created a systemd sleep hook which performs this automatically. After applying this workaround, suspend works correctly. ## Additional logs Wakeup source before fix: i2c-ELAN0415:00 The issue is reproducible on the OEM kernel as well: 6.17.0-1030-oem The AMD S0ix state reports successful entry and exit, so the problem appears related to the ELAN I2C HID touchpad wake handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162061/+subscriptions
[Bug 2162061] [NEW] ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop
Public bug reported: ## Problem On my Acer TravelLite TL14-42M laptop, Ubuntu suspend immediately wakes up after 1-2 seconds. Running: systemctl suspend The laptop enters suspend successfully but wakes immediately. Windows dual boot on the same hardware suspends correctly. ## Hardware Laptop: Acer TravelLite TL14-42M CPU: AMD Ryzen 7 7730U BIOS: 1.07.06RAC1 OS: Ubuntu 24.04.4 LTS Kernel: 6.17.0-1030-oem ## Suspend mode cat /sys/power/mem_sleep Output: [s2idle] ## Investigation Using: cat /sys/kernel/debug/wakeup_sources The wakeup source was identified as: i2c-ELAN0415:00 The device is: ELAN0415 I2C HID touchpad ## Workaround The issue can be fixed by unbinding the touchpad before suspend and rebinding after resume: Before suspend: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind After resume: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind I created a systemd sleep hook which performs this automatically. After applying this workaround, suspend works correctly. ## Additional logs Wakeup source before fix: i2c-ELAN0415:00 The issue is reproducible on the OEM kernel as well: 6.17.0-1030-oem The AMD S0ix state reports successful entry and exit, so the problem appears related to the ELAN I2C HID touchpad wake handling. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162061 Title: ELAN0415 I2C HID touchpad causes immediate wake after suspend on AMD laptop Status in linux package in Ubuntu: New Bug description: ## Problem On my Acer TravelLite TL14-42M laptop, Ubuntu suspend immediately wakes up after 1-2 seconds. Running: systemctl suspend The laptop enters suspend successfully but wakes immediately. Windows dual boot on the same hardware suspends correctly. ## Hardware Laptop: Acer TravelLite TL14-42M CPU: AMD Ryzen 7 7730U BIOS: 1.07.06RAC1 OS: Ubuntu 24.04.4 LTS Kernel: 6.17.0-1030-oem ## Suspend mode cat /sys/power/mem_sleep Output: [s2idle] ## Investigation Using: cat /sys/kernel/debug/wakeup_sources The wakeup source was identified as: i2c-ELAN0415:00 The device is: ELAN0415 I2C HID touchpad ## Workaround The issue can be fixed by unbinding the touchpad before suspend and rebinding after resume: Before suspend: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind After resume: echo i2c-ELAN0415:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind I created a systemd sleep hook which performs this automatically. After applying this workaround, suspend works correctly. ## Additional logs Wakeup source before fix: i2c-ELAN0415:00 The issue is reproducible on the OEM kernel as well: 6.17.0-1030-oem The AMD S0ix state reports successful entry and exit, so the problem appears related to the ELAN I2C HID touchpad wake handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162061/+subscriptions
[Bug 2161635] Re: shutdown hang. power and fans remain on forever
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/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