** 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/2164890 Title: MediaTek MT7902 Wi-Fi [14c3:7902] not supported by Ubuntu 26.04 kernel 7.0 Status in linux package in Ubuntu: New Bug description: I am using Ubuntu 26.04 with the official Ubuntu kernel 7.0.0-30-generic. My laptop has a MediaTek MT7902 802.11ax PCIe Wireless Network Adapter. Hardware: MediaTek MT7902 [Filogic 310] PCI ID: 14c3:7902 Subsystem: AzureWave 1a3b:5520 The PCI device is detected by Ubuntu, but no kernel driver is bound to the device. Output of: lspci -nnk -s 02:00.0 02:00.0 Network controller [0280]: MEDIATEK Corp. MT7902 802.11ax PCIe Wireless Network Adapter [Filogic 310] [14c3:7902] Subsystem: AzureWave Device [1a3b:5520] There is no "Kernel driver in use" line. The installed linux-firmware package is: 20260319.git217ca6e4.1ubuntu Secure Boot is enabled. I have not installed a third-party MT7902 driver. Expected result: Ubuntu should provide kernel support for the MT7902 Wi-Fi adapter so that the wireless adapter works normally. Actual result: Ubuntu detects the PCI device but does not load/bind a driver, so the Wi-Fi adapter is unavailable. I would like this hardware to be supported through the official Ubuntu kernel rather than an unofficial third-party driver. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 24 16:56:35 2026 InstallationDate: Installed on 2026-08-22 (2 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUSTeK COMPUTER INC. Vivobook Go E1504FA_E1504FA ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=d8cbc480-789a-4fa3-8e87-09ac426a9b5a 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/16/2026 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E1504FA.318 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: E1504FA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE1504FA.318:bd01/16/2026:br5.27:svnASUSTeKCOMPUTERINC.:pnVivobookGoE1504FA_E1504FA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnE1504FA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaVivobook: dmi.product.family: Vivobook dmi.product.name: Vivobook Go E1504FA_E1504FA dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164890/+subscriptions
понедельник
[Bug 2164910] Re: Ubuntu 24.04 freezes completely with amdgpu VM_L2_PROTECTION_FAULT on kernel 6.8.0-138-generic
** 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/2164910 Title: Ubuntu 24.04 freezes completely with amdgpu VM_L2_PROTECTION_FAULT on kernel 6.8.0-138-generic Status in linux package in Ubuntu: New Bug description: Ubuntu 24.04 experienced a complete graphical freeze while running kernel 6.8.0-138-generic. The system became completely unresponsive. The mouse pointer was frozen and I was unable to interact with the desktop, so a hard reboot was required. After rebooting, I checked the kernel journal from the previous boot. The final kernel messages immediately before the forced reboot are: Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: [gfxhub0] retry page fault (src_id:0 ring:0 vmid:3 pasid:32774, for process firefox-bin pid 37166 thread firefox:cs0 pid 37250) Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: in page starting at address 0x0000800113480000 from IH client 0x1b (UTCL2) Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00341051 There are no later kernel messages in that boot. Firefox was running when the freeze occurred. The journal therefore mentions firefox-bin, but I cannot determine whether Firefox triggered the GPU fault or was merely the process using the affected GPU context. The system had to be rebooted manually at approximately 16:00 local time. Expected result: The desktop and GPU should continue operating normally. Actual result: The graphical session/system froze completely and required a hard reboot. System information: Ubuntu: 24.04 Desktop: GNOME / Wayland Kernel: 6.8.0-138-generic x86_64 Package: linux-image-6.8.0-138-generic 6.8.0-138.138 I generated a full Apport report for the linux package after rebooting. I am also attaching the complete kernel journal from the previous boot, which contains the GPU fault immediately before the system became unresponsive. Attachment: - kernel-freeze-2026-08-24.log To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164910/+subscriptions
[Bug 2164934] Re: [SRU] Add TLB flush after MES queue eviction/suspension in amdkfd (fixes GPU hang on SVM migration, gfx1151/Strix Point)
** 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/2164934 Title: [SRU] Add TLB flush after MES queue eviction/suspension in amdkfd (fixes GPU hang on SVM migration, gfx1151/Strix Point) Status in linux package in Ubuntu: New Bug description: [Impact] On AMD GPUs using MES (Micro Engine Scheduler), queue suspension does not perform a heavy-weight TLB invalidation. This allows DMA descriptors to access memory that has already been unmapped, causing page faults and GPU queue hangs during SVM (Shared Virtual Memory) page migration. Observed as KFDSVMRangeTest.MultiTHreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled: the runtime queue hangs with packets submitted but never consumed. [Fix] As suggested by the AMD team: upstream commit (https://lore.kernel.org/amd-gfx/20260816172608.14470-2-Priya.Hosur@amd.com/) (amd-gfx mailing list, Priya Hosur): "drm/amdkfd: Add TLB flush after MES queue eviction/suspension" Message-Id: <20260816172608.14470-2-Priya.Hosur@amd.com> Adds kfd_flush_tlb() calls after MES queue removal in: - evict_process_queues_cpsch() - suspend_queues() (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are completed/flushed before the underlying memory is freed or fully migrated. [Where problems could occur] This change adds and extra kfd_flush_tlb() fall, gated behind dqp->dev->kfd->shared_resources.enable_mes, which means it only affects MES enabled devices from newer AMD GPU generations. The risk is limited to a possible minor latency increase during queue suspension on MES enabled hardware. [Other Info] Patch is currently in review upstream, not yet merged into the Linus' tree. Requesting it to be tracked once it lands, or considered for inclusion in Ubuntu kernel. Change-Id: Iaa884d4a7ad1199446bc45f4ad8a9a179ab386e6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164934/+subscriptions
[Bug 2164938] Re: Kernel panic "System is deadlocked on memory" during suspend with NVIDIA 580 on GeForce 920MX (GM108M), Ubuntu 26.04 kernel 7.0.0-30
** 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/2164938 Title: Kernel panic "System is deadlocked on memory" during suspend with NVIDIA 580 on GeForce 920MX (GM108M), Ubuntu 26.04 kernel 7.0.0-30 Status in linux package in Ubuntu: New Bug description: Ubuntu 26.04 LTS on a Lenovo IdeaPad 320-15IKB consistently hits a kernel panic when entering suspend while the proprietary NVIDIA 580 driver stack is loaded. System: - Ubuntu 26.04 LTS (resolute) - Kernel: 7.0.0-30-generic, package version 7.0.0-30.30 - CPU: Intel Core i7-7500U (Kaby Lake) - Integrated GPU: Intel HD Graphics 620 [8086:5916], driver i915 - Discrete GPU: NVIDIA GM108M [GeForce 920MX] [10de:134f] - NVIDIA driver: 580.173.02-0ubuntu0.26.04.1 - linux-modules-nvidia-580-7.0.0-30-generic: 7.0.0-30.30 - Secure Boot enabled - Suspend mode: deep (S3) Problem: With the NVIDIA driver stack loaded, running: sudo systemctl suspend causes the graphical session to switch briefly to a text/console screen and then the system enters a kernel panic. The screen displays: KERNEL PANIC! Please reboot your computer. System is deadlocked on memory The Caps Lock LED flashes continuously, networking is lost, SSH becomes unreachable, and the machine requires a forced power-off. Closing the laptop lid also reproduced an unrecoverable suspend/resume failure when the NVIDIA stack was active. Expected result: The laptop should enter S3/deep suspend and resume normally when a keyboard key is pressed or the lid is reopened. Actual result: With the NVIDIA stack active, suspend can result in a kernel panic / unrecoverable system state. Important A/B test: I performed a controlled test using exactly the same Ubuntu installation and kernel 7.0.0-30, but completely blocked the NVIDIA modules at kernel boot using: module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau After reboot I confirmed: - no nvidia or nouveau modules were loaded; - Intel HD 620 / i915 was the active graphics driver; - the NVIDIA 920MX was present on PCI but had no "Kernel driver in use". With NVIDIA completely disabled: 1. `sudo systemctl suspend` - entered deep suspend successfully; - resumed immediately after pressing Enter; - display returned normally; - login screen returned; - fan behaviour was normal; - Wi-Fi/networking and SSH recovered normally; - no panic occurred. 2. Lid-close suspend - `systemd-logind` detected Lid closed; - kernel entered `PM: suspend entry (deep)`; - reopening the lid resumed the system normally; - kernel logged `PM: suspend exit`; - networking and display recovered normally; - no panic occurred. Relevant successful-suspend log excerpts with NVIDIA blacklisted: Module nvidia is blacklisted PM: suspend entry (deep) PM: suspend exit and for lid suspend: systemd-logind: Lid closed. PM: suspend entry (deep) systemd-logind: Lid opened. PM: suspend exit This strongly indicates that the failure depends on the NVIDIA driver stack being active, rather than on ACPI lid detection or generic S3 suspend support. Additional diagnostics already performed: - ACPI lid switch correctly reports both `state: closed` and `state: open`. - Kernel PM debug `pm_test=freezer` completed successfully. - Direct PM device testing showed the expected NVIDIA error when bypassing the NVIDIA procfs suspend interface with PreserveVideoMemoryAllocations enabled; this was a diagnostic test and is distinct from the systemctl suspend panic. - NVIDIA suspend/resume systemd services are installed. - `PreserveVideoMemoryAllocations: 1`. - kdump is installed and loaded. - The original panic did not produce a vmcore. kdump memory reservation was subsequently increased according to the kdump-tools estimator, but no further panic has intentionally been triggered. - No evidence currently suggests a physical GPU failure. There are repeated i915 HPD polling workqueue warnings during some boots, but these are not considered proven causal and successful suspend/resume with i915 alone demonstrates that the Intel GPU can suspend correctly on this machine. A similar Ubuntu 26.04 / Linux 7.0 / NVIDIA 580 issue has been reported where suspend produces: "Kernel panic - not syncing: System is deadlocked on memory". There are also reports involving NVIDIA GM108M hardware and the NVIDIA suspend path on Linux 7.0.x. I am currently keeping the NVIDIA GPU disabled as a workaround because the system suspends and resumes reliably in that configuration. I can perform additional controlled tests if requested by Ubuntu kernel developers, including testing an older Ubuntu 7.0.0-14 kernel with the NVIDIA 580 modules available from the official resolute repositories. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: diogo 3661 F.... pipewire diogo 3678 F.... wireplumber /dev/snd/pcmC0D0p: diogo 3661 F...m pipewire /dev/snd/seq: diogo 3661 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 24 20:00:16 2026 InstallationDate: Installed on 2026-08-20 (4 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 5986:210f Bison Electronics Inc. EasyCamera Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: LENOVO 80XL ProcEnviron: LANG=pt_PT.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=1200M module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/30/2020 dmi.bios.release: 1.47 dmi.bios.vendor: LENOVO dmi.bios.version: 4WCN47WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 320-15IKB dmi.ec.firmware.release: 1.47 dmi.modalias: dmi:bvnLENOVO:bvr4WCN47WW:bd06/30/2020:br1.47:efr1.47:svnLENOVO:pn80XL:pvrLenovoideapad320-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoideapad320-15IKB:skuLENOVO_MT_80XL_BU_idea_FM_ideapad320-15IKB:pfaideapad320-15IKB: dmi.product.family: ideapad 320-15IKB dmi.product.name: 80XL dmi.product.sku: LENOVO_MT_80XL_BU_idea_FM_ideapad 320-15IKB dmi.product.version: Lenovo ideapad 320-15IKB dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164938/+subscriptions
[Bug 2164910] Re: Ubuntu 24.04 freezes completely with amdgpu VM_L2_PROTECTION_FAULT on kernel 6.8.0-138-generic
Additional Info: linux-firmware was updated to 20240318.git3b128b60-0ubuntu2.29 on Aug 12. Kernel 6.8.0-138.138 was installed on Aug 17. The previous 6.8.0-137 kernel had been running with the same firmware before the reported freeze occurred. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164910 Title: Ubuntu 24.04 freezes completely with amdgpu VM_L2_PROTECTION_FAULT on kernel 6.8.0-138-generic Status in linux package in Ubuntu: New Bug description: Ubuntu 24.04 experienced a complete graphical freeze while running kernel 6.8.0-138-generic. The system became completely unresponsive. The mouse pointer was frozen and I was unable to interact with the desktop, so a hard reboot was required. After rebooting, I checked the kernel journal from the previous boot. The final kernel messages immediately before the forced reboot are: Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: [gfxhub0] retry page fault (src_id:0 ring:0 vmid:3 pasid:32774, for process firefox-bin pid 37166 thread firefox:cs0 pid 37250) Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: in page starting at address 0x0000800113480000 from IH client 0x1b (UTCL2) Aug 24 15:59:52 kernel: amdgpu 0000:2a:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00341051 There are no later kernel messages in that boot. Firefox was running when the freeze occurred. The journal therefore mentions firefox-bin, but I cannot determine whether Firefox triggered the GPU fault or was merely the process using the affected GPU context. The system had to be rebooted manually at approximately 16:00 local time. Expected result: The desktop and GPU should continue operating normally. Actual result: The graphical session/system froze completely and required a hard reboot. System information: Ubuntu: 24.04 Desktop: GNOME / Wayland Kernel: 6.8.0-138-generic x86_64 Package: linux-image-6.8.0-138-generic 6.8.0-138.138 I generated a full Apport report for the linux package after rebooting. I am also attaching the complete kernel journal from the previous boot, which contains the GPU fault immediately before the system became unresponsive. Attachment: - kernel-freeze-2026-08-24.log To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164910/+subscriptions
[Bug 2164918] Re: Linux 7.0.0-30 i915 Backlight Regression on MSI GF63 8RD
*** This bug is a duplicate of bug 2161309 *** https://bugs.launchpad.net/bugs/2161309 ** This bug has been marked a duplicate of bug 2161309 Backlight regression -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164918 Title: Linux 7.0.0-30 i915 Backlight Regression on MSI GF63 8RD Status in linux package in Ubuntu: New Bug description: ## Summary Display brightness control is nonfunctional on Linux Mint when running kernel `7.0.0-30-generic` on an MSI GF63 8RD with Intel UHD Graphics 630. The kernel exposes the `intel_backlight` interface normally, and writes to the interface successfully update both `brightness` and `actual_brightness`. However, these changes are not applied to the physical display backlight, which remains at maximum brightness. Booting the same installation with kernel `6.14.0-37-generic` immediately restores normal brightness control. ## Hardware - **Laptop:** MSI GF63 8RD - **Integrated GPU:** Intel CoffeeLake-H GT2 [UHD Graphics 630] - **iGPU driver:** `i915` - **Discrete GPU:** NVIDIA GeForce GTX 1050 Ti Max-Q - **NVIDIA driver:** `580.178.04` - **Internal display:** eDP - **Session:** X11 ## Software - **Distribution:** Linux Mint 22.3 Cinnamon - **Affected kernel:** `7.0.0-30-generic` - **Known-good kernel:** `6.14.0-37-generic` ## Steps to Reproduce 1. Boot Linux Mint using kernel `7.0.0-30-generic`. 2. Attempt to change display brightness using Cinnamon's brightness controls. 3. Observe that the displayed brightness setting changes, but physical screen brightness does not. 4. Alternatively, bypass userspace and directly change the backlight through sysfs: ```bash echo 500 | sudo tee /sys/class/backlight/intel_backlight/brightness ``` 5. Read the resulting values: ```bash cat /sys/class/backlight/intel_backlight/{brightness,actual_brightness,max_brightness} ``` The kernel reports: ```text brightness:500 actual_brightness:500 max_brightness:1023 ``` Despite this, the physical panel remains at maximum brightness. 6. Reboot and select: ```text Advanced options for Linux Mint → Linux Mint, with Linux 6.14.0-37-generic ``` 7. Brightness control now works normally on the same hardware and Linux Mint installation. ## Backlight Interface on Affected Kernel ```text /sys/class/backlight/intel_backlight ``` The device resolves to: ```text ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/intel_backlight ``` Properties before testing: ```text brightness:1023 actual_brightness:1023 max_brightness:1023 type:raw ``` After writing `500`: ```text brightness:500 actual_brightness:500 max_brightness:1023 type:raw ``` Again, the physical backlight does not change. ## Relevant ACPI Output ```text ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) input: Video Bus as /devices/pci0000:00/acpi.video_bus.0/input/input9 ACPI: video: Video Device [PEGP] (multi-head: no rom: yes post: no) input: Video Bus as /devices/pci0000:00/0000:00:01.0/acpi.video_bus.1/input/input10 ``` The `video` and `msi_wmi` modules are loaded. Loading `video` explicitly does not expose an additional ACPI backlight device; `/sys/class/backlight/` continues to contain only `intel_backlight`. ## Expected Behavior Changing the brightness setting should alter the physical backlight intensity, as it does under kernel `6.14.0-37-generic`. ## Actual Behavior Under `7.0.0-30-generic`, the kernel accepts brightness changes and reports the requested value through both `brightness` and `actual_brightness`, but the physical display remains at maximum brightness. ## Regression This appears to be a kernel regression. The exact same Linux Mint installation and hardware behave as follows: ```text 6.14.0-37-generic → brightness works 7.0.0-30-generic → brightness values change, physical backlight does not ``` No userspace or hardware changes are required to reproduce or resolve the issue; selecting the older kernel at boot is sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164918/+subscriptions
[Bug 2164938] [NEW] Kernel panic "System is deadlocked on memory" during suspend with NVIDIA 580 on GeForce 920MX (GM108M), Ubuntu 26.04 kernel 7.0.0-30
Public bug reported: Ubuntu 26.04 LTS on a Lenovo IdeaPad 320-15IKB consistently hits a kernel panic when entering suspend while the proprietary NVIDIA 580 driver stack is loaded. System: - Ubuntu 26.04 LTS (resolute) - Kernel: 7.0.0-30-generic, package version 7.0.0-30.30 - CPU: Intel Core i7-7500U (Kaby Lake) - Integrated GPU: Intel HD Graphics 620 [8086:5916], driver i915 - Discrete GPU: NVIDIA GM108M [GeForce 920MX] [10de:134f] - NVIDIA driver: 580.173.02-0ubuntu0.26.04.1 - linux-modules-nvidia-580-7.0.0-30-generic: 7.0.0-30.30 - Secure Boot enabled - Suspend mode: deep (S3) Problem: With the NVIDIA driver stack loaded, running: sudo systemctl suspend causes the graphical session to switch briefly to a text/console screen and then the system enters a kernel panic. The screen displays: KERNEL PANIC! Please reboot your computer. System is deadlocked on memory The Caps Lock LED flashes continuously, networking is lost, SSH becomes unreachable, and the machine requires a forced power-off. Closing the laptop lid also reproduced an unrecoverable suspend/resume failure when the NVIDIA stack was active. Expected result: The laptop should enter S3/deep suspend and resume normally when a keyboard key is pressed or the lid is reopened. Actual result: With the NVIDIA stack active, suspend can result in a kernel panic / unrecoverable system state. Important A/B test: I performed a controlled test using exactly the same Ubuntu installation and kernel 7.0.0-30, but completely blocked the NVIDIA modules at kernel boot using: module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau After reboot I confirmed: - no nvidia or nouveau modules were loaded; - Intel HD 620 / i915 was the active graphics driver; - the NVIDIA 920MX was present on PCI but had no "Kernel driver in use". With NVIDIA completely disabled: 1. `sudo systemctl suspend` - entered deep suspend successfully; - resumed immediately after pressing Enter; - display returned normally; - login screen returned; - fan behaviour was normal; - Wi-Fi/networking and SSH recovered normally; - no panic occurred. 2. Lid-close suspend - `systemd-logind` detected Lid closed; - kernel entered `PM: suspend entry (deep)`; - reopening the lid resumed the system normally; - kernel logged `PM: suspend exit`; - networking and display recovered normally; - no panic occurred. Relevant successful-suspend log excerpts with NVIDIA blacklisted: Module nvidia is blacklisted PM: suspend entry (deep) PM: suspend exit and for lid suspend: systemd-logind: Lid closed. PM: suspend entry (deep) systemd-logind: Lid opened. PM: suspend exit This strongly indicates that the failure depends on the NVIDIA driver stack being active, rather than on ACPI lid detection or generic S3 suspend support. Additional diagnostics already performed: - ACPI lid switch correctly reports both `state: closed` and `state: open`. - Kernel PM debug `pm_test=freezer` completed successfully. - Direct PM device testing showed the expected NVIDIA error when bypassing the NVIDIA procfs suspend interface with PreserveVideoMemoryAllocations enabled; this was a diagnostic test and is distinct from the systemctl suspend panic. - NVIDIA suspend/resume systemd services are installed. - `PreserveVideoMemoryAllocations: 1`. - kdump is installed and loaded. - The original panic did not produce a vmcore. kdump memory reservation was subsequently increased according to the kdump-tools estimator, but no further panic has intentionally been triggered. - No evidence currently suggests a physical GPU failure. There are repeated i915 HPD polling workqueue warnings during some boots, but these are not considered proven causal and successful suspend/resume with i915 alone demonstrates that the Intel GPU can suspend correctly on this machine. A similar Ubuntu 26.04 / Linux 7.0 / NVIDIA 580 issue has been reported where suspend produces: "Kernel panic - not syncing: System is deadlocked on memory". There are also reports involving NVIDIA GM108M hardware and the NVIDIA suspend path on Linux 7.0.x. I am currently keeping the NVIDIA GPU disabled as a workaround because the system suspends and resumes reliably in that configuration. I can perform additional controlled tests if requested by Ubuntu kernel developers, including testing an older Ubuntu 7.0.0-14 kernel with the NVIDIA 580 modules available from the official resolute repositories. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: diogo 3661 F.... pipewire diogo 3678 F.... wireplumber /dev/snd/pcmC0D0p: diogo 3661 F...m pipewire /dev/snd/seq: diogo 3661 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 24 20:00:16 2026 InstallationDate: Installed on 2026-08-20 (4 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 5986:210f Bison Electronics Inc. EasyCamera Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: LENOVO 80XL ProcEnviron: LANG=pt_PT.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=1200M module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/30/2020 dmi.bios.release: 1.47 dmi.bios.vendor: LENOVO dmi.bios.version: 4WCN47WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 320-15IKB dmi.ec.firmware.release: 1.47 dmi.modalias: dmi:bvnLENOVO:bvr4WCN47WW:bd06/30/2020:br1.47:efr1.47:svnLENOVO:pn80XL:pvrLenovoideapad320-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoideapad320-15IKB:skuLENOVO_MT_80XL_BU_idea_FM_ideapad320-15IKB:pfaideapad320-15IKB: dmi.product.family: ideapad 320-15IKB dmi.product.name: 80XL dmi.product.sku: LENOVO_MT_80XL_BU_idea_FM_ideapad 320-15IKB dmi.product.version: Lenovo ideapad 320-15IKB dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: gm108m hybrid-graphics kernel-panic nvidia resume suspend ** Attachment added: "Photo of the kernel panic displayed immediately after sudo systemctl suspend with NVIDIA 580 active." https://bugs.launchpad.net/bugs/2164938/+attachment/5994922/+files/Kernel%20Panic.jpg -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164938 Title: Kernel panic "System is deadlocked on memory" during suspend with NVIDIA 580 on GeForce 920MX (GM108M), Ubuntu 26.04 kernel 7.0.0-30 Status in linux package in Ubuntu: New Bug description: Ubuntu 26.04 LTS on a Lenovo IdeaPad 320-15IKB consistently hits a kernel panic when entering suspend while the proprietary NVIDIA 580 driver stack is loaded. System: - Ubuntu 26.04 LTS (resolute) - Kernel: 7.0.0-30-generic, package version 7.0.0-30.30 - CPU: Intel Core i7-7500U (Kaby Lake) - Integrated GPU: Intel HD Graphics 620 [8086:5916], driver i915 - Discrete GPU: NVIDIA GM108M [GeForce 920MX] [10de:134f] - NVIDIA driver: 580.173.02-0ubuntu0.26.04.1 - linux-modules-nvidia-580-7.0.0-30-generic: 7.0.0-30.30 - Secure Boot enabled - Suspend mode: deep (S3) Problem: With the NVIDIA driver stack loaded, running: sudo systemctl suspend causes the graphical session to switch briefly to a text/console screen and then the system enters a kernel panic. The screen displays: KERNEL PANIC! Please reboot your computer. System is deadlocked on memory The Caps Lock LED flashes continuously, networking is lost, SSH becomes unreachable, and the machine requires a forced power-off. Closing the laptop lid also reproduced an unrecoverable suspend/resume failure when the NVIDIA stack was active. Expected result: The laptop should enter S3/deep suspend and resume normally when a keyboard key is pressed or the lid is reopened. Actual result: With the NVIDIA stack active, suspend can result in a kernel panic / unrecoverable system state. Important A/B test: I performed a controlled test using exactly the same Ubuntu installation and kernel 7.0.0-30, but completely blocked the NVIDIA modules at kernel boot using: module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau After reboot I confirmed: - no nvidia or nouveau modules were loaded; - Intel HD 620 / i915 was the active graphics driver; - the NVIDIA 920MX was present on PCI but had no "Kernel driver in use". With NVIDIA completely disabled: 1. `sudo systemctl suspend` - entered deep suspend successfully; - resumed immediately after pressing Enter; - display returned normally; - login screen returned; - fan behaviour was normal; - Wi-Fi/networking and SSH recovered normally; - no panic occurred. 2. Lid-close suspend - `systemd-logind` detected Lid closed; - kernel entered `PM: suspend entry (deep)`; - reopening the lid resumed the system normally; - kernel logged `PM: suspend exit`; - networking and display recovered normally; - no panic occurred. Relevant successful-suspend log excerpts with NVIDIA blacklisted: Module nvidia is blacklisted PM: suspend entry (deep) PM: suspend exit and for lid suspend: systemd-logind: Lid closed. PM: suspend entry (deep) systemd-logind: Lid opened. PM: suspend exit This strongly indicates that the failure depends on the NVIDIA driver stack being active, rather than on ACPI lid detection or generic S3 suspend support. Additional diagnostics already performed: - ACPI lid switch correctly reports both `state: closed` and `state: open`. - Kernel PM debug `pm_test=freezer` completed successfully. - Direct PM device testing showed the expected NVIDIA error when bypassing the NVIDIA procfs suspend interface with PreserveVideoMemoryAllocations enabled; this was a diagnostic test and is distinct from the systemctl suspend panic. - NVIDIA suspend/resume systemd services are installed. - `PreserveVideoMemoryAllocations: 1`. - kdump is installed and loaded. - The original panic did not produce a vmcore. kdump memory reservation was subsequently increased according to the kdump-tools estimator, but no further panic has intentionally been triggered. - No evidence currently suggests a physical GPU failure. There are repeated i915 HPD polling workqueue warnings during some boots, but these are not considered proven causal and successful suspend/resume with i915 alone demonstrates that the Intel GPU can suspend correctly on this machine. A similar Ubuntu 26.04 / Linux 7.0 / NVIDIA 580 issue has been reported where suspend produces: "Kernel panic - not syncing: System is deadlocked on memory". There are also reports involving NVIDIA GM108M hardware and the NVIDIA suspend path on Linux 7.0.x. I am currently keeping the NVIDIA GPU disabled as a workaround because the system suspends and resumes reliably in that configuration. I can perform additional controlled tests if requested by Ubuntu kernel developers, including testing an older Ubuntu 7.0.0-14 kernel with the NVIDIA 580 modules available from the official resolute repositories. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: diogo 3661 F.... pipewire diogo 3678 F.... wireplumber /dev/snd/pcmC0D0p: diogo 3661 F...m pipewire /dev/snd/seq: diogo 3661 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 24 20:00:16 2026 InstallationDate: Installed on 2026-08-20 (4 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 5986:210f Bison Electronics Inc. EasyCamera Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: LENOVO 80XL ProcEnviron: LANG=pt_PT.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=1200M module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm,nouveau SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/30/2020 dmi.bios.release: 1.47 dmi.bios.vendor: LENOVO dmi.bios.version: 4WCN47WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 320-15IKB dmi.ec.firmware.release: 1.47 dmi.modalias: dmi:bvnLENOVO:bvr4WCN47WW:bd06/30/2020:br1.47:efr1.47:svnLENOVO:pn80XL:pvrLenovoideapad320-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoideapad320-15IKB:skuLENOVO_MT_80XL_BU_idea_FM_ideapad320-15IKB:pfaideapad320-15IKB: dmi.product.family: ideapad 320-15IKB dmi.product.name: 80XL dmi.product.sku: LENOVO_MT_80XL_BU_idea_FM_ideapad 320-15IKB dmi.product.version: Lenovo ideapad 320-15IKB dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164938/+subscriptions
[Bug 2161748] Re: [SRU][HPE] Take Intel platform into account for old microcode checks
This patch is added as it is fixing a regression introduced by d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure") commit cda64169bade79427f264e43d0f422eaed9dc116 Author: Borislav Petkov <bp@alien8.de> Date: Wed May 13 22:06:01 2026 +0200 x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest Patch in Fixes: causes the usual: unchecked MSR access error: RDMSR from 0x17 at ... (intel_get_platform_id) Call Trace: early_init_intel early_cpu_init setup_arch _printk start_kernel x86_64_start_reservations x86_64_start_kernel common_startup_64 because the kernel is booted in a guest. In order to avoid it, this MSR access needs to be prevented when running virtualized. That is usually done by checking X86_FEATURE_HYPERVISOR but for this particular case it is too early yet. The platform ID needs to be read as early as when microcode is loaded on the BSP: load_ucode_bsp ... -> get_microcode_blob ... -> intel_find_matching_signature and by that time, CPUID leafs haven't been parsed yet. The microcode loader already has logic to check early whether the kernel is running virtualized so make that globally available to arch/x86/. The query whether running virtualized is getting more and more prominent in recent times so might as well make it an arch-global var which the rest of the code can use. Fixes: d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure") Reported-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Tested-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com ** Description changed: [ Impact ] The issue is Intel added code to Linux to check for old microcode. They base it on some processor fields not realizing there are multiple processor SKUs with the same processor field information. The result is the Linux wrongly prints out "Running old microcode" and sets taint bit 2 for some processor SKUs. It takes specific Intel processor SKUs to hit the issue. This has been seen with Sapphire Rapids and Granite Rapids processors [ Fix ] These patches fix the issue - + cda64169 x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest 238be4ba x86/microcode: Refactor platform ID enumeration into a helper d8630b67 x86/cpu: Add platform ID to CPU info structure fab0c75d x86/cpu: Add platform ID to CPU matching structure 7989c393 x86/microcode: Add platform mask to Intel microcode "old" list The patches fix false-positive "old microcode"/taint-bit-2 reports on Sapphire Rapids and Granite Rapids SKUs. [ Test Plan ] After booting the system check the /proc/sys/kernel/tainted file for the incorrect microcode error Without the fix: root@gnh-204:~# cat /proc/sys/kernel/tainted 4 root@gnh-204:~# dmesg | grep microcode [ 0.000000] x86/CPU: Running old microcode [ 10.088285] microcode: Enabled staging feature. [ 10.092931] microcode: Current revision: 0x01000434 With the fix: root@gnh-204:~# cat /proc/sys/kernel/tainted 0 root@gnh-204:~# dmesg | grep microcode [ 10.090836] microcode: Enabled staging feature. [ 10.095475] microcode: Current revision: 0x01000434 [ Where problems could occur ] The regression risk is low. This code is only touching the x86 microcode/CPU-matching code path and no other subsystems are affected. [ Other Info ] https://code.launchpad.net/~mreed8855/ubuntu/+source/linux/+git/resolute/+ref/kernel_taint_lp_2161748_intel -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161748 Title: [SRU][HPE] Take Intel platform into account for old microcode checks Status in linux package in Ubuntu: Fix Committed Status in linux source package in Resolute: In Progress Status in linux source package in Stonking: Fix Committed Bug description: [ Impact ] The issue is Intel added code to Linux to check for old microcode. They base it on some processor fields not realizing there are multiple processor SKUs with the same processor field information. The result is the Linux wrongly prints out "Running old microcode" and sets taint bit 2 for some processor SKUs. It takes specific Intel processor SKUs to hit the issue. This has been seen with Sapphire Rapids and Granite Rapids processors [ Fix ] These patches fix the issue cda64169 x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest 238be4ba x86/microcode: Refactor platform ID enumeration into a helper d8630b67 x86/cpu: Add platform ID to CPU info structure fab0c75d x86/cpu: Add platform ID to CPU matching structure 7989c393 x86/microcode: Add platform mask to Intel microcode "old" list The patches fix false-positive "old microcode"/taint-bit-2 reports on Sapphire Rapids and Granite Rapids SKUs. [ Test Plan ] After booting the system check the /proc/sys/kernel/tainted file for the incorrect microcode error Without the fix: root@gnh-204:~# cat /proc/sys/kernel/tainted 4 root@gnh-204:~# dmesg | grep microcode [ 0.000000] x86/CPU: Running old microcode [ 10.088285] microcode: Enabled staging feature. [ 10.092931] microcode: Current revision: 0x01000434 With the fix: root@gnh-204:~# cat /proc/sys/kernel/tainted 0 root@gnh-204:~# dmesg | grep microcode [ 10.090836] microcode: Enabled staging feature. [ 10.095475] microcode: Current revision: 0x01000434 [ Where problems could occur ] The regression risk is low. This code is only touching the x86 microcode/CPU-matching code path and no other subsystems are affected. [ Other Info ] https://code.launchpad.net/~mreed8855/ubuntu/+source/linux/+git/resolute/+ref/kernel_taint_lp_2161748_intel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161748/+subscriptions
[Bug 2164934] [NEW] [SRU] Add TLB flush after MES queue eviction/suspension in amdkfd (fixes GPU hang on SVM migration, gfx1151/Strix Point)
Public bug reported: [Impact] On AMD GPUs using MES (Micro Engine Scheduler), queue suspension does not perform a heavy-weight TLB invalidation. This allows DMA descriptors to access memory that has already been unmapped, causing page faults and GPU queue hangs during SVM (Shared Virtual Memory) page migration. Observed as KFDSVMRangeTest.MultiTHreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled: the runtime queue hangs with packets submitted but never consumed. [Fix] As suggested by the AMD team: upstream commit (https://lore.kernel.org/amd-gfx/20260816172608.14470-2-Priya.Hosur@amd.com/) (amd-gfx mailing list, Priya Hosur): "drm/amdkfd: Add TLB flush after MES queue eviction/suspension" Message-Id: <20260816172608.14470-2-Priya.Hosur@amd.com> Adds kfd_flush_tlb() calls after MES queue removal in: - evict_process_queues_cpsch() - suspend_queues() (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are completed/flushed before the underlying memory is freed or fully migrated. [Where problems could occur] This change adds and extra kfd_flush_tlb() fall, gated behind dqp->dev->kfd->shared_resources.enable_mes, which means it only affects MES enabled devices from newer AMD GPU generations. The risk is limited to a possible minor latency increase during queue suspension on MES enabled hardware. [Other Info] Patch is currently in review upstream, not yet merged into the Linus' tree. Requesting it to be tracked once it lands, or considered for inclusion in Ubuntu kernel. Change-Id: Iaa884d4a7ad1199446bc45f4ad8a9a179ab386e6 ** 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/2164934 Title: [SRU] Add TLB flush after MES queue eviction/suspension in amdkfd (fixes GPU hang on SVM migration, gfx1151/Strix Point) Status in linux package in Ubuntu: New Bug description: [Impact] On AMD GPUs using MES (Micro Engine Scheduler), queue suspension does not perform a heavy-weight TLB invalidation. This allows DMA descriptors to access memory that has already been unmapped, causing page faults and GPU queue hangs during SVM (Shared Virtual Memory) page migration. Observed as KFDSVMRangeTest.MultiTHreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled: the runtime queue hangs with packets submitted but never consumed. [Fix] As suggested by the AMD team: upstream commit (https://lore.kernel.org/amd-gfx/20260816172608.14470-2-Priya.Hosur@amd.com/) (amd-gfx mailing list, Priya Hosur): "drm/amdkfd: Add TLB flush after MES queue eviction/suspension" Message-Id: <20260816172608.14470-2-Priya.Hosur@amd.com> Adds kfd_flush_tlb() calls after MES queue removal in: - evict_process_queues_cpsch() - suspend_queues() (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are completed/flushed before the underlying memory is freed or fully migrated. [Where problems could occur] This change adds and extra kfd_flush_tlb() fall, gated behind dqp->dev->kfd->shared_resources.enable_mes, which means it only affects MES enabled devices from newer AMD GPU generations. The risk is limited to a possible minor latency increase during queue suspension on MES enabled hardware. [Other Info] Patch is currently in review upstream, not yet merged into the Linus' tree. Requesting it to be tracked once it lands, or considered for inclusion in Ubuntu kernel. Change-Id: Iaa884d4a7ad1199446bc45f4ad8a9a179ab386e6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164934/+subscriptions
воскресенье
[Bug 2164701] [NEW] Poor frame pacing under Hyper-V (blame kernel commit 52e6b19)
You have been subscribed to a public bug: After setting up a fresh VM on a Hyper-V host with the official amd64 Xubuntu Minimal 26.04 iso, I noticed unexpectedly choppy graphical performance when connecting to the guest console through VMConnect (Basic session). When dragging a window around the desktop, there was easily hundreds of milliseconds of delay or more between moving the mouse and the window actually moving. I used xev to confirm this was a problem with the display and not the input (input events came in at a smooth rate). I investigated various Xfce and Xorg settings to no avail, then tried temporarily replacing Xfce with openbox, which exhibited the same choppiness. At this point, I went looking for differences with another NixOS VM on the same host which did not exhibit the problem and the only significant difference appeared to be that it was running a 6.18 kernel instead of 7.0.0-30-generic like Xubuntu. I installed a 6.18.43 kernel on Xubuntu and the problem disappeared, obtaining performance comparable to the NixOS VM. I had ChatGPT 5.6 do some research and it suggested the problem might be the following commit: 52e6b19 drm/hypervdrm: Use vblank timer It noted that this commit was reverted by Red Hat in one of their kernel branches in June 2026 according to the changelog at rpmfind.net/linux/RPM/centos-stream/9/baseos/x86_64/kernel- tools-5.14.0-719.el9.x86_64.html. To test this hypothesis, I cloned the kernel sources from https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/resolute, switched to tag Ubuntu-7.0.0-30.30 (d974a40), and reverted commit 52e6b19. I then built the .deb packages for this modified kernel, installed them on my VM, and booted into the modified kernel. The problem vanished, with graphical performance again matching the 6.18 NixOS VM. No other changes were made to the kernel, so it seems that 52e6b19 is indeed the commit that introduced the regression compared to 6.18. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: xorg 1:7.7+26ubuntu1 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: XFCE Date: Thu Aug 20 17:57:32 2026 DistUpgraded: Fresh install DistroCodename: resolute DistroVariant: ubuntu GraphicsCard: InstallationDate: Installed on 2026-08-20 (1 days ago) InstallationMedia: Xubuntu Minimal 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lspci: Lspci-vt: Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Microsoft Corporation Virtual Machine ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no username) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=7ca2a92c-536c-4cd1-b534-487b767b4a3f ro quiet splash SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/23/2025 dmi.bios.release: 4.1 dmi.bios.vendor: Microsoft Corporation dmi.bios.version: Hyper-V UEFI Release v4.1 dmi.board.asset.tag: None dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: Hyper-V UEFI Release v4.1 dmi.chassis.asset.tag: 6415-2400-6832-7400-3077-0046-58 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: Hyper-V UEFI Release v4.1 dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev4.1:bd10/23/2025:br4.1:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev4.1:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev4.1:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev4.1:skuNone:pfaVirtualMachine: dmi.product.family: Virtual Machine dmi.product.name: Virtual Machine dmi.product.sku: None dmi.product.version: Hyper-V UEFI Release v4.1 dmi.sys.vendor: Microsoft Corporation version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.131-1 version.libgl1-mesa-dri: libgl1-mesa-dri 26.0.3-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.22-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:22.0.0-1build2 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1build2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.18-1build1 ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug performance resolute ubuntu -- Poor frame pacing under Hyper-V (blame kernel commit 52e6b19) https://bugs.launchpad.net/bugs/2164701 You received this bug notification because you are subscribed to linux in Ubuntu.
[Bug 2163293] Re: Fix noise of audio output on more Dell QCx1255 models after reboot
** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: In Progress => Fix Committed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163293 Title: Fix noise of audio output on more Dell QCx1255 models after reboot Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] More Dell Pro QCx1255 systems have headphone pop noise when using Pipewire audio server on Ubuntu 24.04. The noise appears when headphones are plugged in. The issue does not occur with Pulseaudio. [Fix] Apply the quirk ALC236_FIXUP_DELL_HP_POP_NOISE for more Dell Pro QCx1255 systems to route headphone output to DAC 0x2, which eliminates the popping sound. Upstream commit: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for- linus&id=9573818cc1b7ac22176d0a2b60bfbc440e94f7d5 [Test Plan] 1. Boot Dell Pro QCx1255 with Ubuntu 24.04 and Pipewire audio server 2. Plug in headphones 3. Without patch: popping/crackling noise heard through headphones 4. With patch: no popping noise, clean audio output [Where problems could occur] Only take effect on particular SSIDs. The risk of regression should be low To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2163293/+subscriptions
[Bug 2142389] Re: amdgpu (R9 380) fails to resume from suspend (deep sleep) – black screen, requires hard reboot
Different Tonga hardware and a different trigger, same newer-kernel breakage. Hardware: Apple iMac17,1 (late 2015), AMD R9 M395/M395X Mac Edition (Tonga) [1002:6920], subsystem Apple [106b:014c], internal eDP 5K panel, no external displays. GNOME/Mutter Wayland session (Ubuntu defaults) in all tests. Results on identical hardware: - Ubuntu 22.04 and 24.04 GA kernels (through 6.8): stable — daily driver for years, zero amdgpu errors. - 6.17.0-35 (24.04 HWE): hard GPU hang under sustained CPU load (no video decode active): ring uvd timeout → "atombios stuck in loop for more than 20secs aborting" (tables E57E, B916) → GPU Recovery Failed: -22 → ring sdma1 timeout → kworkers blocked >122s..>737s → power-off required. - 7.0 (26.04): freezes within seconds of launching GPU-accelerated apps; TTY unresponsive. amdgpu.dc=0 helps but freezes still occur, with call traces in the legacy path: dce_v10_0_crtc_disable → amdgpu_dpm_compute_clocks → smu7_send_msg_to_smc / phm_wait_for_register_unequal, repeating at ~5 s intervals. This looks like a different mechanism than the slow-wake EDID issue discussed in drm/amd#5123: no suspend or DPMS involved, no external monitor, and no "No EDID read" anywhere in my logs. Full details and logs upstream: https://gitlab.freedesktop.org/drm/amd/-/work_items/5680. Daily-driver machine, so I can't run development patches, but I can provide further logs and will test any fix once it lands in a release/stable kernel. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2142389 Title: amdgpu (R9 380) fails to resume from suspend (deep sleep) – black screen, requires hard reboot Status in linux package in Ubuntu: Confirmed Bug description: AMDGPU suspend → display black / no video after resume on Radeon R9 380 (No EDID read) Summary: After system suspend from Zorin OS 18 (Ubuntu 24.10 base, kernel 6.17.0-14), the system sometimes resumes but the display remains black (no signal). System continues running (fans/LEDs active), but monitor shows no output. Only hard reboot restores video. Steps to reproduce: Boot Zorin OS 18 (Ubuntu 24.10 kernel 6.17). Suspend system (e.g., via GNOME “Suspend”). Wait short period. Attempt to resume (mouse/keyboard). System wakes but display either shows garbled video or no output. Observed behavior: System appears not crashed (fans/LEDs/keyboard continue). Screen stays black or displays remnants but no usable video. Sometimes resume works, sometimes fails. Relevant log excerpt: amdgpu 0000:01:00.0: [drm] *ERROR* No EDID read. Hardware: Motherboard: Gigabyte B450 AORUS PRO WIFI CPU: AMD Ryzen 5 5500 GPU: AMD Radeon R9 380 Series (Tonga, amdgpu driver) Software environment: Zorin OS 18 Core (Ubuntu 24.10 base) kernel: 6.17.0-14-generic X11 session Workaround currently applied: Suspend disabled. System remains stable without suspend. Note: Bug appears related to video resume rather than system freeze; display subsystem (EDID handshake) may fail after suspend. Additional info: Similar reports of amdgpu black screen / suspend issues exist (e.g., Launchpad #2141216) and community discussions on black screen resume after suspend for AMD GPUs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142389/+subscriptions
[Bug 2163610] Re: OVTI08F4 camera fails to probe on HP Spectre x360 14-eu0xxx (error -121)
Quick update: the Fedora maintainer has now sent a patch upstream that uses a 200 ms post-handshake delay for all sensors. That replaces the HP-only 150 ms workaround I tested here. There is also a Fedora kernel PR, and the related Fedora bug has been reopened until the fix lands. So this is moving in the right direction, but it is not in an Ubuntu kernel yet: https://bugzilla.redhat.com/show_bug.cgi?id=2333331#c104 ** Bug watch added: Red Hat Bugzilla #2333331 https://bugzilla.redhat.com/show_bug.cgi?id=2333331 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163610 Title: OVTI08F4 camera fails to probe on HP Spectre x360 14-eu0xxx (error -121) Status in linux package in Ubuntu: New Bug description: I am reporting a built-in camera failure on an HP Spectre x360 2-in-1 Laptop 14-eu0xxx. System - Ubuntu 26.04 LTS - linux-image-7.0.0-29-generic, package version 7.0.0-29.29 - Camera sensor: OVTI08F4 / OmniVision ov08x40 - Intel IPU6 camera stack Expected result The ov08x40 sensor should probe and the built-in camera should be available to libcamera and desktop camera applications. Actual result The sensor fails to read its chip ID and the camera is unavailable: ov08x40: error reading chip-id register: -121 What I found The existing 45 ms INT3472 handshake delay is not long enough on this laptop. A 150 ms delay allows the sensor to probe. I prepared a DMI-scoped quirk so the longer delay is used only for the matching HP Spectre x360 14-eu0xxx family. After the sensor probes, libcamera also needs the ov08x40 driver to report the native size, crop bounds, and active crop through get_selection(). Without that, camera setup fails with rectangle ioctl errors. Testing I applied both kernel patches to the Ubuntu 7.0.12 source from linux-source-7.0.0 package version 7.0.0-29.29 and built the three affected modules for 7.0.0-29-generic. The patches passed scripts/checkpatch.pl --strict. The rebuilt modules were signed for Secure Boot, installed, and loaded after reboot. With the patches applied: - the sensor was detected and the -121 probe error did not return; - libcamera detected one camera and captured 60 consecutive 3848x2416 frames at 30 fps; - PipeWire exposed the built-in front camera; and - GNOME Snapshot showed a stable live preview. Patches and full validation notes https://github.com/liondragon/hp-spectre-ov08x40-camera Kernel patches https://github.com/liondragon/hp-spectre-ov08x40-camera/tree/main/patches/linux Validation record https://github.com/liondragon/hp-spectre-ov08x40-camera/blob/main/docs/validation.md To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163610/+subscriptions