[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

[Bug 2067498] Re: Can't control display backlight in 24.04 on Dell AIO system

With 26.04 or 26.04.1, does adding the "quiet splash i915.enable_dpcd_backlight=0" kernel parameter in /etc/default/grub instead of "quiet splash" makes a difference ? -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2067498 Title: Can't control display backlight in 24.04 on Dell AIO system Status in linux package in Ubuntu: Confirmed Bug description: Ubuntu 23.10/24.04 Dell Inspiron 7700 AIO 6.5.0-35-generic/6.8.0-31-generic X11 https://askubuntu.com/questions/1514988/backlight-brightness-not- working-in-ubuntu-23-10-24-04-on-dell-7700-aio lsb_release -rd No LSB modules are available. Description: Ubuntu 24.04 LTS Release: 24.04 dell-uart-backlight kernel driver isn't in the 24.04 distribution, so NO Dell AIO display backlights can be adjusted. No brightness slider appears. (dell-uart-backlight is in the 23.10 distribution, but backlight/brightness slider control doesn't work 100% properly). Works fine in 23.04. ls -alR /lib/modules/6.5.0-35-generic/ | grep dell -rw-r--r-- 1 root root 13689 Apr 26 02:32 dell-smm-hwmon.ko.zst drwxr-xr-x 3 root root 4096 May 15 19:10 dell /lib/modules/6.5.0-35-generic/kernel/drivers/platform/x86/dell: -rw-r--r-- 1 root root 18647 Apr 26 02:32 dell-laptop.ko.zst -rw-r--r-- 1 root root 6158 Apr 26 02:32 dell-rbtn.ko.zst -rw-r--r-- 1 root root 8431 Apr 26 02:32 dell_rbu.ko.zst -rw-r--r-- 1 root root 13963 Apr 26 02:32 dell-smbios.ko.zst -rw-r--r-- 1 root root 4432 Apr 26 02:32 dell-smo8800.ko.zst -rw-r--r-- 1 root root 7762 Apr 26 02:32 dell-uart-backlight.ko.zst -rw-r--r-- 1 root root 3799 Apr 26 02:32 dell-wmi-aio.ko.zst -rw-r--r-- 1 root root 9209 Apr 26 02:32 dell-wmi-ddv.ko.zst -rw-r--r-- 1 root root 4532 Apr 26 02:32 dell-wmi-descriptor.ko.zst -rw-r--r-- 1 root root 11198 Apr 26 02:32 dell-wmi.ko.zst -rw-r--r-- 1 root root 3115 Apr 26 02:32 dell-wmi-led.ko.zst drwxr-xr-x 2 root root 4096 May 15 19:10 dell-wmi-sysman /lib/modules/6.5.0-35-generic/kernel/drivers/platform/x86/dell/dell-wmi-sysman: -rw-r--r-- 1 root root 18312 Apr 26 02:32 dell-wmi-sysman.ko.zst ls -alR /lib/modules/6.8.0-31-generic/ | grep dell -rw-r--r-- 1 root root 15140 Apr 19 14:46 dell-smm-hwmon.ko.zst drwxr-xr-x 3 root root 4096 May 25 10:15 dell /lib/modules/6.8.0-31-generic/kernel/drivers/platform/x86/dell: -rw-r--r-- 1 root root 18629 Apr 19 14:46 dell-laptop.ko.zst -rw-r--r-- 1 root root 6180 Apr 19 14:46 dell-rbtn.ko.zst -rw-r--r-- 1 root root 8582 Apr 19 14:46 dell_rbu.ko.zst -rw-r--r-- 1 root root 14726 Apr 19 14:46 dell-smbios.ko.zst -rw-r--r-- 1 root root 4433 Apr 19 14:46 dell-smo8800.ko.zst -rw-r--r-- 1 root root 3790 Apr 19 14:46 dell-wmi-aio.ko.zst -rw-r--r-- 1 root root 9166 Apr 19 14:46 dell-wmi-ddv.ko.zst -rw-r--r-- 1 root root 4492 Apr 19 14:46 dell-wmi-descriptor.ko.zst -rw-r--r-- 1 root root 11306 Apr 19 14:46 dell-wmi.ko.zst -rw-r--r-- 1 root root 3108 Apr 19 14:46 dell-wmi-led.ko.zst drwxr-xr-x 2 root root 4096 May 25 10:15 dell-wmi-sysman /lib/modules/6.8.0-31-generic/kernel/drivers/platform/x86/dell/dell-wmi-sysman: -rw-r--r-- 1 root root 18307 Apr 19 14:46 dell-wmi-sysman.ko.zst dup: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2067497 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-31-generic 6.8.0-31.31 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.1-0ubuntu3 Architecture: amd64 AudioDevicesInUse:  USER PID ACCESS COMMAND  /dev/snd/seq: al 3689 F.... pipewire  /dev/snd/controlC1: al 3696 F.... wireplumber  /dev/snd/controlC0: al 3696 F.... wireplumber CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed May 29 08:32:16 2024 InstallationDate: Installed on 2021-09-25 (978 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Dell Inc. Inspiron 7700 AIO ProcEnviron:  LANG=en_US.UTF-8  PATH=(custom, no user)  SHELL=/bin/bash  TERM=xterm-256color  XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=UUID=f0db2226-e28d-46dd-9b5a-457c87987ed2 ro quiet splash ipv6.disable=1 acpi_backlight=vendor acpi_osi=Linux vt.handoff=7 RelatedPackageVersions:  linux-restricted-modules-6.8.0-31-generic N/A  linux-backports-modules-6.8.0-31-generic N/A  linux-firmware 20240318.git3b128b60-0ubuntu2 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2024-05-25 (4 days ago) dmi.bios.date: 03/27/2024 dmi.bios.release: 1.28 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.28.0 dmi.board.name: 0K9T56 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 13 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.28.0:bd03/27/2024:br1.28:svnDellInc.:pnInspiron7700AIO:pvr:rvnDellInc.:rn0K9T56:rvrA00:cvnDellInc.:ct13:cvr:sku0A07: dmi.product.family: Inspiron dmi.product.name: Inspiron 7700 AIO dmi.product.sku: 0A07 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2067498/+subscriptions

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

I also made a kernel image base on Ko boon Lin's comments #10, https://ratatoskr.run/linux-scsi/2026/03/6765435 https://drive.google.com/file/d/11jqds5MYkHfl0faO1FlfhJYNVfFf8Iqk/view?usp=drive_link, Yuri Zhang Could you like try both of them kernel. In fact, both of fix looks good. but need a real test to confirm. -- 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 2165806] Re: Ubuntu 26.04.1 Server ISO cannot install on MAXIO MAP1602 NVMe due to kernel 7.0.0-30 I/O regression; 7.0.0-31 works

** 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/2165806 Title: Ubuntu 26.04.1 Server ISO cannot install on MAXIO MAP1602 NVMe due to kernel 7.0.0-30 I/O regression; 7.0.0-31 works Status in linux package in Ubuntu: New Bug description: Ubuntu 26.04.1 Server cannot be installed on an ACEMAGIC M1A PRO+ with its factory HOGE H820 2 TB / MAXIO MAP1602 NVMe SSD. The Ubuntu 26.04.1 live-server ISO boots kernel 7.0.0-30. With this kernel, reproducible NVMe READ and WRITE failures occur during installation, and the installation eventually fails during grub-install. The same physical machine, SSD, M.2 slot, and SSD firmware operate normally with kernels 7.0.0-14, 6.8, 6.14, and 7.0.0-31. The regression is also independently reproducible on installed Ubuntu 24.04 and Ubuntu 26.04 systems by switching between 7.0.0-30 and 7.0.0-31. PRIMARY IMPACT The current Ubuntu 26.04.1 Server ISO cannot complete installation on this hardware. During installation, kernel 7.0.0-30 reports NVMe block I/O failures. The installer then eventually fails with: grub-install: error: cannot copy '/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to '/boot/efi/EFI/ubuntu/grubx64.efi': Invalid argument. The grub-install failure occurs in the same installation in which the kernel is reporting NVMe READ/WRITE failures. I believe the storage regression is likely contributing to the grub-install failure, but I have not independently proven that the NVMe errors are the direct cause of the grub-install error. HARDWARE System: ACEMAGIC M1A PRO+ AMD Ryzen AI Max+ 395 AMD Radeon 8060S 128 GB memory, 8000 MT/s BIOS: American Megatrends Project version: P10_F11_20_IEC0008_BI0010_AMI_120W Build date: 2026-01-13 NVMe: Model: HOGE H820 2TB Firmware: H240313a PCI vendor ID: 0x1e4b PCI device/controller: 0x1602 Controller family: MAXIO MAP1602 NVMe SMART data observed during troubleshooting: critical_warning: 0 available_spare: 100% percentage_used: 0% media_errors: 0 num_err_log_entries: 0 temperature: approximately 39 C UBUNTU 26.04.1 SERVER INSTALL FAILURE Installation method: - Ubuntu 26.04.1 live-server ISO - ISO written directly to USB using dd - UEFI boot - Secure Boot disabled - entire NVMe disk - no LVM - ext4 root filesystem - 1 GiB FAT EFI System Partition The installer successfully partitions the disk, creates the filesystems, and mounts the target. During installation, kernel 7.0.0-30 begins producing NVMe block I/O failures. Examples of WRITE failures observed: invalid error, dev nvme0n1, sector 11896 op 0x1:(WRITE) ... invalid error, dev nvme0n1, sector 2080 op 0x1:(WRITE) ... followed by messages including: Buffer I/O error on dev nvme0n1p1, logical block 32, lost async page write Buffer I/O error on dev nvme0n1p1, logical block 33, lost async page write Buffer I/O error on dev nvme0n1p1, logical block 34, lost async page write READ failures were also observed, including: invalid error, dev nvme0n1, sector 3104 op 0x0:(READ) ... invalid error, dev nvme0n1, sector 3144 op 0x0:(READ) ... invalid error, dev nvme0n1, sector 3184 op 0x0:(READ) ... ... invalid error, dev nvme0n1, sector 3480 op 0x0:(READ) ... The failing READ requests repeatedly showed multi-segment I/O, including phys_seg 33. Installation ultimately fails at grub-install with: grub-install: error: cannot copy '/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to '/boot/efi/EFI/ubuntu/grubx64.efi': Invalid argument. The Ubuntu installer offered to send an error report to Canonical after the failure, and I selected that option. Therefore an installer-side failure report from this machine should already exist in Canonical's error-reporting infrastructure, although I do not currently have an identifier for that report. REGRESSION TESTING All of the following tests used the same physical ACEMAGIC M1A PRO+, same HOGE H820 SSD, same M.2 slot, and same SSD firmware. Ubuntu 26.04 ------------ 1. Ubuntu 26.04 base installation, kernel 7.0.0-14 PASS Ubuntu 26.04 installs and boots successfully. No NVMe "invalid error", Buffer I/O errors, or related read/write failures are present. 2. Upgrade the installed Ubuntu 26.04 system to kernel 7.0.0-30 FAIL The same NVMe "invalid error" messages return. 3. Upgrade the same Ubuntu 26.04 installation from 7.0.0-30 to 7.0.0-31 from ppa:canonical-kernel-team/ppa PASS The NVMe errors disappear again. Ubuntu 26.04.1 live-server ISO ------------------------------ 4. Ubuntu 26.04.1 live-server ISO, kernel 7.0.0-30 FAIL The same NVMe READ/WRITE errors occur during installation. Unlike the Ubuntu 24.04.4 installer case below, the failures are severe enough here that grub-install fails and Ubuntu 26.04.1 Server cannot be installed. Ubuntu 24.04 ------------ 5. Ubuntu 24.04.4 installation using kernel 7.0.0-30 KERNEL REGRESSION PRESENT, BUT INSTALLATION COMPLETES Ubuntu 24.04.4 installs successfully. After boot, the same NVMe "invalid error" messages are present in the kernel logs. Thus the storage regression is present with 7.0.0-30 on Ubuntu 24.04 as well, even though that installer happens to complete. 6. Downgrade the same Ubuntu 24.04 system to kernel 6.8 PASS The NVMe errors disappear. Sustained fio testing completes without NVMe errors. The Radeon 8060S does not initialize correctly on this older kernel, which is unrelated to the NVMe regression. 7. Upgrade the same Ubuntu 24.04 system to kernel 6.14 PASS NVMe remains clean. Radeon 8060S / amdgpu initializes successfully. Sustained fio testing completes without NVMe errors. 8. Upgrade the same Ubuntu 24.04 system to kernel 7.0.0-31 from ppa:canonical-kernel-team/ppa PASS NVMe errors remain absent. A 10-minute mixed direct-I/O fio workload using libaio, iodepth=32, numjobs=4, and direct=1 completes without NVMe errors. SUMMARY Ubuntu 26.04 + 7.0.0-14 -> PASS Ubuntu 26.04 + 7.0.0-30 -> FAIL Ubuntu 26.04 + 7.0.0-31 -> PASS Ubuntu 26.04.1 ISO + -30 -> FAIL, installation cannot complete Ubuntu 24.04.4 + 7.0.0-30 -> regression present, install completes Ubuntu 24.04 + 6.8 -> PASS Ubuntu 24.04 + 6.14 -> PASS Ubuntu 24.04 + 7.0.0-31 -> PASS The -30 -> -31 comparison has been reproduced on both Ubuntu 24.04 and Ubuntu 26.04. This strongly isolates the problem to the kernel code present in 7.0.0-30 and absent/fixed in 7.0.0-31, rather than to the Ubuntu userspace release or SSD hardware. APST TESTING NVMe APST was tested as a possible cause. The Ubuntu 26.04.1 installer was booted with: nvme_core.default_ps_max_latency_us=0 The runtime value was verified as: /sys/module/nvme_core/parameters/default_ps_max_latency_us = 0 The same NVMe WRITE / Buffer I/O errors still occurred. Disabling NVMe APST therefore does not resolve the failure. STORAGE VALIDATION The SSD does not appear to contain defective media at the sector range where errors were reported. On a working kernel, a direct read spanning the affected region completed successfully: dd if=/dev/nvme0n1 of=/dev/null bs=512 skip=3000 count=600 iflag=direct 600+0 records in 600+0 records out No new NVMe errors were produced. The same SSD also completed substantial mixed read/write fio testing on working kernels without media errors or kernel block-I/O failures. This included sustained testing on: - 6.8 - 6.14 - 7.0.0-31 LIKELY UPSTREAM REGRESSION / FIX I have not performed a source-level git bisect, so the following is a suspected cause rather than independently proven. Linux 7.0.11 included: iommupt: Avoid rewalking during map upstream commit: d6c65b0fd6218bd21ed0be7a8d3218e8f6dc91de Linux 7.0.13 later included: iommu/dma: Do not try to iommu_map a 0 length region in swiotlb upstream commit: 6ec91df8aff77e2e8fe3179c1f3fc15b43a40ba3 The latter fix describes an IOMMU DMA mapping path in which an unaligned mapping can produce a zero-length middle region. iommu_map() then rejects the zero-length mapping as illegal. The upstream description explicitly notes NVMe as a frequent trigger because NVMe can issue unusually aligned buffers in some paths. Ubuntu kernel 7.0.0-31 contains the Linux 7.0.13 and 7.0.14 upstream stable updates, and 7.0.0-31 is the first tested Ubuntu 7.0 kernel in this environment where the problem disappears. Given the observed: 7.0.0-30 -> FAIL 7.0.0-31 -> PASS and the I/O errors being reported as "invalid error", this IOMMU/DMA fix appears to be a strong candidate for the fix. Please confirm whether this system is hitting that regression, or another change incorporated between Ubuntu 7.0.0-30 and 7.0.0-31. EXPECTED RESULT Ubuntu 26.04.1 Server should install successfully on this hardware. The HOGE H820 / MAXIO MAP1602 NVMe controller should operate without kernel block-I/O failures. IMPACT The practical issue is not merely log noise. The kernel shipped on the Ubuntu 26.04.1 Server ISO causes storage errors during installation and prevents the current 26.04.1 live-server image from completing installation on this system. The same regression can also be reproduced after installation by booting 7.0.0-30 on both Ubuntu 24.04 and Ubuntu 26.04. Kernel 7.0.0-31 from ppa:canonical-kernel-team/ppa does not reproduce the problem on either release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165806/+subscriptions