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
[Bug 2153962] [NEW] net/rds: reset op_nents when zerocopy page pin fails
Public bug reported: 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(+) ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Benjamin Wheeler (benjaminwheeler) Status: In Progress ** Affects: linux (Ubuntu Focal) Importance: Undecided Status: In Progress ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: In Progress ** Affects: linux (Ubuntu Noble) Importance: Undecided Status: In Progress ** Affects: linux (Ubuntu Questing) Importance: Undecided Status: In Progress ** Affects: linux (Ubuntu Resolute) Importance: Undecided Status: In Progress ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Questing) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Changed in: linux (Ubuntu Noble) Status: New => In Progress ** Changed in: linux (Ubuntu Resolute) Status: New => In Progress ** Changed in: linux (Ubuntu Questing) Status: New => In Progress ** Changed in: linux (Ubuntu Jammy) Status: New => In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/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
[Bug 2153556] Re: Kernel regression (6.8.0-117.generic)
We do use it for back-ends on clusters (heartbeat networks) to avoid having to install dedicated switches for this. I believe this even the default recommendation by the Proxmox folks for 3-5 node setups. Hopefully that question is not an omen. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153556 Title: Kernel regression (6.8.0-117.generic) Status in linux package in Ubuntu: New Bug description: There is a regression for the CVE-2026-31419 patch in kernel 117.generic that was supposed to fix a vulnerability in bonding mode 3. This patch caused mode 3 bonding to completely break on a production cluster. We were able to recover services by booting on a .111 fallback. Hardware is ConnectX-6 at 100G, all interfaces, links and bonding status appear to be up but no packets are passed. Unfortunately, this is a production system so it's now on an older kernel so testing isn't possible. If necessary, I can bring up a pair of VMs to run some tests for this. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153556/+subscriptions
[Bug 2153556] Re: Kernel regression (6.8.0-117.generic)
Clint, Do you actually use broadcast mode (mode 3) for a real use case, or is this part of a test? -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153556 Title: Kernel regression (6.8.0-117.generic) Status in linux package in Ubuntu: New Bug description: There is a regression for the CVE-2026-31419 patch in kernel 117.generic that was supposed to fix a vulnerability in bonding mode 3. This patch caused mode 3 bonding to completely break on a production cluster. We were able to recover services by booting on a .111 fallback. Hardware is ConnectX-6 at 100G, all interfaces, links and bonding status appear to be up but no packets are passed. Unfortunately, this is a production system so it's now on an older kernel so testing isn't possible. If necessary, I can bring up a pair of VMs to run some tests for this. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153556/+subscriptions
[Bug 2153791] Re: s2idle broken on ThinkPad L13 Gen 2: iwlwifi crash prevents real suspend, battery fully drains, all input/network dead on wake
** 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/2153791 Title: s2idle broken on ThinkPad L13 Gen 2: iwlwifi crash prevents real suspend, battery fully drains, all input/network dead on wake Status in linux package in Ubuntu: New Bug description: [Regression 6.17.0-29] s2idle broken on ThinkPad L13 Gen 2: iwlwifi crash prevents real suspend, battery fully drains, all input/network dead on wake Regression introduced: 6.17.0-29 (installed 2026-05-20). Worked correctly on 6.17.0-23. Hardware: ThinkPad L13 Gen 2 — Intel Wi-Fi 6 AX201 (iwlwifi) Symptoms after suspend >~30 min: WiFi completely dead on wake All input devices dead: USB mouse, trackpad, TrackPoint Battery fully drained during suspend (system not entering low-power state) Hard reboot required Root cause evidence from journalctl -b 0: iwlwifi 0000:00:14.3: 0x03100000 | IML/ROM error/state usb 3-10: Failed to suspend device, error -110 Bluetooth: hci0: Reading supported features failed (-110) Low-power S0 idle used by default for system suspend Only s2idle available (cat /sys/power/mem_sleep → [s2idle]). S3 not available on this platform. Workaround: Booting 6.17.0-23 resolves all symptoms. ProblemType: Bug DistroRelease: Ubuntu 25.10 Package: linux-image-6.17.0-29-generic 6.17.0-29.29 ProcVersionSignature: Ubuntu 6.17.0-29.29-generic 6.17.13 Uname: Linux 6.17.0-29-generic x86_64 ApportVersion: 2.33.1-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: shash 3139 F.... wireplumber /dev/snd/seq: shash 3105 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu May 21 20:47:48 2026 InstallationDate: Installed on 2025-09-25 (238 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) MachineType: LENOVO 20VJS11U00 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-6.17.0-29-generic root=UUID=53e87fc4-37c9-49c0-b8d2-acb5d94b77c0 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: firmware-sof N/A linux-firmware 20250901.git993ff19b-0ubuntu1.11 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/29/2021 dmi.bios.release: 1.8 dmi.bios.vendor: LENOVO dmi.bios.version: R1PET16W (1.08 ) dmi.board.asset.tag: Not Available dmi.board.name: 20VJS11U00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: LS07831 dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.6 dmi.modalias: dmi:bvnLENOVO:bvrR1PET16W(1.08):bd04/29/2021:br1.8:efr1.6:svnLENOVO:pn20VJS11U00:pvrThinkPadL13Gen2:rvnLENOVO:rn20VJS11U00:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20VJ_BU_Think_FM_ThinkPadL13Gen2: dmi.product.family: ThinkPad L13 Gen 2 dmi.product.name: 20VJS11U00 dmi.product.sku: LENOVO_MT_20VJ_BU_Think_FM_ThinkPad L13 Gen 2 dmi.product.version: ThinkPad L13 Gen 2 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153791/+subscriptions
[Bug 2153949] Re: ASUS ROG Strix SCAR 18 G835LX — speakers silent, TAS2781 amps never bind (wrong HDA fixup)
** 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/2153949 Title: ASUS ROG Strix SCAR 18 G835LX — speakers silent, TAS2781 amps never bind (wrong HDA fixup) Status in linux package in Ubuntu: New Bug description: Built-in speakers on the ASUS ROG Strix SCAR 18 (G835LX) are completely silent on Ubuntu 25.10 with kernel 7.0.0-15-generic. The TAS2781 smart amplifiers (3x TI TAS2781 at I2C 0x38/0x39/0x40) never load firmware and never bind to the HDA codec via the component framework. The HDA quirk table in sound/hda/codecs/realtek/alc269.c maps PCI SSID 1043:3f10 to the wrong fixup: SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), ALC287_FIXUP_TAS2781_I2C calls tas2781_fixup_tias_i2c(), which searches for ACPI HID "TIAS2781". However, the SCAR 18 G835LX uses the newer"TXNW2781" ACPI HID. The component match never succeeds, so tas2781_hda_bind() is never called and firmware is never loaded. To fix: in sound/hda/codecs/realtek/alc269.c, change: - SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), + SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TXNW2781_I2C_ASUS), Yoy can also create a workaround: Create /etc/modprobe.d/tas2781-fix.conf with: options snd_hda_intel model=,1043:1384 This overrides the fixup to use SSID 1043:1384 (ASUS RC73XA) which maps to ALC287_FIXUP_TXNW2781_I2C_ASUS. Reboot after creating the file. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153949/+subscriptions
[Bug 2153949] [NEW] ASUS ROG Strix SCAR 18 G835LX — speakers silent, TAS2781 amps never bind (wrong HDA fixup)
Public bug reported: Built-in speakers on the ASUS ROG Strix SCAR 18 (G835LX) are completely silent on Ubuntu 25.10 with kernel 7.0.0-15-generic. The TAS2781 smart amplifiers (3x TI TAS2781 at I2C 0x38/0x39/0x40) never load firmware and never bind to the HDA codec via the component framework. The HDA quirk table in sound/hda/codecs/realtek/alc269.c maps PCI SSID 1043:3f10 to the wrong fixup: SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), ALC287_FIXUP_TAS2781_I2C calls tas2781_fixup_tias_i2c(), which searches for ACPI HID "TIAS2781". However, the SCAR 18 G835LX uses the newer"TXNW2781" ACPI HID. The component match never succeeds, so tas2781_hda_bind() is never called and firmware is never loaded. To fix: in sound/hda/codecs/realtek/alc269.c, change: - SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), + SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TXNW2781_I2C_ASUS), Yoy can also create a workaround: Create /etc/modprobe.d/tas2781-fix.conf with: options snd_hda_intel model=,1043:1384 This overrides the fixup to use SSID 1043:1384 (ASUS RC73XA) which maps to ALC287_FIXUP_TXNW2781_I2C_ASUS. Reboot after creating the file. ** 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/2153949 Title: ASUS ROG Strix SCAR 18 G835LX — speakers silent, TAS2781 amps never bind (wrong HDA fixup) Status in linux package in Ubuntu: New Bug description: Built-in speakers on the ASUS ROG Strix SCAR 18 (G835LX) are completely silent on Ubuntu 25.10 with kernel 7.0.0-15-generic. The TAS2781 smart amplifiers (3x TI TAS2781 at I2C 0x38/0x39/0x40) never load firmware and never bind to the HDA codec via the component framework. The HDA quirk table in sound/hda/codecs/realtek/alc269.c maps PCI SSID 1043:3f10 to the wrong fixup: SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), ALC287_FIXUP_TAS2781_I2C calls tas2781_fixup_tias_i2c(), which searches for ACPI HID "TIAS2781". However, the SCAR 18 G835LX uses the newer"TXNW2781" ACPI HID. The component match never succeeds, so tas2781_hda_bind() is never called and firmware is never loaded. To fix: in sound/hda/codecs/realtek/alc269.c, change: - SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TAS2781_I2C), + SND_PCI_QUIRK(0x1043, 0x3f10, "ASUS Strix G835LR_LW_LX", ALC287_FIXUP_TXNW2781_I2C_ASUS), Yoy can also create a workaround: Create /etc/modprobe.d/tas2781-fix.conf with: options snd_hda_intel model=,1043:1384 This overrides the fixup to use SSID 1043:1384 (ASUS RC73XA) which maps to ALC287_FIXUP_TXNW2781_I2C_ASUS. Reboot after creating the file. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153949/+subscriptions
[Bug 2148638] Re: ubuntu 26.04 - When the NVME hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized.
Could you please help test two kernels and compare the behavior? 1. Ubuntu mainline v7.1-rc3: https://kernel.ubuntu.com/mainline/v7.1-rc3/ Please check whether the NVMe hot-swap issue still reproduces there. 2. Our locally built test kernel with the proposed PCI hotplug fix [1]. The goal is to distinguish: - whether the issue is already fixed by upstream changes present in v7.1-rc3, or - whether the test kernel fixed it. If v7.1-rc3 still reproduces the issue, but the test kernel does not, that would strongly confirm the proposed fix is addressing the regression. [1] https://drive.google.com/file/d/1P2dOpqIVFteossNZhgWdzOO4zmBPsdoY/view?usp=sharing -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148638 Title: ubuntu 26.04 - When the NVME hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized. Status in linux package in Ubuntu: New Status in linux source package in Resolute: New Bug description: When the CD8P NVMe hard drives were hot-swapped, the OS reported an error and some of the drives were not recognized. This issue happens on CD8P NVMe disk and does not happens on bm1743 NVMe disk. CD8P drives are Kaoxia drives The BM1743 drives that work are Samsung devices. Nvme disk detail: CD8P https://lenovopress.lenovo.com/lp1904-thinksystem-cd8p-read-intensive-nvme-pcie-50-ssd bm1743 https://lenovopress.lenovo.com/lp2156-thinksystem-bm1743-read-intensive-nvme-pcie-50-x4-ssd Steps to reproduce: 1.In the UEFI, enable VMD without created RAID disk. 2.Install ubuntu26.04 on M.2 sata disk. 3.use command lsblk to check all NVMEe disk 4.Unplug all NVMe device, then check NVMe device information again via lsblk. 5.plug all NVMe SSD 6.OS reported an error and some of the drives were not recognized. Compare with Ubuntu 24.04: There is no errors messages and all NVMe disks can be recognized after re-plug all NVMe SSD Info: The issue also happens on latest daily build: 0415 This issue only happens on VMD enabled, there is no this issue when vmd feature disable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148638/+subscriptions
среда
[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-lowlatency/5.15.0-178.188+2)
All autopkgtests for the newly accepted linux-restricted-modules-lowlatency (5.15.0-178.188+2) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-390/390.157-0ubuntu0.22.04.2 (armhf) nvidia-graphics-drivers-390/unknown (i386) nvidia-graphics-drivers-470/unknown (amd64) nvidia-graphics-drivers-470-server/unknown (amd64) nvidia-graphics-drivers-525-server/unknown (amd64, arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules-lowlatency [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions
[Bug 2152924] [NEW] Intermittent system freezes - unsure if kernel-related
You have been subscribed to a public bug: I have been experiencing intermittent system freezes on my Ubuntu installation. I'm not entirely sure if this is a Linux kernel issue or hardware-related, especially since I recently had my computer cleaned. About me: I've been using Ubuntu for 15 years and I'm a programmer, though I primarily use the system as a regular user and work with my own programming languages rather than deep Linux scripting. I want to help improve Ubuntu by reporting issues, but I'm not entirely sure if I'm following the correct procedure. I used AI assistance to help me write this bug report as I want to contribute properly to the community. I apologize if this report is not in the correct format or if this is not a kernel issue. I'm Brazilian and don't speak English fluently, so this report was translated. I hope this information can help identify the issue. Any guidance on proper bug reporting would be appreciated. Best regards. This ZIP file only contains screenshots related to the freezes and crashes I experienced on Ubuntu. Screenshot 1: Browser/system freeze while using Google Calendar. The system became unresponsive even though only about 17% of the 48 GB RAM was being used. Screenshot 2: Ubuntu session crash message appearing after the freeze, asking to close the session automatically. Screenshot 3: Black screen with multiple SQUASHFS and read errors displayed after the crash. None of the screenshots contain sensitive information and they may be used for troubleshooting or debugging purposes. 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: joh 6442 F.... wireplumber /dev/snd/controlC0: joh 6442 F.... wireplumber /dev/snd/controlC2: joh 6442 F.... wireplumber /dev/snd/seq: joh 6420 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon May 18 13:25:10 2026 InstallationDate: Installed on 2026-05-03 (15 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name ProcEnviron: LANG=pt_BR.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-15-generic root=UUID=7e6dc25f-8a2d-437b-acfb-95edbb86efd4 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: 11/30/2020 dmi.bios.release: 10.3 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1003 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX B460-G GAMING dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1003:bd11/30/2020:br10.3:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXB460-GGAMING:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaDefaultstring: dmi.product.family: Default string dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- Intermittent system freezes - unsure if kernel-related https://bugs.launchpad.net/bugs/2152924 You received this bug notification because you are subscribed to linux in Ubuntu.