[SOLVED] 9300-8i HBA Card not working with PVE9 VM

tony8077616

New Member
Nov 1, 2025
10
1
3
Recently, I've been scavenging, and I picked up a computer setup to use for PVE . I plan to virtualize TrueNAS but have run into some issues.


The HBA card simply cannot pass the hard drive information directly through to TrueNAS using the PCI Passthrough method. This also results in the following errors occurring simultaneously in both PVE and TrueNAS.
1000023273.jpgIMG_20251028_032010996.jpgIMG_20251027_010251894.jpg
1000023272.jpg
Computer Hardware:
- CPU: Intel Core i7-4790
- MB: Gigabyte H97-D3H v1.0 (Firmware: F7, Secure Boot disabled, UEFI Mode)
- GPU: Zotac GTX 1650 Super
- RAM: Mixed 4x8G DDR3-1600
- HBA: Broadcom LSI SAS9300-8i (Firmware: 16.00.12.00, IT Mode. Due to the motherboard architecture, it operates at PCI-e 2.0x4, PCI Address: 00:05:00)
- HDD: WD MyBook shucked drives, 3x14TB and 1x16TB (Connected to HBA card Port 0 using a 1-to-4 Mini-SAS to SATA cable)
- Boot: Crucial BX500 SATA3 SSD 512G (Plugged directly into the motherboard)

Before I bought the HBA card, I could read the drives normally using the onboard storage controller (AHCI or RAID mode), but I couldn't pass the correct hard drive information (such as drive brand and SMART data) into the virtualized system.
When installing PVE 9, TrueNAS 25.10, and OMV 7 individually as the bare-metal (first layer) operating system, the hard drives on the HBA card could be read normally.
However, errors occur when TrueNAS and OMV boot as virtualized containers/machines under PVE.

I'd like to ask, does anyone watching have any suggestions?
 
Last edited:
Did the card ever work in another system? If you don't know that, the card might just be damaged ==> No reason to look any further.

Besides that, you are running a system, that definitely is not intended for server use. Might be, that the BIOS isn't setup correctly. Those "DMAR" error messages look suspiciously like BIOS FW-bugs.
Good luck!
 
Last edited:
Just out of curiosity: How did you come up with that suggestion?

https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt
Quote from the link:
I don't think the issue is with the HBA controller. Just a troubleshooting step.

@tony8077616 , you could list the IOMMU groups to see if there are conflicts. I use this quick and dirty script:

Code:
#!/bin/bash
for d in $(find /sys/kernel/iommu_groups/ -type l | sort -n -k5 -t/); do
    n=${d#*/iommu_groups/*}; n=${n%%/*}
    printf 'IOMMU Group %s ' "$n"
    lspci -nns "${d##*/}"
done;
exit 0

Phil
 
Last edited:
OK, I see.
Going by the information, that was provided, the card's option ROM has big problem with the "SeaBIOS" implementation. See you "Firmware Fault" message and also the resulting issues reported by the "mpt3sas" driver, afterwards.
I would suggest switching the VM to "Q35" (if it isn't already) and using UEFI-, instead of Legacy-booting.
 
I don't think the issue is with the HBA controller. Just a troubleshooting step.

@tony8077616 , you could list the IOMMU groups to see if there are conflicts. I use this quick and dirty script:

Code:
#!/bin/bash
for d in $(find /sys/kernel/iommu_groups/ -type l | sort -n -k5 -t/); do
    n=${d#*/iommu_groups/*}; n=${n%%/*}
    printf 'IOMMU Group %s ' "$n"
    lspci -nns "${d##*/}"
done;
exit 0

Phil
1762191110559.png
Here you are
 
OK, I see.
Going by the information, that was provided, the card's option ROM has big problem with the "SeaBIOS" implementation. See you "Firmware Fault" message and also the resulting issues reported by the "mpt3sas" driver, afterwards.
I would suggest switching the VM to "Q35" (if it isn't already) and using UEFI-, instead of Legacy-booting.
Change to Q35 with and without vIOMMU (Intel or VirtIO) still not working
1762192313012.png
 
Try adding intel_iommu=igfx_off to your GRUB command line.

Phil
I don't try adding intel_iommu=igfx_off to GRUB command line.

Just try disable IGFX from Host BIOS, and it worked with both q35 and i440fx
1762193519934.png
1762193535281.png
But why?
1762193006094.png

Is it IRQ assignment problem?
 

Attachments

  • 1762194084946.png
    1762194084946.png
    69 KB · Views: 5
Last edited:
That sounds really strange!
You disabled the internal graphics (which you did not seem to use?) and then some completely unrelated PCIe cards start to work correctly?
If that is the case, then I guess some thanks to Gigabyte are in order. Unless Blonov can shed some light on why that should not be the case.
 
That sounds really strange!
You disabled the internal graphics (which you did not seem to use?) and then some completely unrelated PCIe cards start to work correctly?
If that is the case, then I guess some thanks to Gigabyte are in order. Unless Blonov can shed some light on why that should not be the case.
I've used. But I forget to switch my hdmi from internal graphics to GTX1650s because of PVE may freeze when loading install PVE from ISO and it only work with internal graphics
I refer to same H97 with asus motherboard, is it IRQ assignment problem?
 
Last edited:
I wanna to try this.
Before it, I've already add intel_iommu=on in GRUB command line. Should I just change intel_iommu=on to intel_iommu=igfx_off?

Add it: "intel_iommu=on intel_iommu=igfx_off".
If IOMMU is supported and (fully) enabled in the motherboard BIOS, then it is also enabled in Proxmox automatically.

You may need to also add iommu=pt as mentioned in the link.

Phil
 
Last edited:
Add it: "intel_iommu=on intel_iommu=igfx_off".
If IOMMU is supported and (fully) enabled in the motherboard BIOS, then it is also enabled in Proxmox automatically.

You may need to also add iommu=pt as mentioned in the link. IRQ should normally

Phil
1762196801845.png

MB only have VT and VT-d option, I've already enabled it.
GRUB I've add intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction vfio_iommu_type1 allow_unsafe_interrupts=1 before I disable IGFX from bios.