The question I have: Must/should I update the firmware from 19.00.00.00?
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 20.00.07.00. You'll see a lot of reports about P20 being buggy and not to upgrade from P19, but from 20.00.04.00 onward things are solid. The driver in 10-STABLE is 21.01.00.00 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.
