MRSAS(4)

💖 MRSAS(4) 💖 — the LSI MegaRAID 6Gb/s & 12Gb/s SAS+SATA RAID controller driver

okay so bestie, this is the kernel interfaces manual page for mrsas, and honestly? it's giving "your RAID card finally speaks cam(4)" energy and we're obsessed. sit down, grab a snack 🍓, we're going through every single line together.

---

✨ NAME ✨

mrsas — LSI MegaRAID 6Gb/s and 12Gb/s SAS+SATA RAID controller driver

no cap, that's the whole name section. short, sweet, iconic. 💅

---

🎀 SYNOPSIS 🎀

so there's two ways to get this driver living in your kernel, and both are lowkey easy.

Option one: bake it into the kernel. drop these lines into your kernel configuration file:

device pci
device mrsas

Option two: load it as a module at boot time. put this line in loader.conf(5):

mrsas_load="YES"

that's it. that's the whole vibe check. 🦋

---

🌸 DESCRIPTION 🌸

so what does mrsas actually do? the mrsas driver will detect LSI's next generation (6Gb/s and 12Gb/s) PCI Express SAS/SATA RAID controllers. if you wanna know which cards, the HARDWARE section has the full list — go peek, it's right there. 👀

a disk (virtual disk/physical disk) attached to the mrsas driver will be visible to the user through camcontrol(8) as /dev/da? device nodes. and there's also a simple management interface provided on a per-controller basis via the /dev/mrsas? device node. two flavours of device node, one driver, main character energy honestly. 👑

now, the lore: the mrsas name is derived from the phrase "MegaRAID SAS HBA", which is substantially different than the old "MegaRAID" Driver mfi(4) which does not connect targets to the cam(4) layer and thus requires a new driver which attaches targets to the cam(4) layer. so like, it's not just a glow-up, it's a whole new architecture. 💀

older MegaRAID controllers are supported by mfi(4) and will not work with mrsas — not even a little bit, don't try it — but both the mfi(4) and mrsas drivers can detect and manage the LSI MegaRAID SAS 2208/2308/3008/3108 series of controllers. so those ones are like, double-booked. sharing custody fr fr.

the device.hints(5) option is provided to tune the mrsas driver's behavior for LSI MegaRAID SAS 2208/2308/3008/3108 controllers. by default, the mfi(4) driver will detect these controllers. see the PRIORITY section to know more about driver priority for MR-Fusion devices — it's a whole saga and honestly it deserves its own section, which it has. 📖

mrsas will provide a priority of (-30) (between BUS_PROBE_DEFAULT and BUS_PROBE_LOW_PRIORITY) at probe call for device id's 0x005B, 0x005D, and 0x005F so that mrsas does not take control of these devices without user intervention. so it's polite. it waits to be invited. 🫶

and finally — solid-state drives (SSD) get ATA TRIM support with mrsas if underlying adapter allows it. this may require configuring SSD as Non-RAID drive rather then JBOD virtual mode. (that's the man page's wording, i'm not touching it, i'm just delivering the facts ✨)

---

🔥 HARDWARE 🔥

the mrsas driver supports the following hardware — and yes, we're listing every single one, no skipping, that's the rule:

🦋 [ Thunderbolt 6Gb/s MR controller ]

• LSI MegaRAID SAS 9265
• LSI MegaRAID SAS 9266
• LSI MegaRAID SAS 9267
• LSI MegaRAID SAS 9270
• LSI MegaRAID SAS 9271
• LSI MegaRAID SAS 9272
• LSI MegaRAID SAS 9285
• LSI MegaRAID SAS 9286
• DELL PERC H810
• DELL PERC H710/P

🌈 [ Invader/Fury 12Gb/s MR controller ]

• LSI MegaRAID SAS 9380
• LSI MegaRAID SAS 9361
• LSI MegaRAID SAS 9341
• DELL PERC H830
• DELL PERC H730/P
• DELL PERC H330

like, look at that list. it ate. 🎀

---

⚙️ CONFIGURATION ⚙️

this is where you get to customise your little guy. all of these go in loader.conf(5), and all of them are per-adapter, so pay attention to what X means. 👇

to disable Online Controller Reset(OCR) for a specific mrsas driver instance, set the following tunable value in loader.conf(5):

dev.mrsas.X.disable_ocr=1

where X is the adapter number.

to change the I/O timeout value for a specific mrsas driver instance, set the following tunable value in loader.conf(5):

dev.mrsas.X.mrsas_io_timeout=NNNNNN

where NNNNNN is the timeout value in milli-seconds.

to change the firmware fault check timer value for a specific mrsas driver instance, set the following tunable value in loader.conf(5):

dev.mrsas.X.mrsas_fw_fault_check_delay=NN

where NN is the fault check delay value in seconds.

and if you ever wanna know how busy your controller is, the current number of active I/O commands is shown in the dev.mrsas.X.fw_outstanding sysctl(8) variable. it's giving dashboard, it's giving "how much is going on right now". 📊

---

🐛 DEBUGGING 🐛

want the driver to spill the tea? to enable debugging prints from the mrsas driver, set the hw.mrsas.X.debug_level variable, where X is the adapter number, either in loader.conf(5) or via sysctl(8).

the following bits have the described effects — you can mix and match, it's a bitmask situation:

• 0x01 — Enable informational prints.
• 0x02 — Enable tracing prints.
• 0x04 — Enable prints for driver faults.
• 0x08 — Enable prints for OCR and I/O timeout.
• 0x10 — Enable prints for AEN events.

pick your poison, bestie. 💜

---

👑 PRIORITY 👑

okay this is the drama section, the one where two drivers are fighting over the same card and honestly? it's giving love triangle.

the mrsas driver will always set a default (-30) priority in the PCI subsystem for selection of MR-Fusion cards. (it is between BUS_PROBE_DEFAULT and BUS_PROBE_LOW_PRIORITY). MR-Fusion Controllers include all cards with the Device IDs - 0x005B, 0x005D, 0x005F.

the mfi(4) driver will set a priority of either BUS_PROBE_DEFAULT or BUS_PROBE_LOW_PRIORITY (depending on the device.hints setting) in the PCI subsystem for selection of MR-Fusion cards. with the above design in place, the mfi(4) driver will attach to a MR-Fusion card given that it has a higher priority than mrsas. so by default, mfi(4) wins the card. that's just how it is. 🤷

using /boot/device.hints (as mentioned below), the user can provide a preference for the mrsas driver to detect a MR-Fusion card instead of the mfi(4) driver:

hw.mfi.mrsas_enable="1"

at boot time, the mfi(4) driver will get priority to detect MR-Fusion controllers by default. before changing this default driver selection policy, LSI advises users to understand how the driver selection policy works. LSI's policy is to provide priority to the mfi(4) driver to detect MR-Fusion cards, but allow for the ability to choose the mrsas driver to detect MR-Fusion cards.

LSI recommends setting hw.mfi.mrsas_enable="0" for customers who are using the older mfi(4) driver and do not want to switch to mrsas. for those customers who are using a MR-Fusion controller for the first time, LSI recommends using the mrsas driver and setting hw.mfi.mrsas_enable="1".

changing the default behavior is well tested under most conditions, but unexpected behavior may pop up if more complex and unrealistic operations are executed by switching between the mfi(4) and mrsas drivers for MR-Fusion. switching drivers is designed to happen only one time. although multiple switching is possible, it is not recommended. the user should decide from Start of Day which driver they want to use for the MR-Fusion card. 😭

and the part that gets people every time: the user may see different device names when switching from mfi(4) to mrsas. this behavior is Functions As Designed and the user needs to change the fstab(5) entry manually if they are doing any experiments with mfi(4) and mrsas interoperability. so like, yes, your mounts will break, and no, it's not a bug. 🙈

---

📁 FILES 📁

• /dev/da? — array/logical disk interface
• /dev/mrsas? — management interface

---

🔗 SEE ALSO 🔗

cam(4), mfi(4), pci(4), device.hints(5), camcontrol(8)

---

📜 HISTORY 📜

the mrsas driver first appeared in FreeBSD 10.1. ✨

mfi Driver: mfi(4) is the old FreeBSD driver which started with support for Gen-1 Controllers and was extended to support up to MR-Fusion (Device ID = 0x005B, 0x005D, 0x005F).

mrsas Driver: mrsas is the new driver reworked by LSI which supports Thunderbolt and onward products. the SAS+SATA RAID controller with device id 0x005b is referred to as the Thunderbolt controller throughout this man page.

cam aware HBA drivers: FreeBSD has a cam(4) layer which attaches storage devices and provides a common access mechanism to storage controllers and attached devices. the mrsas driver is cam(4) aware and devices associated with mrsas can be seen using camcontrol(8). the mfi(4) driver does not understand the cam(4) layer and it directly associates storage disks to the block layer.

Thunderbolt Controller: this is the 6Gb/s MegaRAID HBA card which has device id 0x005B.

Invader Controller: this is 12Gb/s MegaRAID HBA card which has device id 0x005D.

Fury Controller: this is the 12Gb/s MegaRAID HBA card which has device id 0x005F.

the naming lore is honestly so extra and i respect it so much. 🌈

---

💌 AUTHORS 💌

the mrsas driver and this manual page were written by Kashyap Desai <Kashyap.Desai@lsi.com>. thank you for your service, king. 🫡

---

🚧 TODO 🚧

the stuff that is not happening yet, and we're saying it with love:

• the driver does not support big-endian architectures at this time.
• the driver does not support alias for device name (it is required when the user switches between two drivers and does not want to edit /etc/fstab manually).
• the mrsas driver exposes devices as /dev/da?, whereas mfi(4) exposes devices as /dev/mfid?.
• mrsas does not support the Linux Emulator interface.
• mrsas will not work with mfiutil(8).

so yeah, a few things still on the vision board. we move. 💅

---

and that's the whole page, bestie!! this one came out of the Debian manual set and it's dated Mar 13, 2019 — so like, respect the vintage, it's practically a period piece. stay slay, keep your firmware updated, and remember: pick your driver at Start of Day. 🎀✨💖