Board family: Supermicro X11SSM(-F) / X11SSL(-F), C236 chipset, LGA1151 (Xeon E3-1200 v5/v6, Core i3/Pentium/Celeron)Hypervisor: Proxmox VE 8.xGuest: TrueNAS CORE, full HBA controller passthrough (not per-disk passthrough)Card: Dell PERC H310, cross-flashed to genuine LSI IT-mode firmware (LSI SAS2008 chipset)
Disclosure: I used an AI assistant to help research the root cause and draft this write-up. As such this might be a bit of a wordy post. The troubleshooting steps and results described are from MY own hands-on work; the cited sources (Supermicro FAQ, TrueNAS forum thread, board manual) and the outcomes are real and have been human verified.
Purpose: In the process up updating from CORE to SCALE on Proxmox host I was also moving my drives from direct passthrough (SATA drives) to an HBA with full passthrough of the HBA (full SMART visibility and recommended practice). I ran into board level issues with this setup that stopped the Proxmox host itself from POSTing. This can hit anyone doing PCI passthrough on this board family regardless of what you're passing the card into. There's also a Proxmox-specific gotcha buried in here around PCI resource mappings (mapped vs. raw device) that broke an unrelated passthrough on the same host, which seemed worth flagging for this audience specifically. Posting here in case others come across this as well, it can perhaps save them time. (Cross-posted from the TrueNAS Community Forums, since the guest OS side of this — chasing full SMART visibility via HBA passthrough — is a very common ask over there too.)
TL;DR for future searchers
If you get mrcReadMPRErr (or similar Memory Reference Code POST errors) specifically when installing an add-in card — HBA, NIC, NVMe, anything occupying a PCIe slot — on a Supermicro board, especially C236-chipset boards like the X11SSM/X11SSL family:
If you have other PCI devices passed through to VMs on the same host, see the side-effect note near the bottom — this jumper change can break existing "mapped device" passthrough mappings.
The Setup
I run a Proxmox host with a TrueNAS CORE VM for storage. Originally the VM's disks were passed through individually via stable /dev/disk/by-id/ paths — this works, but it means the guest OS only ever sees a generic QEMU HARDDISK for each disk, with no real SMART, vendor, or serial data visible from inside the VM. This is a challenge if you want drive health monitoring.
The fix for that is to pass through the HBA/SAS controller itself as a PCI device instead of passing through disks one at a time. I picked up a Dell PERC H310, flashed it to genuine LSI IT-mode firmware (sas2flash, standard process, documented all over ServeTheHome/TrueNAS forums — not repeating that part here), and validated the whole approach end-to-end on a spare test box first: drives detected correctly at the Proxmox bare-metal level, full controller passed through to a test TrueNAS VM, and real per-drive SMART/vendor/serial data confirmed visible from inside the guest. Passthrough method validated, card confirmed good.
The Problem
Moving the same, already-validated card into the actual production Proxmox host (Supermicro X11SSM board) was a different story. With the card installed and drives connected, the whole physical machine failed to POST — not a Proxmox/OS-level failure, this was before BIOS/boot even started. Angry beeping, and the BIOS's POST code display showed:
Remove the card, system boots fine. Card works perfectly in the other test box. Put it back in the production board, same failure every time.
What Was Ruled Out
The actual root cause: SMBus contention on the PCI slots
The breakthrough came from finding two independent reports of the exact same error code on a sibling board (X11SSL-F, same C236 family, same manual as the X11SSM):
Per the board's own Quick Reference Guide:
Jumper: JI2C1/JI2C2 | Description: SMB to PCI Slots | Default: Pins 1-2 (Enabled)
SMB here means System Management Bus (a slow I2C-based housekeeping bus used for things like reading DIMM SPD data and letting the BMC pull card telemetry) — worth flagging explicitly since it's easy to misread as "Samba/SMB" if you're coming from a NAS-heavy context like I was.
When this jumper is enabled (default), the PCI slots' SMBus lines are actively connected to the board's SMBus controller, and they get enumerated during memory training. With a full set of RAM DIMMs and an add-in card also on that bus, some Supermicro C236 boards apparently can't handle the combined addressing load during POST, and the memory-training phase fails outright — before the OS, before even the rest of BIOS, with the generic-sounding mrcReadMPRErr code that (understandably) sends everyone down the "it's a RAM problem" rabbit hole first.
Notably, this isn't unique to the X11SSM/X11SSL — some other Supermicro boards (e.g. X10SLX-F) actually ship with this same jumper disabled by default, which suggests it's a known-fragile feature across multiple board generations, not a one-off defect.
The Fix
Move both JI2C1 and JI2C2 from the default pins 1-2 to pins 2-3 (disabling the SMB-to-PCI-slots connection). Both jumpers should be set together.
Will This Hurt Anything?
Two questions worth answering up front, since I had them too:
With the jumpers moved, the system POSTs cleanly with the HBA installed and all drives connected. The card passes through to the TrueNAS guest as a single PCI device, TrueNAS recognized the existing ZFS pool immediately with no import issues, and real per-drive SMART data (health status, vendor, serial) is now visible from inside the guest — which was the entire point of this migration in the first place. All drives passed a subsequent SMART health check (smartctl -H) after the move.
One Side Effect Worth Knowing About (Proxmox-Specific)
If you're running a separate VM with a passed-through NIC on the same host (in my case, a router/firewall VM), be aware that this BIOS-level jumper change can invalidate an existing "mapped device" PCI resource mapping in Proxmox — the Datacenter-level Hardware Mapping that lets you reference a PCI device by name instead of its raw address. Mine had to be redone as raw device passthrough (one entry per PCI function, e.g. both functions of a dual-port NIC) after the jumper change, even though the NIC itself never moved slots. If your other passed-through devices stop working after this fix, this is the first thing to check — it's a quick fix, just re-add them as raw devices instead of mapped devices in the VM's Hardware → Add: PCI Device dialog.
Hope this saves someone the troubleshooting time it cost me.
~Mike W.
Disclosure: I used an AI assistant to help research the root cause and draft this write-up. As such this might be a bit of a wordy post. The troubleshooting steps and results described are from MY own hands-on work; the cited sources (Supermicro FAQ, TrueNAS forum thread, board manual) and the outcomes are real and have been human verified.
Purpose: In the process up updating from CORE to SCALE on Proxmox host I was also moving my drives from direct passthrough (SATA drives) to an HBA with full passthrough of the HBA (full SMART visibility and recommended practice). I ran into board level issues with this setup that stopped the Proxmox host itself from POSTing. This can hit anyone doing PCI passthrough on this board family regardless of what you're passing the card into. There's also a Proxmox-specific gotcha buried in here around PCI resource mappings (mapped vs. raw device) that broke an unrelated passthrough on the same host, which seemed worth flagging for this audience specifically. Posting here in case others come across this as well, it can perhaps save them time. (Cross-posted from the TrueNAS Community Forums, since the guest OS side of this — chasing full SMART visibility via HBA passthrough — is a very common ask over there too.)
TL;DR for future searchers
If you get mrcReadMPRErr (or similar Memory Reference Code POST errors) specifically when installing an add-in card — HBA, NIC, NVMe, anything occupying a PCIe slot — on a Supermicro board, especially C236-chipset boards like the X11SSM/X11SSL family:
- Don't assume it's bad RAM or a power supply issue just because the error sounds memory-related and appears during POST.
- Check your board's manual for a jumper along the lines of "SMB to PCI Slots" (often labeled JI2C1/JI2C2 on Supermicro boards).
- Try disabling it (moving from the default pins 1-2 to pins 2-3) before spending days chasing RAM/PSU theories like I did.
If you have other PCI devices passed through to VMs on the same host, see the side-effect note near the bottom — this jumper change can break existing "mapped device" passthrough mappings.
The Setup
I run a Proxmox host with a TrueNAS CORE VM for storage. Originally the VM's disks were passed through individually via stable /dev/disk/by-id/ paths — this works, but it means the guest OS only ever sees a generic QEMU HARDDISK for each disk, with no real SMART, vendor, or serial data visible from inside the VM. This is a challenge if you want drive health monitoring.
The fix for that is to pass through the HBA/SAS controller itself as a PCI device instead of passing through disks one at a time. I picked up a Dell PERC H310, flashed it to genuine LSI IT-mode firmware (sas2flash, standard process, documented all over ServeTheHome/TrueNAS forums — not repeating that part here), and validated the whole approach end-to-end on a spare test box first: drives detected correctly at the Proxmox bare-metal level, full controller passed through to a test TrueNAS VM, and real per-drive SMART/vendor/serial data confirmed visible from inside the guest. Passthrough method validated, card confirmed good.
The Problem
Moving the same, already-validated card into the actual production Proxmox host (Supermicro X11SSM board) was a different story. With the card installed and drives connected, the whole physical machine failed to POST — not a Proxmox/OS-level failure, this was before BIOS/boot even started. Angry beeping, and the BIOS's POST code display showed:
Code:
0x06 = mrcReadMPRErrRemove the card, system boots fine. Card works perfectly in the other test box. Put it back in the production board, same failure every time.
What Was Ruled Out
- RAM — this error code is very commonly associated with memory training/compatibility issues (it's part of Intel's Memory Reference Code, which runs during POST before the rest of BIOS loads). Tested with reduced DIMM population and swapped slots. Didn't fix it.
- Disabling the OPROM for the slot — under PCIe/PCI/PnP Configuration in the Advanced BIOS tab, tried disabling the Option ROM for the slot the card was in on the theory that the card's own boot-time firmware initialization was the trigger. No change. Same error, same beep pattern.
- Drive spin-up power draw — the next working theory was that simultaneously spinning up multiple drives, combined with the card's own power draw, was stressing the PSU specifically during the POST/memory-training window. To test this, we unplugged all spinning drives entirely, leaving the HBA installed with nothing connected to it. Same error, same beep pattern. This ruled out drive power draw as the (sole) cause — the problem was clearly tied to the card's mere presence on the bus, not what was attached to it.
The actual root cause: SMBus contention on the PCI slots
The breakthrough came from finding two independent reports of the exact same error code on a sibling board (X11SSL-F, same C236 family, same manual as the X11SSM):
- Supermicro's own support FAQ documents 0x06=mrcReadMPRErr on the X11SSL-F occurring when an add-in card (in their example, an NVMe SSD) is installed alongside 3+ populated 16GB DIMMs. Their fix: set jumpers Ji2C1 and Ji2C2 to pins 2-3.A TrueNAS Community forum thread independently hit and fixed the identical error — in their case triggered by adding an unrelated 10GbE NIC, not even an HBA — using the exact same jumper fix (see post titled: "Error 0x06=mrcReadMPRErr with X710-DA2 on Supermicro X11SSL-F" - thank you Oxyde for the solution).
- That second data point was the key: the common factor across all these reports isn't "HBA cards" specifically, it's any add-in card occupying a PCIe slot, combined with enough RAM installed. That pointed straight at something in the memory-training/enumeration path that both RAM and add-in cards touch — which is the System Management Bus (SMBus/I2C), not the PCIe data path itself.
Per the board's own Quick Reference Guide:
Jumper: JI2C1/JI2C2 | Description: SMB to PCI Slots | Default: Pins 1-2 (Enabled)
SMB here means System Management Bus (a slow I2C-based housekeeping bus used for things like reading DIMM SPD data and letting the BMC pull card telemetry) — worth flagging explicitly since it's easy to misread as "Samba/SMB" if you're coming from a NAS-heavy context like I was.
When this jumper is enabled (default), the PCI slots' SMBus lines are actively connected to the board's SMBus controller, and they get enumerated during memory training. With a full set of RAM DIMMs and an add-in card also on that bus, some Supermicro C236 boards apparently can't handle the combined addressing load during POST, and the memory-training phase fails outright — before the OS, before even the rest of BIOS, with the generic-sounding mrcReadMPRErr code that (understandably) sends everyone down the "it's a RAM problem" rabbit hole first.
Notably, this isn't unique to the X11SSM/X11SSL — some other Supermicro boards (e.g. X10SLX-F) actually ship with this same jumper disabled by default, which suggests it's a known-fragile feature across multiple board generations, not a one-off defect.
The Fix
Move both JI2C1 and JI2C2 from the default pins 1-2 to pins 2-3 (disabling the SMB-to-PCI-slots connection). Both jumpers should be set together.
Will This Hurt Anything?
Two questions worth answering up front, since I had them too:
- Does this cost you PCI performance? AI's research has indicated: No, despite Supermicro's own docs framing this jumper as being "to improve PCI performance." SMBus is a low-speed (100-400kHz) side-channel, completely separate from the actual PCIe data lanes your card uses for real throughput (SAS/SATA transfers, network packets, etc.). Disabling it only removes the BMC's ability to pull optional telemetry (temperature, power, VPD) from cards that support exposing it over SMBus — it does not touch PCIe bandwidth, link speed, or the card's actual data path at all.
- Does it affect PCI device/address assignment? AI's research has indicated: No. PCIe enumeration (bus/device/function numbers, BAR allocation, IRQ routing) happens entirely through the separate PCIe configuration space mechanism during POST, with no involvement from SMBus whatsoever. Devices will enumerate at the same addresses either way. However, see side effect noted below.
With the jumpers moved, the system POSTs cleanly with the HBA installed and all drives connected. The card passes through to the TrueNAS guest as a single PCI device, TrueNAS recognized the existing ZFS pool immediately with no import issues, and real per-drive SMART data (health status, vendor, serial) is now visible from inside the guest — which was the entire point of this migration in the first place. All drives passed a subsequent SMART health check (smartctl -H) after the move.
One Side Effect Worth Knowing About (Proxmox-Specific)
If you're running a separate VM with a passed-through NIC on the same host (in my case, a router/firewall VM), be aware that this BIOS-level jumper change can invalidate an existing "mapped device" PCI resource mapping in Proxmox — the Datacenter-level Hardware Mapping that lets you reference a PCI device by name instead of its raw address. Mine had to be redone as raw device passthrough (one entry per PCI function, e.g. both functions of a dual-port NIC) after the jumper change, even though the NIC itself never moved slots. If your other passed-through devices stop working after this fix, this is the first thing to check — it's a quick fix, just re-add them as raw devices instead of mapped devices in the VM's Hardware → Add: PCI Device dialog.
Hope this saves someone the troubleshooting time it cost me.
~Mike W.