This bug is awaiting verification that the linux- azure-7.0/7.0.0-1020.21~24.04.2 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- azure-7.0' to 'verification-done-noble-linux-azure-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux-azure-7.0' to 'verification-failed-noble-linux-azure-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-azure-7.0-v2 verification-needed-noble-linux-azure-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2168944 Title: AMD system hangs on resume when a Thunderbolt dock is plugged in during s2idle Status in HWE Next: New Status in linux package in Ubuntu: Fix Released Status in linux source package in Resolute: Fix Released Status in linux source package in Stonking: Fix Released Bug description: [Impact] On Dell systems with an AMD APU, plugging in a Thunderbolt dock while the system is in s2idle wakes it up early. Then the system can't resume. The power LED blinks an EC power-rail failure code (3 amber, 5 white). The only way out is a forced power off. The EC reports SLP_S3#, PLTRST# and RUNPWROK as abnormal. The board- level cause is SoC leakage on the 0.75V rail. That trips over-voltage protection (OVP) and the rail powers off. The amd_pmc driver waits 2.5 seconds before a new HW sleep cycle to avoid this. The wait is skipped when the dock wakes the system very briefly. Failure rate: 100% on affected hardware. Seen on 6.17 OEM kernels. It does not show up with the amd_pmc driver blacklisted. [Fix] The driver used the metrics table (s0i3_last_entry_status) to detect an intermediate wakeup. The table does not update for every fast wakeup, so the 2.5 second wait was sometimes skipped. The patch drops the metrics table check. It uses the driver's own is_first_check_after_suspend state instead. Upstream commit, in linux-next (not in a released kernel tag yet): 9d45679a02f5e platform/x86/amd: Stop counting intermediate cycles with metrics table Fixes: 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at start of cycle"), v6.16. It needs 037f0b03c663a ("platform/x86/amd/pmc: Don't log during intermediate wakeups", v7.2), which added is_first_check_after_suspend. That commit is already in this tree as e1a1c7606406b. Patch link: https://patch.msgid.link/20260914141734.2703545-1-mario.limonciello@amd.com [Test Plan] On a Dell system with an AMD APU and a Thunderbolt dock: 1. Boot to the desktop. 2. Suspend the system: $ sudo systemctl suspend 3. Plug in the dock while suspended. 4. Unplug the dock, then suspend again. 5. Plug in the dock again. Without the patch: the system fails to resume and the LED shows 3A5W. A forced power off is needed. With the patch: the system wakes up on its own after the dock is plugged in, on both cycles. No hang, no LED error. [Where problems could occur] This could break s2idle suspend and resume on AMD systems that use the amd_pmc driver. The wait now depends on is_first_check_after_suspend. If that flag is wrong, the wait could be skipped and the hang comes back. Or the wait could run when it isn't needed. Then suspend takes 2.5 seconds longer after a brief wakeup from USB, Thunderbolt or another device. The change only removes the metrics table read from the suspend path. It adds no new hardware calls. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2168944/+subscriptions
вторник
[Bug 2170908] Re: Intel Bluetooth stops working on some cold boots on Dell systems
This bug is awaiting verification that the linux- azure-7.0/7.0.0-1020.21~24.04.2 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- azure-7.0' to 'verification-done-noble-linux-azure-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux-azure-7.0' to 'verification-failed-noble-linux-azure-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-azure-7.0-v2 verification-needed-noble-linux-azure-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2170908 Title: Intel Bluetooth stops working on some cold boots on Dell systems Status in HWE Next: New Status in linux package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Resolute: Fix Released Status in linux-oem-7.0 source package in Resolute: Fix Released Bug description: [Impact] On some cold boots, the Intel PCIe Bluetooth controller (btintel_pcie) is declared dead and Bluetooth does not work. hci0 stays down for the rest of the session. Seen on a Dell system (CID: 202608-39584) running linux-oem-7.0. Error log: Bluetooth: hci0: Controller in error state Bluetooth: hci0: Timeout (3000 ms) on alive interrupt, alive context: intel_reset1 Bluetooth: hci0: Failed to send frame (-62) Bluetooth: hci0: Failed to send Intel Reset command Bluetooth: hci0: Intel Soft Reset failed (-62) Measured on the affected system: 10 of 60 cold boots hit the error. 4 of those 10 left hci0 down. The driver treats bit 12 of the boot stage register as a fatal error. The hardware documents that bit as a warning only. When the controller sets it, the driver starts a soft reset on a controller that was fine, and the reset fails. [Fix] Cherry-pick of upstream commit 5917dd39db2b ("Bluetooth: btintel_pcie: treat boot stage bit 12 as warning"), in v7.1 (first seen in v7.1-rc3). It renames the bit to DEVICE_WARNING and removes it from btintel_pcie_in_error(). Only the abort handler bit (bit 13) is an error now. A set warning bit is logged and the boot continues. It also prints the boot stage value in the error message. Fixes: 190377500fde ("Bluetooth: btintel_pcie: Dump debug registers on error"), in v6.16. [Test Plan] Power off and power on the machine 60 times (full power loss, not reboot): $ sudo systemctl poweroff After each boot check: $ journalctl -b -k | grep -E "Controller in error state|Soft Reset failed" $ hciconfig hci0 | grep "UP RUNNING" Without patch: 10 of 60 boots show "Controller in error state" and the Soft Reset failure. 4 of 60 leave hci0 down. With patch: 0 of 60 boots show an error. hci0 is UP RUNNING every time. On 7 of 60 boots the new line shows up and the controller works: Bluetooth: hci0: Controller device warning (boot_stage: 0xa0db1003) [Where problems could occur] Could break error handling in the btintel_pcie driver. If a real fatal error ever sets only bit 12, the driver will no longer treat it as an error. It will not run the error path or the soft reset. Bluetooth would then fail later (command timeouts, hci0 not coming up) instead of at the first error. Errors that set bit 13 (abort handler) are handled as before. The change only touches btintel_pcie.c and btintel_pcie.h. It does not touch other Intel Bluetooth transports (btusb). To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2170908/+subscriptions
[Bug 2173937] [NEW] Upgrade 26.04 to 7.0.0-43-generic and WLAN-Stick TP-Link TL-WN821N Version 3
Public bug reported: Upgrade from Kernel 7.0.0-42-generic WLAN-Stick TP-Link TL-WN821N Version 3 works properly and fine to 7.0.0-43-generic does not active WLAN-Stick TP-Link TL-WN821N Version 3 not working any more, no LEDs are on the stick Ubuntu shows saved "WLAN-Networks" in WLAN Graphical-Settings but it is unable to connect it. Please help me! Thank you from Berny! ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-42-generic 7.0.0-42.42 ProcVersionSignature: Ubuntu 7.0.0-42.42-generic 7.0.14 Uname: Linux 7.0.0-42-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: bernhard 2296 F.... wireplumber /dev/snd/controlC0: bernhard 2296 F.... wireplumber /dev/snd/seq: bernhard 2284 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Nov 10 23:57:22 2026 MachineType: Acer Aspire XC-605 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-42-generic root=UUID=1b7bf562-f899-4f06-8edb-1d28e8c4d82c ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-10-06 (35 days ago) dmi.bios.date: 11/08/2013 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P11-A2 dmi.board.name: Aspire XC-605 dmi.board.vendor: Acer dmi.chassis.type: 3 dmi.chassis.vendor: Acer dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP11-A2:bd11/08/2013:br4.6:svnAcer:pnAspireXC-605:pvr:rvnAcer:rnAspireXC-605:rvr:cvnAcer:ct3:cvr:sku:pfaAcerDesktop: dmi.product.family: Acer Desktop dmi.product.name: Aspire XC-605 dmi.sys.vendor: Acer ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2173937 Title: Upgrade 26.04 to 7.0.0-43-generic and WLAN-Stick TP-Link TL-WN821N Version 3 Status in linux package in Ubuntu: New Bug description: Upgrade from Kernel 7.0.0-42-generic WLAN-Stick TP-Link TL-WN821N Version 3 works properly and fine to 7.0.0-43-generic does not active WLAN-Stick TP-Link TL-WN821N Version 3 not working any more, no LEDs are on the stick Ubuntu shows saved "WLAN-Networks" in WLAN Graphical-Settings but it is unable to connect it. Please help me! Thank you from Berny! ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-42-generic 7.0.0-42.42 ProcVersionSignature: Ubuntu 7.0.0-42.42-generic 7.0.14 Uname: Linux 7.0.0-42-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: bernhard 2296 F.... wireplumber /dev/snd/controlC0: bernhard 2296 F.... wireplumber /dev/snd/seq: bernhard 2284 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Nov 10 23:57:22 2026 MachineType: Acer Aspire XC-605 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-42-generic root=UUID=1b7bf562-f899-4f06-8edb-1d28e8c4d82c ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-10-06 (35 days ago) dmi.bios.date: 11/08/2013 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P11-A2 dmi.board.name: Aspire XC-605 dmi.board.vendor: Acer dmi.chassis.type: 3 dmi.chassis.vendor: Acer dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP11-A2:bd11/08/2013:br4.6:svnAcer:pnAspireXC-605:pvr:rvnAcer:rnAspireXC-605:rvr:cvnAcer:ct3:cvr:sku:pfaAcerDesktop: dmi.product.family: Acer Desktop dmi.product.name: Aspire XC-605 dmi.sys.vendor: Acer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173937/+subscriptions
[Bug 2173834] Re: [Renoir ACP] snd_rn_pci_acp3x does not bind to 0000:05:00.5 on HP ProBook 445 G8 (103c:8861); internal mic silent on kernel 7.0.0-43-generic
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2173834 Title: [Renoir ACP] snd_rn_pci_acp3x does not bind to 0000:05:00.5 on HP ProBook 445 G8 (103c:8861); internal mic silent on kernel 7.0.0-43-generic Status in linux package in Ubuntu: New Bug description: Title: [Renoir ACP] snd_rn_pci_acp3x does not bind to 0000:05:00.5 on HP ProBook 445 G8 (103c:8861); internal mic silent on kernel 7.0.0-43-generic Summary ------- The internal microphone on an HP ProBook 445 G8 produces no usable audio input. The AMD ACP audio coprocessor at 0000:05:00.5 does not bind to any driver after loading snd_rn_pci_acp3x, and the kernel logs no probe success or failure. The codec path (Realtek ALC236) is connected and unmuted, but it records only the idle noise floor (about -41 dBFS peak) regardless of Capture or Internal Mic Boost gain. System ------ Distribution: Ubuntu 26.04.1 LTS Kernel: 7.0.0-43-generic #43-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 23 13:25:25 UTC 2026 x86_64 Laptop: HP ProBook 445 G8 Notebook PC CPU/APU: AMD Ryzen (Renoir/Cezanne family) PCI ACP: 0000:05:00.5 Audio Coprocessor [1022:15e2] (rev 01), subsystem 103c:8861 PCI HDA: 0000:05:00.6 Ryzen HD Audio Controller [1022:15e3], driver snd_hda_intel Codec: Realtek ALC236, codec SSID 103c:8862 (card 1, Generic_1 HD-Audio Generic) Firmware pkg: linux-firmware 20260319.git217ca6e4.1ubuntu (installed, up to date) Audio server: PipeWire / WirePlumber Observations ------------ 1. lspci -nnvk -s 05:00.5 lists modules but no driver: Kernel modules: snd_pci_acp3x, snd_rn_pci_acp3x, snd_pci_acp5x, snd_pci_acp6x, snd_acp_pci, snd_rpl_pci_acp6x, snd_pci_ps, snd_sof_amd_renoir, snd_sof_amd_rembrandt, snd_sof_amd_vangogh, snd_sof_amd_acp63, snd_sof_amd_acp70 There is no "Kernel driver in use:" line. 2. After `sudo modprobe -r snd_rn_pci_acp3x` and `sudo modprobe snd_rn_pci_acp3x`: - modprobe prints no error. - /sys/bus/pci/devices/0000:05:00.5/driver does not exist. - dmesg contains only: "snd_rn_pci_acp3x 0000:05:00.5: enabling device (0000 -> 0002)" with no probe success or failure message. 3. `modprobe -v snd_sof_amd_renoir` prints nothing, and no SOF messages appear in dmesg. 4. ACPI platform devices are present: AMDI0005:00, AMDI0010:00-05, AMDI0020:00-03, AMDI0030:00, AMDI0040:00, AMDI0060:00. 5. `arecord -l` exposes only the codec: card 1: Generic_1 [HD-Audio Generic], device 0: ALC236 Analog [ALC236 Analog] No ACP or DMIC card appears. 6. Recording from hw:1,0 (48 kHz, S16_LE, stereo, 5 to 6 s): - Capture 54/63 (+23.25 dB), Internal Mic Boost on (+12 dB): peak -41.2 dBFS, RMS -54.5 dBFS. - Capture 63/63 (+30 dB), Internal Mic Boost on (+12 dB): peak about -41 dBFS. - Recording through PipeWire with source volume 1.0 and Capture 63: peak -40.4 dBFS. Raising gain by about 7 dB did not raise the recorded level, which suggests the recorded data is the codec's idle noise rather than microphone input. 7. Codec state (/proc/asound/card1/codec#0): - Node 0x12 (Pin Complex, Stereo Amp-In): Amp-In vals [0x01 0x01], unmuted. - Pin Default 0x90a60130: "[Fixed] Mic at Int N/A", Conn = Digital, Misc = NO_PRESENCE. - Node 0x24 (Audio Selector): connection 0x12 selected. - Node 0x23 (Audio Mixer): input 0x12 present, amp unmuted. 8. PipeWire default source: "Ryzen HD Audio Controller Analog Stereo" (id 47), not muted. 9. No firmware errors in dmesg. `dpkg -L linux-firmware` contains no amd/sof or acp files. `firmware-sof-signed` is an Intel package and not a candidate for this device. 10. /etc/modprobe.d/ contains no ACP or snd options. The only "acp" match is a blacklist entry for asus_acpi. 11. Full boot log (dmesg.txt) shows the HDA codec binds normally: snd_hda_codec_alc269 hdaudioC1D0: ALC236: picked fixup for codec SSID 103c:8862 inputs: Internal Mic=0x12, Mic=0x19 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173834/+subscriptions
[Bug 2173885] Re: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days
** 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/2173885 Title: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days Status in linux package in Ubuntu: New Bug description: ## Summary Since this machine moved to 7.0.0-42/-43 it has hit a kernel panic 4 times in 10 days (~1 in every 10 boots). Each time the kernel Oopses instantly (Ubuntu's `panic_on_oops=1`), kdump writes a vmcore and the machine reboots. Two different MM/folio code paths are involved. Dumps present in `/var/crash`: `202610311135`, `202611010006`, `202611041154`, `202611101949`. ## Latest Oops (2026-11-10 19:45:52 +0800, uptime 91 s, kernel 7.0.0-43-generic) ``` BUG: unable to handle page fault for address: 000000000002a200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1455aa067 P4D 1455aa067 PUD 1455a9067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 1000 PID: 2913 Comm: Thread-1 (get_m Tainted: G OE 7.0.0-43-generic #43-Ubuntu PREEMPT(lazy) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision 5760/0T7J1J, BIOS 1.39.0 03/31/2026 RIP: 0010:lruvec_stat_mod_folio+0x50/0x100 Code: 1c c5 a0 e9 5f a5 e8 cf d1 c7 ff 49 8b 54 24 38 48 89 d0 48 83 e0 f8 83 e2 02 74 04 48 8b 40 10 49 63 d5 48 85 c0 74 63 66 90 <48> 63 8b 00 a2 02 00 4c 8b a4 c8 80 06 00 00 49 83 c4 40 49 3b 9c RSP: 0018:ffffd196ccf7f6f0 EFLAGS: 00010286 RAX: ffff8a2a0816a1c0 RBX: 0000000000000000 RCX: ffff8a2d7260b200 RDX: ffffffffffffffff RSI: 0000000000000011 RDI: fffff27119138640 R13: 00000000ffffffff R14: 0000000000000011 R15: fffff27119138640 CR2: 000000000002a200 Call Trace: <TASK> folio_remove_rmap_ptes+0x41/0x270 zap_present_ptes.constprop.0+0x290/0x750 zap_pte_range+0x1f5/0x780 zap_pmd_range.isra.0+0xce/0x250 unmap_page_range+0x23a/0x3d0 unmap_single_vma+0x96/0x110 unmap_vmas+0xa5/0x180 unmap_region+0xa4/0x110 vms_complete_munmap_vmas+0x1f7/0x280 do_vmi_align_munmap+0x185/0x210 do_vmi_munmap+0xd1/0x1b0 __vm_munmap+0xc1/0x190 __x64_sys_munmap+0x1b/0x30 x64_sys_call+0x22a3/0x2390 do_syscall_64+0x105/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ``` Reading of the registers: `RBX=0` and the faulting instruction is `movslq 0x2a200(%rbx),%rcx`, i.e. a NULL base plus a member offset that matches `struct mem_cgroup`; `memcg` obtained from the folio was NULL while the path still dereferenced it. `R13=0xffffffff` (−1) is the stat delta (`-nr_pages` for a single page). The `folio` pointer itself (`R15=fffff27119138640`) is a vmemmap address, so this looks like rmap accounting on a folio that is not charged to any memcg (device-private / special mapping), reached through the plain `munmap()` → `zap_pte_range()` path. The faulting task is a Python thread (`Thread-1 (get_model)`) of a local FunASR STT daemon; the `munmap()` being torn down is a ~928 MB region (`RSI=0x39f3e000`), i.e. it happens while that daemon loads model weights right after boot. The nvidia modules are loaded (taint OE), but no nvidia frame appears anywhere in the stack. ## Earlier panic on the same kernel family (2026-10-31 11:35) ``` RIP: 0010:detach_extent_buffer_folio+0x19 [btrfs] CR2=0x0000200000000018 eb->folios[i] garbage btree_release_folio → filemap_release_folio → shrink_folio_list → balance_pgdat → kswapd ``` So within 10 days two different folio/rmap/reclaim code paths died. Both look like mm regressions rather than hardware (no MCE, no I/O errors, no thermal events in dmesg; memory test not run yet, but the two signatures are in different subsystems). ## System - Ubuntu 26.04 (resolute), `7.0.0-43-generic` (7.0.14 base), 16 threads, 61 GiB RAM, 16 GiB zram - Dell Precision 5760, BIOS 1.39.0 - root on btrfs (`space_cache=v2`, `discard=async`, single device, 712 GiB used / 236 GiB free) - nvidia 595.99.02 (OOT, tainted), virtualbox 7.2.6 - Reproducible only statistically: ~1 panic per 10 boots, always during heavy allocation/free right after boot (FunASR model loading) or during kswapd reclaim ## Why I cannot bisect downwards `7.0.0-31-generic` (installed) boots, but DisplayPort-MST outputs are dead on it: KWin enumerates `eDP-1`, `DP-9`, `DP-11` (the two external monitors sit on i915 DP-MST), windows are placed on the MST outputs and the screens stay black. So 7.0.0-31 is not usable here as a control. ## Secondary issue `kdump-tools` logs `The kernel version is not supported. The makedumpfile operation may be incomplete.` while saving the vmcore (makedumpfile in the kdump initrd is older than the 7.0 kernel). dmesg extraction still works; the compressed dump is 872 MB. ## Questions / request 1. Is this a known regression in 7.0.0-42/-43 (folio/rmap accounting, `lruvec_stat_mod_folio`)? 2. Is there a fix in `-proposed` I can test? 3. I can provide the full dmesg, `/proc/vmcore`-derived dump (872 MB) or run any debug kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+subscriptions
[Bug 2173891] Re: Stonking update: v7.3.3 upstream stable release
** 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/2173891 Title: Stonking update: v7.3.3 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Stonking: In Progress Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v7.3.3 upstream stable release from git://git.kernel.org/ xen-netback: Fix UAF when reading statistics data xen-netback: defer xenvif_mcast_addr_list_free() xen-blkback: Avoid UAF when reading I/O statistics Linux 7.3.3 UBUNTU: Upstream stable to v7.3.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173891/+subscriptions
[Bug 2173892] Re: 7.0.0-42/-43: .NET processes in Alpine/musl containers crash with general protection fault in ld-musl (6.8 reported fine)
** 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/2173892 Title: 7.0.0-42/-43: .NET processes in Alpine/musl containers crash with general protection fault in ld-musl (6.8 reported fine) Status in linux package in Ubuntu: New Bug description: Release: Ubuntu 26.04.1 LTS Kernel: linux-image-7.0.0-42 and 7.0.0-43 (both affected) Hardware: Intel Core i5-9500T (microcode 0xfa), 16 GB RAM, bare metal .NET 8 applications running in Alpine (musl) Docker containers (Prowlarr, Radarr, Sonarr; linuxserver.io images) die intermittently and silently, with nothing in the application log. The kernel logs a general protection fault inside musl each time: traps: .NET BGC[pid] general protection fault ip:...70b sp:... error:0 in ld-musl-x86_64.so.1[4270b,...] traps: .NET TP Worker[pid] general protection fault ... in ld-musl-x86_64.so.1[4270b,...] Apport also recorded a SIGSEGV (signal 11) for the Sonarr process (it could not build a report because the executable lives inside the container). The container's supervisor (s6) restarts the app, so Docker shows the container as "Up" with RestartCount=0. In the worst case the app restarted every ~3 seconds (about 42 faults in 11 minutes). The faulting offset is the same every time: the instruction right after raise(SIGABRT) in musl's abort(), per the analysis in the upstream thread https://github.com/Prowlarr/Prowlarr/issues/2884. So the runtime hits a fatal condition and aborts itself. Reproducibility / what I ruled out - Reproduces with a brand-new empty application config (not application data). - Reproduces on 7.0.0-42 and 7.0.0-43. - Reproduces with two different musl-based images (linuxserver.io and hotio). - No MCE/EDAC/OOM/disk errors in dmesg. Container image layers verified against their digests; the musl binary hash is identical to one in a container that does not crash. - The reporter in the issue above says the same workload is stable on kernel 6.8 and crashes every time on 7.0.0-42, and that glibc-based .NET builds also crash for them. That points to a kernel/runtime interaction (signal handling, thread suspension, memory protection) rather than musl itself. I have not tested 6.8 myself. - Mitigation: DOTNET_gcConcurrent=0 stopped the tight restart loop here. Possibly relevant (unconfirmed) AppArmor audit lines at crash time (parser 5.0.2, Docker 29.9.3, runc 1.5.2, containerd 2.4.2): apparmor="DENIED" operation="signal" profile="docker-default" comm=".NET BGC" signal=abrt peer="docker-default//&unconfined" apparmor="AUDIT" operation="change_onexec" info="change_profile unprivileged unconfined converted to stacking" A test with --security-opt apparmor=unconfined was stable on an idle fresh container, but so was the default profile in the same test, so this is inconclusive (the crashes seem to need load). Expected: no GPF in musl for these workloads, as on 6.8. Question: is there a known change in 7.0 affecting signal delivery or thread suspension that could cause this, and is a fix planned? I can test patched or older kernels. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-43-generic 7.0.0-43.43 ProcVersionSignature: Ubuntu 7.0.0-43.43-generic 7.0.14 Uname: Linux 7.0.0-43-generic x86_64 AlsaVersion: Advanced Linux Sound Architecture Driver Version k7.0.0-43-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperMD5CheckResult: pass Date: Tue Nov 10 12:08:17 2026 InstallationDate: Installed on 2021-06-18 (1971 days ago) InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Release amd64 (20210421) MachineType: HP HP EliteDesk 800 G5 Desktop Mini ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-43-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro systemd.unified_cgroup_hierarchy=1 usbcore.autosuspend=-1 text PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/31/2024 dmi.bios.release: 22.0 dmi.bios.vendor: HP dmi.bios.version: R21 Ver. 02.22.00 dmi.board.name: 8595 dmi.board.vendor: HP dmi.board.version: KBC Version 08.09.21 dmi.chassis.type: 6 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.9 dmi.modalias: dmi:bvnHP:bvrR21Ver.02.22.00:bd12/31/2024:br22.0:efr8.9:svnHP:pnHPEliteDesk800G5DesktopMini:pvrSBKPF:rvnHP:rn8595:rvrKBCVersion08.09.21:cvnHP:ct6:cvr:sku1X550LP#AC4:pfa103C_53307FHPEliteDesk: dmi.product.family: 103C_53307F HP EliteDesk dmi.product.name: HP EliteDesk 800 G5 Desktop Mini dmi.product.sku: 1X550LP#AC4 dmi.product.version: SBKPF dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173892/+subscriptions
[Bug 2173894] Re: Intel IOMMU duplicate DMA PTE warnings overlap RMRR in multifunction NVIDIA GPU group
** 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/2173894 Title: Intel IOMMU duplicate DMA PTE warnings overlap RMRR in multifunction NVIDIA GPU group Status in linux package in Ubuntu: New Bug description: Ubuntu 24.04.5 LTS amd64, kernel 6.8.0-149-generic (6.8.0-149.149), ASRock X99 Extreme3, Intel i7-5930K, BIOS P1.40, NVIDIA GTX 1660 Ti, driver 580.178.04. During one supervised Ollama cold model load, 15 duplicate-PTE warnings occurred over approximately 0.180 seconds. The collected log identifies llama-server and NVIDIA DMA allocation/scatterlist calls leading to Intel IOMMU mapping. Inference completed. The active DMAR table is 204 bytes with a valid checksum. Its single RMRR spans 0x7ae64000–0x7ae72fff in segment 0000. Explicit endpoint scopes are 01:00.2, 00:14.0, 00:1a.0 and 00:1d.0. The 15 conflicting vPFNs, 0x7ae64–0x7ae72, exactly cover this region. GPU graphics, audio, USB and USB-C functions 01:00.0–01:00.3 share IOMMU group 28, type DMA-FQ. The region is listed as direct-relaxable. Only GPU USB function 01:00.2 is explicitly scoped by the RMRR. Boot logs report a broken RMRR entry for that function and application of a workaround. Confirmed observations are the firmware scopes, group membership, address overlap and NVIDIA mapping stack. The unproven hypothesis is that the USB-specific reservation is mapped in the shared domain but omitted from its IOVA allocator exclusions. Initialization order and allocator state have not been instrumented. The USB driver is not established as the mapping caller. No supported correction has been verified. Please assess applicability of the shared-domain reservation issue and identify a reviewed correction or supported backport. No additional inference or stress reproduction was performed for collection. Attachments are sanitized extracts; topology was recorded later than the original Apport snapshot. Related upstream discussion: https://lkml.iu.edu/2410.3/01077.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173894/+subscriptions
[Bug 2173915] Re: linux-hwe-5.15 5.15.0-203.213~20.04.1: i915 DP link training fails with "Timeout waiting for DDI BUF D to get active" on Alder Lake-P [8086:46a6]
** 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/2173915 Title: linux-hwe-5.15 5.15.0-203.213~20.04.1: i915 DP link training fails with "Timeout waiting for DDI BUF D to get active" on Alder Lake-P [8086:46a6] Status in linux package in Ubuntu: New Bug description: impact: External DisplayPort / Type-C displays connected to DDI D fail modesetting and link training upon hotplug or EDID resolution switching, preventing external monitors from activating and causing Checkbox monitor/zapper-edid to time out. hardware: - Dell XPS 13 Plus (CID 202112-29761), Intel Core i7-1260P, Intel Alder Lake-P Integrated Graphics [8086:46a6] - HP EliteBook 860 G9 Notebook PC (CID 202201-29867), Intel Core i7-1280P, Intel Alder Lake-P Integrated Graphics [8086:46a6] versions: - fails on: 5.15.0-191.201~20.04.1, 5.15.0-203.213~20.04.1 (Ubuntu 20.04.6 focal ESM) - multiple cycles and builds observed failing identically on both models reproduction: 1. Connect external monitor or Zapper HDMI capture via DP / Type-C (enumerated as card0-DP-1). 2. Trigger an EDID resolution switch (e.g. via edid_cycle.py "$ZAPPER_HOST" switching between 1280x1024, 1920x1080, and 2560x1440). 3. Observe kernel log output: i915 0000:00:02.0: [drm] ERROR Timeout waiting for DDI BUF D to get active i915 0000:00:02.0: [drm] ERROR Link Training Unsuccessful 4. Observe test output: Timed out switching EDID. Timed out after 15s waiting for DP-1 to connect. Connected monitors: ['eDP-1']; with current mode: ['eDP-1']; DRM connected: ['DP-1', 'eDP-1']. analysis: In drivers/gpu/drm/i915/display/intel_ddi.c, intel_wait_ddi_buf_active() polls for DDI_BUF_IS_IDLE to clear on port D. When retraining the link during an EDID resolution change on Alder Lake-P, the DDI buffer idle status fails to clear within the timeout. Consequently, intel_dp_start_link_train fails link training, userspace (GNOME / mutter) cannot configure a mode on DP-1, and only eDP-1 remains active in the graphical session despite DRM reporting DP-1 connected. proposed fix: Investigate DDI buffer activation timeouts and link retraining sequencing for Alder Lake-P (Gen12 / ADL-P) DDI D in drivers/gpu/drm/i915/display/intel_ddi.c, or backport relevant i915 DP link training and retimer fixes from newer upstream and OEM kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173915/+subscriptions
[Bug 2173885] Re: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days
Adding version.log as requested by the kernel bug guidelines. ** Attachment added: "version.log (proc/version_signature + lsb_release -rd + apt-cache policy)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+attachment/6016719/+files/version.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2173885 Title: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days Status in linux package in Ubuntu: New Bug description: ## Summary Since this machine moved to 7.0.0-42/-43 it has hit a kernel panic 4 times in 10 days (~1 in every 10 boots). Each time the kernel Oopses instantly (Ubuntu's `panic_on_oops=1`), kdump writes a vmcore and the machine reboots. Two different MM/folio code paths are involved. Dumps present in `/var/crash`: `202610311135`, `202611010006`, `202611041154`, `202611101949`. ## Latest Oops (2026-11-10 19:45:52 +0800, uptime 91 s, kernel 7.0.0-43-generic) ``` BUG: unable to handle page fault for address: 000000000002a200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1455aa067 P4D 1455aa067 PUD 1455a9067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 1000 PID: 2913 Comm: Thread-1 (get_m Tainted: G OE 7.0.0-43-generic #43-Ubuntu PREEMPT(lazy) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision 5760/0T7J1J, BIOS 1.39.0 03/31/2026 RIP: 0010:lruvec_stat_mod_folio+0x50/0x100 Code: 1c c5 a0 e9 5f a5 e8 cf d1 c7 ff 49 8b 54 24 38 48 89 d0 48 83 e0 f8 83 e2 02 74 04 48 8b 40 10 49 63 d5 48 85 c0 74 63 66 90 <48> 63 8b 00 a2 02 00 4c 8b a4 c8 80 06 00 00 49 83 c4 40 49 3b 9c RSP: 0018:ffffd196ccf7f6f0 EFLAGS: 00010286 RAX: ffff8a2a0816a1c0 RBX: 0000000000000000 RCX: ffff8a2d7260b200 RDX: ffffffffffffffff RSI: 0000000000000011 RDI: fffff27119138640 R13: 00000000ffffffff R14: 0000000000000011 R15: fffff27119138640 CR2: 000000000002a200 Call Trace: <TASK> folio_remove_rmap_ptes+0x41/0x270 zap_present_ptes.constprop.0+0x290/0x750 zap_pte_range+0x1f5/0x780 zap_pmd_range.isra.0+0xce/0x250 unmap_page_range+0x23a/0x3d0 unmap_single_vma+0x96/0x110 unmap_vmas+0xa5/0x180 unmap_region+0xa4/0x110 vms_complete_munmap_vmas+0x1f7/0x280 do_vmi_align_munmap+0x185/0x210 do_vmi_munmap+0xd1/0x1b0 __vm_munmap+0xc1/0x190 __x64_sys_munmap+0x1b/0x30 x64_sys_call+0x22a3/0x2390 do_syscall_64+0x105/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ``` Reading of the registers: `RBX=0` and the faulting instruction is `movslq 0x2a200(%rbx),%rcx`, i.e. a NULL base plus a member offset that matches `struct mem_cgroup`; `memcg` obtained from the folio was NULL while the path still dereferenced it. `R13=0xffffffff` (−1) is the stat delta (`-nr_pages` for a single page). The `folio` pointer itself (`R15=fffff27119138640`) is a vmemmap address, so this looks like rmap accounting on a folio that is not charged to any memcg (device-private / special mapping), reached through the plain `munmap()` → `zap_pte_range()` path. The faulting task is a Python thread (`Thread-1 (get_model)`) of a local FunASR STT daemon; the `munmap()` being torn down is a ~928 MB region (`RSI=0x39f3e000`), i.e. it happens while that daemon loads model weights right after boot. The nvidia modules are loaded (taint OE), but no nvidia frame appears anywhere in the stack. ## Earlier panic on the same kernel family (2026-10-31 11:35) ``` RIP: 0010:detach_extent_buffer_folio+0x19 [btrfs] CR2=0x0000200000000018 eb->folios[i] garbage btree_release_folio → filemap_release_folio → shrink_folio_list → balance_pgdat → kswapd ``` So within 10 days two different folio/rmap/reclaim code paths died. Both look like mm regressions rather than hardware (no MCE, no I/O errors, no thermal events in dmesg; memory test not run yet, but the two signatures are in different subsystems). ## System - Ubuntu 26.04 (resolute), `7.0.0-43-generic` (7.0.14 base), 16 threads, 61 GiB RAM, 16 GiB zram - Dell Precision 5760, BIOS 1.39.0 - root on btrfs (`space_cache=v2`, `discard=async`, single device, 712 GiB used / 236 GiB free) - nvidia 595.99.02 (OOT, tainted), virtualbox 7.2.6 - Reproducible only statistically: ~1 panic per 10 boots, always during heavy allocation/free right after boot (FunASR model loading) or during kswapd reclaim ## Why I cannot bisect downwards `7.0.0-31-generic` (installed) boots, but DisplayPort-MST outputs are dead on it: KWin enumerates `eDP-1`, `DP-9`, `DP-11` (the two external monitors sit on i915 DP-MST), windows are placed on the MST outputs and the screens stay black. So 7.0.0-31 is not usable here as a control. ## Secondary issue `kdump-tools` logs `The kernel version is not supported. The makedumpfile operation may be incomplete.` while saving the vmcore (makedumpfile in the kdump initrd is older than the 7.0 kernel). dmesg extraction still works; the compressed dump is 872 MB. ## Questions / request 1. Is this a known regression in 7.0.0-42/-43 (folio/rmap accounting, `lruvec_stat_mod_folio`)? 2. Is there a fix in `-proposed` I can test? 3. I can provide the full dmesg, `/proc/vmcore`-derived dump (872 MB) or run any debug kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+subscriptions
[Bug 2173885] Re: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days
Test comment (will be edited): logging system info next. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2173885 Title: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days Status in linux package in Ubuntu: New Bug description: ## Summary Since this machine moved to 7.0.0-42/-43 it has hit a kernel panic 4 times in 10 days (~1 in every 10 boots). Each time the kernel Oopses instantly (Ubuntu's `panic_on_oops=1`), kdump writes a vmcore and the machine reboots. Two different MM/folio code paths are involved. Dumps present in `/var/crash`: `202610311135`, `202611010006`, `202611041154`, `202611101949`. ## Latest Oops (2026-11-10 19:45:52 +0800, uptime 91 s, kernel 7.0.0-43-generic) ``` BUG: unable to handle page fault for address: 000000000002a200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1455aa067 P4D 1455aa067 PUD 1455a9067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 1000 PID: 2913 Comm: Thread-1 (get_m Tainted: G OE 7.0.0-43-generic #43-Ubuntu PREEMPT(lazy) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision 5760/0T7J1J, BIOS 1.39.0 03/31/2026 RIP: 0010:lruvec_stat_mod_folio+0x50/0x100 Code: 1c c5 a0 e9 5f a5 e8 cf d1 c7 ff 49 8b 54 24 38 48 89 d0 48 83 e0 f8 83 e2 02 74 04 48 8b 40 10 49 63 d5 48 85 c0 74 63 66 90 <48> 63 8b 00 a2 02 00 4c 8b a4 c8 80 06 00 00 49 83 c4 40 49 3b 9c RSP: 0018:ffffd196ccf7f6f0 EFLAGS: 00010286 RAX: ffff8a2a0816a1c0 RBX: 0000000000000000 RCX: ffff8a2d7260b200 RDX: ffffffffffffffff RSI: 0000000000000011 RDI: fffff27119138640 R13: 00000000ffffffff R14: 0000000000000011 R15: fffff27119138640 CR2: 000000000002a200 Call Trace: <TASK> folio_remove_rmap_ptes+0x41/0x270 zap_present_ptes.constprop.0+0x290/0x750 zap_pte_range+0x1f5/0x780 zap_pmd_range.isra.0+0xce/0x250 unmap_page_range+0x23a/0x3d0 unmap_single_vma+0x96/0x110 unmap_vmas+0xa5/0x180 unmap_region+0xa4/0x110 vms_complete_munmap_vmas+0x1f7/0x280 do_vmi_align_munmap+0x185/0x210 do_vmi_munmap+0xd1/0x1b0 __vm_munmap+0xc1/0x190 __x64_sys_munmap+0x1b/0x30 x64_sys_call+0x22a3/0x2390 do_syscall_64+0x105/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ``` Reading of the registers: `RBX=0` and the faulting instruction is `movslq 0x2a200(%rbx),%rcx`, i.e. a NULL base plus a member offset that matches `struct mem_cgroup`; `memcg` obtained from the folio was NULL while the path still dereferenced it. `R13=0xffffffff` (−1) is the stat delta (`-nr_pages` for a single page). The `folio` pointer itself (`R15=fffff27119138640`) is a vmemmap address, so this looks like rmap accounting on a folio that is not charged to any memcg (device-private / special mapping), reached through the plain `munmap()` → `zap_pte_range()` path. The faulting task is a Python thread (`Thread-1 (get_model)`) of a local FunASR STT daemon; the `munmap()` being torn down is a ~928 MB region (`RSI=0x39f3e000`), i.e. it happens while that daemon loads model weights right after boot. The nvidia modules are loaded (taint OE), but no nvidia frame appears anywhere in the stack. ## Earlier panic on the same kernel family (2026-10-31 11:35) ``` RIP: 0010:detach_extent_buffer_folio+0x19 [btrfs] CR2=0x0000200000000018 eb->folios[i] garbage btree_release_folio → filemap_release_folio → shrink_folio_list → balance_pgdat → kswapd ``` So within 10 days two different folio/rmap/reclaim code paths died. Both look like mm regressions rather than hardware (no MCE, no I/O errors, no thermal events in dmesg; memory test not run yet, but the two signatures are in different subsystems). ## System - Ubuntu 26.04 (resolute), `7.0.0-43-generic` (7.0.14 base), 16 threads, 61 GiB RAM, 16 GiB zram - Dell Precision 5760, BIOS 1.39.0 - root on btrfs (`space_cache=v2`, `discard=async`, single device, 712 GiB used / 236 GiB free) - nvidia 595.99.02 (OOT, tainted), virtualbox 7.2.6 - Reproducible only statistically: ~1 panic per 10 boots, always during heavy allocation/free right after boot (FunASR model loading) or during kswapd reclaim ## Why I cannot bisect downwards `7.0.0-31-generic` (installed) boots, but DisplayPort-MST outputs are dead on it: KWin enumerates `eDP-1`, `DP-9`, `DP-11` (the two external monitors sit on i915 DP-MST), windows are placed on the MST outputs and the screens stay black. So 7.0.0-31 is not usable here as a control. ## Secondary issue `kdump-tools` logs `The kernel version is not supported. The makedumpfile operation may be incomplete.` while saving the vmcore (makedumpfile in the kdump initrd is older than the 7.0 kernel). dmesg extraction still works; the compressed dump is 872 MB. ## Questions / request 1. Is this a known regression in 7.0.0-42/-43 (folio/rmap accounting, `lruvec_stat_mod_folio`)? 2. Is there a fix in `-proposed` I can test? 3. I can provide the full dmesg, `/proc/vmcore`-derived dump (872 MB) or run any debug kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+subscriptions
[Bug 2169304] Re: Regression: systemd-shutdown hangs for 60s at fwupd.shutdown hook under kernel 7.3 (ASUS X580GD)
Confirmed shutdown hook is gone. Can no longer cause issues. test@test-SUT:~$ apt policy fwupd fwupd: Installed: 2.1.6-3ubuntu4~26.04.1 Candidate: 2.1.6-3ubuntu4~26.04.1 Version table: *** 2.1.6-3ubuntu4~26.04.1 100 100 http://archive.ubuntu.com/ubuntu resolute-proposed/main amd64 Packages 100 /var/lib/dpkg/status 2.1.1-1ubuntu3.1 500 500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages 2.1.1-1ubuntu3 500 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages test@test-SUT:~$ dpkg -L fwupd | grep shutdown test@test-SUT:~$ ** Tags removed: verification-needed-resolute ** Tags added: verification-done-resolute -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2169304 Title: Regression: systemd-shutdown hangs for 60s at fwupd.shutdown hook under kernel 7.3 (ASUS X580GD) Status in fwupd package in Ubuntu: Fix Released Status in linux package in Ubuntu: Won't Fix Status in fwupd source package in Resolute: Fix Committed Status in linux source package in Resolute: Won't Fix Status in fwupd source package in Stonking: Fix Released Status in linux source package in Stonking: Won't Fix Bug description: [Impact] * fwupd ships a systemd-shutdown hook that runs `fwupdtool activate` very late in shutdown. On some hardware this blocks until a hard 60-second I/O timeout, delaying every shutdown/reboot. This is easily mistaken for a kernel/systemd hang (see this bug, originally filed against linux). * This upload removes the fwupd.shutdown hook entirely (data/fwupd.shutdown.in, its install rule, and the spec %files entry). Delayed activation at shutdown is no longer recommended upstream; devices are activated via the normal daemon/CLI paths instead. Removing the hook removes the only code path that could block shutdown. [Test Plan] 1. Confirm /usr/lib/systemd/system-shutdown/fwupd.shutdown exists before the update, and is gone after upgrading from -proposed. 2. Reboot/shut down a few times and confirm no added delay. 3. Confirm fwupdmgr get-devices/get-updates still work normally. Reporter syldeb35 already confirmed via a PPA build that the hang is gone (comment #8). [Where problems could occur] * A device relying on activation happening specifically at shutdown (rather than next daemon start/boot, or explicit fwupdmgr activate) would have that activation delayed by one cycle, not lost. * Packaging: the hook file simply stops being shipped; no maintainer-script logic depends on it. * Low risk: this deletes a rarely-used, already-discouraged code path with no changes to core daemon/plugin/activation logic. [Other Info] * Upstream fix: fwupd commit f295aead0 "Remove fwupd.shutdown delayed activation". * linux (Ubuntu) is Won't Fix — root cause and fix are in fwupd, not the kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/2169304/+subscriptions
понедельник
[Bug 2170572] Re: linux-image-7.0.0-38-generic randomly freezes Lenovo Legion 5
This bug is awaiting verification that the linux/7.3.0-11.12 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-stonking-linux' to 'verification-done-stonking- linux'. If the problem still exists, change the tag 'verification- needed-stonking-linux' to 'verification-failed-stonking-linux'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-stonking-linux-v2 verification-needed-stonking-linux -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2170572 Title: linux-image-7.0.0-38-generic randomly freezes Lenovo Legion 5 Status in linux package in Ubuntu: Invalid Status in linux source package in Resolute: Fix Committed Status in linux source package in Stonking: Fix Committed Bug description: == SRU Justification == -- Impact An apparmor change in v7.2 caused a NULL pointer validation in some cases. At least one of those happens in a critical section leaving a held lock behind. Which in the end causes the kernel to hang. -- Fix A fix to this was recently released upstream. It would at some point get pulled via stable updates but given the severity of the bug should be given priority. commit 4de32fd05ce9 Author: Maxime Bélair <maxime.belair@canonical.com> Date: Mon Aug 24 17:58:02 2026 +0200 apparmor: fix NULL ctx->peer derefs in unix socket ctx updates -- Test case This seems to require certain HW/setup to happen. And even then might need several restarts. -- Regression potential Anywhere within the area of apparmor controlled socket access. --- original description --- An unattended upgrade from the 7.0.0-31-generic kernel to the 7.0.0-38-generic kernel started causing random freezes on my Lenovo Legion 5 15IAX10 laptop, reverting back to 7.0.0-34-generic seems to fix my issues. I was able to switch to a tty and take a photo (attached), it seems like a kernel bug where CPU is stuck on a spin lock waiting for something. ``` $ grep -C 2 -i "linux-image" /var/log/apt/history.log Start-Date: 2026-10-08 09:10:45 Commandline: /usr/bin/unattended-upgrade Install: linux-modules-7.0.0-38-generic:amd64 (7.0.0-38.38, automatic), linux-image-7.0.0-38-generic:amd64 (7.0.0-38.38, automatic), linux-headers-7.0.0-38-generic:amd64 (7.0.0-38.38, automatic), linux-tools-7.0.0-38:amd64 (7.0.0-38.38, automatic), linux-headers-7.0.0-38:amd64 (7.0.0-38.38, automatic), linux-tools-7.0.0-38-generic:amd64 (7.0.0-38.38, automatic), linux-main-modules-zfs-7.0.0-38-generic:amd64 (7.0.0-38.38, automatic) Upgrade: linux-generic-hwe-24.04:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-image-generic-hwe-26.04:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-tools-common:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-headers-generic:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-perf:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-headers-generic-hwe-26.04:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-generic-hwe-26.04:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-generic:amd64 (7.0.0-34.34, 7.0.0-38.38), linux-image-generic:amd64 (7.0.0-34.34, 7.0.0-38.38), bpftool:amd64 (7.7.0+7.0.0-34.34, 7.7.0+7.0.0-38.38), linux-libc-dev:amd64 (7.0.0-34.34, 7.0.0-38.38) End-Date: 2026-10-08 09:11:28 -- Start-Date: 2026-10-08 09:12:00 Commandline: /usr/bin/unattended-upgrade Remove: linux-image-7.0.0-31-generic:amd64 (7.0.0-31.31), linux-modules-7.0.0-31-generic:amd64 (7.0.0-31.31), linux-main-modules-zfs-7.0.0-31-generic:amd64 (7.0.0-31.31+2) End-Date: 2026-10-08 09:12:06 ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170572/+subscriptions