MPR(4)

💖 MPR(4) 💖

okay bestie, so this is mpr — the LSI Fusion-MPT 3/3.5 IT/IR 12Gb/s Serial Attached SCSI/SATA/PCIe driver. it's a kernel interfaces manual page. buckle up, it's a long one, but we're gonna get through it together 🫶

---

✨ SYNOPSIS ✨

so like, you want this driver baked right into your kernel? add these lines to your kernel configuration file:

device pci
device scbus
device mpr

or, if you'd rather load it as a module at boot time (very slay of you), drop this line into loader.conf(5):

mpr_load="YES"

---

🌸 DESCRIPTION 🌸

the mpr driver gives you support for Broadcom Ltd./Avago Tech (LSI) Fusion-MPT 3/3.5 IT/IR SAS/PCIe controllers. that's the whole vibe. it talks to your fancy storage hardware so you don't have to 💅

---

👑 HARDWARE 👑

these are the controllers that mpr is obsessed with, no cap:

• Broadcom Ltd./Avago Tech (LSI) SAS 3004 (4 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3008 (8 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3108 (8 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3216 (16 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3224 (24 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3316 (16 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3324 (24 Port SAS)
• Broadcom Ltd./Avago Tech (LSI) SAS 3408 (8 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3416 (16 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3508 (8 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3516 (16 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3616 (16 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3708 (8 Port SAS/PCIe)
• Broadcom Ltd./Avago Tech (LSI) SAS 3716 (16 Port SAS/PCIe)

---

🎀 CONFIGURATION 🎀

quick heads up before we dive in: in literally every tunable description down below, X stands for the adapter number. iykyk ✨

💅 interrupting the vibe (MSI / MSI-X)

want MSI interrupts GONE for all mpr driver instances? set this tunable in loader.conf(5):

hw.mpr.disable_msi=1

just for one specific mpr driver instance? set this instead:

dev.mpr.X.disable_msi=1

okay but what about MSI-X? to disable MSI-X interrupts for all mpr driver instances, set this tunable in loader.conf(5):

hw.mpr.disable_msix=1

and for one specific instance:

dev.mpr.X.disable_msix=1

🔥 DMA chains

to cap the maximum number of DMA chains allocated for all adapters, set this in loader.conf(5):

hw.mpr.max_chains=NNNN

for just one adapter:

dev.mpr.X.max_chains=NNNN

the default max_chains value is 16384. yes, that's a lot. she's generous.

a few sysctl(8) variables to keep an eye on:

• the current number of free chain frames lives in dev.mpr.X.chain_free
• the lowest number of free chain frames seen since boot lives in dev.mpr.X.chain_free_lowwater
• the number of times chain frame allocations have failed since boot lives in dev.mpr.X.chain_alloc_fail — this one is literally your sign to figure out whether the max_chains tunable should be increased to help performance 👀

🦋 I/O stuff

the current number of active I/O commands is shown in the dev.mpr.X.io_cmds_active sysctl(8) variable.

the highest number of active I/O commands seen since boot is stored in the dev.mpr.X.io_cmds_highwater sysctl(8) variable.

🌈 PRP pages (NVMe besties)

PRP pages are used by NVMe devices for I/O transfers, much like Scatter/Gather lists. here's the tea:

• the current number of free PRP pages is stored in dev.mpr.X.prp_pages_free
• the lowest number of free PRP pages seen since boot is stored in dev.mpr.X.prp_pages_free_lowwater
• the number of times that PRP page allocations have failed since boot is stored in dev.mpr.X.prp_page_alloc_fail

(those are all sysctl(8) variables, btw 💜)

🍓 max_io_pages

to set the maximum number of pages that will be used per I/O for all adapters, set this tunable in loader.conf(5):

hw.mpr.max_io_pages=NNNN

for a specific adapter:

dev.mpr.X.max_io_pages=NNNN

the default max_io_pages value is -1, meaning that the maximum I/O size that will be used per I/O will be calculated using the IOCFacts values stored in the controller. the lowest value that the driver will use for max_io_pages is 1 — otherwise IOCFacts will be used to calculate the maximum I/O size. the smaller I/O size calculated from either max_io_pages or IOCFacts will be the maximum I/O size used by the driver. it's giving "smallest one wins" 💀

💖 excluding devices

you can exclude devices from mpr control for all adapters by setting this tunable in loader.conf(5):

hw.mpr.exclude_ids=Y

Y represents the target ID of the device. if more than one device is to be excluded, target IDs are separated by commas. cute and simple.

or exclude devices for a specific adapter:

dev.mpr.X.exclude_ids=Y

again, Y is the target ID of the device, and multiple target IDs get separated by commas.

⭐ StartStopUnit (SSU) — the shutdown ritual

the adapter can issue the StartStopUnit SCSI command to SATA direct-access devices during shutdown. this allows the device to quiesce powering down, which is very polite of it.

to control this feature for all adapters, set the

hw.mpr.enable_ssu

tunable in loader.conf(5) to one of these values:

• 0 — Do not send SSU to either HDDs or SSDs.
• 1 — Send SSU to SSDs, but not to HDDs. This is the default value.
• 2 — Send SSU to HDDs, but not to SSDs.
• 3 — Send SSU to both HDDs and SSDs.

to control this feature for a specific adapter, set this tunable value in loader.conf(5):

dev.mpr.X.enable_ssu

the same set of values are valid as when setting this tunable for all adapters. slay 💅

🧚 spinup wait time (for the slow little guys)

SATA disks that take several seconds to spin up and fail the SATA Identify command might not be discovered by the driver. like, they're just not showing up. rude.

this problem can sometimes be overcome by increasing the value of the spinup wait time in loader.conf(5) with the

hw.mpr.spinup_wait_time=NNNN

tunable. NNNN represents the number of seconds to wait for SATA devices to spin up when the device fails the initial SATA Identify command.

spinup wait times can also be set for specific adapters in loader.conf(5) with the

dev.mpr.X.spinup_wait_time=NNNN

tunable. NNNN is the number of seconds to wait for SATA devices to spin up when they fail the initial SATA Identify command. same energy, different scope ✨

🌸 device mapping & Phy numbers

the driver can map devices discovered by the adapter so that target IDs corresponding to a specific device persist across resets and reboots. iconic behaviour, honestly.

but — in some cases it is possible for devices to lose their mapped IDs due to unexpected behavior from certain hardware, such as some types of enclosures. to overcome this problem, a tunable is provided that will force the driver to map devices using the Phy number associated with the device.

🚨 ok so listen: this feature is not recommended if the topology includes multiple enclosures/expanders. if multiple enclosures/expanders are present in the topology, Phy numbers are repeated, causing all devices at these Phy numbers except the first device to fail enumeration. that's a whole mess. don't do it.

to control this feature for all adapters, set the

hw.mpr.use_phy_num

tunable in loader.conf(5) to one of these values:

• -1 — Only use Phy numbers to map devices and bypass the driver's mapping logic.
• 0 — Never use Phy numbers to map devices.
• 1 — Use Phy numbers to map devices, but only if the driver's mapping logic fails to map the device that is being enumerated. This is the default value.

to control this feature for a specific adapter, set this tunable value in loader.conf(5):

dev.mpr.X.use_phy_num

the same set of values are valid as when setting this tunable for all adapters.

---

🔍 DEBUGGING 🔍

driver diagnostic printing is controlled in loader.conf(5) by using the global hw.mpr.debug_level and per-device dev.mpr.X.debug_level tunables. you can also alter the debug level for any adapter at run-time using the sysctl(8) variable dev.mpr.X.debug_level. live changes, main character energy ✨

all debug_level variables can be named by either an integer value or a text string. multiple values can be specified together by either ORing the integer values or by providing a comma-separated list of names. a text string prefixed by "+" adds the specified debug levels to the existing set, while the prefix "-" removes them from the existing set. the current debug_level status is reported in both formats for convenience, because she's thoughtful like that 💜

here are the levels, all of them, no skips:

• 0x0001, info — Basic information (enabled by default)
• 0x0002, fault — Driver faults (enabled by default)
• 0x0004, event — Controller events
• 0x0008, log — Logging data from controller
• 0x0010, recovery — Tracing of recovery operations
• 0x0020, error — Parameter errors and programming bugs
• 0x0040, init — System initialization operations
• 0x0080, xinfo — More detailed information
• 0x0100, user — Tracing of user-generated commands (IOCTL)
• 0x0200, mapping — Tracing of device mapping
• 0x0400, trace — Tracing through driver functions

---

🫶 SEE ALSO 🫶

cam(4), cd(4), ch(4), da(4), mps(4), mpt(4), pci(4), sa(4), scsi(4), targ(4), loader.conf(5), sysctl(8)

---

⭐ HISTORY ⭐

the mpr driver first appeared in FreeBSD 9.3. a legend from the start.

---

💖 AUTHORS 💖

the mpr driver was originally written by Scott Long <scottl@FreeBSD.org>. it has been improved and tested by LSI Corporation, Avago Technologies (formally LSI), and Broadcom Ltd. (formally Avago).

this man page was written by Ken Merry <ken@FreeBSD.org> with additional input from Stephen McConnell <slm@FreeBSD.org>.

---

okay that's the whole page bestie, you made it to the end 🎉 this was the mpr page from the Debian crowd, dated June 1, 2019. go forth and configure your HBAs, you absolute icon 💅✨