Additional finding: the workaround also works when applied at runtime, without rebooting or changing the hardware request limit.
On Ubuntu 26.04 (kernel 7.0.0-30-generic), booted without additional kernel parameters: Before: max_sectors_kb = 4096 max_hw_sectors_kb = 32767 Applied: echo 1280 > /sys/block/sda/queue/max_sectors_kb After: max_sectors_kb = 1280 max_hw_sectors_kb = 32767 (unchanged) The identical buffered fio test then completed successfully (16 GiB, no I/O errors, no new SATA CRC errors). Initially, the SATA link had downshifted to 1.5 Gb/s following the previous failures. To exclude this as a contributing factor, I repeated the test after a complete power cycle. With the SATA link operating at its full 6.0 Gb/s speed, the runtime workaround again passed: 16 GiB written in 68.5 seconds (239 MiB/s) fio err=0 No kernel I/O errors SMART UDMA_CRC_Error_Count unchanged (44 -> 44) This confirms that reducing max_sectors_kb alone is sufficient to avoid the observed failures under this workload, even at full SATA link speed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2171415 Title: [Regression] Intel H97 SATA I/O errors and DMAR faults with kernel 7.0, avoided by libata.force=max_sec=2560 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2171415/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
