понедельник

[Bug 2148534] Re: [Ubuntu 26.04] Failed install OS onto JBOD disk on B540d-2HS M.2 controller

Also tried with the build from comment #11 (kenrel version 7.0.12+), and it looks fine too. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148534 Title: [Ubuntu 26.04] Failed install OS onto JBOD disk on B540d-2HS M.2 controller Status in linux package in Ubuntu: Confirmed Status in linux source package in Resolute: Confirmed Bug description: The system hangs during storage initialization when using a B540 RAID Kit with a single Micron 7450 Pro NVMe SSD configured in JBOD mode. Environment: Hardware: Lenovo ThinkSystem SR650 V4 Controller: B540d-2HS M.2 controller Disk: ThinkSystem M.2 7450 PRO 960GB Read Intensive NVMe PCIe 4.0 x4 NHS SSD Kernel (broken): 7.0.0-13-generic (Ubuntu) Kernel (working): 6.8.x (Ubuntu 24.04 LTS) Reproduce steps: 1. Set the B540 RAID controller to allow JBOD or configure the Micron 7450P as a JBOD drive. 2. Start Ubuntu 26.04 installation. 3. The installer/kernel attempts to scan scsi0. 4. The driver hangs at "waiting for commands" and eventually triggers a firmware reset loop. The megaraid_sas driver reports multiple command timeouts followed by a controller firmware crash. Even though the logs show Secure JBOD support-: Yes and NVMe passthru support-: Yes, It seems like kernel oops in megasas_make_prp_nvme due to a page fault on an unmapped virtual address while building the NVMe, which can be refered in logs below with Call Trace. [ 271.793726] #PF: supervisor write access in kernel mode [ 271.794694] #PF: error_code(0x0002) - not-present page [ 271.795648] PGD 100000067 P4D 101b42067 PUD 101b43067 PMD 10219a067 PTE 0 [ 271.796887] Oops: Oops: 0002 [#1] SMP NOPTI [ 271.797675] CPU: 1 UID: 0 PID: 1905 Comm: kworker/u1025:3 Tainted: P S O 7.0.0-13-generic #13-Ubuntu PREEMPT(lazy) [ 271.799778] Tainted: [P]=PROPRIETARY_MODULE, [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE [ 271.801123] Hardware name: Lenovo ThinkSystem SR650 V4/SB27B70076, BIOS IHE111A-1.21 03/28/2025 [ 271.801140] sd 0:0:2:0: [sda] tag#244 page boundary ptr_sgl: 0x0000000040507511 [ 271.802682] Workqueue: writeback wb_workfn [ 271.802733] sd 0:0:2:0: [sda] tag#245 page boundary ptr_sgl: 0x000000004c4d3310 [ 271.806138] (flush-8:0) [ 271.806643] RIP: 0010:megasas_make_prp_nvme.isra.0+0x12f/0x220 [megaraid_sas] [ 271.807955] Code: 20 49 83 c7 20 48 89 d1 48 83 e1 fc 83 e2 01 4c 0f 45 f9 49 8b 5f 10 45 8b 67 18 4c 89 e9 4c 8d 69 08 45 85 eb 74 52 45 29 ce <48> 89 19 83 c0 01 45 85 f6 7f af 4c 8b 7d c8 c1 e0 03 b9 01 00 00 [ 271.811246] RSP: 0018:ff50bfb988f8b298 EFLAGS: 00010206 [ 271.812215] RAX: 0000000000000200 RBX: 00000000f6a00000 RCX: ff50bfb983b9a000 [ 271.813520] RDX: ff50bfb983b9a008 RSI: 0000000000000000 RDI: 0000000000000000 [ 271.814822] RBP: ff50bfb988f8b2f8 R08: 00000000ffbb0000 R09: 0000000000001000 [ 271.816365] R10: 0000000000001000 R11: 0000000000000fff R12: 0000000000200000 [ 271.817860] R13: ff50bfb983b9a008 R14: 00000000001ff000 R15: ff2b1ee1e1f2cb08 [ 271.819321] FS: 0000000000000000(0000) GS:ff2b1ee542880000(0000) knlGS:0000000000000000 [ 271.820923] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 271.822134] CR2: ff50bfb983b9a000 CR3: 0000060144844004 CR4: 0000000000f73ef0 [ 271.823587] PKRU: 55555554 [ 271.824274] Call Trace: [ 271.824920] <TASK> [ 271.825514] megasas_build_io_fusion+0x2e2/0x330 [megaraid_sas] [ 271.826772] megasas_build_and_issue_cmd_fusion+0xa3/0x280 [megaraid_sas] [ 271.828168] ? sd_init_command+0x138/0x4a0 [ 271.829110] megasas_queue_command+0x11b/0x200 [megaraid_sas] [ 271.830347] ? scsi_init_command+0x74/0xc0 [ 271.831291] ? __rq_qos_issue+0x29/0x50 [ 271.832199] scsi_dispatch_cmd+0x95/0x290 [ 271.833129] scsi_queue_rq+0x62e/0x8e0 [ 271.834017] blk_mq_dispatch_rq_list+0x131/0x510 [ 271.835064] __blk_mq_do_dispatch_sched+0x2d9/0x360 [ 271.836154] ? mod_memcg_lruvec_state+0x101/0x2f0 [ 271.837206] __blk_mq_sched_dispatch_requests+0x157/0x1a0 [ 271.838369] ? elv_rb_add+0x70/0x90 [ 271.839210] blk_mq_sched_dispatch_requests+0x2d/0x80 [ 271.840316] blk_mq_run_hw_queue+0x2c0/0x330 [ 271.841295] blk_mq_dispatch_list+0x159/0x350 [ 271.842319] blk_mq_flush_plug_list+0x59/0x1e0 [ 271.843328] blk_add_rq_to_plug+0xe7/0x220 [ 271.844262] ? blk_account_io_start+0xd2/0x210 [ 271.845258] blk_mq_submit_bio+0x677/0x920 [ 271.846182] __submit_bio+0xad/0x250 [ 271.847022] submit_bio_noacct_nocheck+0x102/0x1d0 [ 271.848068] submit_bio_noacct+0x131/0x430 [ 271.848982] submit_bio+0xb3/0x110 [ 271.849782] ext4_io_submit+0x40/0x70 [ 271.850624] ext4_do_writepages+0x60a/0x970 [ 271.851546] ? psi_group_change+0x195/0x460 [ 271.852466] ext4_writepages+0xc8/0x1b0 [ 271.853325] ? ext4_writepages+0xc8/0x1b0 [ 271.854209] do_writepages+0xcb/0x180 [ 271.855038] ? write_inode+0x78/0x150 [ 271.855863] __writeback_single_inode+0x45/0x270 [ 271.856852] ? wbc_detach_inode+0x115/0x2c0 [ 271.857756] writeback_sb_inodes+0x25e/0x5e0 [ 271.858685] __writeback_inodes_wb+0x54/0x100 [ 271.859621] ? queue_io+0x13b/0x150 [ 271.860416] wb_writeback+0x2e0/0x370 [ 271.861223] wb_workfn+0x39e/0x470 [ 271.861987] process_one_work+0x1ac/0x3d0 [ 271.862851] worker_thread+0x1b8/0x360 [ 271.863671] ? __pfx_worker_thread+0x10/0x10 [ 271.864586] kthread+0xf7/0x130 [ 271.865304] ? __pfx_kthread+0x10/0x10 [ 271.866118] ret_from_fork+0x195/0x2a0 [ 271.866934] ? __pfx_kthread+0x10/0x10 [ 271.867743] ? __pfx_kthread+0x10/0x10 [ 271.868551] ret_from_fork_asm+0x1a/0x30 [ 271.869394] </TASK> To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148534/+subscriptions

воскресенье

[Bug 2163215] Re: Fix SDCA jack detection race and reprobe issues on Dell Slate Max platform with CirrusLogic audio solution

Verified on Dell Slate Max platform with linux-oem-6.17/6.17.0-1033.33 kernel, boot the system with headphones unplugged, the headphone connect status is unplugged as expected. Then plug/unplug the headphone, the connect status is well reflected. Then suspend/resume to get the connect status, it's correct. Repeat for 3 times reboot/suspend/resume w/o problem. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163215 Title: Fix SDCA jack detection race and reprobe issues on Dell Slate Max platform with CirrusLogic audio solution Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] On Dell Slate Max systems with SoundWire Device Class Audio (SDCA) hardware, there is a race condition when setting up jack detection. Plug headset first, sound can output and headset Mic is workable. But after cold boot/reboot, audio device is keep but no sound output from headset, headset Mic also no function. Hot plug headset can recovery. [Fix] Reorganize SDCA IRQ registration and lifecycle management to run at the correct time and avoid races. The fixes do this by adding a new component-level callback that runs after all ALSA controls are created. This ensures the jack detection IRQs are registered only when the controls are ready. Upstream commits (first appeared in v7.2-rc6): - 3e81e2fb2163 ASoC: Add a component fixup_controls callback - b8f71f16134f ASoC: SDCA: Switch to fixup_controls callback for IRQ registration - bf1b7821f853 ASoC: SDCA: Move kcontrol search out of IRQ - 050406cbd676 ASoC: SDCA: Populate IRQ data earlier - 0880082c27b6 ASoC: SDCA: Remove devm from primary IRQ cleanup - f18e97fa7f12 ASoC: SDCA: Add sdca_irq_cleanup_late() - 4ecef577d1ce ASoC: SDCA: Rename sdca_irq_allocate() to include devm [Test Plan] Boot the system, plug headphones in and out, and check if audio switches correctly. 1. Boot the system with headphones unplugged. 2. Plug headphones in and check the jack state: $ evtest (or check alsamixer/sound settings) 3. Unplug headphones and verify sound switches back. 4. Reload the SoundWire driver modules or trigger suspend/resume to force card teardown and reprobe: $ sudo rtcwake -m mem -s 15 Or reload the SoundWire modules: $ sudo modprobe -r snd_sof_intel_sdw $ sudo modprobe snd_sof_intel_sdw Without these patches: - On boot, headphones might show up as connected when they are not, or sound might not switch correctly when plugged in. - After suspend/resume or reloading modules, jack detection stops working, or the system crashes/shows warnings due to stale pointers. With these patches: - Headphones and speaker paths are always set correctly on boot. - Jack detection and audio routing work correctly after suspend/resume and driver reloads. [Where problems could occur] Could break SDCA jack detection and SoundWire audio class drivers. If the new fixup_controls callback has a bug, jack IRQs will not be registered. Jack detection could stop working completely. If the cached kcontrol search gets a wrong pointer, the kernel will crash with a NULL pointer dereference when the IRQ handler runs. [Other Info] All seven patches are upstream in v7.2-rc6. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2163215/+subscriptions

[Bug 2163620] Comment bridged from LTC Bugzilla

------- Comment From Tasmiya.Nalatwad@ibm.com 2026-08-31 01:52 EDT------- Hi Team, I have tested this bug with qemu patchs posted by Amit, and upstream linux kernel, The issue is Not reproducible. OS Ubuntu 26.10 (Stonking Stingray) qemu-system-ppc64 --version QEMU emulator version 11.1.50 (v8.0.0-29343-g869a938207) uname -a Linux ubuntu 7.2.0+ #1 SMP PREEMPT_DYNAMIC Thu Aug 27 13:22:02 UTC 2026 ppc64le GNU/Linux Power 10 compatibility mode root@ubuntu:~# lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Model name: POWER10 (architected), altivec supported Model: 2.0 (pvr 0082 0200) Thread(s) per core: 8 Core(s) per socket: 2 Socket(s): 1 Virtualization features: Hypervisor vendor: pHyp Virtualization type: para -------- Steps Performed ------- 1. Install ubuntu 26.10 on a Power11 Lpar. 2. Change the compatibility mode of lpar to Power 10 from HMC 3. check model name, it should show as Power 10 in lscpu command 4. Start a guest in P10 compat mode, Guest should start and boot properly. 5. Guest boot was successful and i am able to login to the guest. -------- guest logs --------- Ubuntu Stonking Stingray (development branch) ubuntu-server hvc0 connecting... ^[[42;1R^[[42;83RPlease remove the installation medium, then press ENTER: [ 530.920533] (sd-umoun[14084]: Failed to unmount /run/shutdown/mounts/5f222a50d05d26db: Device or resource busy [ 530.922935] (sd-umoun[14085]: Failed to unmount /run/shutdown/mounts/c99926a0aece8251: Device or resource busy [ 530.926286] shutdown[1]: Could not detach loopback /dev/loop3: Device or resource busy [ 530.926846] shutdown[1]: Could not detach loopback /dev/loop2: Device or resource busy [ 530.927416] shutdown[1]: Could not detach loopback /dev/loop1: Device or resource busy [ 530.928021] shutdown[1]: Could not detach loopback /dev/loop0: Device or resource busy [ 530.929514] shutdown[1]: Unable to finalize remaining file systems, loop devices, ignoring. [ 530.937941] reboot: Restarting system Domain creation completed. Restarting guest. Running text console command: virsh --connect qemu:///system console ubuntu Authorization not available. Check if polkit service is running or see debug message for more information. Connected to domain 'ubuntu' Escape character is ^] (Ctrl + ]) guest login: guest Password: Welcome to Ubuntu Stonking Stingray (development branch) (GNU/Linux 7.0.0-14-generic ppc64le) * Documentation: https://docs.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro System information as of Fri Aug 28 08:03:59 PM UTC 2026 System load: 0.0 Processes: 229 Usage of /: 26.7% of 9.75GB Users logged in: 0 Memory usage: 6% IPv4 address for enp0s1: 192.168.122.239 Swap usage: 0% 0 updates can be applied immediately. The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. guest@guest:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:db:f9:c0 brd ff:ff:ff:ff:ff:ff altname enx525400dbf9c0 inet 192.168.122.239/24 metric 100 brd 192.168.122.255 scope global dynamic enp0s1 valid_lft 3580sec preferred_lft 3580sec inet6 fe80::5054:ff:fedb:f9c0/64 scope link proto kernel_ll valid_lft forever preferred_lft forever guest@guest:~$guest@guest:~$ lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 10 On-line CPU(s) list: 0-9 Model name: POWER10 (architected), altivec supported Model: 2.0 (pvr 0082 0200) Thread(s) per core: 1 Core(s) per socket: 10 Socket(s): 1 Virtualization features: Hypervisor vendor: KVM Virtualization type: para -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163620 Title: [Ubuntu 26.10] : KVM guest boot hangs on POWER11 host when processor compatibility mode is set to POWER10 Status in linux package in Ubuntu: In Progress Status in linux source package in Stonking: In Progress Bug description: [Impact] On a POWER11 system with the processor compatibility mode set to POWER10, Ubuntu 26.10 guest installation fails to boot on a KVM-enabled host. When a guest is created using virt-install and booted from the Ubuntu 26.10 installation ISO, the boot process hangs during early kernel initialization and the installer does not proceed further. [Fix] Apply the following patches from linux-next: - 884ea0283f4e KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode - ac3e65ddddf3 KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl - b76fb087efcd KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM - 8735048f54ec KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV - c1721e584244 KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl [Test Plan] - Setup KVM enabled host with Ubuntu26.10. - Install libvirt and qemu packages required for bringing up GUests - Create and boot an Ubuntu 26.10 KVM guest from the Ubuntu 26.10 installation ISO on a POWER11 LPAR running in POWER10 compatibility mode using the following command: ``` /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm' --machine pseries --memory=10000 --vcpu=10,sockets=1,cores=10,threads=1 --import --nographics --os-variant ubuntu25.10 --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/ubuntu26_10.qcow2,bus=scsi,size=50,format=qcow2 --network=bridge=virbr0,model=virtio --boot emulator=/usr/bin/qemu-system-ppc64 --cdrom /home/ubuntu-26.10-snapshot2-live-server-ppc64el.iso ``` [Regression Potential] The change is confined to powerpc nested virtualization code. Users of nested virtualization in powerpc may be affected. --- == Problem Description === On a POWER11 system with the processor compatibility mode set to POWER10, Ubuntu 26.10 guest installation fails to boot on a KVM-enabled host. When a guest is created using virt-install and booted from the Ubuntu 26.10 installation ISO, the boot process hangs during early kernel initialization and the installer does not proceed further. HOST ENV: OS : Ubuntu 26.10 (Stonking Stingray) kernel : 7.0.0-14-generic libvirt : libvirtd (libvirt) 12.0.0 qemu : QEMU emulator version 10.2.1 on host : # lscpu Architecture: ppc64le   Byte Order: Little Endian CPU(s): 80   On-line CPU(s) list: 0-79 Model name: POWER10 (architected), altivec supported   Model: 2.0 (pvr 0082 0200)   Thread(s) per core: 8   Core(s) per socket: 10   Socket(s): 1 Virtualization features:   Hypervisor vendor: pHyp   Virtualization type: para Caches (sum of all):   L1d: 640 KiB (20 instances)   L1i: 960 KiB (20 instances)   L2: 20 MiB (20 instances)   L3: 80 MiB (20 instances) NUMA:   NUMA node(s): 3   NUMA node0 CPU(s):   NUMA node1 CPU(s): 0-79   NUMA node2 CPU(s): Vulnerabilities:   Gather data sampling: Not affected   Ghostwrite: Not affected   Indirect target selection: Not affected   Itlb multihit: Not affected   L1tf: Not affected   Mds: Not affected   Meltdown: Not affected   Mmio stale data: Not affected   Old microcode: Not affected   Reg file data sampling: Not affected   Retbleed: Not affected   Spec rstack overflow: Not affected   Spec store bypass: Not affected   Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation barrier enabled   Spectre v2: Mitigation; Software count cache flush (hardware accelerated), Software link stack flush   Srbds: Not affected   Tsa: Not affected   Tsx async abort: Not affected   Vmscape: Not affected Steps to re-create: =================== - Setup KVM enabled host with Ubuntu26.10. - Install libvirt and qemu packages required for bringing up GUests - Create and boot an Ubuntu 26.10 KVM guest from the Ubuntu 26.10 installation ISO on a POWER11 LPAR running in POWER10 compatibility mode using the following command: --logs-- /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm' --machine pseries --memory=10000 --vcpu=10,sockets=1,cores=10,threads=1 --import --nographics --os-variant ubuntu25.10 --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/ubuntu26_10.qcow2,bus=scsi,size=50,format=qcow2 --network=bridge=virbr0,model=virtio --boot emulator=/usr/bin/qemu-system-ppc64 --cdrom /home/ubuntu-26.10-snapshot2-live-server-ppc64el.iso WARNING CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media Starting install... Allocating 'ubuntu26_10.qcow2' | 50 GB 00:00:00 Creating domain... | 00:00:00 Running text console command: virsh --connect qemu:///system console vm Connected to domain 'vm' Escape character is ^] (Ctrl + ]) Populating /vdevice methods Populating /vdevice/vty@30000000 Populating /vdevice/nvram@71000000 Populating /pci@800000020000000                      00 0800 (D) : 1af4 1000 virtio [ net ]                      00 1000 (D) : 1af4 1004 virtio [ scsi ] Populating /pci@800000020000000/scsi@2        SCSI: Looking for devices           100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+"           100000100000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"                      00 1800 (D) : 1b36 000d serial bus [ usb-xhci ]                      00 2000 (D) : 1af4 1003 virtio [ serial ]                      00 2800 (D) : 1af4 1002 legacy-device*                      00 3000 (D) : 1af4 1005 legacy-device* No NVRAM common partition, re-initializing... Scanning USB   XHCI: Initializing Using default console: /vdevice/vty@30000000   Welcome to Open Firmware   Copyright (c) 2004, 2017 IBM Corporation All rights reserved.   This program and the accompanying materials are made available   under the terms of the BSD License available at   http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/scsi@2/disk@100000100000000 ... Successfully loaded Welcome to GRUB! error: couldn't examine /ibm,secure-boot property. error: unrecognized number.                              GNU GRUB version 2.14  +----------------------------------------------------------------------------+  |*Try or Install Ubuntu Server |  | |  | |  | |  | |  | |  | |  | |  | |  | |  | |  | |  +----------------------------------------------------------------------------+       Use the ^ and v keys to select which entry is highlighted.       Press enter to boot the selected OS, `e' to edit the commands       before booting or `c' for a command-line. OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 7.0.0-14-generic (buildd@bos03-ppc64el-029) (powerpc64le-linux-gnu-gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.46) #14-Ubuntu SMP PREEMPT_DYNAMIC Mon Apr 13 11:10:37 UTC 2026 (Ubuntu 7.0.0-14.14-generic 7.0.0) Detected machine type: 0000000000000101 command line: BOOT_IMAGE=/casper/vmlinux quiet --- Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) Calling ibm,client-architecture-support... == Comment: #2 == The patches are in ppc next now: c1721e584244 KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl 8735048f54ec KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV b76fb087efcd KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM ac3e65ddddf3 KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl 884ea0283f4e KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode Please note that one of the dependent patches had already made it to upstream. e4de1b9cb3b5 ("powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later processors") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163620/+subscriptions

[Bug 2158075] Re: PCI/PM Regression: NVIDIA MX250 / PCI Bridge unable to change power state from D3cold to D0 on kernels >= 6.8 (HP Envy)

[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158075 Title: PCI/PM Regression: NVIDIA MX250 / PCI Bridge unable to change power state from D3cold to D0 on kernels >= 6.8 (HP Envy) Status in linux package in Ubuntu: Expired Bug description: Expected Behavior: The discrete NVIDIA GeForce MX250 GPU should successfully initialize and wake from low-power runtime states during system boot and user session initialization. Actual Behavior: During the early system boot phase, the kernel fails to wake the discrete GPU from its power-saving D3cold state to D0. Because the hardware remains unresponsive, it reports a broken 64-bit BAR allocation window mapped above 4GB, and the NVIDIA proprietary driver fails to initialize entirely. This bug is persistent across modern HWE kernel stacks (tested on 6.11.0-29-generic and 6.17.0-35-generic). Steps taken that did NOT resolve the issue: - Verified DKMS modules compile completely cleanly for NVIDIA 535.309.01 against both kernels. - Attempted ACPI OSI overrides via GRUB including 'acpi_osi="Windows 2015"' and 'acpi_osi="Windows 2009"' to force legacy vendor firmware paths; the D3cold -> D0 timeout persisted. - Tested kernel and driver power-state management parameters including 'pcie_port_pm=off', 'pci=realloc', and 'nvidia.NVreg_DynamicPowerManagement=1'. None of these flags successfully intercepted or prevented the hardware from falling into an un-wakeable D3cold state. - System is only stable when completely bypassing the device initialization tree using 'prime-select intel'. Hardware Platform: - Laptop: HP Envy x360 15-dr0003np - GPU: NVIDIA GeForce MX250 / Integrated Intel Graphics - OS: Linux Mint 22.3 (Noble Base) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158075/+subscriptions

[Bug 2163215] Re: Fix SDCA jack detection race and reprobe issues on Dell Slate Max platform with CirrusLogic audio solution

** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: In Progress => Fix Committed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163215 Title: Fix SDCA jack detection race and reprobe issues on Dell Slate Max platform with CirrusLogic audio solution Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Bug description: [Impact] On Dell Slate Max systems with SoundWire Device Class Audio (SDCA) hardware, there is a race condition when setting up jack detection. Plug headset first, sound can output and headset Mic is workable. But after cold boot/reboot, audio device is keep but no sound output from headset, headset Mic also no function. Hot plug headset can recovery. [Fix] Reorganize SDCA IRQ registration and lifecycle management to run at the correct time and avoid races. The fixes do this by adding a new component-level callback that runs after all ALSA controls are created. This ensures the jack detection IRQs are registered only when the controls are ready. Upstream commits (first appeared in v7.2-rc6): - 3e81e2fb2163 ASoC: Add a component fixup_controls callback - b8f71f16134f ASoC: SDCA: Switch to fixup_controls callback for IRQ registration - bf1b7821f853 ASoC: SDCA: Move kcontrol search out of IRQ - 050406cbd676 ASoC: SDCA: Populate IRQ data earlier - 0880082c27b6 ASoC: SDCA: Remove devm from primary IRQ cleanup - f18e97fa7f12 ASoC: SDCA: Add sdca_irq_cleanup_late() - 4ecef577d1ce ASoC: SDCA: Rename sdca_irq_allocate() to include devm [Test Plan] Boot the system, plug headphones in and out, and check if audio switches correctly. 1. Boot the system with headphones unplugged. 2. Plug headphones in and check the jack state: $ evtest (or check alsamixer/sound settings) 3. Unplug headphones and verify sound switches back. 4. Reload the SoundWire driver modules or trigger suspend/resume to force card teardown and reprobe: $ sudo rtcwake -m mem -s 15 Or reload the SoundWire modules: $ sudo modprobe -r snd_sof_intel_sdw $ sudo modprobe snd_sof_intel_sdw Without these patches: - On boot, headphones might show up as connected when they are not, or sound might not switch correctly when plugged in. - After suspend/resume or reloading modules, jack detection stops working, or the system crashes/shows warnings due to stale pointers. With these patches: - Headphones and speaker paths are always set correctly on boot. - Jack detection and audio routing work correctly after suspend/resume and driver reloads. [Where problems could occur] Could break SDCA jack detection and SoundWire audio class drivers. If the new fixup_controls callback has a bug, jack IRQs will not be registered. Jack detection could stop working completely. If the cached kcontrol search gets a wrong pointer, the kernel will crash with a NULL pointer dereference when the IRQ handler runs. [Other Info] All seven patches are upstream in v7.2-rc6. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2163215/+subscriptions

[Bug 2165859] Re: Infinite connect/disconnect loop with JBL Flip Essential 2

It looks like the kernel keeps trying to repatch the Intel Bluetooth device every time the JBL Flip Essential 2 reconnects. Seems more like a kernel driver bug, although it could just be overly verbose log messages. ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux-firmware-intel-wireless (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/2165859 Title: Infinite connect/disconnect loop with JBL Flip Essential 2 Status in bluez package in Ubuntu: New Status in linux package in Ubuntu: New Status in linux-firmware-intel-wireless package in Ubuntu: New Bug description: Issue: Pairs successfully, but audio stutters/cuts. After 5 to 15 seconds, it disconnects and enters an infinite connect/disconnect loop. Troubleshooting done: Tested forcing ControllerMode = bredr, wiping /var/lib/bluetooth/*, and disabling Wi-Fi to rule out coexistence issues. Bug persists. Important Context: Other Bluetooth headphones (JBL Tune) work perfectly on this machine. The exact same JBL Flip worked fine on this laptop (Dell Inspiron 3442) when running Windows. wi-fi adapter : WiFi card Intel 7260HMW dual band wireless AC 7260 model 7260WMH ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: bluez 5.85-4ubuntu0.1 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Aug 30 22:01:34 2026 InstallationDate: Installed on 2026-06-19 (73 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Inspiron 3442 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-30-generic root=UUID=8a3bf956-d00f-4316-846a-5cd949643d6b ro cryptdevice=UUID=2982648c-dcfb-4627-8569-f1e0ab6a495b:luks-2982648c-dcfb-4627-8569-f1e0ab6a495b root=/dev/mapper/luks-2982648c-dcfb-4627-8569-f1e0ab6a495b splash SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/02/2020 dmi.bios.release: 65.16 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.name: 0P8H6J dmi.board.vendor: Dell Inc. dmi.board.version: A16 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnDellInc.:bvrA16:bd09/02/2020:br65.16:svnDellInc.:pnInspiron3442:pvrNotSpecified:rvnDellInc.:rn0P8H6J:rvrA16:cvnDellInc.:ct8:cvrNotSpecified:sku0651:pfa: dmi.product.name: Inspiron 3442 dmi.product.sku: 0651 dmi.product.version: Not Specified dmi.sys.vendor: Dell Inc. hciconfig: hci0: Type: Primary Bus: USB BD Address: 48:51:B7:15:CE:1B ACL MTU: 1021:5 SCO MTU: 96:6 UP RUNNING PSCAN INQUIRY RX bytes:2819 acl:37 sco:0 events:183 errors:0 TX bytes:7301 acl:41 sco:0 commands:123 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/2165859/+subscriptions

[Bug 2165864] [NEW] Ethernet MAC address not set correctly after Thunderbolt dock hot-plug on Dell systems

Public bug reported: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). ** Affects: linux (Ubuntu) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Noble) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-7.0 (Ubuntu Noble) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Resolute) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu Resolute) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux (Ubuntu Stonking) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Stonking) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu Stonking) Importance: Undecided Status: Invalid ** Description changed: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): + https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ + Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). ** Also affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-7.0 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-7.0 (Ubuntu Stonking) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Status: New => In Progress ** Changed in: linux (Ubuntu Noble) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux (Ubuntu Resolute) Status: New => In Progress ** Changed in: linux (Ubuntu Resolute) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux (Ubuntu Stonking) Status: New => In Progress ** Changed in: linux (Ubuntu Stonking) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: New => In Progress ** Changed in: linux-oem-6.17 (Ubuntu Noble) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Stonking) Status: New => Invalid ** Changed in: linux-oem-7.0 (Ubuntu Noble) Status: New => Invalid ** Changed in: linux-oem-7.0 (Ubuntu Resolute) Status: New => In Progress ** Changed in: linux-oem-7.0 (Ubuntu Resolute) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-7.0 (Ubuntu Stonking) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165864 Title: Ethernet MAC address not set correctly after Thunderbolt dock hot-plug on Dell systems Status in linux package in Ubuntu: In Progress Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: In Progress Status in linux-oem-6.17 source package in Noble: In Progress Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux-oem-7.0 source package in Resolute: In Progress Status in linux source package in Stonking: In Progress Status in linux-oem-6.17 source package in Stonking: Invalid Status in linux-oem-7.0 source package in Stonking: Invalid Bug description: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165864/+subscriptions

[Bug 2165844] Re: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write

** 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/2165844 Title: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write Status in linux package in Ubuntu: New Bug description: [Summary] Any buffered write() to an ntfs3-mounted volume can hit a BUG_ON in the generic iomap write path and panic the kernel. An unprivileged process (rsync, uid 1000) took the whole machine down; the system froze instantly, then kdump rebooted into the capture kernel. [Impact] This is reachable from unprivileged userspace with a plain write(2) syscall. Whatever the state of the NTFS volume, the correct outcome is -EIO returned to the caller, not a kernel panic. Reproducing it needs nothing but a writable NTFS mount, which udisks/GNOME Files creates by default when a user clicks a Windows partition. [Environment] Ubuntu 26.04, linux-image-7.0.0-30-generic 7.0.0-30.30, x86_64 ASUS ROG STRIX B550-XE GAMING WIFI, BIOS 3607 NTFS volume: 1.8 TB Windows system partition, mounted read-write by udisks (driver ntfs3, POSIX ACLs enabled) [What happened] Writing to the NTFS mount, the kernel hit the assertion and died: kernel BUG at fs/iomap/buffered-io.c:1061! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 1000 PID: 18561 Comm: rsync Kdump: loaded Tainted: G O Hardware name: ASUS System Product Name/ROG STRIX B550-XE GAMING WIFI RIP: 0010:iomap_write_end+0x1e0/0x1f0 Call Trace: iomap_write_iter+0x171/0x340 iomap_file_buffered_write+0xa6/0x110 ntfs_file_write_iter+0x267/0x310 [ntfs3] vfs_write+0x25b/0x490 ksys_write+0x71/0xf0 __x64_sys_write+0x19/0x30 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The faulting syscall was a 137-byte write(2) to fd 1 (ORIG_RAX 0x1, RDX 0x89) — an ordinary small buffered write, not anything exotic. The G/O taint is the out-of-tree NVIDIA module (595.84). It is unrelated to this code path; ntfs3, iomap and the write path are all in-tree. [Preceding symptom] About 14 minutes before the panic, ntfs3 logged a large burst of metadata repairs on the same volume: ntfs3(nvme0n1p2): ino=..., Correct links count -> N ntfs3: 15286 callbacks suppressed So the volume was not perfectly clean. That may well be what steers the write path into the bad state — but an inconsistent filesystem must not be able to panic the kernel, so it looks like a missing error path rather than a disk problem. [Reproducer] Not deterministic here, but the shape is simple: 1. Mount an NTFS volume read-write with ntfs3 (udisksctl mount is enough). 2. Run sustained buffered I/O against it (rsync of a large tree). The other reports linked below describe the same trace from ordinary file writes, including games writing save data. [Already reported elsewhere] Same trace, same line, on 7.0.x kernels since roughly April 2026: - https://github.com/CachyOS/linux-cachyos/issues/841 - https://discuss.cachyos.org/t/kernel-bug-in-iomap-write-end-triggered-by-ntfs3-buffered-write-linux-7-0-1-cachyos/28546 - https://bbs.archlinux.org/viewtopic.php?pid=2296728 - https://forum.manjaro.org/t/total-system-hangs-and-fs-iomap-kernel-panic-on-7-0-10-stable-on-6-18-lts/188283 I could not find an upstream fix. Upstream appears to be replacing ntfs3 with the new ntfsplus driver in 7.1 rather than fixing this one. [Suggestion for Ubuntu] Since 26.04 ships 7.0 and a user can trigger a kernel panic by copying files onto a Windows partition from the file manager, it may be worth either backporting a fix or having udisks default NTFS mounts to read-only until 7.1 lands via HWE. [Attached] Full kernel ring buffer from the kdump vmcore (VmCoreDmesg), plus the usual apport-collected hardware and package data. Sanitisation applied before upload: firewall log lines were dropped, and MAC addresses, the wireless BSSID/SSID and LAN IPv4 addresses were replaced with placeholders in VmCoreDmesg, CurrentDmesg and WifiSyslog. Nothing else was altered; the panic trace is untouched. An incomplete vmcore (2.3 GB, truncated because the machine was power-cycled during the dump) is available if it would help. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Sun Aug 30 11:45:03 2026 InstallationDate: Installed on 2026-07-12 (49 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name PackageArchitecture: amd64 ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=5778b2dd-b496-4525-b52f-223e5be557bc ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux Title: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True dmi.bios.date: 03/18/2024 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3607 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX B550-XE GAMING WIFI dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3607:bd03/18/2024:br5.17:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXB550-XEGAMINGWIFI:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165844/+subscriptions

[Bug 2165857] Re: snd_ctxfi: CA20K2 SB1270 S/PDIF IEC61937 passthrough fails with multiple=2 due to unhandled DAIO conf 0x9

** 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/2165857 Title: snd_ctxfi: CA20K2 SB1270 S/PDIF IEC61937 passthrough fails with multiple=2 due to unhandled DAIO conf 0x9 Status in linux package in Ubuntu: New Bug description: IEC61937 S/PDIF passthrough fails on a Creative Sound Blaster X-Fi Titanium HD SB1270 (CA20K2) using the snd_ctxfi driver when the driver operates with: reference_rate=48000 multiple=2 The same hardware and S/PDIF output work when using multiple=1. Affected Ubuntu kernel: linux-image-7.0.0-30-generic 7.0.0-30.30 The Apport report confirms that this kernel package has origin: Ubuntu. S/PDIF PCM device used for testing: hw:0,4 ## Steps to reproduce 1. Load the stock snd_ctxfi driver with: reference_rate=48000 multiple=2 2. Send an IEC61937 AC3/DTS encoded stream through the X-Fi S/PDIF PCM device hw:0,4. 3. Encoded S/PDIF passthrough fails. 4. Change the driver configuration to: reference_rate=48000 multiple=1 5. Repeat exactly the same IEC61937 test. Result: passthrough works. ## Expected result IEC61937 AC3/DTS passthrough should work with: reference_rate=48000 multiple=2 ## Actual result With the stock snd_ctxfi driver: multiple=2 -> FAIL multiple=1 -> PASS ## Root cause analysis The problem was isolated to the CA20K2 DAIO transmitter configuration. In: sound/pci/ctxfi/ctdaio.c the configuration is generated as: conf = (desc->msr & 0x7) | (desc->passthru << 3); For the failing passthrough configuration, this produces: conf == 0x9 The CA20K2 implementation in: sound/pci/ctxfi/cthw20k2.c uses: switch (conf & 0xf) to configure ATXCTL_NUC. The existing switch handles cases 1, 2, 4 and 8, but does not handle case 9. A minimal test modification was made so that configuration 9 is handled together with configuration 1: case 1: case 9: set_field(&ctl->txctl[idx], ATXCTL_NUC, 0); break; A replacement snd-ctxfi.ko was rebuilt from the source corresponding to the running Ubuntu kernel. No unrelated driver logic was changed. The rebuilt module has matching vermagic: 7.0.0-30-generic The patched driver was then tested again using the original configuration: reference_rate=48000 multiple=2 Results: IEC61937 AC3 passthrough: PASS IEC61937 DTS passthrough: PASS 5.1 decoding/output: PASS Additional regression tests of the audio driver passed. This demonstrates that multiple=1 is only a workaround. The CA20K2 hardware is capable of correct IEC61937 passthrough with multiple=2 once configuration 0x9 is explicitly handled. The same missing case 9 is also present in the current upstream Linux snd_ctxfi CA20K2 implementation, so this does not appear to be an Ubuntu-specific source modification. I can provide the exact minimal source diff/patch and additional test details if required. ProblemType: Bug DistroRelease: AnduinOS 2.0.2 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 [origin: Ubuntu] ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: zorgan 3141 F.... wireplumber /dev/snd/controlC1: zorgan 3141 F.... wireplumber /dev/snd/seq: zorgan 3133 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sun Aug 30 21:38:19 2026 MachineType: Gigabyte Technology Co., Ltd. Z590 D ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=8506df91-3e89-4e62-8c8b-165299db5989 ro quiet splash preempt=full PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) WifiSyslog: dmi.bios.date: 06/10/2025 dmi.bios.release: 5.19 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: F11b dmi.board.asset.tag: Default string dmi.board.name: Z590 D dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrF11b:bd06/10/2025:br5.19:svnGigabyteTechnologyCo.,Ltd.:pnZ590D:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnZ590D:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:pfaZ590MB: dmi.product.family: Z590 MB dmi.product.name: Z590 D dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165857/+subscriptions

[Bug 2165857] [NEW] snd_ctxfi: CA20K2 SB1270 S/PDIF IEC61937 passthrough fails with multiple=2 due to unhandled DAIO conf 0x9

Public bug reported: IEC61937 S/PDIF passthrough fails on a Creative Sound Blaster X-Fi Titanium HD SB1270 (CA20K2) using the snd_ctxfi driver when the driver operates with: reference_rate=48000 multiple=2 The same hardware and S/PDIF output work when using multiple=1. Affected Ubuntu kernel: linux-image-7.0.0-30-generic 7.0.0-30.30 The Apport report confirms that this kernel package has origin: Ubuntu. S/PDIF PCM device used for testing: hw:0,4 ## Steps to reproduce 1. Load the stock snd_ctxfi driver with: reference_rate=48000 multiple=2 2. Send an IEC61937 AC3/DTS encoded stream through the X-Fi S/PDIF PCM device hw:0,4. 3. Encoded S/PDIF passthrough fails. 4. Change the driver configuration to: reference_rate=48000 multiple=1 5. Repeat exactly the same IEC61937 test. Result: passthrough works. ## Expected result IEC61937 AC3/DTS passthrough should work with: reference_rate=48000 multiple=2 ## Actual result With the stock snd_ctxfi driver: multiple=2 -> FAIL multiple=1 -> PASS ## Root cause analysis The problem was isolated to the CA20K2 DAIO transmitter configuration. In: sound/pci/ctxfi/ctdaio.c the configuration is generated as: conf = (desc->msr & 0x7) | (desc->passthru << 3); For the failing passthrough configuration, this produces: conf == 0x9 The CA20K2 implementation in: sound/pci/ctxfi/cthw20k2.c uses: switch (conf & 0xf) to configure ATXCTL_NUC. The existing switch handles cases 1, 2, 4 and 8, but does not handle case 9. A minimal test modification was made so that configuration 9 is handled together with configuration 1: case 1: case 9: set_field(&ctl->txctl[idx], ATXCTL_NUC, 0); break; A replacement snd-ctxfi.ko was rebuilt from the source corresponding to the running Ubuntu kernel. No unrelated driver logic was changed. The rebuilt module has matching vermagic: 7.0.0-30-generic The patched driver was then tested again using the original configuration: reference_rate=48000 multiple=2 Results: IEC61937 AC3 passthrough: PASS IEC61937 DTS passthrough: PASS 5.1 decoding/output: PASS Additional regression tests of the audio driver passed. This demonstrates that multiple=1 is only a workaround. The CA20K2 hardware is capable of correct IEC61937 passthrough with multiple=2 once configuration 0x9 is explicitly handled. The same missing case 9 is also present in the current upstream Linux snd_ctxfi CA20K2 implementation, so this does not appear to be an Ubuntu-specific source modification. I can provide the exact minimal source diff/patch and additional test details if required. ProblemType: Bug DistroRelease: AnduinOS 2.0.2 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 [origin: Ubuntu] ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: zorgan 3141 F.... wireplumber /dev/snd/controlC1: zorgan 3141 F.... wireplumber /dev/snd/seq: zorgan 3133 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sun Aug 30 21:38:19 2026 MachineType: Gigabyte Technology Co., Ltd. Z590 D ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=8506df91-3e89-4e62-8c8b-165299db5989 ro quiet splash preempt=full PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) WifiSyslog: dmi.bios.date: 06/10/2025 dmi.bios.release: 5.19 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: F11b dmi.board.asset.tag: Default string dmi.board.name: Z590 D dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrF11b:bd06/10/2025:br5.19:svnGigabyteTechnologyCo.,Ltd.:pnZ590D:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnZ590D:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:pfaZ590MB: dmi.product.family: Z590 MB dmi.product.name: Z590 D dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute third-party-packages 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/2165857 Title: snd_ctxfi: CA20K2 SB1270 S/PDIF IEC61937 passthrough fails with multiple=2 due to unhandled DAIO conf 0x9 Status in linux package in Ubuntu: New Bug description: IEC61937 S/PDIF passthrough fails on a Creative Sound Blaster X-Fi Titanium HD SB1270 (CA20K2) using the snd_ctxfi driver when the driver operates with: reference_rate=48000 multiple=2 The same hardware and S/PDIF output work when using multiple=1. Affected Ubuntu kernel: linux-image-7.0.0-30-generic 7.0.0-30.30 The Apport report confirms that this kernel package has origin: Ubuntu. S/PDIF PCM device used for testing: hw:0,4 ## Steps to reproduce 1. Load the stock snd_ctxfi driver with: reference_rate=48000 multiple=2 2. Send an IEC61937 AC3/DTS encoded stream through the X-Fi S/PDIF PCM device hw:0,4. 3. Encoded S/PDIF passthrough fails. 4. Change the driver configuration to: reference_rate=48000 multiple=1 5. Repeat exactly the same IEC61937 test. Result: passthrough works. ## Expected result IEC61937 AC3/DTS passthrough should work with: reference_rate=48000 multiple=2 ## Actual result With the stock snd_ctxfi driver: multiple=2 -> FAIL multiple=1 -> PASS ## Root cause analysis The problem was isolated to the CA20K2 DAIO transmitter configuration. In: sound/pci/ctxfi/ctdaio.c the configuration is generated as: conf = (desc->msr & 0x7) | (desc->passthru << 3); For the failing passthrough configuration, this produces: conf == 0x9 The CA20K2 implementation in: sound/pci/ctxfi/cthw20k2.c uses: switch (conf & 0xf) to configure ATXCTL_NUC. The existing switch handles cases 1, 2, 4 and 8, but does not handle case 9. A minimal test modification was made so that configuration 9 is handled together with configuration 1: case 1: case 9: set_field(&ctl->txctl[idx], ATXCTL_NUC, 0); break; A replacement snd-ctxfi.ko was rebuilt from the source corresponding to the running Ubuntu kernel. No unrelated driver logic was changed. The rebuilt module has matching vermagic: 7.0.0-30-generic The patched driver was then tested again using the original configuration: reference_rate=48000 multiple=2 Results: IEC61937 AC3 passthrough: PASS IEC61937 DTS passthrough: PASS 5.1 decoding/output: PASS Additional regression tests of the audio driver passed. This demonstrates that multiple=1 is only a workaround. The CA20K2 hardware is capable of correct IEC61937 passthrough with multiple=2 once configuration 0x9 is explicitly handled. The same missing case 9 is also present in the current upstream Linux snd_ctxfi CA20K2 implementation, so this does not appear to be an Ubuntu-specific source modification. I can provide the exact minimal source diff/patch and additional test details if required. ProblemType: Bug DistroRelease: AnduinOS 2.0.2 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 [origin: Ubuntu] ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: zorgan 3141 F.... wireplumber /dev/snd/controlC1: zorgan 3141 F.... wireplumber /dev/snd/seq: zorgan 3133 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sun Aug 30 21:38:19 2026 MachineType: Gigabyte Technology Co., Ltd. Z590 D ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=8506df91-3e89-4e62-8c8b-165299db5989 ro quiet splash preempt=full PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) WifiSyslog: dmi.bios.date: 06/10/2025 dmi.bios.release: 5.19 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: F11b dmi.board.asset.tag: Default string dmi.board.name: Z590 D dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrF11b:bd06/10/2025:br5.19:svnGigabyteTechnologyCo.,Ltd.:pnZ590D:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnZ590D:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:pfaZ590MB: dmi.product.family: Z590 MB dmi.product.name: Z590 D dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165857/+subscriptions

[Bug 2165854] [NEW] IPU6 ISYS never probes on Samsung Galaxy Book NP960QFG (RPL, OV02C1)

Public bug reported: [IMPACT] Webcam integrated on Samsung Galaxy Book NP960QFG-KA1AR is non-functional on Zorin OS 18.1 / Ubuntu 24.04 with kernel 7.0.0-30-generic. Driver loads PCI device, detects sensor, registers PSYS, but ISYS never completes probe and no firmware is loaded. Every V4L2 STREAMON returns ENOLINK ("Link has been severed"). [HARDWARE] Vendor: Samsung Electronics Co Ltd Model: Galaxy Book NP960QFG-KA1AR (RPL, 12th/13th gen) Subsystem: c1ca CPU: Intel Raptor Lake-P (Host bridge 0xa707) PCI device: 0000:00:05.0 Multimedia controller [0480] Intel Corporation Device a75d (IPU6-v3, hardware version 5) Sensor: OVTI02C1:00 (Omnivision OV02C1) on i2c-0 address 0x36 Lens cover: samsung-galaxybook SAM0429:00, currently open (not blocking) BIOS: P07ALN.260.240415.SH (Samsung) Secure Boot: disabled [SOFTWARE] Distro: Zorin OS 18.1 (based on Ubuntu 24.04 noble) Kernel: 7.0.0-30-generic (HWE) Kernel alt: 6.17.0-35-generic also installed in /boot Init system: systemd [PACKAGES] intel-ipu6-dkms 0~git202603270946.51fe7248-0ubuntu1+zorin1 libcamhal-common 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal-ipu6ep 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal-ipu6ep-common 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal0 0~git202601200757.9899efa~ubuntu24.04.3 gstreamer1.0-icamera 0~git202509260937.4fb31db~ubuntu24.04.9 linux-modules-ipu6-7.0.0-30-generic 7.0.0-30.30~24.04.1 linux-modules-ipu6-generic-7.0 7.0.0-30.30~24.04.1 v4l2loopback-dkms 0.15.3-1ubuntu2+zorin1 v4l2-relayd 0.1.2-0ubuntu3.1 [FIRMWARE] /lib/firmware/intel/ipu/ipu6ep_fw.bin (467 KB, decompressed from .zst) /lib/firmware/intel/ipu/shisp_2401a0_v21.bin (12 MB, decompressed from .zst) /lib/firmware/intel/ipu/ipu6ep_fw.bin.zst (original) /lib/firmware/intel/ipu/shisp_2401a0_v21.bin.zst (original) Other ipu6 firmwares: ipu6epadln, ipu6epmtl, ipu6, ipu6se, ipu7, ipu7ptl, irci [DMESG OUTPUT (filtered to intel-ipu* and related)] [ 2.633510] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) [ 2.642939] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 [ 2.643149] intel-ipu6 0000:00:05.0: Connected 1 cameras [ 2.644075] intel-ipu6 0000:00:05.0: IPU6-v3[a75d] hardware version 5 [ 2.672743] intel_ipu6_isys: loading out-of-tree module taints kernel. [ 2.672778] intel_ipu6_isys: module verification failed: signature and/or required key missing - tainting kernel [ 2.711217] intel_ipu6_psys.psys intel_ipu6.psys.40: pkg_dir entry count:8 [ 2.713832] intel_ipu6_psys.psys intel_ipu6.psys.40: psys probe minor: 0 NOTE: there is NO "isys probe minor" line. The ISYS subdriver binds to the intel_ipu6.isys.40 auxiliary device but the probe never logs completion and no ISYS firmware (ipu6ep_fw.bin, shisp_2401a0_v21.bin) is ever requested or loaded. Compare with healthy systems where dmesg shows: intel_ipu6_isys.isys intel_ipu6.isys.40: isys probe minor: 0 intel-ipu6 0000:00:05.0: Loading IPU6 ISYS firmware: ipu6ep_fw.bin intel-ipu6 0000:00:05.0: Loading IPU6 ISP firmware: shisp_2401a0_v21.bin None of those lines appear. [LSPCI -vvv -s 00:05.0] 00:05.0 Multimedia controller: Intel Corporation Device a75d DeviceName: Onboard - Sound Subsystem: Samsung Electronics Co Ltd Device c1ca Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 IOMMU group: 0 Region 0: Memory at 603c000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: intel-ipu6 Kernel modules: intel_ipu6 [MEDIA TOPOLOGY] media controller API version 7.0.12 driver: intel-ipu6 model: ipu6 bus info: PCI:0000:00:05.0 hw revision: 0x144dc1ca 32 ISYS Capture nodes (/dev/video5..7, 9..13, 17, 23, 27, 28 exposed by driver; /dev/video0 is v4l2loopback; /dev/video1, 2, 3, 4, 8, 14..16, 18..22, 24..26, 29..32 exist but Driver not in use). 4 CSI-2 receiver subdevs (/dev/v4l-subdev0..3). 1 sensor subdev: /dev/v4l-subdev4 = ov02c10 0-0036, pad0 Source -> "Intel IPU6 CSI2 0":0 [ENABLED, IMMUTABLE] pad fmt: SGRBG10_1X10/1928x1092 field:none, link_freq=400 MHz, pixel_rate=80 MHz The CSI-2 receivers report fmt SGRBG10_1X10/4096x3072 (default, unconfigured). [REPRODUCTION] 1. Boot kernel 7.0.0-30-generic (Zorin OS 18.1 / Ubuntu 24.04 HWE). 2. sudo modprobe intel-ipu6 intel-ipu6-isys intel-ipu6-psys ov02c10 3. ls /dev/video* -> 33 nodes appear 4. v4l2-ctl -d /dev/video10 --stream-mmap=4 --stream-count=5 --stream-to=/tmp/test.raw -> "VIDIOC_STREAMON returned -1 (Link has been severed)" 5. File is empty (size 0). No frames captured. 6. Same result with gst-launch-1.0 v4l2src ! fakesink, with icamerasrc, with any other ISYS Capture node. [WHAT WAS TRIED] - linux-modules-ipu6-generic-7.0 (Ubuntu in-kernel): same failure - intel-ipu6-dkms 51fe7248 (PPA Zorin, upstream Intel): same failure - Upstream intel/ipu6-drivers @ main with manual DWC PHY HSFREQRANGE patch (commit 1f025c6, "Improve DWC PHY HSFREQRANGE band selection"): same failure - Firmware formats: .zst vs decompressed .bin, no change - HAL libcamhal-ipu6ep + gstreamer1.0-icamera: fails with "CamHAL[ERR] Stream config is not supported. format:V4L2_PIX_FMT_NV12 (1920x1080)" because HAL loads AIQB AR0234_TGL_10bits.aiqb which is for a different sensor - v4l2-ctl --set-fmt on ISYS Capture nodes: works for format negotiation but STREAMON still fails with ENOLINK - media-ctl -V: subdevs reject VIDIOC_SUBDEV_S_FMT ("Inappropriate ioctl") - modprobe bind/unbind, soft reset: no change - Power management: D3 NoSoftRst+ in lspci (PME disabled), no S0ix issues seen [EXPECTED] The ISYS subdriver should boot, load ipu6ep_fw.bin and shisp_2401a0_v21.bin, negotiate the CSI-2 link with the OV02C1 sensor, and STREAMON on a Capture node should return success, producing NV12 1920x1080 frames at 30 fps via the HAL or raw Bayer via V4L2. [WORKAROUNDS] None known for this hardware on kernel 7.0. External USB webcam is the only functional option today. [ADDITIONAL INFO] - Related issues: intel/ipu6-drivers#329 (Galaxy Book4 Pro 360, similar), #369 - The ISYS auxiliary device (intel_ipu6.isys.40) is created and bound to intel_ipu6_isys.isys driver, but the probe function either returns silently or fails before logging. - The PSYS auxiliary device (intel_ipu6.psys.40) probes and registers /dev/ipu-psys0 correctly. - Both the in-kernel driver and the DKMS share the same code path and fail at the same point, suggesting the issue is not in the driver glue but in the ISYS firmware boot sequence or in the hardware interaction. - The DWC PHY HSFREQRANGE patch (upstream commit 1f025c6) targets Arrow Lake / OV08X40, not RPL / OV02C1; the symptom (DDL lock instability) may not apply to this configuration. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: ipu6 kernel-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165854 Title: IPU6 ISYS never probes on Samsung Galaxy Book NP960QFG (RPL, OV02C1) Status in linux package in Ubuntu: New Bug description: [IMPACT] Webcam integrated on Samsung Galaxy Book NP960QFG-KA1AR is non-functional on Zorin OS 18.1 / Ubuntu 24.04 with kernel 7.0.0-30-generic. Driver loads PCI device, detects sensor, registers PSYS, but ISYS never completes probe and no firmware is loaded. Every V4L2 STREAMON returns ENOLINK ("Link has been severed"). [HARDWARE] Vendor: Samsung Electronics Co Ltd Model: Galaxy Book NP960QFG-KA1AR (RPL, 12th/13th gen) Subsystem: c1ca CPU: Intel Raptor Lake-P (Host bridge 0xa707) PCI device: 0000:00:05.0 Multimedia controller [0480] Intel Corporation Device a75d (IPU6-v3, hardware version 5) Sensor: OVTI02C1:00 (Omnivision OV02C1) on i2c-0 address 0x36 Lens cover: samsung-galaxybook SAM0429:00, currently open (not blocking) BIOS: P07ALN.260.240415.SH (Samsung) Secure Boot: disabled [SOFTWARE] Distro: Zorin OS 18.1 (based on Ubuntu 24.04 noble) Kernel: 7.0.0-30-generic (HWE) Kernel alt: 6.17.0-35-generic also installed in /boot Init system: systemd [PACKAGES] intel-ipu6-dkms 0~git202603270946.51fe7248-0ubuntu1+zorin1 libcamhal-common 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal-ipu6ep 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal-ipu6ep-common 0~git202601200757.9899efa~ubuntu24.04.3 libcamhal0 0~git202601200757.9899efa~ubuntu24.04.3 gstreamer1.0-icamera 0~git202509260937.4fb31db~ubuntu24.04.9 linux-modules-ipu6-7.0.0-30-generic 7.0.0-30.30~24.04.1 linux-modules-ipu6-generic-7.0 7.0.0-30.30~24.04.1 v4l2loopback-dkms 0.15.3-1ubuntu2+zorin1 v4l2-relayd 0.1.2-0ubuntu3.1 [FIRMWARE] /lib/firmware/intel/ipu/ipu6ep_fw.bin (467 KB, decompressed from .zst) /lib/firmware/intel/ipu/shisp_2401a0_v21.bin (12 MB, decompressed from .zst) /lib/firmware/intel/ipu/ipu6ep_fw.bin.zst (original) /lib/firmware/intel/ipu/shisp_2401a0_v21.bin.zst (original) Other ipu6 firmwares: ipu6epadln, ipu6epmtl, ipu6, ipu6se, ipu7, ipu7ptl, irci [DMESG OUTPUT (filtered to intel-ipu* and related)] [ 2.633510] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) [ 2.642939] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 [ 2.643149] intel-ipu6 0000:00:05.0: Connected 1 cameras [ 2.644075] intel-ipu6 0000:00:05.0: IPU6-v3[a75d] hardware version 5 [ 2.672743] intel_ipu6_isys: loading out-of-tree module taints kernel. [ 2.672778] intel_ipu6_isys: module verification failed: signature and/or required key missing - tainting kernel [ 2.711217] intel_ipu6_psys.psys intel_ipu6.psys.40: pkg_dir entry count:8 [ 2.713832] intel_ipu6_psys.psys intel_ipu6.psys.40: psys probe minor: 0 NOTE: there is NO "isys probe minor" line. The ISYS subdriver binds to the intel_ipu6.isys.40 auxiliary device but the probe never logs completion and no ISYS firmware (ipu6ep_fw.bin, shisp_2401a0_v21.bin) is ever requested or loaded. Compare with healthy systems where dmesg shows: intel_ipu6_isys.isys intel_ipu6.isys.40: isys probe minor: 0 intel-ipu6 0000:00:05.0: Loading IPU6 ISYS firmware: ipu6ep_fw.bin intel-ipu6 0000:00:05.0: Loading IPU6 ISP firmware: shisp_2401a0_v21.bin None of those lines appear. [LSPCI -vvv -s 00:05.0] 00:05.0 Multimedia controller: Intel Corporation Device a75d DeviceName: Onboard - Sound Subsystem: Samsung Electronics Co Ltd Device c1ca Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 IOMMU group: 0 Region 0: Memory at 603c000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: intel-ipu6 Kernel modules: intel_ipu6 [MEDIA TOPOLOGY] media controller API version 7.0.12 driver: intel-ipu6 model: ipu6 bus info: PCI:0000:00:05.0 hw revision: 0x144dc1ca 32 ISYS Capture nodes (/dev/video5..7, 9..13, 17, 23, 27, 28 exposed by driver; /dev/video0 is v4l2loopback; /dev/video1, 2, 3, 4, 8, 14..16, 18..22, 24..26, 29..32 exist but Driver not in use). 4 CSI-2 receiver subdevs (/dev/v4l-subdev0..3). 1 sensor subdev: /dev/v4l-subdev4 = ov02c10 0-0036, pad0 Source -> "Intel IPU6 CSI2 0":0 [ENABLED, IMMUTABLE] pad fmt: SGRBG10_1X10/1928x1092 field:none, link_freq=400 MHz, pixel_rate=80 MHz The CSI-2 receivers report fmt SGRBG10_1X10/4096x3072 (default, unconfigured). [REPRODUCTION] 1. Boot kernel 7.0.0-30-generic (Zorin OS 18.1 / Ubuntu 24.04 HWE). 2. sudo modprobe intel-ipu6 intel-ipu6-isys intel-ipu6-psys ov02c10 3. ls /dev/video* -> 33 nodes appear 4. v4l2-ctl -d /dev/video10 --stream-mmap=4 --stream-count=5 --stream-to=/tmp/test.raw -> "VIDIOC_STREAMON returned -1 (Link has been severed)" 5. File is empty (size 0). No frames captured. 6. Same result with gst-launch-1.0 v4l2src ! fakesink, with icamerasrc, with any other ISYS Capture node. [WHAT WAS TRIED] - linux-modules-ipu6-generic-7.0 (Ubuntu in-kernel): same failure - intel-ipu6-dkms 51fe7248 (PPA Zorin, upstream Intel): same failure - Upstream intel/ipu6-drivers @ main with manual DWC PHY HSFREQRANGE patch (commit 1f025c6, "Improve DWC PHY HSFREQRANGE band selection"): same failure - Firmware formats: .zst vs decompressed .bin, no change - HAL libcamhal-ipu6ep + gstreamer1.0-icamera: fails with "CamHAL[ERR] Stream config is not supported. format:V4L2_PIX_FMT_NV12 (1920x1080)" because HAL loads AIQB AR0234_TGL_10bits.aiqb which is for a different sensor - v4l2-ctl --set-fmt on ISYS Capture nodes: works for format negotiation but STREAMON still fails with ENOLINK - media-ctl -V: subdevs reject VIDIOC_SUBDEV_S_FMT ("Inappropriate ioctl") - modprobe bind/unbind, soft reset: no change - Power management: D3 NoSoftRst+ in lspci (PME disabled), no S0ix issues seen [EXPECTED] The ISYS subdriver should boot, load ipu6ep_fw.bin and shisp_2401a0_v21.bin, negotiate the CSI-2 link with the OV02C1 sensor, and STREAMON on a Capture node should return success, producing NV12 1920x1080 frames at 30 fps via the HAL or raw Bayer via V4L2. [WORKAROUNDS] None known for this hardware on kernel 7.0. External USB webcam is the only functional option today. [ADDITIONAL INFO] - Related issues: intel/ipu6-drivers#329 (Galaxy Book4 Pro 360, similar), #369 - The ISYS auxiliary device (intel_ipu6.isys.40) is created and bound to intel_ipu6_isys.isys driver, but the probe function either returns silently or fails before logging. - The PSYS auxiliary device (intel_ipu6.psys.40) probes and registers /dev/ipu-psys0 correctly. - Both the in-kernel driver and the DKMS share the same code path and fail at the same point, suggesting the issue is not in the driver glue but in the ISYS firmware boot sequence or in the hardware interaction. - The DWC PHY HSFREQRANGE patch (upstream commit 1f025c6) targets Arrow Lake / OV08X40, not RPL / OV02C1; the symptom (DDL lock instability) may not apply to this configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165854/+subscriptions

[Bug 2165844] [NEW] linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write

Public bug reported: [Summary] Any buffered write() to an ntfs3-mounted volume can hit a BUG_ON in the generic iomap write path and panic the kernel. An unprivileged process (rsync, uid 1000) took the whole machine down; the system froze instantly, then kdump rebooted into the capture kernel. [Impact] This is reachable from unprivileged userspace with a plain write(2) syscall. Whatever the state of the NTFS volume, the correct outcome is -EIO returned to the caller, not a kernel panic. Reproducing it needs nothing but a writable NTFS mount, which udisks/GNOME Files creates by default when a user clicks a Windows partition. [Environment] Ubuntu 26.04, linux-image-7.0.0-30-generic 7.0.0-30.30, x86_64 ASUS ROG STRIX B550-XE GAMING WIFI, BIOS 3607 NTFS volume: 1.8 TB Windows system partition, mounted read-write by udisks (driver ntfs3, POSIX ACLs enabled) [What happened] Writing to the NTFS mount, the kernel hit the assertion and died: kernel BUG at fs/iomap/buffered-io.c:1061! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 1000 PID: 18561 Comm: rsync Kdump: loaded Tainted: G O Hardware name: ASUS System Product Name/ROG STRIX B550-XE GAMING WIFI RIP: 0010:iomap_write_end+0x1e0/0x1f0 Call Trace: iomap_write_iter+0x171/0x340 iomap_file_buffered_write+0xa6/0x110 ntfs_file_write_iter+0x267/0x310 [ntfs3] vfs_write+0x25b/0x490 ksys_write+0x71/0xf0 __x64_sys_write+0x19/0x30 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The faulting syscall was a 137-byte write(2) to fd 1 (ORIG_RAX 0x1, RDX 0x89) — an ordinary small buffered write, not anything exotic. The G/O taint is the out-of-tree NVIDIA module (595.84). It is unrelated to this code path; ntfs3, iomap and the write path are all in-tree. [Preceding symptom] About 14 minutes before the panic, ntfs3 logged a large burst of metadata repairs on the same volume: ntfs3(nvme0n1p2): ino=..., Correct links count -> N ntfs3: 15286 callbacks suppressed So the volume was not perfectly clean. That may well be what steers the write path into the bad state — but an inconsistent filesystem must not be able to panic the kernel, so it looks like a missing error path rather than a disk problem. [Reproducer] Not deterministic here, but the shape is simple: 1. Mount an NTFS volume read-write with ntfs3 (udisksctl mount is enough). 2. Run sustained buffered I/O against it (rsync of a large tree). The other reports linked below describe the same trace from ordinary file writes, including games writing save data. [Already reported elsewhere] Same trace, same line, on 7.0.x kernels since roughly April 2026: - https://github.com/CachyOS/linux-cachyos/issues/841 - https://discuss.cachyos.org/t/kernel-bug-in-iomap-write-end-triggered-by-ntfs3-buffered-write-linux-7-0-1-cachyos/28546 - https://bbs.archlinux.org/viewtopic.php?pid=2296728 - https://forum.manjaro.org/t/total-system-hangs-and-fs-iomap-kernel-panic-on-7-0-10-stable-on-6-18-lts/188283 I could not find an upstream fix. Upstream appears to be replacing ntfs3 with the new ntfsplus driver in 7.1 rather than fixing this one. [Suggestion for Ubuntu] Since 26.04 ships 7.0 and a user can trigger a kernel panic by copying files onto a Windows partition from the file manager, it may be worth either backporting a fix or having udisks default NTFS mounts to read-only until 7.1 lands via HWE. [Attached] Full kernel ring buffer from the kdump vmcore (VmCoreDmesg), plus the usual apport-collected hardware and package data. Sanitisation applied before upload: firewall log lines were dropped, and MAC addresses, the wireless BSSID/SSID and LAN IPv4 addresses were replaced with placeholders in VmCoreDmesg, CurrentDmesg and WifiSyslog. Nothing else was altered; the panic trace is untouched. An incomplete vmcore (2.3 GB, truncated because the machine was power-cycled during the dump) is available if it would help. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Sun Aug 30 11:45:03 2026 InstallationDate: Installed on 2026-07-12 (49 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name PackageArchitecture: amd64 ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=5778b2dd-b496-4525-b52f-223e5be557bc ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux Title: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True dmi.bios.date: 03/18/2024 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3607 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX B550-XE GAMING WIFI dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3607:bd03/18/2024:br5.17:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXB550-XEGAMINGWIFI:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug iomap kernel-bug ntfs3 resolute -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165844 Title: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write Status in linux package in Ubuntu: New Bug description: [Summary] Any buffered write() to an ntfs3-mounted volume can hit a BUG_ON in the generic iomap write path and panic the kernel. An unprivileged process (rsync, uid 1000) took the whole machine down; the system froze instantly, then kdump rebooted into the capture kernel. [Impact] This is reachable from unprivileged userspace with a plain write(2) syscall. Whatever the state of the NTFS volume, the correct outcome is -EIO returned to the caller, not a kernel panic. Reproducing it needs nothing but a writable NTFS mount, which udisks/GNOME Files creates by default when a user clicks a Windows partition. [Environment] Ubuntu 26.04, linux-image-7.0.0-30-generic 7.0.0-30.30, x86_64 ASUS ROG STRIX B550-XE GAMING WIFI, BIOS 3607 NTFS volume: 1.8 TB Windows system partition, mounted read-write by udisks (driver ntfs3, POSIX ACLs enabled) [What happened] Writing to the NTFS mount, the kernel hit the assertion and died: kernel BUG at fs/iomap/buffered-io.c:1061! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 1000 PID: 18561 Comm: rsync Kdump: loaded Tainted: G O Hardware name: ASUS System Product Name/ROG STRIX B550-XE GAMING WIFI RIP: 0010:iomap_write_end+0x1e0/0x1f0 Call Trace: iomap_write_iter+0x171/0x340 iomap_file_buffered_write+0xa6/0x110 ntfs_file_write_iter+0x267/0x310 [ntfs3] vfs_write+0x25b/0x490 ksys_write+0x71/0xf0 __x64_sys_write+0x19/0x30 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The faulting syscall was a 137-byte write(2) to fd 1 (ORIG_RAX 0x1, RDX 0x89) — an ordinary small buffered write, not anything exotic. The G/O taint is the out-of-tree NVIDIA module (595.84). It is unrelated to this code path; ntfs3, iomap and the write path are all in-tree. [Preceding symptom] About 14 minutes before the panic, ntfs3 logged a large burst of metadata repairs on the same volume: ntfs3(nvme0n1p2): ino=..., Correct links count -> N ntfs3: 15286 callbacks suppressed So the volume was not perfectly clean. That may well be what steers the write path into the bad state — but an inconsistent filesystem must not be able to panic the kernel, so it looks like a missing error path rather than a disk problem. [Reproducer] Not deterministic here, but the shape is simple: 1. Mount an NTFS volume read-write with ntfs3 (udisksctl mount is enough). 2. Run sustained buffered I/O against it (rsync of a large tree). The other reports linked below describe the same trace from ordinary file writes, including games writing save data. [Already reported elsewhere] Same trace, same line, on 7.0.x kernels since roughly April 2026: - https://github.com/CachyOS/linux-cachyos/issues/841 - https://discuss.cachyos.org/t/kernel-bug-in-iomap-write-end-triggered-by-ntfs3-buffered-write-linux-7-0-1-cachyos/28546 - https://bbs.archlinux.org/viewtopic.php?pid=2296728 - https://forum.manjaro.org/t/total-system-hangs-and-fs-iomap-kernel-panic-on-7-0-10-stable-on-6-18-lts/188283 I could not find an upstream fix. Upstream appears to be replacing ntfs3 with the new ntfsplus driver in 7.1 rather than fixing this one. [Suggestion for Ubuntu] Since 26.04 ships 7.0 and a user can trigger a kernel panic by copying files onto a Windows partition from the file manager, it may be worth either backporting a fix or having udisks default NTFS mounts to read-only until 7.1 lands via HWE. [Attached] Full kernel ring buffer from the kdump vmcore (VmCoreDmesg), plus the usual apport-collected hardware and package data. Sanitisation applied before upload: firewall log lines were dropped, and MAC addresses, the wireless BSSID/SSID and LAN IPv4 addresses were replaced with placeholders in VmCoreDmesg, CurrentDmesg and WifiSyslog. Nothing else was altered; the panic trace is untouched. An incomplete vmcore (2.3 GB, truncated because the machine was power-cycled during the dump) is available if it would help. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Sun Aug 30 11:45:03 2026 InstallationDate: Installed on 2026-07-12 (49 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name PackageArchitecture: amd64 ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=5778b2dd-b496-4525-b52f-223e5be557bc ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux Title: linux 7.0.0-30: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end() on ntfs3 buffered write UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True dmi.bios.date: 03/18/2024 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3607 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX B550-XE GAMING WIFI dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3607:bd03/18/2024:br5.17:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXB550-XEGAMINGWIFI:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165844/+subscriptions