** 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/2172546 Title: phantom BTN_LEFT press after S3 resume (ThinkPad P14s Gen 1 AMD, LEN2064) Status in linux package in Ubuntu: New Bug description: After suspend/resume, the Synaptics clickpad reports BTN_LEFT=1 about one second after resume, with no finger on the pad, and never releases it (seen in both raw captures made; see EARLIER EPISODES for the others). The desktop then treats the pointer as dragging: text selects as soon as the pointer moves, and clicks are ignored until logout. ENVIRONMENT Machine: LENOVO 20Y10011US, ThinkPad P14s Gen 1 (AMD) BIOS: R1BET87W (1.56), 06/04/2026 OS/kernel: Ubuntu 26.04, 7.0.0-42-generic (linux-image 7.0.0-42.42) Session: GNOME Shell 50.1 on Wayland, libinput 1.31.1 Sleep: mem_sleep = s2idle [deep]; suspends are S3 ("deep") Touchpad: "SynPS/2 Synaptics TouchPad", Phys isa0060/serio1/input0, PNP LEN2064 PNP0f13, fw 10.32, id 0x1e2a1, board id 3471, /dev/input/event6; INPUT_PROP_BUTTONPAD Driver: psmouse (PS/2). TrackPoint is "TPPS/2 Elan TrackPoint" (event7), on the Synaptics pass-through port. STEPS TO REPRODUCE (no applications needed) 1. Log in. Record the raw touchpad stream: sudo cat /dev/input/event6 > raw.bin 2. systemctl suspend. Resume. Touch nothing for 10 seconds. 3. Move the pointer (TrackPoint is enough). A text selection or drag starts. OBSERVED (raw kernel events, EV_KEY only; traces attached) Run 2 (trace2-raw-evkey.txt), suspend entry 14:33:53, resume 14:34:04: 14:33:53.719 BTN_LEFT 0 at suspend entry (no events at all for 11.8 s) 14:34:05.509 BTN_LEFT 1 ~1.5 s after resume, no touch (no events for 24.7 s; no BTN_LEFT release for the rest of the file) Run 1 (trace1-raw-evkey.txt), suspend entry 14:23:53, resume 14:23:59: 14:23:53.368 BTN_LEFT 0 14:24:00.473 BTN_LEFT 1 ~1 s after resume, no touch, no release libinput (1.31.1) passes the press through faithfully: "event6 POINTER_BUTTON BTN_LEFT pressed, seat count: 1", never released (libinput-buttons-excerpt.txt). The TrackPoint's buttons (event7) still press and release normally while the touchpad's is stuck. The first BTN_LEFT event in each capture is a release with no press earlier in the capture. The kernel input core only emits a 0 when it believes the bit was 1, so I do not know how the bit became 1, or whether this release is related. EARLIER EPISODES (libinput-level capture only, no raw stream) 13:56 resume: press ~1.4 s after the wake key, never released. 14:10 and 14:11 resumes (a different pattern): the press came ~27 s and ~20 s after the resume, with typing in between. The first was released ~1 s after the next suspend entry, as in the raw runs; the second was never released. I cannot say whether those were phantom presses or the pad being touched. An earlier episode on Oct 19 (previous boot) had the same symptoms; nothing was captured and the cause is not confirmed. WHAT I TRIED - Reloading psmouse (modprobe -r / modprobe): the press still occurs on the next resume (the 13:56 episode followed a reload at 13:39). - psmouse.synaptics_intertouch=1, also with rmi_smbus preloaded: the driver logs "Trying to set up SMBus access" then "SMbus companion is not ready yet" and falls back to PS/2, so the RMI path is not available here (intertouch-attempt.txt). The boot-time hint in dmesg is the same message the driver prints about LEN2064. - Touchpad disabled in GNOME (send-events disabled): one suspend/ resume cycle, no wedge. This is the only workaround found; it costs the touchpad. NOT KNOWN - Whether other kernel versions are affected, or whether a BIOS/EC update changes it. I have not tried an older kernel. - Whether the press originates in the touchpad firmware or in the driver's resume path (the log shows the driver re-querying the pad at resume, ~1 s before the press). - Whether a fresh boot, rather than a login/logout, changes the first-resume behaviour. All runs above are on one boot (11:53). ATTACHMENTS trace1-raw-evkey.txt, trace2-raw-evkey.txt decoded EV_KEY events trace1-kernel-journal.txt, trace2-kernel-journal.txt PM/psmouse lines libinput-buttons-excerpt.txt libinput debug-events button lines intertouch-attempt.txt the SMBus fallback messages ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-42-generic 7.0.0-42.42 ProcVersionSignature: Ubuntu 7.0.0-42.42-generic 7.0.14 Uname: Linux 7.0.0-42-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: user 259203 F.... wireplumber /dev/snd/controlC1: user 259203 F.... wireplumber /dev/snd/controlC0: user 259203 F.... wireplumber /dev/snd/seq: user 259192 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Oct 29 15:20:37 2026 InstallationDate: Installed on 2026-08-02 (88 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 20Y10011US 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-42-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 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) WifiSyslog: (removed) dmi.bios.date: 06/04/2026 dmi.bios.release: 1.56 dmi.bios.vendor: LENOVO dmi.bios.version: R1BET87W(1.56 ) dmi.board.asset.tag: Not Available dmi.board.name: 20Y10011US dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 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.56 dmi.modalias: dmi:bvnLENOVO:bvrR1BET87W(1.56):bd06/04/2026:br1.56:efr1.56:svnLENOVO:pn20Y10011US:pvrThinkPadP14sGen1:rvnLENOVO:rn20Y10011US:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20Y1_BU_Think_FM_ThinkPadP14sGen1:pfaThinkPadP14sGen1: dmi.product.family: ThinkPad P14s Gen 1 dmi.product.name: 20Y10011US dmi.product.sku: LENOVO_MT_20Y1_BU_Think_FM_ThinkPad P14s Gen 1 dmi.product.version: ThinkPad P14s Gen 1 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172546/+subscriptions
четверг
[Bug 2172563] Re: [IPU7] Stale 64-byte cache lines in captured frames (colored horizontal dashes on motion) - please backport "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries"
** 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/2172563 Title: [IPU7] Stale 64-byte cache lines in captured frames (colored horizontal dashes on motion) - please backport "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries" Status in linux package in Ubuntu: New Bug description: On a Lenovo ThinkPad X9-15 Gen 1 (Intel Core Ultra 7 258V, Lunar Lake, IPU7 8086:645d, Sony IMX471 sensor), the built-in camera works through libcamera, but frames contain short colored horizontal dashes wherever the image changes between frames, for example when moving a hand quickly in front of the camera. A static scene looks clean. Analysis: - Most full-length dashes are exactly 32 pixels wide and aligned to 32-pixel boundaries of the raw frame. With 10-bit Bayer stored in 16-bit containers, that is 64 bytes, i.e. one CPU cache line. - The artifacts appear with libcamera's software ISP in both GPU mode and CPU mode (LIBCAMERA_SOFTISP_MODE=cpu), so they are already present in the raw buffer delivered by intel-ipu7-isys. - This matches the patch "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries" (LKML, August 2026). It explains that dma_sync_sgtable_for_{cpu,device}() perform no cache maintenance on x86, so stale cached frame data from an earlier buffer slot survives buffer handoff. The patch calls ipu7_dma_sync_sgtable() from buf_prepare and buf_finish. https://ratatoskr.run/lkml/2026/08/17455941 Steps to reproduce: 1. Open GNOME Snapshot (or `cam -c1 --capture` / any libcamera client). 2. Move a hand quickly in front of the camera and take a photo. 3. Observe colored 32-pixel horizontal dashes along moving edges. Expected: clean frames without mixed-in data from earlier frames. Versions: - Ubuntu 26.10, kernel 7.3.0-9-generic (also not fixed in the 7.3.0-10.10 changelog) - libcamera 0.7.0-1ubuntu2 (simple pipeline handler, software ISP) - Machine: ThinkPad X9-15 Gen 1 (21Q60068BM), BIOS N4CET46W (1.22) Request: please consider backporting the above patch (or the merged upstream equivalent) to the Ubuntu kernel's staging ipu7 driver. ProblemType: Bug DistroRelease: Ubuntu 26.10 Package: linux-image-7.3.0-9-generic 7.3.0-9.9 ProcVersionSignature: Ubuntu 7.3.0-9.9-generic 7.3.0-rc6 Uname: Linux 7.3.0-9-generic x86_64 ApportVersion: 2.36.0-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: milen 3926 F.... pipewire milen 20413 F.... wireplumber /dev/snd/seq: milen 3926 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Oct 30 00:20:23 2026 InstallationDate: Installed on 2026-10-26 (3 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) MachineType: LENOVO 21Q60068BM 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.3.0-9-generic root=UUID=4a259af1-cc51-483b-bfd7-f0aec4937876 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux StagingDrivers: intel_ipu7_isys intel_ipu7 UpgradeStatus: Upgraded to stonking on 2026-10-28 (1 days ago) dmi.bios.date: 08/14/2026 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: N4CET46W (1.22 ) dmi.board.asset.tag: Not Available dmi.board.name: 21Q60068BM dmi.board.vendor: LENOVO dmi.board.version: SDK0T76576 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:bvrN4CET46W(1.22):bd08/14/2026:br1.22:efr1.15:svnLENOVO:pn21Q60068BM:pvrThinkPadX9-15Gen1:rvnLENOVO:rn21Q60068BM:rvrSDK0T76576WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21Q6_BU_Think_FM_ThinkPadX9-15Gen1:pfaThinkPadX9-15Gen1: dmi.product.family: ThinkPad X9-15 Gen 1 dmi.product.name: 21Q60068BM dmi.product.sku: LENOVO_MT_21Q6_BU_Think_FM_ThinkPad X9-15 Gen 1 dmi.product.version: ThinkPad X9-15 Gen 1 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172563/+subscriptions
[Bug 2172563] [NEW] [IPU7] Stale 64-byte cache lines in captured frames (colored horizontal dashes on motion) - please backport "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries"
Public bug reported: On a Lenovo ThinkPad X9-15 Gen 1 (Intel Core Ultra 7 258V, Lunar Lake, IPU7 8086:645d, Sony IMX471 sensor), the built-in camera works through libcamera, but frames contain short colored horizontal dashes wherever the image changes between frames, for example when moving a hand quickly in front of the camera. A static scene looks clean. Analysis: - Most full-length dashes are exactly 32 pixels wide and aligned to 32-pixel boundaries of the raw frame. With 10-bit Bayer stored in 16-bit containers, that is 64 bytes, i.e. one CPU cache line. - The artifacts appear with libcamera's software ISP in both GPU mode and CPU mode (LIBCAMERA_SOFTISP_MODE=cpu), so they are already present in the raw buffer delivered by intel-ipu7-isys. - This matches the patch "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries" (LKML, August 2026). It explains that dma_sync_sgtable_for_{cpu,device}() perform no cache maintenance on x86, so stale cached frame data from an earlier buffer slot survives buffer handoff. The patch calls ipu7_dma_sync_sgtable() from buf_prepare and buf_finish. https://ratatoskr.run/lkml/2026/08/17455941 Steps to reproduce: 1. Open GNOME Snapshot (or `cam -c1 --capture` / any libcamera client). 2. Move a hand quickly in front of the camera and take a photo. 3. Observe colored 32-pixel horizontal dashes along moving edges. Expected: clean frames without mixed-in data from earlier frames. Versions: - Ubuntu 26.10, kernel 7.3.0-9-generic (also not fixed in the 7.3.0-10.10 changelog) - libcamera 0.7.0-1ubuntu2 (simple pipeline handler, software ISP) - Machine: ThinkPad X9-15 Gen 1 (21Q60068BM), BIOS N4CET46W (1.22) Request: please consider backporting the above patch (or the merged upstream equivalent) to the Ubuntu kernel's staging ipu7 driver. ProblemType: Bug DistroRelease: Ubuntu 26.10 Package: linux-image-7.3.0-9-generic 7.3.0-9.9 ProcVersionSignature: Ubuntu 7.3.0-9.9-generic 7.3.0-rc6 Uname: Linux 7.3.0-9-generic x86_64 ApportVersion: 2.36.0-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: milen 3926 F.... pipewire milen 20413 F.... wireplumber /dev/snd/seq: milen 3926 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Oct 30 00:20:23 2026 InstallationDate: Installed on 2026-10-26 (3 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) MachineType: LENOVO 21Q60068BM 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.3.0-9-generic root=UUID=4a259af1-cc51-483b-bfd7-f0aec4937876 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux StagingDrivers: intel_ipu7_isys intel_ipu7 UpgradeStatus: Upgraded to stonking on 2026-10-28 (1 days ago) dmi.bios.date: 08/14/2026 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: N4CET46W (1.22 ) dmi.board.asset.tag: Not Available dmi.board.name: 21Q60068BM dmi.board.vendor: LENOVO dmi.board.version: SDK0T76576 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:bvrN4CET46W(1.22):bd08/14/2026:br1.22:efr1.15:svnLENOVO:pn21Q60068BM:pvrThinkPadX9-15Gen1:rvnLENOVO:rn21Q60068BM:rvrSDK0T76576WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21Q6_BU_Think_FM_ThinkPadX9-15Gen1:pfaThinkPadX9-15Gen1: dmi.product.family: ThinkPad X9-15 Gen 1 dmi.product.name: 21Q60068BM dmi.product.sku: LENOVO_MT_21Q6_BU_Think_FM_ThinkPad X9-15 Gen 1 dmi.product.version: ThinkPad X9-15 Gen 1 dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug staging stonking third-party-packages wayland-session ** Attachment added: "ipu7-launchpad-bug.md" https://bugs.launchpad.net/bugs/2172563/+attachment/6013556/+files/ipu7-launchpad-bug.md -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172563 Title: [IPU7] Stale 64-byte cache lines in captured frames (colored horizontal dashes on motion) - please backport "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries" Status in linux package in Ubuntu: New Bug description: On a Lenovo ThinkPad X9-15 Gen 1 (Intel Core Ultra 7 258V, Lunar Lake, IPU7 8086:645d, Sony IMX471 sensor), the built-in camera works through libcamera, but frames contain short colored horizontal dashes wherever the image changes between frames, for example when moving a hand quickly in front of the camera. A static scene looks clean. Analysis: - Most full-length dashes are exactly 32 pixels wide and aligned to 32-pixel boundaries of the raw frame. With 10-bit Bayer stored in 16-bit containers, that is 64 bytes, i.e. one CPU cache line. - The artifacts appear with libcamera's software ISP in both GPU mode and CPU mode (LIBCAMERA_SOFTISP_MODE=cpu), so they are already present in the raw buffer delivered by intel-ipu7-isys. - This matches the patch "media: staging/ipu7: Synchronize capture buffers at the vb2 boundaries" (LKML, August 2026). It explains that dma_sync_sgtable_for_{cpu,device}() perform no cache maintenance on x86, so stale cached frame data from an earlier buffer slot survives buffer handoff. The patch calls ipu7_dma_sync_sgtable() from buf_prepare and buf_finish. https://ratatoskr.run/lkml/2026/08/17455941 Steps to reproduce: 1. Open GNOME Snapshot (or `cam -c1 --capture` / any libcamera client). 2. Move a hand quickly in front of the camera and take a photo. 3. Observe colored 32-pixel horizontal dashes along moving edges. Expected: clean frames without mixed-in data from earlier frames. Versions: - Ubuntu 26.10, kernel 7.3.0-9-generic (also not fixed in the 7.3.0-10.10 changelog) - libcamera 0.7.0-1ubuntu2 (simple pipeline handler, software ISP) - Machine: ThinkPad X9-15 Gen 1 (21Q60068BM), BIOS N4CET46W (1.22) Request: please consider backporting the above patch (or the merged upstream equivalent) to the Ubuntu kernel's staging ipu7 driver. ProblemType: Bug DistroRelease: Ubuntu 26.10 Package: linux-image-7.3.0-9-generic 7.3.0-9.9 ProcVersionSignature: Ubuntu 7.3.0-9.9-generic 7.3.0-rc6 Uname: Linux 7.3.0-9-generic x86_64 ApportVersion: 2.36.0-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: milen 3926 F.... pipewire milen 20413 F.... wireplumber /dev/snd/seq: milen 3926 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Oct 30 00:20:23 2026 InstallationDate: Installed on 2026-10-26 (3 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) MachineType: LENOVO 21Q60068BM 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.3.0-9-generic root=UUID=4a259af1-cc51-483b-bfd7-f0aec4937876 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux StagingDrivers: intel_ipu7_isys intel_ipu7 UpgradeStatus: Upgraded to stonking on 2026-10-28 (1 days ago) dmi.bios.date: 08/14/2026 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: N4CET46W (1.22 ) dmi.board.asset.tag: Not Available dmi.board.name: 21Q60068BM dmi.board.vendor: LENOVO dmi.board.version: SDK0T76576 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:bvrN4CET46W(1.22):bd08/14/2026:br1.22:efr1.15:svnLENOVO:pn21Q60068BM:pvrThinkPadX9-15Gen1:rvnLENOVO:rn21Q60068BM:rvrSDK0T76576WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21Q6_BU_Think_FM_ThinkPadX9-15Gen1:pfaThinkPadX9-15Gen1: dmi.product.family: ThinkPad X9-15 Gen 1 dmi.product.name: 21Q60068BM dmi.product.sku: LENOVO_MT_21Q6_BU_Think_FM_ThinkPad X9-15 Gen 1 dmi.product.version: ThinkPad X9-15 Gen 1 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172563/+subscriptions
[Bug 2172527] Re: linux 7.0.0-42: writeback deadlock — sync() never returns with >1 GB dirty pages and an idle disk (full system freeze)
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/2172527 Title: linux 7.0.0-42: writeback deadlock — sync() never returns with >1 GB dirty pages and an idle disk (full system freeze) Status in linux package in Ubuntu: Confirmed Bug description: **Package:** `linux` (source) — affects `linux-image-7.0.0-42-generic 7.0.0-42.42` --- ## Problem description After upgrading from `linux-image-7.0.0-38-generic` to `linux-image-7.0.0-42-generic` (installed 2026-10-29 12:46 EEST via unattended-upgrades), the machine started freezing completely, several times per session, requiring a hard power-off. The freeze is a **writeback deadlock at the kernel level**, not a slow or failing disk: the block device is completely idle (`inflight = 0`, ~0.3 MiB/s written) while more than 1 GB of dirty pages never reach it. ## Regression range | Boot | Kernel | Time (EEST) | Result | |------|--------|-------------|--------| | 12:33–12:58 | 7.0.0-38 | before upgrade | clean, normal shutdown | | 13:00–17:05 | 7.0.0-42 | after upgrade | `EXT4-fs error` on sdb2, writeback stalls, systemd-oomd kill | | 17:20–18:53 | 7.0.0-42 | | journal ends abruptly mid-line → hard freeze | | 18:55–20:02 | 7.0.0-42 | | 52 × "waiting for writeback completion", up to 386 s | | 20:17–now | 7.0.0-38 | after rollback | clean, `sync` returns in 0.068 s | Bisected by kernel rollback only; no other component was changed when testing -38. ## Steps to reproduce 1. Boot `7.0.0-42-generic` on this machine with Docker running (7 containers). 2. Generate moderate write load (container churn, browser start, Go builds). 3. Within minutes the system stops responding; any process that writes enters D state. ## Actual behaviour - `sync` never returns: ``` PID 114212 D wb_wait_for_completion sync (killed by Ctrl-C after >120 s, remained stuck) ``` - Dirty pages never flushed, device idle: ``` Dirty: 1387248 kB Writeback: 2244 kB ``` `/sys/block/sda/stat` sampled over 5 s: ``` read 0.00 MiB/s write 0.29 MiB/s inflight = 0 ``` - Kernel hung-task detector: ``` INFO: The task dockerd:14019 has been waiting for writeback completion for more than 386 seconds. INFO: task dockerd:3461 <writer> blocked on an rw-semaphore likely owned by task dockerd:14015 <writer> INFO: task kworker/1:0:23825 blocked for more than 368 seconds. ``` - `flush-8:0` and `inode_switch_wbs` kworkers in D state. - `/proc/pressure/io`: `some avg10 = 84.37`, `full avg10 = 72.81` while the disk is idle. - All writers enter D state: `brave` in `submit_bio_wait` / `folio_wait_bit_common`, GNOME Shell stops repainting, `journald` reports `system.journal corrupted or uncleanly shut down` after each forced reboot. - `systemd-oomd` fired once because of the dirty-page pressure (`Pressure: Avg10: 87.24` → killed the kitty scope). ## Expected behaviour `sync` completes, `Dirty` returns to ~0, and the system stays responsive. ## Evidence that the storage device is NOT the cause - No `ata3.00: exception`, `failed command`, `Sense Key`, `Medium Error`, `critical medium error` or `Buffer I/O error` in any affected boot. - SMART: `Current_Pending_Sector = 8` and `Offline_Uncorrectable = 0`, both unchanged for over a year (pre-existing, no new reallocations, `UDMA_CRC_Error_Count = 0`, temperature 40 °C). - Reads and metadata operations continue working while writes are stuck — the device answers, it simply is never asked to write. - On the same disk and same filesystem, `7.0.0-38` handles the same workload with `sync` in 0.068 s and `Dirty: 0 kB`. ## Suspected area `wb_wait_for_completion()` / cgroup writeback (`inode_switch_wbs`) does not make progress. Possibly related to the cgroup-writeback changes tracked in LP #2170496 (panic in `rcu_do_batch`, suspected `cgroup_writeback_umount`), and to the Docker workload in LP #2172422. The writeback workqueue appears to stop being scheduled: the device queue is empty and `Writeback` stays ≈2 MB while `Dirty` grows to 1.3 GB. ## Workaround Pin the kernel to `7.0.0-38.38`; the regression disappears immediately. ## Attachments - `kernel-7.0.0-42-boot-1300-1705.txt` — first -42 boot (10 writeback stalls, 3 EXT4 errors) - `kernel-7.0.0-42-boot-1720-1853.txt` — second -42 boot, journal ends abruptly (hard freeze) - `kernel-7.0.0-42-boot-1855-2002.txt` — third -42 boot (52 writeback stalls, up to 386 s) - `live-snapshot.txt` — uname, meminfo, PSI, diskstats, kernel versions, apt holds - `linux-bug.apport` — `apport-cli -f -p linux` collection ## System information ``` Ubuntu 26.04.1 LTS (Resolute Raccoon) Lenovo ThinkPad T480 (20L5) Intel Core i7-8550U, Intel UHD Graphics 620 (i915) GNOME 50.1 / Wayland, Mesa 26.0.8, systemd 259.5 ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172527/+subscriptions
[Bug 2169319] Re: amdgpu: screen flashes at 120/144 Hz on RX 9060 XT (gfx1200), regression 7.0.0-34 -> 7.0.0-38
*** This bug is a duplicate of bug 2169181 *** https://bugs.launchpad.net/bugs/2169181 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169319 Title: amdgpu: screen flashes at 120/144 Hz on RX 9060 XT (gfx1200), regression 7.0.0-34 -> 7.0.0-38 Status in linux package in Ubuntu: Confirmed Bug description: After upgrading to linux-image-7.0.0-38-generic, a DisplayPort monitor shows ~1 ms visual flashes (tearing-like) at 120 Hz and 144 Hz. 7.0.0-34-generic is clean at the same refresh rate with identical userspace. Hardware - GPU: AMD Radeon RX 9060 XT (gfx1200), PCI 1002:7590, driver amdgpu - Display: HWV ZQE-CAA, 3440x1440, 165 Hz native, DP-1, 10 bpc, no DSC - Session: GNOME Wayland (mutter 50.1), Mesa 26.0.8 Symptom - Brief flashes on pointer motion and small damage repaints (typing in a terminal, overview hover, mouse movement). GL apps make it more frequent; it still happens with all GPU apps closed. - Clean at 60 Hz and 100 Hz. Glitches at 120 Hz and 144 Hz. - Clean on the GDM greeter. Regression - 7.0.0-34-generic: clean at 144 Hz. 7.0.0-38-generic: glitches at 144 Hz. - Same mutter, Mesa and monitor on both; only the kernel changed. - A second machine (AMD iGPU, internal panel, 7.0.0-34) is unaffected; it has not run -38 yet. Ruled out (still glitches on -38) - Userspace mismatch after upgrade (rebooted after full-upgrade) - GNOME animations disabled - Hardware cursor plane disabled (MUTTER_DEBUG_DISABLE_HW_CURSORS=1, MUTTER_DEBUG_INHIBIT_HW_CURSOR=1, verified in gnome-shell environ) - Overlay planes (MUTTER_DEBUG_FORCE_KMS_MODE=simple, verified) - Link side: dp1 link_settings (4 lanes, 0x1e = HBR3), DSC state (off), max bpc (10), amdgpu_dm_capabilities and amdgpu_dm_dtn_log are identical between -34 and -38 at 144 Hz. No DP link-training/DSC errors in dmesg on either kernel. Suspect commits (from the linux 7.0.0-38.38 changelog, not bisected) 1. drm/amd/display: consolidate DCN vblank/flip handling onto ... 2. drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources 3. drm/amd/display: Fix mem_type change detection for async flips 4. drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips Attached: dp1-link, dm-capabilities and dtn for both kernels, modes-DP1.txt, monitor-edid-34.txt in all in file ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: xorg (not installed) ProcVersionSignature: Ubuntu 7.0.0-34.34-generic 7.0.14 Uname: Linux 7.0.0-34-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Oct 2 18:38:04 2026 InstallationDate: Installed on 2025-02-22 (587 days ago) InstallationMedia: Ubuntu 24.04.2 LTS "Noble Numbat" - Release amd64 (20250215) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/zsh TERM=tmux-256color XDG_RUNTIME_DIR=<set> SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to resolute on 2026-10-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169319/+subscriptions
[Bug 2169181] Re: Visual background flickering and pixel artifacts after updating to kernel 7.0.0-38 (regression from 7.0.0-34) | Ubuntu 26.04 | AMD Radeon RX 9060
I also confirm that kernel 7.0.0-42-generic doesn't have the issue anymore. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169181 Title: Visual background flickering and pixel artifacts after updating to kernel 7.0.0-38 (regression from 7.0.0-34) | Ubuntu 26.04 | AMD Radeon RX 9060 Status in linux package in Ubuntu: Confirmed Bug description: I am experiencing intermittent pixel corruption and flickering artifacts in the background/desktop UI after updating to kernel version 7.0.0-38. Behavior: Random pixels/artifacts briefly flicker in the background from time to time. This issue was NOT present in kernel 7.0.0-34. The issue started immediately after updating to kernel 7.0.0-38. CPU: AMD Ryzen 5 9600X (12) @ 5.49 GHz GPU: AMD Radeon RX 9060 XT 16 GB[Discrete] P.S. I was planning to upgrade to the 26.10 beta this weekend, but I will stay on Resolute to help resolve this issue with any testing you might need. Thank you very much. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-38-generic 7.0.0-38.38 ProcVersionSignature: Ubuntu 7.0.0-38.38-generic 7.0.14 Uname: Linux 7.0.0-38-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Oct 1 18:29:50 2026 InstallationDate: Installed on 2026-08-31 (31 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlp11s0Link: Not connected. MachineType: ASUS System Product Name ProcEnviron: LANG=es_ES.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-38-generic root=UUID=1bdfa414-371c-4c93-9288-8cdc845cb610 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: 02/25/2026 dmi.bios.release: 38.41 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3841 dmi.board.asset.tag: Default string dmi.board.name: PRIME B650-PLUS WIFI 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.:bvr3841:bd02/25/2026:br38.41:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEB650-PLUSWIFI: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/2169181/+subscriptions
среда
[Bug 2172422] Re: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start
Root cause narrowed down to AppArmor signal mediation. On 7.0.0-42 and -43, the kernel log shows docker-default denying gosu's signals to its own threads, with the peer labelled as a stack: apparmor="DENIED" operation="signal" class="signal" profile="docker-default" pid=30562 comm="gosu" requested_mask="send" denied_mask="send" signal=rtmin+1 peer="docker-default//&unconfined" pid 30562 is the stuck gosu process. SIGRTMIN+1 is the signal Go's runtime uses for doAllThreadsSyscall (setuid/setgid on every thread). The threads never receive it, so the main thread spins in sched_yield forever. Counts of gosu signal denials per boot on the same host: 7.0.0-38: 0 7.0.0-42: 34x rtmin (+ int/term/urg) 7.0.0-43: 22x rtmin Control test: the same gosu 1.19 binary on 7.0.0-42 in a minimal KVM guest on the same CPU (no AppArmor policy, no Docker) completes instantly. So scheduling/futex are fine; the regression is that a container task's own threads are now labelled "docker-default//&unconfined" instead of "docker-default", so docker-default's "signal peer=docker-default" rule no longer matches. Affects any Docker container under the docker-default profile whose entrypoint drops privileges with Go >= 1.16-style all-threads setuid (official mariadb/postgres/mongo images). -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172422 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: Confirmed Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172422/+subscriptions
[Bug 2172428] [NEW] Touchpad SYNA2392 not detected on Lenovo 14w Gen 2 (82N9), created as platform device instead of I2C client
Public bug reported: Title: Lenovo 14w Gen 2 (82N9): Synaptics SYNA2392 touchpad not enumerated as I2C client (kernel 7.0.0-42) Hardware: Lenovo 14w Gen 2, model 82N9, AMD 3015e, BIOS LENOVO H0CN30WW (2024-09-18) Software: Linux Mint 22.3 XFCE (Ubuntu-based), kernel 7.0.0-42-generic Windows 11 on the same machine: touchpad worked normally. Problem: the internal touchpad is not detected. xinput list shows no touchpad. Findings: - ACPI: SYNA2392:00 present (status 15), ELAN238E:00 present (status 0). Both have _CID PNP0C50. - SYNA2392:00 is instantiated as a platform device (subsystem -> platform), not as an I2C client. There is no i2c-SYNA2392:00 in /sys/bus/i2c/devices. - Its parent controller AMDI0010:01 is bound to i2c_designware, but /sys/bus/platform/devices/AMDI0010:01/i2c-1/ has no client device. - i2c_hid_acpi and hid_multitouch are loaded or loadable; nothing happens. - No related messages in dmesg, no ACPI errors. - Same result after updating from 7.0.0-38 to 7.0.0-42. DSDT (Scope _SB.I2CD, Device TPD0): _CRS returns an I2cSerialBusV2 resource (0x15 or 0x2C) only if the EC field TPTY equals 1 or 2. For any other value, nothing is returned. Reading TPTY afterwards via ec_sys (offset 0x9F) gives 02, consistent with the Synaptics. Hypothesis (unconfirmed): _CRS is evaluated during enumeration when TPTY is not yet valid, so the device is created without an I2C resource. Question: is this a known issue with this firmware? Happy to test patches or provide more output. ** 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/2172428 Title: Touchpad SYNA2392 not detected on Lenovo 14w Gen 2 (82N9), created as platform device instead of I2C client Status in linux package in Ubuntu: New Bug description: Title: Lenovo 14w Gen 2 (82N9): Synaptics SYNA2392 touchpad not enumerated as I2C client (kernel 7.0.0-42) Hardware: Lenovo 14w Gen 2, model 82N9, AMD 3015e, BIOS LENOVO H0CN30WW (2024-09-18) Software: Linux Mint 22.3 XFCE (Ubuntu-based), kernel 7.0.0-42-generic Windows 11 on the same machine: touchpad worked normally. Problem: the internal touchpad is not detected. xinput list shows no touchpad. Findings: - ACPI: SYNA2392:00 present (status 15), ELAN238E:00 present (status 0). Both have _CID PNP0C50. - SYNA2392:00 is instantiated as a platform device (subsystem -> platform), not as an I2C client. There is no i2c-SYNA2392:00 in /sys/bus/i2c/devices. - Its parent controller AMDI0010:01 is bound to i2c_designware, but /sys/bus/platform/devices/AMDI0010:01/i2c-1/ has no client device. - i2c_hid_acpi and hid_multitouch are loaded or loadable; nothing happens. - No related messages in dmesg, no ACPI errors. - Same result after updating from 7.0.0-38 to 7.0.0-42. DSDT (Scope _SB.I2CD, Device TPD0): _CRS returns an I2cSerialBusV2 resource (0x15 or 0x2C) only if the EC field TPTY equals 1 or 2. For any other value, nothing is returned. Reading TPTY afterwards via ec_sys (offset 0x9F) gives 02, consistent with the Synaptics. Hypothesis (unconfirmed): _CRS is evaluated during enumeration when TPTY is not yet valid, so the device is created without an I2C resource. Question: is this a known issue with this firmware? Happy to test patches or provide more output. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172428/+subscriptions
[Bug 2172423] Re: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start
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/2172423 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: Confirmed Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172423/+subscriptions
[Bug 2172423] Re: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start
Installed kernel packages (-38 working, -42 and -43 broken) and uname -a from the running -38 kernel. ** Attachment added: "kernels-installed.log" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172423/+attachment/6013235/+files/kernels-installed.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172423 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: New Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172423/+subscriptions
[Bug 2172423] Re: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start
** 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/2172423 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: New Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172423/+subscriptions
[Bug 2172423] [NEW] Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start
Public bug reported: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-daily-bug ** Attachment added: "version.log" https://bugs.launchpad.net/bugs/2172423/+attachment/6013233/+files/version.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172423 Title: Regression 7.0.0-42/-43: Go 1.24 programs livelock in setuid (gosu); official DB Docker images hang on start Status in linux package in Ubuntu: New Bug description: Summary ------- After upgrading from 7.0.0-38 to 7.0.0-42 (resolute-updates, published 2026-10-28), gosu 1.19 (built with Go 1.24.6) never returns. The official mariadb, postgres and mongo Docker images use gosu to drop privileges in their entrypoints, so all of those containers hang at "Switching to dedicated user" indefinitely. 7.0.0-43 from -proposed shows the same behavior. Booting back to 7.0.0-38 fixes it immediately. Reproducer ---------- timeout 60 docker run --rm --entrypoint gosu mariadb:10.11 nobody id 7.0.0-38: prints "uid=65534(nobody) gid=65534(nogroup) ..." instantly 7.0.0-42: hangs until the timeout 7.0.0-43: hangs until the timeout On -42 and -43 this was tested at 10+ minutes of uptime, after the boot-time load had settled. Stuck gosu processes were still alive after 270+ seconds. On -42 the host stayed in this state for ~10 hours (database containers restarted ~180 times each, never starting). Observations ------------ - strace -f of a stuck gosu process (6 threads): main thread: sched_yield() = 0, repeated forever other 5: futex(..., FUTEX_WAIT_PRIVATE, 0, NULL) (never woken) This looks like Go's all-threads setuid/setgid path (runtime.doAllThreadsSyscall) waiting forever for threads that are never woken or signaled. - gosu 1.13 built with Go 1.16.5 (image mariadb:10.6.4-focal) WORKS on 7.0.0-43. Only the newer Go runtime (1.24.6) is affected. - Same host, same images; only the kernel changed. The same images work on other hosts running 7.0.0-38. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172423/+subscriptions
вторник
[Bug 2148638] Re: ubuntu 26.04 - When the NVME hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized.
Hi Aaron, Do we have update for this issue? Thanks. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148638 Title: ubuntu 26.04 - When the NVME hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized. Status in linux package in Ubuntu: New Status in linux source package in Resolute: New Bug description: When the CD8P NVMe hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized. This issue happens on CD8P NVMe disk and does not happens on bm1743 NVMe disk. CD8P drives are Kaoxia drives The BM1743 drives that work are Samsung devices. Nvme disk detail: CD8P https://lenovopress.lenovo.com/lp1904-thinksystem-cd8p-read-intensive-nvme-pcie-50-ssd bm1743 https://lenovopress.lenovo.com/lp2156-thinksystem-bm1743-read-intensive-nvme-pcie-50-x4-ssd Steps to reproduce: 1.In the UEFI, enable VMD without created RAID disk. 2.Install ubuntu26.04 on M.2 sata disk. 3.use command lsblk to check all NVMEe disk 4.Unplug all NVMe device, then check NVMe device information again via lsblk. 5.plug all NVMe SSD 6.OS reported an error and some of the drives were not recognized. Compare with Ubuntu 24.04: There is no errors messages and all NVMe disks can be recognized after re-plug all NVMe SSD Info: The issue also happens on latest daily build: 0415 This issue only happens on VMD enabled, there is no this issue when vmd feature disable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148638/+subscriptions