[РЕШЕНО] Ошибка № ...

воскресенье

[Bug 2162837] Re: ThinkPad T14 Gen 5 Intel automatically powers on after successful shutdown

I am experiencing the exact same Embedded Controller shutdown issue on a ThinkPad T16 Gen 3 (Meteor Lake).I am running Linux Mint 22 (Ubuntu base) using the Kernel 7.0.0-30-generic.Behavior:Upon triggering a regular shutdown, the system blanks the screen and cuts power for 3 seconds, but then the laptop boots itself back up automatically.Important details & Current Workaround:The machine used to run Windows 11 perfectly fine without any shutdown or reboot loops.As a temporary workaround, I mapped the physical power button to Hibernate. Hibernation works correctly and the laptop remains powered off, confirming this is specifically an ACPI S5 shutdown / EC handshake bug under Linux.Please include the ThinkPad T16 Gen 3 in the hardware list for the upcoming EC/Kernel fixes. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162837 Title: ThinkPad T14 Gen 5 Intel automatically powers on after successful shutdown Status in linux package in Ubuntu: New Bug description: Similar to Ubuntu bug #2138359 on ThinkPad P14s Gen 5 Intel, but reproduced on ThinkPad T14 Gen 5 Intel. Hardware Model: Lenovo ThinkPad T14 Gen 5 Intel Machine Type: 21MMS57F00 CPU: Intel Core Ultra 7 155U (Meteor Lake) BIOS: N47ET29W (1.18) Operating System Ubuntu 24.04.4 LTS Kernel: 6.17.0-35-generic Desktop: GNOME 46 (Wayland) Problem After selecting "Power Off" from GNOME or executing: sudo systemctl poweroff the system performs a normal shutdown. The display turns off. The fan stops. The power LED turns off. Approximately 1–3 seconds later the notebook powers on again automatically without pressing the power button. This is not a reboot. The system fully powers off before powering on again. Expected result The notebook should remain powered off. Actual result The notebook automatically powers on again. Troubleshooting already performed - Tested GNOME shutdown. - Tested "sudo systemctl poweroff". - Battery only. - AC adapter connected. - USB mouse connected and disconnected. - Wake-on-LAN disabled. - RTC wakealarm is empty. - ACPI wake sources disabled using /proc/acpi/wakeup. - Latest BIOS installed (1.18). - journalctl shows successful PowerOff. - systemd-logind correctly requests PowerOff (not Reboot). - fwts reports no critical ACPI firmware errors. No change. Windows comparison Windows 11 on the same machine shuts down correctly and remains powered off. History The issue has existed across multiple BIOS versions. The motherboard has already been replaced twice by Lenovo service. The problem remains unchanged. Additional information A complete diagnostic archive is attached (thinkpad_shutdown_bug.tar.gz). This issue appears very similar to Ubuntu bug #2138359 reported on ThinkPad P14s Gen 5 Intel using the same Intel Meteor Lake platform. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162837/+subscriptions

[Bug 2159596] Re: amdgpu fails to come up due to BAR issue when at PCIe root

Is this related? https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2164850 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159596 Title: amdgpu fails to come up due to BAR issue when at PCIe root Status in linux package in Ubuntu: Triaged Status in linux-hwe-7.0 package in Ubuntu: Triaged Bug description: With the 7.0 hwe kernel on 24.04 (and presumably also the 7.0 kernel on 26.04), amdgpu completely fails to init on the SolidRun HoneyComb LX2 (NXP LX2160A, arm64, ACPI), where the GPU endpoint is enumerated directly on the root bus of its segment (there is no root port device, so pdev->bus->self is NULL): amdgpu 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: releasing amdgpu 0004:01:00.0: BAR 2 [mem 0xa410000000-0xa4101fffff 64bit pref]: releasing amdgpu 0004:01:00.0: sw_init of IP block <gmc_v8_0> failed -19 amdgpu 0004:01:00.0: amdgpu_device_ip_init failed amdgpu 0004:01:00.0: Fatal error during GPU init No error is logged because the resize path reports success; amdgpu then finds BAR0 IORESOURCE_UNSET and bails out with -ENODEV. Observed at runtime on Ubuntu's linux-hwe-7.0 (7.0.0-14, broken) vs linux-hwe-6.17 (working), but nothing here is distro-specific: Ubuntu carries this code unmodified, and the affected function is identical to current mainline. By source inspection the regression window is v6.18 (old code paths) to v6.19 (consolidation). See https://lkml.org/lkml/2026/7/5/502 for full description and patch. Workaround is to disable resizable BAR using amdgpu.rebar=0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159596/+subscriptions

[Bug 2163363] Re: [amdgpu/ttm] TTM list corruption and NULL dereference under GPU memory pressure on ASUS ProArt PX13 (7.0.0-29)

Now three days, no crashes. Previously 3 or 4 per day. Let me know if further confirmation helps. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163363 Title: [amdgpu/ttm] TTM list corruption and NULL dereference under GPU memory pressure on ASUS ProArt PX13 (7.0.0-29) Status in linux package in Ubuntu: Confirmed Bug description: An ASUS ProArt PX13 HN7306EAC with an AMD integrated GPU (PCI ID 1002:1586) repeatedly experienced kernel-side TTM/AMDGPU corruption and complete graphical failure while running Ubuntu 26.04 kernel 7.0.0-29-generic. The failures occurred with different visible userspace processes. They are therefore reported as possible triggers, not assumed root causes. FIRST HARD FREEZE / NULL DEREFERENCE A complete desktop freeze required a hard reset. The first fatal event was: BUG: kernel NULL pointer dereference, address: 0000000000000019 Comm: ptyxis RIP: ttm_lru_bulk_move_pos_tail+0x53/0xd0 [ttm] Relevant call path: ttm_resource_add_bulk_move ttm_bo_populate ttm_bo_vm_fault_reserved amdgpu_gem_fault A previous occurrence involved firefox:gl0 and failed in the same TTM/AMDGPU resource-management area. LATER TTM LIST CORRUPTION Immediately before the warnings, the kernel repeatedly logged: amdgpu_vm_validate() failed. Not enough memory for command submission! This was followed by: list_add corruption list_del corruption Relevant call paths included: ttm_resource_move_to_lru_tail ttm_bo_populate ttm_bo_vm_fault_reserved amdgpu_gem_fault and: ttm_resource_fini ttm_resource_free amdgpu_bo_move amdgpu_cs_bo_validate amdgpu_cs_ioctl LATER GRAPHICAL-SESSION FAILURE AMDGPU again rejected command submissions with -12. GNOME Shell then aborted with SIGABRT in Mesa Gallium, closing the Wayland session and all terminal applications. This event was a graphical-session restart, not a full machine reboot. ENVIRONMENT Hardware: ASUS ProArt PX13 HN7306EAC CPU/GPU: AMD Ryzen AI Max+ 395 / Radeon 8060S GPU PCI ID: 1002:1586 BIOS: HN7306EAC.307 (2026-01-27) RAM: 128 GB shared system/GPU memory Distribution: Ubuntu 26.04 Kernel: 7.0.0-29-generic, package 7.0.0-29.29 (upstream base 7.0.12) Desktop: GNOME on Wayland WORKLOAD / POSSIBLE TRIGGER Local llama.cpp/Vulkan language-model workloads and desktop applications were active. They use shared system/GPU memory and may increase memory pressure. This is reported as a possible trigger only, not as a demonstrated root cause. NEGATIVE EVIDENCE The inspected logs before the first Oops did not show an OOM kill, MCE, thermal shutdown, PCIe AER error, GPU ring timeout, or GPU reset. The kernel was not tainted before the first Oops. EXPECTED RESULT Userspace GPU activity or memory pressure must not corrupt TTM lists, trigger a kernel NULL pointer dereference, or terminate the graphical session. PRIVACY No vmcore, dump-incomplete, or full memory image is attached because those artifacts may contain credentials, documents, medical data, and browser contents. RELATED REPORT A public report with a similar ttm_lru_bulk_move_pos_tail signature and hard desktop freeze is available at: https://github.com/basecamp/omarchy/issues/6443 --- ProblemType: Bug ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 26.04 InstallationDate: Installed on 2026-08-01 (15 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS ProArt PX13 HN7306EAC Package: linux (not installed) 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-29-generic root=UUID=80141fa6-a50a-4bc8-816b-cc4d43d1fa74 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12 Tags: resolute wayland-session Uname: Linux 7.0.0-29-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sudo users _MarkForUpload: True dmi.bios.date: 01/27/2026 dmi.bios.release: 5.36 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: HN7306EAC.307 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: HN7306EAC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 3.6 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrHN7306EAC.307:bd01/27/2026:br5.36:efr3.6:svnASUS:pnProArtPX13HN7306EAC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnHN7306EAC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct31:cvr1.0:sku:pfaProArtPX13: dmi.product.family: ProArt PX13 dmi.product.name: ProArt PX13 HN7306EAC dmi.product.version: 1.0 dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163363/+subscriptions

суббота

[Bug 2162722] Re: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg)

Recurrence on 2026-08-23 14:29 JST — different RIP (lru_activate, not lru_gen_del_folio). Kernel: 7.0.0-30-generic #30-Ubuntu SMP PREEMPT_DYNAMIC Package: linux-image-7.0.0-30-generic 7.0.0-30.30 Oops: page fault (not-present page) at lru_activate+0x91/0x3e0 Comm: libuv-worker (PID 46527, UID 1000) Tainted: G OE (nvidia and other OOT modules) Call trace (kernel): lru_activate folio_batch_move_lru __folio_batch_add_and_move folio_mark_accessed filemap_read generic_file_read_iter ext4_file_read_iter vfs_read -> ksys_read -> read syscall This is a read-path fault during ext4 file I/O, not exit_mmap / folio release like the original report and my 2026-08-14 comment (lru_gen_del_folio). kdump: /var/crash/202608231429/ (dmesg excerpt attached) Hardware: ASUS PRIME Z690M-PLUS D4, BIOS 3811, RTX 5060 Ti, 64GB RAM — not OOM. Context: - Root ext4 on /dev/nvme0n1p2 had metadata corruption on 2026-08-22 night; offline fsck -fy from Live USB completed earlier on 2026-08-23 ~00:37 JST; subsequent boots reported clean and no EXT4-fs error lines in journal for ~5h session. - This oops kdump dmesg also shows no EXT4-fs error lines before the fault. - MGLRU mitigation from my 2026-08-14 comment remains applied: /etc/tmpfiles.d/disable-mglru.conf (w ... N), cat /sys/kernel/mm/lru_gen/enabled -> 0x0000 at crash time. Disabling MGLRU did not prevent this lru_activate fault. Prior recurrences on this machine (same bug, various RIPs): | Date (JST) | Kernel | RIP / path | Comm | |-------------------|----------|-------------------------|-----------------| | 2026-08-03 17:25 | 7.0.0-28 | lru_gen_del_folio | ThreadPoolForeg | | 2026-08-09 16:39 | 7.0.0-29 | lru_gen_del_folio | kswapd0 | | 2026-08-13 14:14 | 7.0.0-29 | lru_gen_del_folio | node (Cursor) | | 2026-08-14 03:41 | 7.0.0-29 | lru_gen_del_folio | ThreadPoolForeg | | 2026-08-23 14:29 | 7.0.0-30 | lru_activate (this post)| libuv-worker | Related local investigation (not part of Ubuntu): hostpc OS stability audit 2026-08-23. ** Attachment added: "launchpad_2162722_kdump_dmesg_202608231429.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162722/+attachment/5994486/+files/launchpad_2162722_kdump_dmesg_202608231429.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162722 Title: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg) Status in linux package in Ubuntu: New Bug description: DistroRelease: Ubuntu 26.04 LTS (resolute) Package: linux-image-7.0.0-28-generic 7.0.0-28.28 Kernel: Linux 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC x86_64 Hardware: ASUS PRIME Z690M-PLUS D4, BIOS 3811 GPU: NVIDIA GeForce RTX 5060 Ti (driver 610.43.02, tainted OE) Impact of the bug: The entire system rebooted unexpectedly (kdump). Work in progress was lost. What I expected to happen: The desktop session should remain stable under normal application load. What actually happened: On 2026-08-03 ~17:25 JST, during heavy Electron/Chromium workload (Cursor IDE agent/plan build), the kernel hit an Oops and kdump triggered an automatic reboot. kdump artifacts: /var/crash/202608031725/ (dmesg + vmcore) Apport ticket: cb836c7a-8f1f-11f1-8811-9953c338e1ca Kernel Oops (from kdump dmesg): Oops: general protection fault, probably for non-canonical address 0xffff7127d16b6d48: 0000 [#1] SMP NOPTI CPU: 6 PID: 80704 Comm: ThreadPoolForeg Tainted: G OE (nvidia out-of-tree modules loaded) RIP: lru_gen_del_folio.constprop.0+0x19a/0x380 Call Trace: lru_gen_del_folio __page_cache_release.part.0 folios_put_refs free_pages_and_swap_cache zap_pte_range exit_mmap do_exit get_signal Not OOM: 64 GB RAM, swap unused at time of crash. Correlating load (not proven causal): - GNOME localsearch indexing CIFS/rclone/SSHFS mounts under ~/drive and ~/mnt - CIFS automount retries to unreachable //192.168.1.152/ (return code -113/-4) Host mitigations already applied locally: - localsearch ignored-directories: drive, mnt - Disabled unreachable .152 CIFS fstab automount Regression notes: Similar sudden reboots were rare on Ubuntu 24.04 (6.8 kernel). This is the first kdump on 26.04 / 7.0.0-28-generic on this machine. 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: ytsubame 2780 F.... wireplumber /dev/snd/controlC0: ytsubame 2780 F.... wireplumber /dev/snd/seq: ytsubame 2696 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 3 18:39:40 2026 InstallationDate: Installed on 2026-07-13 (21 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name PackageArchitecture: amd64 ProcEnviron: LANG=ja_JP.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=dumb XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=9061133c-3778-49ec-85ba-ecb208384534 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: 0: hci0: Bluetooth Soft blocked: no Hard blocked: no SourcePackage: linux Title: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg) UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True dmi.bios.date: 10/22/2025 dmi.bios.release: 38.11 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3811 dmi.board.asset.tag: Default string dmi.board.name: PRIME Z690M-PLUS D4 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.:bvr3811:bd10/22/2025:br38.11:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEZ690M-PLUSD4: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/2162722/+subscriptions

[Bug 2161148] Re: [SRU] intel_backlight (i915/eDP AUX-DPCD) stops responding to live brightness writes in 7.0.0-28-generic (works in 6.17.0-40-generic)

*** This bug is a duplicate of bug 2161309 *** https://bugs.launchpad.net/bugs/2161309 --- Confirmed same regression on a **ThinkPad X1 Yoga 3rd gen** (Intel UHD 620 / Whiskey Lake, eDP panel **CMN N140HCE-GP2**), kernel `7.0.0-28-generic`. Adding another confirmed hardware combination plus one data point that seems important for the SRU: **the choice of `enable_dpcd_backlight` value determines whether *live* writes work or only boot-time initial brightness.** - `intel_backlight` registered; sysfs writes stick (`brightness == actual_brightness`) but the panel does not respond — identical to the "silent failure" described above. - With `acpi_backlight=native i915.enable_dpcd_backlight=1`: boot-time initial brightness was correct, but slider/keys/`echo > brightness` had no visual effect (same as the earlier reporter's result with =1/=3). I verified the panel itself is healthy and PWM-wired by sweeping the PCH PWM duty-cycle register directly via MMIO (`resource0`, base `0x2ffa000000`, duty reg at offset `0xc8254`, frequency counter = 1060) during a pristine-state boot where the driver backlight path stays uninitialized (`acpi_backlight=video`, so no DPCD/PWM latch has happened yet). Sweeping the duty cycle changed the panel brightness **visibly** — so the panel TCON responds to the PWM pin fine. Conclusion consistent with the bug title: on 7.0.0-28 the i915 backlight-selection heuristic puts the panel into VESA DPCD/AUX mode, the TCON latches into that mode, and from then on the PWM pin (which `intel_backlight` drives) is ignored. Sysfs keeps reporting success, which matches everyone's "silent failure" observations. ``` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=native i915.enable_dpcd_backlight=0" ``` After reboot with these parameters: `intel_backlight` registered (max_brightness 1060), and **live** brightness updates work — keys, GNOME slider, and sysfs writes all visibly change the screen. This differs usefully from the earlier test with `enable_dpcd_backlight=1`: blocking the DPCD selection entirely (=0) restores the full write path, not just initial level. Worth keeping in mind for whoever tests SRU kernels: `=0` and `=1` are not equivalent workarounds on affected panels. Happy to provide dmesg/journal excerpts if useful. — yaleed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161148 Title: [SRU] intel_backlight (i915/eDP AUX-DPCD) stops responding to live brightness writes in 7.0.0-28-generic (works in 6.17.0-40-generic) Status in linux package in Ubuntu: Fix Committed Bug description: After the kernel update to 7.0.0-28-generic (HWE, arrived alongside a KDE Plasma update), the internal laptop screen brightness became stuck at maximum. The /sys/class/backlight/intel_backlight/brightness sysfs value still changes correctly (both via the KDE Plasma slider and via manual echo > brightness), and org.kde.powerdevil.backlighthelper is invoked successfully each time, but the physical panel brightness no longer follows the value at runtime. Booting the previous kernel (6.17.0-40-generic) with the exact same GRUB configuration (no special kernel parameters) restores correct behaviour immediately: both the slider and manual sysfs writes change the physical screen brightness as expected. This points to a regression in the i915 driver's eDP AUX/DPCD backlight write path in 7.0.0-28-generic, not an issue with KDE Plasma/powerdevil (which was ruled out — see tests below). System information Laptop: Dell Vostro 15 3510 GPU: Intel UHD Graphics G4 (Tiger Lake-LP GT2, 48EU) — i915 0000:00:02.0, device ID 9a78, "tigerlake/uy" OS: Ubuntu Noble 24.04 (KDE neon on top) Desktop: KDE Plasma (recently updated) Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28~24.04.1, via linux-generic-hwe-24.04) Working kernel: linux-image-6.17.0-40-generic (6.17.0-40.40~24.04.1) GRUB config: default, no special parameters (GRUB_CMDLINE_LINUX_DEFAULT="quiet splash") Steps to reproduce (on 7.0.0-28-generic) Boot into 7.0.0-28-generic with a clean/default GRUB command line. Check the sysfs interface: ls /sys/class/backlight/ → intel_backlight cat /sys/class/backlight/intel_backlight/brightness cat /sys/class/backlight/intel_backlight/max_brightness → e.g. 410 / 1023 Change brightness via the KDE Plasma slider, or manually: echo 200 | sudo tee /sys/class/backlight/intel_backlight/brightness Observe: the sysfs value updates correctly (confirmed by reading it back), and org.kde.powerdevil.backlighthelper is activated successfully in the journal, but the physical screen brightness does not change — it stays at the level set at boot time by systemd-backlight. Steps to reproduce the working case (6.17.0-40-generic) Boot into 6.17.0-40-generic with the same, unmodified GRUB command line. Note the sysfs interface uses a different (raw PWM-like) brightness scale on this kernel, e.g. max_brightness in the tens of thousands rather than 1023. Repeat the same slider / manual echo test. Observe: the physical screen brightness follows the value correctly, both from the KDE Plasma slider and from manual sysfs writes. What we ruled out KDE Plasma / powerdevil is not at fault. org.kde.powerdevil.backlighthelper is called successfully via D-Bus/KAuth every time the slider is moved, on both kernels, and the sysfs value is written correctly in both cases. The failure is purely between "sysfs value" and "physical panel output", which is below the desktop environment / kernel userspace boundary. Not a permissions issue. /sys/class/backlight/intel_backlight/brightness write succeeds (verified via direct sudo tee), the value persists when re-read. Tried acpi_backlight=native and acpi_backlight=vendor kernel parameters on 7.0.0-28-generic: acpi_backlight=vendor → intel_backlight sysfs interface disappears entirely (i915: [drm] Skipping intel_backlight registration in dmesg), no backlight class device is exposed at all on this hardware. acpi_backlight=native → interface present, sysfs value changes, but no physical brightness change (same broken behaviour as default). Tried i915.enable_dpcd_backlight=1 and =3 (note: per modinfo i915, this parameter is actually boolean, so both likely evaluated to the same "enabled" state) combined with acpi_backlight=native: Fixed the boot-time initial brightness (screen now dims to the value saved/restored by systemd-backlight at boot, instead of being stuck at 100%). Did not fix live/runtime updates — slider and manual sysfs writes still don't change the physical brightness after boot. dmesg during a live brightness write shows no relevant AUX/DPCD/backlight error messages on 7.0.0-28-generic (driver does not log at that verbosity by default) — happy to gather more verbose i915 debug logs if useful (e.g. via drm.debug). Expected behaviour Writing to /sys/class/backlight/intel_backlight/brightness (whether via the desktop environment or directly) should change the physical panel brightness at runtime, as it does on 6.17.0-40-generic with identical hardware and GRUB configuration. Actual behaviour On 7.0.0-28-generic, only the kernel's own boot-time backlight restoration (systemd-backlight@backlight:intel_backlight.service) succeeds in setting a correct initial physical brightness (and only when acpi_backlight=native i915.enable_dpcd_backlight=1 is set); all subsequent runtime writes to the sysfs brightness file are silently ignored by the hardware, even though the sysfs value itself updates. Current workaround Pinning/holding the working kernel as default via GRUB (GRUB_DEFAULT=saved + grub-set-default) and holding the linux- image-7.0.0-28-generic / linux-generic-hwe-24.04 packages to prevent apt from reactivating the broken kernel on the next update. Additional info available on request Full journalctl -b output around powerdevil/backlight activity on both kernels dmesg output on both kernels Willing to test additional kernel parameters or debug builds if it helps narrow down the regression --- ProblemType: Bug ApportVersion: 2.28.2-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: marco 1381 F.... pipewire marco 1385 F.... wireplumber /dev/snd/pcmC0D0p: marco 1381 F...m pipewire /dev/snd/seq: marco 1381 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: KDE DistroRelease: KDE neon 24.04 InstallationDate: Installed on 2024-09-15 (676 days ago) InstallationMedia: neon user "Jammy" - Build amd64 LIVE Binary 20240905-07:31 Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0c45:6730 Microdia Integrated_Webcam_HD Bus 001 Device 003: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP) Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: Dell Inc. Vostro 15 3510 Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=c2da2a46-13bf-4152-abce-a885e59c21bd ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 7.0.0-28.28~24.04.1-generic 7.0.12 RelatedPackageVersions: linux-restricted-modules-7.0.0-28-generic N/A linux-backports-modules-7.0.0-28-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 Tags: noble wayland-session Uname: Linux 7.0.0-28-generic x86_64 UpgradeStatus: Upgraded to noble on 2024-10-13 (648 days ago) UserGroups: adm cdrom dip docker lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 03/31/2026 dmi.bios.release: 1.45 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.45.0 dmi.board.name: 069V6G dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.45.0:bd03/31/2026:br1.45:svnDellInc.:pnVostro153510:pvr:rvnDellInc.:rn069V6G:rvrA00:cvnDellInc.:ct10:cvr:sku0AB2:pfaVostro: dmi.product.family: Vostro dmi.product.name: Vostro 15 3510 dmi.product.sku: 0AB2 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161148/+subscriptions

[Bug 1815588] Re: speed mismatch trying to attach usb device to guest vm

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.] ** Changed in: libvirt (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1815588 Title: speed mismatch trying to attach usb device to guest vm Status in libvirt package in Ubuntu: Expired Status in linux package in Ubuntu: Invalid Bug description: Distro: 18.04.02, just recently upgraded from 16.04 MachineType: LENOVO 20J7S02N00 All of the machines USB ports are USB 3.0 I added the USB drive from virt-managers UI. Trying to start the guest vm results in: Error starting domain: internal error: process exited while connecting to monitor: 2019-02-12T11:12:16.334471Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed) 2019-02-12T11:12:16.485645Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: failed to open host usb device 2:2 Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1508, in startup self._backend.create() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1062, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error: process exited while connecting to monitor: 2019-02-12T11:12:16.334471Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed) 2019-02-12T11:12:16.485645Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: failed to open host usb device 2:2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815588/+subscriptions

[Bug 2164686] Re: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu

Thanks, Daniel — that context is very helpful. To confirm: this Lenovo Mullins/Kabini system is running Ubuntu 24.04 with kernel 7.0.0-30-generic, so it’s still on the pre-7.1 behaviour where Sea Islands APUs default to radeon. After manually switching to amdgpu (via SI/CIK parameters and radeon blacklist), the system becomes fully stable: multi-monitor output works correctly, Chrome/Electron apps stop flickering, and chrome://gpu shows a clean ANGLE + amdgpu pipeline with zero GPU process crashes. So this hardware does behave exactly like the upstream 7.1 change expects. I’m happy to test again once Ubuntu ships a 7.1-based kernel, or provide any additional logs if useful. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164686 Title: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Status in linux package in Ubuntu: New Bug description: Bug Report: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Summary On Ubuntu 24.04 (kernel 7.0.0-30-generic), my Lenovo system with an AMD Mullins/Kabini APU consistently defaults to the legacy radeon driver. This hardware fully supports amdgpu, and switching to amdgpu results in immediate and significant stability improvements, including correct multi-monitor behaviour and stable GPU acceleration in Chromium-based applications. This suggests the driver-selection heuristics for Sea Islands (CIK) hardware may need updating. My subsystem ID (17aa:369a) may be missing from the amdgpu-preferred list. Hardware - Model: Lenovo desktop - GPU: AMD Mullins / Radeon R4/R5 Graphics - PCI ID: 1002:9851 - Subsystem: 17aa:369a - Generation: Sea Islands (CIK) Incorrect default behaviour On a clean Ubuntu install, the system binds the GPU to the legacy radeon driver: lspci -nnk | grep -A3 VGA Kernel driver in use: radeon Kernel modules: radeon, amdgpu Using radeon causes: - GPU process crashes in Chrome/Chromium - flickering and corrupted text input - unstable multi-monitor behaviour - degraded performance in Electron apps - fallback to software rendering in some cases Correct behaviour after manual override After enabling amdgpu and disabling radeon via kernel parameters: amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0 radeon.cik_support=0 and blacklisting radeon, the system boots with: Kernel driver in use: amdgpu Kernel modules: radeon, amdgpu Chrome’s GPU diagnostics confirm stable hardware acceleration: - Canvas: Hardware accelerated - Compositing: Hardware accelerated - WebGL: Hardware accelerated - GPU process crash count: 0 Multi-monitor output also becomes stable. Evidence from chrome://gpu Representative lines: GL_RENDERER: ANGLE (AMD Radeon R5 Graphics … Mesa 26.0.8) GPU process crash count: 0 This demonstrates that amdgpu + Mesa 26 is fully functional on this hardware. Kernel logs dmesg shows amdgpu initialising: amdgpu: Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node This indicates the module loads correctly but is not selected by default. Expected behaviour Ubuntu should bind Mullins/Kabini APUs to amdgpu by default when: - the hardware supports it - the module loads cleanly - the modern driver provides significantly better stability This may require: - adding subsystem ID 17aa:369a to amdgpu-preferred lists - adjusting SI/CIK detection heuristics - updating documentation for Mullins/Kabini users Request Please evaluate whether this Lenovo Mullins/Kabini device should default to amdgpu rather than radeon, and whether the driver-selection rules for Sea Islands hardware need updating. I am happy to provide full logs, kernel dumps, or run additional tests if needed. (This report was generated with the assistance of Microsoft Copilot after investigating persistent Chrome flickering and keyboard input corruption on this hardware. Firefox was unaffected. I don’t claim to fully understand the underlying driver behaviour, but the evidence above reflects the results of the investigation.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164686/+subscriptions

[Bug 2164800] Re: SAUCE: Revert erroneous application of "netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()"

** 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/2164800 Title: SAUCE: Revert erroneous application of "netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()" Status in linux package in Ubuntu: In Progress Status in linux source package in Jammy: New Bug description: BugLink: https://bugs.launchpad.net/bugs/2164800 [Impact] Upstream commit f41c5d151078 ("netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()") was incorrectly reapplied to the j:linux tree during the v5.15.200 stable upstream pull, modifying the wrong function (nft_map_catchall_deactivate). [Fix] Revert the problematic commit. [Test plan] Build tested only. [Where problems could occur] Any issues (albeit unlikely) with this could negatively impact netfilter in affected systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164800/+subscriptions

[Bug 2164818] Re: Working then suddenly off for no reason.

** 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/2164818 Title: Working then suddenly off for no reason. Status in linux package in Ubuntu: New Bug description: Laptop went off suddenly. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-138-generic 6.8.0-138.138 ProcVersionSignature: Ubuntu 6.8.0-138.138-generic 6.8.12 Uname: Linux 6.8.0-138-generic x86_64 ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: qd91 3088 F.... wireplumber /dev/snd/controlC1: qd91 3088 F.... wireplumber /dev/snd/seq: qd91 3083 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Aug 22 17:50:26 2026 InstallationDate: Installed on 2024-02-08 (926 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: Dell Inc. Latitude 5420 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-138-generic root=UUID=02738a08-52ac-4d19-88c9-cacd3b303bbb ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-138-generic N/A linux-backports-modules-6.8.0-138-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2024-05-22 (822 days ago) dmi.bios.date: 05/26/2026 dmi.bios.release: 1.55 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.55.0 dmi.board.name: 0772C9 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.55.0:bd05/26/2026:br1.55:svnDellInc.:pnLatitude5420:pvr:rvnDellInc.:rn0772C9:rvrA00:cvnDellInc.:ct10:cvr:sku0A20: dmi.product.family: Latitude dmi.product.name: Latitude 5420 dmi.product.sku: 0A20 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164818/+subscriptions

Re: [Bug 2161098] Re: Random hard freezes caused by i915 kernel page fault in eb_relocate_parse_slow on MacBookAir6,2 (Intel HD 5000)acBookAir6,2 (Intel HD 5000)

Hi Alice, Thank you very much for providing the patched kernel and for your work on this issue. I tested it as instructed, installing only the two packages you mentioned: * |linux-image-unsigned-6.8.0-139-generic| * |linux-modules-6.8.0-139-generic| I did not add the Canonical kernel team PPA or make any other configuration changes. Unfortunately, the result of the test was not usable. After booting into |6.8.0-139-generic|, Ubuntu reached the normal graphical desktop, and the GNOME clock continued running, so the system itself did not appear to be completely frozen. However: * the built-in keyboard was completely unresponsive; * the built-in trackpad was completely unresponsive; * my Bluetooth mouse was also completely unresponsive; * the Wi-Fi/network indicator was missing, and Wi-Fi appeared to be unavailable; * the only physical control that continued to respond was the power button. I therefore had to perform a forced shutdown. I then booted back into my existing |6.8.0-138-generic| kernel, and everything immediately worked normally again, including the keyboard, trackpad and Bluetooth mouse. For reference, on 138 my DKMS status is: |broadcom-sta/6.30.223.271, 6.8.0-138-generic, x86_64: installed| |facetimehd/0.7.0.1, 6.8.0-138-generic, x86_64: installed| So there is a clear difference between the two kernels: 138 is fully functional on this MacBook, whereas 139 boots to the desktop but loses several hardware functions. I have now removed 139 and returned to 138 so that I don't have to keep performing forced shutdowns. I hope this information is useful. Please let me know if there are any specific logs or additional tests you would like me to perform on 138 or, if necessary, on another test build. I'm happy to help with testing so we can narrow down the original i915 issue. Thanks again for taking the time to build and provide the patched kernel. Regards, Khaled On 21/08/2026 18:41, Alice C. Munduruca wrote: > It'll take at least a day to build due to backlogged builders. If you > are a bit impatient and would like to build a kernel yourself from > source you can follow [1] and just apply the patch above to the correct > file. > > Regardless, let me know what your testing shows so that we can get this > patch upstream for v7.3 :) > > [1]:https://ubuntu.com/kernel/docs/how-to/develop-customise/build- > kernel/ > -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161098 Title: Random hard freezes caused by i915 kernel page fault in eb_relocate_parse_slow on MacBookAir6,2 (Intel HD 5000)acBookAir6,2 (Intel HD 5000) Status in linux package in Ubuntu: In Progress Bug description: Hardware: - Apple MacBookAir6,2 - Intel Haswell HD Graphics 5000 (i915) Software: - Ubuntu 26.10 - Mesa 26.0.3 - Kernel 7.0.0-27 and 7.0.0-28 affected - Currently testing kernel 7.0.0-14 Problem: The system randomly hard freezes. The display remains unchanged with no graphical corruption, but the keyboard and mouse become completely unresponsive and only a hard power-off recovers the system. The freezes are not tied to any particular application. One crash happened while running Papers, but other freezes have occurred during normal desktop use. The previous boot journal contains the following kernel oops: BUG: unable to handle page fault Call trace: kfree() eb_relocate_parse_slow [i915] i915_gem_do_execbuffer [i915] i915_gem_execbuffer2_ioctl [i915] The same MacBook Air hardware is completely stable under macOS (including Big Sur), suggesting this is a Linux kernel regression rather than a hardware fault. The issue has occurred multiple times on kernels 7.0.0-27 and 7.0.0-28. I am now testing kernel 7.0.0-14 to determine whether the regression was introduced after that version. 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 NonfreeKernelModules: wl ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: khaled 2072 F.... wireplumber /dev/snd/controlC0: khaled 2072 F.... wireplumber /dev/snd/seq: khaled 2048 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jul 17 16:19:07 2026 InstallationDate: Installed on 2026-07-14 (3 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp3s0Link: Error: command ['iw', 'dev', 'wlp3s0', 'link'] failed with exit code 255: command failed: Operation not permitted (-1) Connected to <hidden-mac> (on wlp3s0) SSID: <hidden> freq: 5280.0 MachineType: Apple Inc. MacBookAir6,2 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-14-generic root=UUID=b8679823-0d43-482e-99df-035663cbd8cf 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: 01/13/2023 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 478.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-7DF21CB3ED6977E5 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookAir6,2 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-7DF21CB3ED6977E5 dmi.modalias: dmi:bvnAppleInc.:bvr478.0.0.0.0:bd01/13/2023:br0.1:svnAppleInc.:pnMacBookAir6,2:pvr1.0:rvnAppleInc.:rnMac-7DF21CB3ED6977E5:rvrMacBookAir6,2:cvnAppleInc.:ct10:cvrMac-7DF21CB3ED6977E5:skuSystemSKU#:pfaMacBookAir: dmi.product.family: MacBook Air dmi.product.name: MacBookAir6,2 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161098/+subscriptions

пятница

[Bug 2154748] Re: [Ubuntu 26.04] Severe Performance Degradation on kernel 7.0.0-15

This bug is awaiting verification that the linux- gcp-7.0/7.0.0-1011.11~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- gcp-7.0' to 'verification-done-noble-linux-gcp-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux-gcp-7.0' to 'verification-failed-noble-linux-gcp-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-gcp-7.0-v2 verification-needed-noble-linux-gcp-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/2154748 Title: [Ubuntu 26.04] Severe Performance Degradation on kernel 7.0.0-15 Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [ Impact ] s390 selects GENERIC_LOCKBREAK if PREEMPT is enabled. Reason is a historic 18 years old commit [1] which fixed a compile error for PREEMPT enabled kernels. Back than only PREEMPT_NONE and PREEMPT_VOLUNTARY kernels were considered to be important for s390. PREEMPT should "just work". However, since recently PREEMPT is always enabled [2], which also causes GENERIC_LOCKBREAK to be always enabled. For some workloads this leads to massive performance degradation; e.g. a simple kernel compile on machines with many CPUs may take up to four times longer. To fix this just remove the GENERIC_LOCKBREAK from s390's Kconfig, since the compile error from 18 years ago does not exist anymore. [1] commit b6b40c532a36 ("[S390] Define GENERIC_LOCKBREAK.") [2] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [ Fix ] Backport commit: 1f57f68c4dd1 ("s390: Remove GENERIC_LOCKBREAK Kconfig option") [ Test Plan ] Compile and boot tested. Tested performance by compiling a kernel and monitoring execution with perf. [ Regression Potential ] The regression potential of the patch is low. It affects only s390x spinlock implementation. --- == Comment: #2 - Mete Durlu <Mete.Durlu@ibm.com> - 2026-06-01 08:59:07 == ---Problem Description--- Ubuntu 26.04 shows massive performance degradation. On large machines with more than 20 COREs (40 CPUs with SMT) CPU bound workloads suffer greatly. Ex: linux kernel compilation takes >10x more time Resource utilization shows up to 100% system time during the workload. perf top output indicates excessive lock contention in the kernel. $ make -j$(nproc) $ perf top 52.41% [kernel] [k] arch_spin_trylock_retry 8.76% [kernel] [k] _raw_spin_lock_irqsave 2.03% [kernel] [k] arch_spin_relax 1.09% cc1 [.] ht_lookup_with_hash(ht*, unsigned char 0.97% [kernel] [k] diag49c 0.95% [kernel] [k] lru_gen_add_folio 0.80% [kernel] [k] post_alloc_hook.localalias 0.77% [kernel] [k] lru_gen_del_folio.constprop.0 0.63% cc1 [.] htab_find_slot_with_hash 0.60% [kernel] [k] folios_put_refs 0.49% [kernel] [k] arch_vcpu_is_preempted 0.48% cc1 [.] ggc_internal_alloc_no_dtor(unsigned lo 0.44% cc1 [.] _cpp_lex_direct ... The lock contention seems to be linked directly to the thread count on the workload; # on a system with 34 COREs (68 CPUs w SMT) $ make -j20 perf top shows no arch_spin_trylock_retry $ make -j25 perf top shows ~2% arch_spin_trylock_retry $ make -j30 perf top shows ~5% arch_spin_trylock_retry $ make -j34 # thread count = core count perf top shows ~15% arch_spin_trylock_retry $ make -j40 # thread count > core count perf top shows >30% arch_spin_trylock_retry There has also been hints of delays on workqueue execution in dmesg output: ... [10600.136975] workqueue: vmstat_update hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10806.428576] workqueue: delayed_vfree_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10819.822422] workqueue: delayed_vfree_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [10885.381900] workqueue: delayed_vfree_work hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND [10915.209117] workqueue: pcpu_balance_workfn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [11059.719121] workqueue: pcpu_balance_workfn hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [20223.529295] workqueue: inode_switch_wbs_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22584.374168] workqueue: mmput_async_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22602.115559] workqueue: delayed_vfree_work hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND [22817.328172] workqueue: vmstat_update hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [22840.202092] workqueue: delayed_vfree_work hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND [26834.512017] workqueue: delayed_vfree_work hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND [26883.480296] workqueue: vmstat_update hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND ... Systems with less COREs don't seem to be effected. The limit seems to be around 15 COREs (30 CPUs) ---uname output--- Linux localhost 7.0.0-15-generic #15-Ubuntu SMP PREEMPT Wed Apr 22 15:04:00 UTC 2026 s390x GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2154748/+subscriptions

[Bug 2156556] Re: Fix no audio from right built-in speaker on HP ZBook with TAS2781 amplifier

[Bug 2161757] Re: Resolute real-time patchset: 7.0.1-rt2

** Changed in: ubuntu-realtime Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Resolute) Status: In Progress => Fix Committed ** Changed in: linux-realtime (Ubuntu) Status: In Progress => Fix Committed ** Changed in: linux-realtime (Ubuntu Resolute) Status: In Progress => Fix Committed ** Tags removed: verification-needed-resolute-linux ** Tags added: verification-done-resolute-linux -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161757 Title: Resolute real-time patchset: 7.0.1-rt2 Status in ubuntu-realtime: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux-realtime package in Ubuntu: Fix Committed Status in linux source package in Resolute: Fix Committed Status in linux-realtime source package in Resolute: Fix Committed Bug description: [Impact] Starting in resolute, the patches from the PREEMPT_RT patchset are applied to generic so they can be inherited by derivative kernels and flavors that need real-time. PREEMPT_RT 7.0-rc1-rt1 patchset was previously applied ( https://bugs.launchpad.net/ubuntu- realtime/+bug/2143181 ). The patches have been updated with patchset 7.0.1-rt2. This set of patches will be filtered to only ones that apply where we support real-time, including amd64 and arm64. Of those, only two have changed. They were previously dropped due to conflicts, so this effort will reapply the new versions of the patches. [Fix] For kernel 7.0, the upstream PREEMPT_RT patchset 7.0.1-rt2 has been released. https://cdn.kernel.org/pub/linux/kernel/projects/rt/7.0/ The following patches were previously applied and have not changed: UBUNTU: SAUCE: sysfs: Add /sys/kernel/realtime entry UBUNTU: SAUCE: Revert "drm/i915: Depend on !PREEMPT_RT." UBUNTU: SAUCE: drm/i915: Consider RCU read section as atomic. UBUNTU: SAUCE: drm/i915/guc: Consider also RCU depth in busy loop. UBUNTU: SAUCE: drm/i915: Drop the irqs_disabled() check UBUNTU: SAUCE: drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock() UBUNTU: SAUCE: drm/i915: Disable tracing points on PREEMPT_RT UBUNTU: SAUCE: drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates UBUNTU: SAUCE: drm/i915: Use preempt_disable/enable_rt() where recommended These patches have been updated and will be applied as part of this patchset: UBUNTU: SAUCE: Reapply "serial: 8250: Revert "drop lockdep annotation from serial8250_clear_IER()"" UBUNTU: SAUCE: Reapply "serial: 8250: Switch to nbcon console" [Test Case] Compile and boot test [Where things could go wrong] These patches primarily apply to the 8250 serial driver, so they may cause minor performance differences in these drivers even when PREEMPT_RT is disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-realtime/+bug/2161757/+subscriptions