{"id":317,"date":"2026-04-26T09:00:23","date_gmt":"2026-04-26T08:00:23","guid":{"rendered":"https:\/\/debnar.org\/wp\/?p=317"},"modified":"2026-04-26T09:00:23","modified_gmt":"2026-04-26T08:00:23","slug":"truenas-upgrade-from-24-10-2-4-to-25-10-3","status":"publish","type":"post","link":"https:\/\/debnar.org\/wp\/?p=317","title":{"rendered":"Truenas upgrade from 24.10.2.4 to 25.10.3"},"content":{"rendered":"<p>After a reboot following an upgrade, my TrueNAS system crashed with the following error:<\/p>\n<pre class=\"wrap:true lang:sh decode:true \" title=\"kernel IOMMU DMA error\">scsi host0: Adaptec AIC7XXX EISA\/VLB\/PCI SCSI HBA DRIVER, Rev 7.0\r\n&lt;Adaptec 3960D Ultra160 SCSI adapter&gt;\r\naic7899: Ultra160 Wide Channel A, SCSI id=7, 32\/253 SCBs\r\naic7xxx 0000:05:02.1: enabling device (0000 -&gt; 0003)\r\nDMAR: DRHD: handling fault status reg 3\r\nDMAR: [DMA read NO PASID] Request device [05:00.0] fault addr 0x12174000 [Fault reason 0x02] Present bit in context entry is clear<\/pre>\n<p>This was followed by a large number of SCB errors in an endless loop.<\/p>\n<p><!--more--><\/p>\n<p>The problem is fairly straightforward if you know where to look. First, let\u2019s break down the error message:<\/p>\n<blockquote><p>&#8211; DMAR &#8211; DMA remapping<br \/>\n&#8211; DRHD &#8211; DMA Remapping Hardware Unit Definition <em>[1]<\/em><\/p><\/blockquote>\n<p>Because of the DMAR reference, the error is related to Intel\u2019s IOMMU technology. What does the IOMMU do? When a device accesses memory via DMA, the IOMMU creates a mapping table and keeps track of which device is allowed to access which memory region. Without an IOMMU, a faulty or compromised driver could access memory regions it shouldn\u2019t, potentially causing a segmentation fault or worse.<\/p>\n<p>The root cause in my case was a PCIe-to-PCI bridge. If you look closely, you can see that there is a bridge device between the actual device and the motherboard:<\/p>\n<pre class=\"lang:default decode:true\" title=\"lspci -tv output\">lspci -tv\r\n-[0000:00]-+-00.0  Intel Corporation Gemini Lake Host Bridge\r\n...\r\n           +-13.0-[01-05]----00.0-[02-05]--+-03.0-[03]--+-00.0  QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA\r\n           |                               |            \\-00.1  QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA\r\n           |                               \\-07.0-[04-05]----00.0-[05]--+-02.0  Adaptec AHA-3960D \/ AIC-7899A U160\/m\r\n           |                                                            \\-02.1  Adaptec AHA-3960D \/ AIC-7899A U160\/m\r\n           +-13.1-[06]--\r\n...<\/pre>\n<h1>So what happens?<\/h1>\n<p>A device attempts to access memory. However, because of the bridge, the request contains the bridge\u2019s device ID instead of the actual device\u2019s ID. You can see this in the original error message: the bridge ID is <code data-start=\"2258\" data-end=\"2267\">05:00.0<\/code>, while the actual PCI devices are <code data-start=\"2302\" data-end=\"2311\">05:02.0<\/code> and <code data-start=\"2316\" data-end=\"2325\">05:02.1<\/code>.<\/p>\n<h1>How to solve this?<\/h1>\n<p>Disable the entire Intel IOMMU with a kernel parameter:<\/p>\n<blockquote><p>intel_iommu=off<\/p><\/blockquote>\n<h1>How to do this permanently?<\/h1>\n<p>In truenas you can add a kernel parameter with the following command, so it won&#8217;t break the followup upgrades:<\/p>\n<pre class=\"lang:sh decode:true\" title=\"kernel parameter intel_iommu=off\">midclt call system.advanced.update '{\"kernel_extra_options\": \"intel_iommu=off\"}'<\/pre>\n<h1>Links:<\/h1>\n<p>[1]:\u00a0<a href=\"https:\/\/www.kernel.org\/doc\/Documentation\/Intel-IOMMU.txt\">https:\/\/www.kernel.org\/doc\/Documentation\/Intel-IOMMU.txt<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>After a reboot following an upgrade, my TrueNAS system crashed with the following error: scsi host0: Adaptec AIC7XXX EISA\/VLB\/PCI SCSI HBA DRIVER, Rev 7.0 &lt;Adaptec 3960D Ultra160 SCSI adapter&gt; aic7899: Ultra160 Wide Channel A, SCSI id=7, 32\/253 SCBs aic7xxx 0000:05:02.1: &hellip; <a href=\"https:\/\/debnar.org\/wp\/?p=317\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[94,27,119],"tags":[34,120],"class_list":["post-317","post","type-post","status-publish","format-standard","hentry","category-english","category-linux","category-truenas","tag-kernel","tag-truenas"],"_links":{"self":[{"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=317"}],"version-history":[{"count":1,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/317\/revisions"}],"predecessor-version":[{"id":318,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/317\/revisions\/318"}],"wp:attachment":[{"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/debnar.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}