*** This bug is a duplicate of bug 2142389 *** https://bugs.launchpad.net/bugs/2142389 Olá, Cesar! Tudo bem? Vi que o seu relatório de bug foi unificado aqui com o meu (o #2142389). Isso é excelente porque mostra aos desenvolvedores da Canonical que o comportamento na R9 380 não é um caso isolado e nos ajuda a concentrar as informações em um só lugar. Estamos organizando um tópico bem bacana e saudável lá no fórum Diolinux Plus para centralizar os testes de bancada, logs e soluções temporárias que a galera está encontrando para contornar essa falha de suspensão. Se quiser somar forças com a gente por lá e acompanhar o desenrolar dessa história de perto, o link do nosso espaço é este aqui: 👉 https://plus.diolinux.com.br/t/regressao-no-kernel-ameaca-gpus-amd-series-r5-r7-r9-e-rx-tongas-e-polaris/82166 Será muito bem-vindo para compartilhar suas percepções com o pessoal. Um abraço e vamos nos ajudando! 🐧🌿 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2152546 Title: amdgpu (R9 380) fails to resume from suspend (deep sleep) – black screen, requires hard reboot Status in linux package in Ubuntu: Incomplete 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/2152546/+subscriptions
суббота
[Bug 2154053] Re: atlantic driver issue on kernel 7
** Summary changed: - atlatnic driver issue on kernel 7 + atlantic driver issue on kernel 7 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154053 Title: atlantic driver issue on kernel 7 Status in linux package in Ubuntu: New Bug description: I recently updated to Ubuntu 26.04 with a Kernel 7.0.0 I am having issue with the driver for my 10G card which worked fine on Ubuntu 25.10 with kernel 6.0.17. To confirm those error never occurred on Ubuntu 25.10, only since I updated to 26.04. NIC: AQC113 [1d6a:04c0] Behavior encountered: ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 21 18:50:54 motoko kernel: acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] May 21 18:50:55 motoko kernel: pcieport 0000:00:01.1: AER: enabled with IRQ 27 May 21 18:50:55 motoko kernel: pcieport 0000:00:01.2: AER: enabled with IRQ 28 May 21 18:50:55 motoko kernel: pcieport 0000:00:03.1: AER: enabled with IRQ 29 May 21 18:50:55 motoko kernel: pcieport 0000:00:07.1: AER: enabled with IRQ 31 May 21 18:50:55 motoko kernel: pcieport 0000:00:08.1: AER: enabled with IRQ 32 May 21 18:50:55 motoko kernel: atlantic: Detect ATL2FW 105002a May 21 18:50:55 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 21 18:50:55 motoko kernel: Modules linked in: nvidia(OE+) ee1004(+) snd_hda_core(+) snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event ghash_clmulni_intel aesni_intel snd_rawmidi rapl snd_seq mfd_aaeon eeepc_wmi(+) fjes(-) asus_wmi snd_seq_device sparse_keymap snd_timer input_leds(+) joydev(+) platform_profile wmi_bmof drm_ttm_helper snd ttm ccp i2c_piix4 video k10temp soundcore i2c_smbus mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc lp parport_pc ppdev parport msr efi_pstore nfnetlink dmi_sysfs autofs4 atlantic r8169 ahci macsec libahci realtek nvme nvme_core nvme_keyring nvme_auth hkdf wmi hid_generic usbhid uas hid usb_storage May 21 18:51:15 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:25 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:34:41 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:49 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:35:04 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 08:56:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 08:57:09 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 Device: ethtool enp6s0 | grep -E 'Speed|Duplex|Link detected' ethtool -i enp6s0 | grep firmware netlink error: Operation not permitted Speed: 10000Mb/s Duplex: Full Link detected: yes firmware-version: 1.5.42 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3113 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3113 F.... wireplumber /dev/snd/seq: gdm-greeter 3009 F.... pipewire CasperMD5CheckResult: pass Date: Fri May 22 18:19:59 2026 InstallationDate: Installed on 2024-05-26 (727 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=f2b31c5a-0840-4e84-be10-e3a511e7c343 ro quiet splash pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (6 days ago) dmi.bios.date: 08/09/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4021 dmi.board.asset.tag: Default string dmi.board.name: PRIME X570-P dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4021:bd08/09/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX570-P:rvrRevX.0x: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: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154053/+subscriptions
[Bug 2153968] Re: After upgrading the kernel from 7.0.0-14 to 7.0.0-15 on a MacBook Pro 11,4 (Haswell, i915, Ubuntu 26.04), suspend on lid close stopped working.
Additional note: As a workaround, the system is currently running on kernel 7.0.0-14-generic. On this kernel, a separate backlight issue exists after resume — brightness is not restored to its previous level. This is fixed by adding acpi_backlight=native to GRUB_CMDLINE_LINUX_DEFAULT. This workaround was also tested on 7.0.0-15-generic, but did not resolve the backlight issue on that kernel. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153968 Title: After upgrading the kernel from 7.0.0-14 to 7.0.0-15 on a MacBook Pro 11,4 (Haswell, i915, Ubuntu 26.04), suspend on lid close stopped working. Status in linux package in Ubuntu: New Bug description: After upgrading the kernel from 7.0.0-14 to 7.0.0-15 on a MacBook Pro 11,4 (Haswell, i915, Ubuntu 26.04), suspend on lid close stopped working. The system goes to sleep but fails to resume — the screen remains black, keyboard and trackpad are unresponsive. The issue is absent on kernel 7.0.0-14. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0 Uname: Linux 7.0.0-14-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: elph 3715 F.... wireplumber /dev/snd/controlC0: elph 3715 F.... wireplumber /dev/snd/seq: elph 3699 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri May 22 10:39:47 2026 InstallationDate: Installed on 2026-04-26 (26 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 05ac:8290 Apple, Inc. Bluetooth Host Controller Bus 001 Device 003: ID 05ac:0274 Apple, Inc. Apple Internal Keyboard / Trackpad Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 05ac:8406 Apple, Inc. Internal Memory Card Reader MachineType: Apple Inc. MacBookPro11,4 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-14-generic root=UUID=37a6c347-573a-443f-9173-51f2fc996c3c ro quiet splash acpi_osi=Darwin 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: 10/07/2023 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 489.0.0.0.0 dmi.board.name: Mac-06F11FD93F0323C5 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,4 dmi.chassis.type: 9 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-06F11FD93F0323C5 dmi.modalias: dmi:bvnAppleInc.:bvr489.0.0.0.0:bd10/07/2023:br0.1:svnAppleInc.:pnMacBookPro11,4:pvr1.0:rvnAppleInc.:rnMac-06F11FD93F0323C5:rvrMacBookPro11,4:cvnAppleInc.:ct9:cvrMac-06F11FD93F0323C5:sku:pfaMacBookPro: dmi.product.family: MacBook Pro dmi.product.name: MacBookPro11,4 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/2153968/+subscriptions
пятница
[Bug 2154053] Re: atlatnic driver issue on kernel 7
Apparently this is not kernel related. I rebooted to 6.0.17 but I still see the issue ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 22 18:51:48 motoko kernel: atlantic: Detect ATL2FW 105002a May 22 18:51:48 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 22 18:51:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 18:52:00 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 18:52:08 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154053 Title: atlatnic driver issue on kernel 7 Status in linux package in Ubuntu: New Bug description: I recently updated to Ubuntu 26.04 with a Kernel 7.0.0 I am having issue with the driver for my 10G card which worked fine on Ubuntu 25.10 with kernel 6.0.17. To confirm those error never occurred on Ubuntu 25.10, only since I updated to 26.04. NIC: AQC113 [1d6a:04c0] Behavior encountered: ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 21 18:50:54 motoko kernel: acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] May 21 18:50:55 motoko kernel: pcieport 0000:00:01.1: AER: enabled with IRQ 27 May 21 18:50:55 motoko kernel: pcieport 0000:00:01.2: AER: enabled with IRQ 28 May 21 18:50:55 motoko kernel: pcieport 0000:00:03.1: AER: enabled with IRQ 29 May 21 18:50:55 motoko kernel: pcieport 0000:00:07.1: AER: enabled with IRQ 31 May 21 18:50:55 motoko kernel: pcieport 0000:00:08.1: AER: enabled with IRQ 32 May 21 18:50:55 motoko kernel: atlantic: Detect ATL2FW 105002a May 21 18:50:55 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 21 18:50:55 motoko kernel: Modules linked in: nvidia(OE+) ee1004(+) snd_hda_core(+) snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event ghash_clmulni_intel aesni_intel snd_rawmidi rapl snd_seq mfd_aaeon eeepc_wmi(+) fjes(-) asus_wmi snd_seq_device sparse_keymap snd_timer input_leds(+) joydev(+) platform_profile wmi_bmof drm_ttm_helper snd ttm ccp i2c_piix4 video k10temp soundcore i2c_smbus mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc lp parport_pc ppdev parport msr efi_pstore nfnetlink dmi_sysfs autofs4 atlantic r8169 ahci macsec libahci realtek nvme nvme_core nvme_keyring nvme_auth hkdf wmi hid_generic usbhid uas hid usb_storage May 21 18:51:15 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:25 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:34:41 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:49 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:35:04 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 08:56:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 08:57:09 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 Device: ethtool enp6s0 | grep -E 'Speed|Duplex|Link detected' ethtool -i enp6s0 | grep firmware netlink error: Operation not permitted Speed: 10000Mb/s Duplex: Full Link detected: yes firmware-version: 1.5.42 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3113 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3113 F.... wireplumber /dev/snd/seq: gdm-greeter 3009 F.... pipewire CasperMD5CheckResult: pass Date: Fri May 22 18:19:59 2026 InstallationDate: Installed on 2024-05-26 (727 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=f2b31c5a-0840-4e84-be10-e3a511e7c343 ro quiet splash pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (6 days ago) dmi.bios.date: 08/09/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4021 dmi.board.asset.tag: Default string dmi.board.name: PRIME X570-P dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4021:bd08/09/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX570-P:rvrRevX.0x: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: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154053/+subscriptions
[Bug 2153962] Re: net/rds: reset op_nents when zerocopy page pin fails
** 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/2153962 Title: net/rds: reset op_nents when zerocopy page pin fails Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: In Progress Status in linux source package in Noble: In Progress Status in linux source package in Questing: In Progress Status in linux source package in Resolute: In Progress Bug description: From https://lore.kernel.org/netdev/20260505234336.2132721-1-achender@kernel.org/ When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson <achender@kernel.org> --- net/rds/message.c | 1 + 1 file changed, 1 insertion(+) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153962/+subscriptions
[Bug 2153976] Re: Fix graceful fault handling after FPU softirq changes causes hard freeze on EFI runtime calls
** 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/2153976 Title: Fix graceful fault handling after FPU softirq changes causes hard freeze on EFI runtime calls 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: New Status in linux source package in Resolute: New Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, 02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153976/+subscriptions
[Bug 2153983] Re: After upgrading to Ubuntu 26.04, the touchpad click stopped working
** 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/2153983 Title: After upgrading to Ubuntu 26.04, the touchpad click stopped working Status in linux package in Ubuntu: New Bug description: After upgrading to Ubuntu 26.04, the touchpad click stopped working. Logs show 'libinput error: kernel bug: missing right button'. This affects the SYNA3602:00 093A:0255 device on Kernel 7.0.0. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: hasan 2305 F.... wireplumber /dev/snd/seq: hasan 2284 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri May 22 14:24:43 2026 InstallationDate: Installed on 2026-03-08 (75 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 04f2:b650 Chicony Electronics Co., Ltd USB2.0 FHD UVC WebCam Bus 001 Device 003: ID 046d:c077 Logitech, Inc. Mouse Bus 001 Device 004: ID 8087:0026 Intel Corp. AX201 Bluetooth Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: Daffodil Computers Ltd. DC253D ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=82bcd8aa-a94f-4841-93f0-4298c7d088b0 ro quiet splash i8042.reset crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-21 (1 days ago) dmi.bios.date: 09/14/2024 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: BM_BI_IDL528_175B_F dmi.board.asset.tag: Default string dmi.board.name: DC253D dmi.board.vendor: Daffodil Computers Ltd. dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 10 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.ec.firmware.release: 1.6 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrBM_BI_IDL528_175B_F:bd09/14/2024:br5.27:efr1.6:svnDaffodilComputersLtd.:pnDC253D:pvrBM_BI_IDL528_175B_F:rvnDaffodilComputersLtd.:rnDC253D:rvrDefaultstring:cvnDefaultstring:ct10:cvrDefaultstring:skuDC253D:pfaDefaultstring: dmi.product.family: Default string dmi.product.name: DC253D dmi.product.sku: DC253D dmi.product.version: BM_BI_IDL528_175B_F dmi.sys.vendor: Daffodil Computers Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153983/+subscriptions
[Bug 2154053] Re: atlatnic driver issue on kernel 7
** 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/2154053 Title: atlatnic driver issue on kernel 7 Status in linux package in Ubuntu: New Bug description: I recently updated to Ubuntu 26.04 with a Kernel 7.0.0 I am having issue with the driver for my 10G card which worked fine on Ubuntu 25.10 with kernel 6.0.17. To confirm those error never occurred on Ubuntu 25.10, only since I updated to 26.04. NIC: AQC113 [1d6a:04c0] Behavior encountered: ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 21 18:50:54 motoko kernel: acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] May 21 18:50:55 motoko kernel: pcieport 0000:00:01.1: AER: enabled with IRQ 27 May 21 18:50:55 motoko kernel: pcieport 0000:00:01.2: AER: enabled with IRQ 28 May 21 18:50:55 motoko kernel: pcieport 0000:00:03.1: AER: enabled with IRQ 29 May 21 18:50:55 motoko kernel: pcieport 0000:00:07.1: AER: enabled with IRQ 31 May 21 18:50:55 motoko kernel: pcieport 0000:00:08.1: AER: enabled with IRQ 32 May 21 18:50:55 motoko kernel: atlantic: Detect ATL2FW 105002a May 21 18:50:55 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 21 18:50:55 motoko kernel: Modules linked in: nvidia(OE+) ee1004(+) snd_hda_core(+) snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event ghash_clmulni_intel aesni_intel snd_rawmidi rapl snd_seq mfd_aaeon eeepc_wmi(+) fjes(-) asus_wmi snd_seq_device sparse_keymap snd_timer input_leds(+) joydev(+) platform_profile wmi_bmof drm_ttm_helper snd ttm ccp i2c_piix4 video k10temp soundcore i2c_smbus mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc lp parport_pc ppdev parport msr efi_pstore nfnetlink dmi_sysfs autofs4 atlantic r8169 ahci macsec libahci realtek nvme nvme_core nvme_keyring nvme_auth hkdf wmi hid_generic usbhid uas hid usb_storage May 21 18:51:15 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:25 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:34:41 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:49 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:35:04 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 08:56:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 08:57:09 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 Device: ethtool enp6s0 | grep -E 'Speed|Duplex|Link detected' ethtool -i enp6s0 | grep firmware netlink error: Operation not permitted Speed: 10000Mb/s Duplex: Full Link detected: yes firmware-version: 1.5.42 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3113 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3113 F.... wireplumber /dev/snd/seq: gdm-greeter 3009 F.... pipewire CasperMD5CheckResult: pass Date: Fri May 22 18:19:59 2026 InstallationDate: Installed on 2024-05-26 (727 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=f2b31c5a-0840-4e84-be10-e3a511e7c343 ro quiet splash pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (6 days ago) dmi.bios.date: 08/09/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4021 dmi.board.asset.tag: Default string dmi.board.name: PRIME X570-P dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4021:bd08/09/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX570-P:rvrRevX.0x: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: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154053/+subscriptions
[Bug 2154053] [NEW] atlatnic driver issue on kernel 7
Public bug reported: I recently updated to Ubuntu 26.04 with a Kernel 7.0.0 I am having issue with the driver for my 10G card which worked fine on Ubuntu 25.10 with kernel 6.0.17. To confirm those error never occurred on Ubuntu 25.10, only since I updated to 26.04. NIC: AQC113 [1d6a:04c0] Behavior encountered: ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 21 18:50:54 motoko kernel: acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] May 21 18:50:55 motoko kernel: pcieport 0000:00:01.1: AER: enabled with IRQ 27 May 21 18:50:55 motoko kernel: pcieport 0000:00:01.2: AER: enabled with IRQ 28 May 21 18:50:55 motoko kernel: pcieport 0000:00:03.1: AER: enabled with IRQ 29 May 21 18:50:55 motoko kernel: pcieport 0000:00:07.1: AER: enabled with IRQ 31 May 21 18:50:55 motoko kernel: pcieport 0000:00:08.1: AER: enabled with IRQ 32 May 21 18:50:55 motoko kernel: atlantic: Detect ATL2FW 105002a May 21 18:50:55 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 21 18:50:55 motoko kernel: Modules linked in: nvidia(OE+) ee1004(+) snd_hda_core(+) snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event ghash_clmulni_intel aesni_intel snd_rawmidi rapl snd_seq mfd_aaeon eeepc_wmi(+) fjes(-) asus_wmi snd_seq_device sparse_keymap snd_timer input_leds(+) joydev(+) platform_profile wmi_bmof drm_ttm_helper snd ttm ccp i2c_piix4 video k10temp soundcore i2c_smbus mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc lp parport_pc ppdev parport msr efi_pstore nfnetlink dmi_sysfs autofs4 atlantic r8169 ahci macsec libahci realtek nvme nvme_core nvme_keyring nvme_auth hkdf wmi hid_generic usbhid uas hid usb_storage May 21 18:51:15 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:25 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:34:41 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:49 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:35:04 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 08:56:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 08:57:09 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 Device: ethtool enp6s0 | grep -E 'Speed|Duplex|Link detected' ethtool -i enp6s0 | grep firmware netlink error: Operation not permitted Speed: 10000Mb/s Duplex: Full Link detected: yes firmware-version: 1.5.42 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3113 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3113 F.... wireplumber /dev/snd/seq: gdm-greeter 3009 F.... pipewire CasperMD5CheckResult: pass Date: Fri May 22 18:19:59 2026 InstallationDate: Installed on 2024-05-26 (727 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=f2b31c5a-0840-4e84-be10-e3a511e7c343 ro quiet splash pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (6 days ago) dmi.bios.date: 08/09/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4021 dmi.board.asset.tag: Default string dmi.board.name: PRIME X570-P dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4021:bd08/09/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX570-P:rvrRevX.0x: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: System manufacturer ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154053 Title: atlatnic driver issue on kernel 7 Status in linux package in Ubuntu: New Bug description: I recently updated to Ubuntu 26.04 with a Kernel 7.0.0 I am having issue with the driver for my 10G card which worked fine on Ubuntu 25.10 with kernel 6.0.17. To confirm those error never occurred on Ubuntu 25.10, only since I updated to 26.04. NIC: AQC113 [1d6a:04c0] Behavior encountered: ❯ journalctl -k -b | grep -iE 'atlantic|link change|carrier|AER|PCIe Bus Error' May 21 18:50:54 motoko kernel: acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] May 21 18:50:55 motoko kernel: pcieport 0000:00:01.1: AER: enabled with IRQ 27 May 21 18:50:55 motoko kernel: pcieport 0000:00:01.2: AER: enabled with IRQ 28 May 21 18:50:55 motoko kernel: pcieport 0000:00:03.1: AER: enabled with IRQ 29 May 21 18:50:55 motoko kernel: pcieport 0000:00:07.1: AER: enabled with IRQ 31 May 21 18:50:55 motoko kernel: pcieport 0000:00:08.1: AER: enabled with IRQ 32 May 21 18:50:55 motoko kernel: atlantic: Detect ATL2FW 105002a May 21 18:50:55 motoko kernel: atlantic 0000:06:00.0 enp6s0: renamed from eth1 May 21 18:50:55 motoko kernel: Modules linked in: nvidia(OE+) ee1004(+) snd_hda_core(+) snd_intel_dspcfg snd_intel_sdw_acpi snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event ghash_clmulni_intel aesni_intel snd_rawmidi rapl snd_seq mfd_aaeon eeepc_wmi(+) fjes(-) asus_wmi snd_seq_device sparse_keymap snd_timer input_leds(+) joydev(+) platform_profile wmi_bmof drm_ttm_helper snd ttm ccp i2c_piix4 video k10temp soundcore i2c_smbus mac_hid nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc lp parport_pc ppdev parport msr efi_pstore nfnetlink dmi_sysfs autofs4 atlantic r8169 ahci macsec libahci realtek nvme nvme_core nvme_keyring nvme_auth hkdf wmi hid_generic usbhid uas hid usb_storage May 21 18:51:15 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:25 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:34:41 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 02:34:49 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 02:35:04 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 May 22 08:56:59 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 10000 new 0 May 22 08:57:09 motoko kernel: atlantic 0000:06:00.0 enp6s0: atlantic: link change old 0 new 10000 Device: ethtool enp6s0 | grep -E 'Speed|Duplex|Link detected' ethtool -i enp6s0 | grep firmware netlink error: Operation not permitted Speed: 10000Mb/s Duplex: Full Link detected: yes firmware-version: 1.5.42 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 3113 F.... wireplumber /dev/snd/controlC0: gdm-greeter 3113 F.... wireplumber /dev/snd/seq: gdm-greeter 3009 F.... pipewire CasperMD5CheckResult: pass Date: Fri May 22 18:19:59 2026 InstallationDate: Installed on 2024-05-26 (727 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=f2b31c5a-0840-4e84-be10-e3a511e7c343 ro quiet splash pcie_aspm=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (6 days ago) dmi.bios.date: 08/09/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4021 dmi.board.asset.tag: Default string dmi.board.name: PRIME X570-P dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4021:bd08/09/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX570-P:rvrRevX.0x: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: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154053/+subscriptions
четверг
[Bug 2153976] [NEW] Fix graceful fault handling after FPU softirq changes causes hard freeze on EFI runtime calls
Public bug reported: [Impact] Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, 02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: Invalid ** Affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: Invalid ** Description changed: - [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, - 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hard - system freeze. The machine becomes unreachable by ping/SSH and requires a hard - power cycle. - - Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making - kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use - local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in - preempt_count during EFI runtime calls, making in_interrupt() return true in - normal task context. The EFI graceful page fault handler - efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults - in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails - out, leaving firmware page faults unhandled. This escalates to die() which also - sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), - freezing the system. - - [Fix] - Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). - This preserves the original intent of bailing for interrupts or NMI faults, - while no longer falsely triggering from the FPU code path's local_bh_disable(). - - - [Test Plan] - 1. Boot affected HP machine with the patched 6.17-oem kernel. - 2. Run: - $ sudo fwts uefirttime - - Without patch: system hard-freezes, requires power cycle. - With patch: fwts completes (pass or fail), system remains responsive. - - [Where problems could occur] - The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). - - If !in_task() incorrectly identifies a real interrupt-context fault as task - context, the handler would try to process it as an EFI firmware fault instead - of letting the normal oops path handle it. This could mask real kernel bugs - during interrupt-context EFI faults, though such faults are extremely rare. - - Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the - fpregs_lock() call could cause a page fault that gets misidentified. The use of - !in_task() (which incorporates in_serving_softirq()) handles this window - correctly. - - [Other Info] - Upstream commit: 088f65e206087bf903743bd18417261d7a4c9644 - Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") SRU for oem-6.17. + [Impact] + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, + 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hard + system freeze. The machine becomes unreachable by ping/SSH and requires a hard + power cycle. + + Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making + kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use + local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in + preempt_count during EFI runtime calls, making in_interrupt() return true in + normal task context. The EFI graceful page fault handler + efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults + in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails + out, leaving firmware page faults unhandled. This escalates to die() which also + sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), + freezing the system. + + [Fix] + Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). + This preserves the original intent of bailing for interrupts or NMI faults, + while no longer falsely triggering from the FPU code path's local_bh_disable(). + + [Test Plan] + 1. Boot affected HP machine with the patched 6.17-oem kernel. + 2. Run: + $ sudo fwts uefirttime + + Without patch: system hard-freezes, requires power cycle. + With patch: fwts completes (pass or fail), system remains responsive. + + [Where problems could occur] + The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). + + If !in_task() incorrectly identifies a real interrupt-context fault as task + context, the handler would try to process it as an EFI firmware fault instead + of letting the normal oops path handle it. This could mask real kernel bugs + during interrupt-context EFI faults, though such faults are extremely rare. + + Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the + fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window + correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, - 202511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hard - system freeze. The machine becomes unreachable by ping/SSH and requires a hard - power cycle. + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. - Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making - kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use - local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in - preempt_count during EFI runtime calls, making in_interrupt() return true in - normal task context. The EFI graceful page fault handler - efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults - in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails - out, leaving firmware page faults unhandled. This escalates to die() which also - sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), - freezing the system. + Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making + kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use + local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in + preempt_count during EFI runtime calls, making in_interrupt() return true in + normal task context. The EFI graceful page fault handler + efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults + in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails + out, leaving firmware page faults unhandled. This escalates to die() which also + sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), + freezing the system. - [Fix] - Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). - This preserves the original intent of bailing for interrupts or NMI faults, - while no longer falsely triggering from the FPU code path's local_bh_disable(). + [Fix] + Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). + This preserves the original intent of bailing for interrupts or NMI faults, + while no longer falsely triggering from the FPU code path's local_bh_disable(). - [Test Plan] - 1. Boot affected HP machine with the patched 6.17-oem kernel. - 2. Run: - $ sudo fwts uefirttime + [Test Plan] + 1. Boot affected HP machine with the patched 6.17-oem kernel. + 2. Run: + $ sudo fwts uefirttime - Without patch: system hard-freezes, requires power cycle. - With patch: fwts completes (pass or fail), system remains responsive. + Without patch: system hard-freezes, requires power cycle. + With patch: fwts completes (pass or fail), system remains responsive. - [Where problems could occur] - The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). - - If !in_task() incorrectly identifies a real interrupt-context fault as task - context, the handler would try to process it as an EFI firmware fault instead - of letting the normal oops path handle it. This could mask real kernel bugs - during interrupt-context EFI faults, though such faults are extremely rare. - - Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the - fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window - correctly. + [Where problems could occur] + The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). + If !in_task() incorrectly identifies a real interrupt-context fault as task + context, the handler would try to process it as an EFI firmware fault instead + of letting the normal oops path handle it. This could mask real kernel bugs + during interrupt-context EFI faults, though such faults are extremely rare. + Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the + fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a + hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the - fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. + fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window + correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a + hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, + 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the - fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window + fpregs_lock() call could cause a page fault that gets misidentified. The use + of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the - fpregs_lock() call could cause a page fault that gets misidentified. The use - of !in_task() (which incorporates in_serving_softirq()) handles this window + fpregs_lock() call could cause a page fault that gets misidentified. The use + of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Description changed: [Impact] - Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, - 202511-38088,02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a + Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, + 02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use - of !in_task() (which incorporates in_serving_softirq()) handles this window + of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. ** Also affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid ** Description changed: [Impact] Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, - 02511-38091, 202511-38068, 202511-38069) with 6.17.0-1018-oem causes a - hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a - hardpower cycle. + 02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze. + The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153976 Title: Fix graceful fault handling after FPU softirq changes causes hard freeze on EFI runtime calls 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: New Status in linux source package in Resolute: New Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] Running `sudo fwts uefirttime` on HP systems (CID: 202511-38089, 202511-38088, 02511-38091, 202511-38068, 202511-38069) with 6.17 causes a hardsystem freeze. The machine becomes unreachable by ping/SSH and requires a hardpower cycle. Root cause: commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") changed kernel_fpu_begin() to use local_bh_disable() instead of preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during EFI runtime calls, making in_interrupt() return true in normal task context. The EFI graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), freezing the system. [Fix] Replace in_interrupt() with !in_task() in efi_crash_gracefully_on_page_fault(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). [Test Plan] 1. Boot affected HP machine with the patched 6.17-oem kernel. 2. Run: $ sudo fwts uefirttime Without patch: system hard-freezes, requires power cycle. With patch: fwts completes (pass or fail), system remains responsive. [Where problems could occur] The change is in the EFI page fault handler (arch/x86/platform/efi/quirks.c). If !in_task() incorrectly identifies a real interrupt-context fault as task context, the handler would try to process it as an EFI firmware fault instead of letting the normal oops path handle it. This could mask real kernel bugs during interrupt-context EFI faults, though such faults are extremely rare. Also, a softirq taken between efi_rts_work.efi_rts_id assignment and the fpregs_lock() call could cause a page fault that gets misidentified. The use of !in_task() (which incorporates in_serving_softirq()) handles this window correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153976/+subscriptions
[Bug 2153412] Re: Boot failure in 24.04.4 LTS after 6.8.0-117-generic upgrade
Hi Richard, Did you know where is the nvidia module from? From normal module package or dkms? BR An -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153412 Title: Boot failure in 24.04.4 LTS after 6.8.0-117-generic upgrade Status in linux package in Ubuntu: New Bug description: Failure to boot system with three monitors and NVIDIA driver. Freezes at black screen or screen with Ubuntu text. Diagnostics (ChatGPT assisted) included this conclusion: +++Diagnostic+++ The failed boot’s journal simply stops abruptly at 09:25:12, while systemd is still in very early boot, just after starting Plymouth and flushing the journal to disk. There is no later evidence of reaching normal multi-user startup, let alone GDM. That makes this look like a hard freeze during early boot: The NVIDIA 470 modules do load. The machine then continues briefly through early device and systemd initialization. Logging stops suddenly before the display manager starts. (A separate user with Ubuntu 24.04.4, kernel 6.8.0-117, and an older NVIDIA GT 710 reports a strikingly similar failure, with 6.8.0-111 still working.) Kernel 6.8.0-117 is likely triggering a low-level regression on older NVIDIA 470-series systems, causing a freeze during early graphics- related boot initialization. ++++++++++summary+++++++++++++ Regression: 6.8.0-111-generic boots; 6.8.0-117-generic hard-freezes. GPU/driver: GeForce GT 730 GK208B, nvidia-driver-470 470.256.02. Symptoms: DP screens black/frozen splash, DVI screen multicolored stripes. Logs: NVIDIA module loads successfully; journal stops abruptly during early boot before GDM. Topology test: unplugging DVI or DisplayPort did not change the failure. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-111-generic 6.8.0-111.111 ProcVersionSignature: Ubuntu 6.8.0-111.111-generic 6.8.12 Uname: Linux 6.8.0-111-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: rae 3431 F.... wireplumber /dev/snd/controlC0: rae 3431 F.... wireplumber /dev/snd/controlC1: rae 3431 F.... wireplumber /dev/snd/seq: rae 3429 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed May 20 12:08:11 2026 InstallationDate: Installed on 2019-11-08 (2385 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) IwConfig: lo no wireless extensions. eno1 no wireless extensions. MachineType: HP HP EliteDesk 800 G5 TWR ProcFB: 0 simpledrmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-111-generic root=UUID=f85bdd6e-e36e-4cc1-a8a1-0063ccb67b0d ro quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-6.8.0-111-generic N/A linux-backports-modules-6.8.0-111-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/28/2021 dmi.bios.release: 12.0 dmi.bios.vendor: HP dmi.bios.version: R01 Ver. 02.12.00 dmi.board.name: 8591 dmi.board.vendor: HP dmi.board.version: KBC Version 08.98.00 dmi.chassis.asset.tag: CZC939FL6Q dmi.chassis.type: 3 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.152 dmi.modalias: dmi:bvnHP:bvrR01Ver.02.12.00:bd12/28/2021:br12.0:efr8.152:svnHP:pnHPEliteDesk800G5TWR:pvr:rvnHP:rn8591:rvrKBCVersion08.98.00:cvnHP:ct3:cvr:sku6BD61AV: dmi.product.family: 103C_53307F HP EliteDesk dmi.product.name: HP EliteDesk 800 G5 TWR dmi.product.sku: 6BD61AV dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153412/+subscriptions
[Bug 2153966] [NEW] usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()
Public bug reported: SRU Justification: [ Impact ] xhci_endpoint_disable() clears host_ep->hcpriv = NULL, which breaks xhci_endpoint_reset(). When a USB driver (e.g. uvcvideo) calls usb_set_interface(), submits URBs that make host sequence state non-zero, then calls usb_clear_halt(), the device clears its sequence state but xhci_endpoint_reset() bails out because hcpriv is NULL. The next URB malfunctions: USB2 loses one packet, USB3 gets Transaction Error or may not complete at all on some host controllers from ASMedia and AMD. This is triggered by uvcvideo on bulk video devices. [ Fix ] Cherry-pick upstream mainline commit: - 25e531b422dc ("usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()") Fixes: 18b74067ac78 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: stable@vger.kernel.org [ Test Plan ] 1. System with USB3 bulk video device (e.g. USB webcam using uvcvideo) 2. Use the camera with an application (e.g. cheese, guvcview) 3. Trigger usb_set_interface + usb_clear_halt sequence 4. Verify no Transaction Errors or packet loss in dmesg 5. Verify endpoint_reset works correctly after endpoint_disable [ Where problems could occur ] The fix removes one line (host_ep->hcpriv = NULL) from xhci_endpoint_disable(). Risk is very low — the commit message explains hcpriv should only be NULL on emulated root hub endpoints, and core should not try to reset dropped endpoints. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Affects: linux (Ubuntu Questing) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu Questing) Importance: Undecided Status: New ** Affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Questing) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Questing) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Resolute) 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/2153966 Title: usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable() Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: New Status in linux-oem-6.17 source package in Noble: New Status in linux source package in Questing: New Status in linux-oem-6.17 source package in Questing: New Status in linux source package in Resolute: New Status in linux-oem-6.17 source package in Resolute: New Bug description: SRU Justification: [ Impact ] xhci_endpoint_disable() clears host_ep->hcpriv = NULL, which breaks xhci_endpoint_reset(). When a USB driver (e.g. uvcvideo) calls usb_set_interface(), submits URBs that make host sequence state non-zero, then calls usb_clear_halt(), the device clears its sequence state but xhci_endpoint_reset() bails out because hcpriv is NULL. The next URB malfunctions: USB2 loses one packet, USB3 gets Transaction Error or may not complete at all on some host controllers from ASMedia and AMD. This is triggered by uvcvideo on bulk video devices. [ Fix ] Cherry-pick upstream mainline commit: - 25e531b422dc ("usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()") Fixes: 18b74067ac78 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: stable@vger.kernel.org [ Test Plan ] 1. System with USB3 bulk video device (e.g. USB webcam using uvcvideo) 2. Use the camera with an application (e.g. cheese, guvcview) 3. Trigger usb_set_interface + usb_clear_halt sequence 4. Verify no Transaction Errors or packet loss in dmesg 5. Verify endpoint_reset works correctly after endpoint_disable [ Where problems could occur ] The fix removes one line (host_ep->hcpriv = NULL) from xhci_endpoint_disable(). Risk is very low — the commit message explains hcpriv should only be NULL on emulated root hub endpoints, and core should not try to reset dropped endpoints. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153966/+subscriptions
[Bug 2153962] Re: net/rds: reset op_nents when zerocopy page pin fails
Currently I am able to verify the reproducer no longer works on Q/R, but not N/J/F. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153962 Title: net/rds: reset op_nents when zerocopy page pin fails Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Noble: In Progress Status in linux source package in Questing: In Progress Status in linux source package in Resolute: In Progress Bug description: From https://lore.kernel.org/netdev/20260505234336.2132721-1-achender@kernel.org/ When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson <achender@kernel.org> --- net/rds/message.c | 1 + 1 file changed, 1 insertion(+) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153962/+subscriptions