Kernel 7.0.14-23 boot failure: ata5 host bus error, ZFS key rejected on Haswell (i7-4790K)

D

deadseth

New Member
Oct 12, 2026
3
0
1
Hello,

After booting into the recent Proxmox kernel 7.0.14-23-pve, my system encounters critical hardware and storage errors during startup, forcing it into an unstable state. Reverting to kernel 6.8.12-43-pve completely resolves the issue.

Hardware Specs:

  • CPU: Intel Core i7-4790K
  • Motherboard chipset: Intel Z97 / 9-series
Observed Errors from dmesg / Journal:
[ 2.311073] zfs: module license 'CDDL' taints kernel.
[ 2.923062] ZFS: Loaded module v2.2.10-pve1, ZFS pool version 5000... (also encountered 'Key was rejected by service' via systemd-modules-load)
[ 0.729384] ata5: SATA max UDMA/133 abar m2048@0xf7d19000 port 0xf7d19300 irq 31 lpm-pol 0
[ ... ] ata5.00: exception Emask 0x70 SAct 0x20000000 SErr 0x440900 action 0x6
[ ... ] ata5.00: irq_stat 0x28000000, host bus error, interface fatal error

Full kernel bug report log:
root@proxmox:~# dmesg | grep -E -i "ata5|zfs|error|fail|dmar" > ~/proxmox_kernel_bug_report.txt && cat ~/proxmox_kernel_bug_report.txt
[ 0.006520] ACPI: DMAR 0x00000000D73F0A70 0000B8 (v01 INTEL BDW 00000001 INTL 00000001)
[ 0.006531] ACPI: Reserving DMAR table memory at [mem 0xd73f0a70-0xd73f0b27]
[ 0.096954] DMAR: Host address width 39
[ 0.096955] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[ 0.096961] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a
[ 0.096963] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[ 0.096965] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da
[ 0.096966] DMAR: RMRR base: 0x000000d9e7c000 end: 0x000000d9e8afff
[ 0.096969] DMAR: RMRR base: 0x000000db000000 end: 0x000000df1fffff
[ 0.096971] DMAR-IR: IOAPIC id 8 under DRHD base 0xfed91000 IOMMU 1
[ 0.096972] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.096972] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[ 0.096973] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[ 0.097468] DMAR-IR: Enabled IRQ remapping in xapic mode
[ 0.234312] DMAR: No ATSR found
[ 0.234313] DMAR: No SATC found
[ 0.234314] DMAR: IOMMU feature pgsel_inv inconsistent
[ 0.234316] DMAR: IOMMU feature sc_support inconsistent
[ 0.234317] DMAR: IOMMU feature pass_through inconsistent
[ 0.234318] DMAR: dmar0: Using Queued invalidation
[ 0.234323] DMAR: dmar1: Using Queued invalidation
[ 0.294973] DMAR: Intel(R) Virtualization Technology for Directed I/O
[ 0.545408] RAS: Correctable Errors collector initialized.
[ 0.729384] ata5: SATA max UDMA/133 abar m2048@0xf7d19000 port 0xf7d19300 irq 31 lpm-pol 0
[ 1.038266] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.040145] ata5.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 1.040149] ata5.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 1.040415] ata5.00: supports DRM functions and may not be fully accessible
[ 1.040417] ata5.00: ATA-9: Samsung SSD 750 EVO 120GB, MAT01B6Q, max UDMA/133
[ 1.040958] ata5.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 1.042837] ata5.00: Features: Trust Dev-Sleep NCQ-sndrcv
[ 1.043331] ata5.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 1.043343] ata5.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 1.043546] ata5.00: supports DRM functions and may not be fully accessible
[ 1.046036] ata5.00: configured for UDMA/133
[ 2.311073] zfs: module license 'CDDL' taints kernel.
[ 2.311094] zfs: module license taints kernel.
[ 2.923062] ZFS: Loaded module v2.2.10-pve1, ZFS pool version 5000, ZFS filesystem version 5
[ 3.386667] i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory
[ 13.618694] EXT4-fs warning (device dm-10): ext4_clear_journal_err:6344: Filesystem error recorded from previous mount: IO failure
[ 13.620791] EXT4-fs (dm-10): warning: mounting fs with errors, running e2fsck is recommended
[ 13.621788] EXT4-fs (dm-10): Errors on filesystem, clearing orphan list.
[ 15.849148] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 15.849157] cfg80211: failed to load regulatory.db
[ 333.088270] EXT4-fs (dm-10): error count since last fsck: 6
[ 333.088277] EXT4-fs (dm-10): initial error at time 1791826133: ext4_orphan_add:186
[ 333.088280] EXT4-fs (dm-10): last error at time 1791826133: ext4_journal_check_start:86


Has anyone experienced similar DMA/IOMMU or SATA controller (ata5) regressions on older Haswell platforms with the version 7 kernel?
 
Hey Deadseth,

I think you may have run into an already reported Haswell / Intel 9-series IOMMU regression rather than a ZFS problem or necessarily a failing SSD.

There is another H97/Haswell report here with a similar failure pattern on the newer kernels: Intel AHCI/SATA errors, filesystem I/O failures and, during one boot, even the same: Failed to insert module 'zfs': Key was rejected by service

On an H97/i7-4770 system, intel_iommu=sp_off made kernel 7.0 stable. There is also a Z97/Haswell report where the same workaround resolved the IOMMU/SATA problems. I would try booting 7.0.14-23 once with: intel_iommu=sp_off and then check: dmesg -T | grep -iE 'DMAR|IOMMU|ata5|AHCI|ICRC|FPDMA|host bus|I/O error|PTE' I would also capture the complete kernel journal rather than the current grep: journalctl -k -b > /root/kernel-7.0.14-23.log

By the way, there is a rather important discrepancy in the log you posted. Your quoted ata5.00 ... host bus error isn't actually present in the later filtered output, and neither are any runtime DMAR fault/PTE messages. Seeing the complete failed-boot journal would help me (or someone else) establish whether the SATA controller is actually receiving bad IOMMU mappings.

Also, I wouldn't concentrate too heavily on:
zfs: module license 'CDDL' taints kernel
That's normal, just means CDDL isn't compatible with the kernel license and that dives into a non-technical (think non-engineering) problem. Your log also says: ZFS: Loaded module v2.2.10-pve1 Therefore, ZFS loaded during that boot just fine. The intermittent Key that was rejected by the service may be secondary to the underlying I/O/DMA problem; another H97 user also saw exactly that combination from what I've read.

On the other hand the EXT4 file system error is not a happy one: EXT4-fs (dm-10): Filesystem error recorded from previous mount: IO failure

You already have filesystem errors resulting from the failed I/O. I would therefore stay on the known-good 6.8 kernel for normal use until this is sorted out, identify what dm-10 corresponds to, and run an offline filesystem check as appropriate rather than continuing to stress the filesystem under the problematic kernel. If 7.0.14-23 is clean with intel_iommu=sp_off, I think that gives us a fairly convincing answer to the problem. :)

Thanks! Have a great day.


Tmanok
 
Last edited:
Thank you for the detailed explanation and for pointing me in the right direction.

I'm not particularly experienced with kernel-level debugging or IOMMU internals. I built and configured my Proxmox setup with help from AI tools such as ChatGPT, Gemini and DeepSeek, so I'd rather avoid making low-level changes that I don't fully understand, especially since this machine runs my OPNsense firewall and several other services.

For now, I think I'll stick with the known-good 6.8.12-43-pve kernel and wait for a future kernel update that either fixes this regression or provides a confirmed solution that doesn't require a manual workaround.

Your suggestion of testing with intel_iommu=sp_off is very helpful, and I may revisit it later when I can properly validate the results and ensure the system remains stable under normal workloads.

Thanks again for taking the time to explain the issue and share your findings!
 
Totally makes sense, I'm nervous about changes sometimes too, even after most of a decade using PVE! The reality is, sometimes infrastructure runs into faults and it can be risky to your operation to make changes. Still, Linux is far easier to troubleshoot and work on then Windows. I remember the days of troubleshooting Hyper-V and feeling very helpless at times until I could get support from the vendor on vendor derived bugs in their kernel. There's just no fixing a locked up piece of software. The key is resilient deployment, backups backups backups, and once in a very blue moon a re-installation. I had a half-rack cluster of PVE 5 going to all the way to PVE 8 before it needed physical relocation (retired most of the hardware too), so the reliable longevity exists in this project.

Cheers,


Tmanok
 
Thanks for sharing! Just to clarify, I'm not planning on doing any major changes or troubleshooting steps right now. I simply run daily updates and upgrades whenever they are available, and I reboot the entire system (along with all containers and VMs) on a daily basis.

By the way, regarding your comment—why did you mention that a re-installation is needed "once in a very blue moon"? Is there something specific that tends to accumulate or break over years of PVE upgrades that makes a fresh install preferable eventually? On my main desktop PC running Windows, I do formats and clean reinstalls fairly often, but here on Proxmox I'm still quite new and have zero experience with that side of things yet!
 
Hey Deadseth,

Thanks for the update and the question. Nah, Linux isn't quite like Windows in that sense, you can painlessly upgrade versions for more than five years strong as I said in my example. It's more of a mindset driven by hardware failure and inevitable changes in the physical world. It's easier than ever now thanks to innovations from Proxmox with cluster to cluster migrations, and until removing nodes becomes as clean and painless as adding nodes, it's better for the health of a cluster to simply reinstall if you have massive hardware changes.

Great question, though, and I hope you stay around for a long time!
Cheers,


Tmanok
 
You must log in or register to reply here.
Top Bottom
Back