Solved LSI SAS 9201-16i - is Firmware: new enough?


I recently acquired a new LSI SAS 9201-16i card. I'll be using it on FreeBSD 10.3 (for now).

The dmesg output is:

mps0: <Avago Technologies (LSI) SAS2116> port 0xe000-0xe0ff mem 0xf7ec0000-0xf7ec3fff,0xf7e80000-0xf7ebffff irq 16 at device 0.0 on pci1
mps0: Firmware:, Driver:
mps0: IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>

It appears to be already in IT mode, which is ideal. I'm basing that on the excellent blog post for a similar card I discovered today. I'm basing that on the HostDisc part of the output.

The question I have: Must/should I update the firmware from

What do you think?
The question I have: Must/should I update the firmware from
In general, you want the firmware and driver to be relatively close in version. When a product is undergoing active development, the driver may expect certain firmware features to be present which may not be there in older firmware. However, the firmware / driver for these cards are mostly in maintenance mode at this point so incompatibilities are unlikely.

The P20 firmware had a number of issues and it was re-kitted 3 times, the newest being You'll see a lot of reports about P20 being buggy and not to upgrade from P19, but from onward things are solid. The driver in 10-STABLE is which adds support for auto-sizing the maximum scatter-gather I/O size rather than assuming the (miniscule) default of 256KB.
I'm now building world on an 11.x box I have so I can get mpsutil() which can flash this card for me.
mpsutil(8) is in 10-STABLE. But I would like to strongly discourage people from flashing cards (any cards) except via a standalone utility (bootable DOS image or EFI, as appropriate). Flashing the card halts and reboots the controller's onboard CPU. If you have the cover off your system when you flash, you can confirm this as LSI cards have a heartbeat LED under control of the onboard CPU and you will see it stop flashing and then start again. Presumably the flash utility coordinates with the driver, so the driver doesn't report "all my devices went away" to the operating system - if it did, all the devices would be marked as destroyed and then re-detected, similarly to unplugging and then plugging a USB flash drive back in. But if the flash fails for some reason (which you've run into in the past), you'll be left with a running operating system with missing drives. Not Good if they're in a ZFS pool and the system decides there aren't enough copies left for a usable pool. Another issue specific to this family of controllers is that drives enumerate randomly each time they're probed - in my case I have 16 drives on a 9201-16i and the da0 through da15 device names end up being assigned to the actual drives in a random order which changes on each boot. Even if you are using glabel(8) to identify the drives, I don't think the kernel expects the mapping to change while the kernel is running.

I'd also suggest flashing the BIOS as well as the firmware - in fact, on my cards I flash the firmware as well as both the EFI and classic BIOS. Some people will say "it slows down booting", but the time spent is a small percentage of the overall time the average server-class system takes to get from power-on (or reset) to the FreeBSD loader menu. And you get a useful config utility which you can use even if the system isn't (or can't) boot, as well as support for staggered spinup if your drives support it.

As an aside, we've discussed things like tape backup before (we talked in detail about SCSI controllers and why "differential" can mean 2 incompatible things). You might be interested in this article of mine about the latest generation of my FreeBSD-based storage appliances. There's some handy backup scripts and ideas about replication in there, as well as discussions of the 9201-16i controller and other hardware.