LSI SAS ROM question

[demon]

I've decided to build myself a FreeNAS box, and I believe I've done it up reasonably:

• ASRock C2750D4I board
• Crucial CT2KIT102472BD160B memory (2x 8 GB ECC 1600MHz UDIMMs, they are CT102472BD160B.18FED)
• Silverstone Tek DS380B case
• Silverstone Tek ST45SF-G fully-modular power supply
• LSI SAS 9211-8i SAS board, crossflashed with IT (target-only) firmware
• 6x WD Red 3 TB SATA drives (latest refresh with NASware 3.0)
• Kingston DataTraveler SE9 64 GB USB flash disk for boot media

My question is specifically about the SAS board. I currently have the Phase 17 IT firmware image on it, because I had read somewhere (can't recall where now) that phase 17 fixed some issue. Redownloading the zip file with the firmware in it doesn't seem to indicate such a thing - the only items the PDF which appears to be a changelog mentions are OS compatibility additions (RHEL 6.4, OEL 6.4, OEL 5.9), a version report correction for ESX 5.1U1, and:

SCGCQ00368532 (ENHREQ) - SAS2FLASH : CLI switch adder to force an update of the SBR from
ManPage2 only and do not reset.

Is that worth the warnings from FreeNAS (9.3 BETA as of about 5 days ago) about the driver/firmware version mismatch? Or is it a non-concern, and I should flash it back down to the Phase 16 firmware? I'm currently waiting for a replacement SAS backplane board (the one that came in the case had a power short that triggered short protection, boo), so I want to have everything as ready as I can for drive and functional testing when that part finally arrives. Thanks.

And yes, I know I could have used the board's onboard Intel SATA ports, but I can afford it, and wanted to experiment with new things. (Yeah, how's that going...)

Edit:

Okay, that was from the wrong PDF (that was for the SAS2FLASH tool itself). The SAS2FW changelog PDF says:

SCGCQ00469017 (CSET) - Removed allocation length handling for Read Capacity code
SCGCQ00469047 (CSET) - Removed allocation length compliance code for Request Sense
SCGCQ00470697 (CSET) - OS hang during install of Linux system to a SSD

Are those issues that would be worth keeping the Phase 17 firmware? (Obviously the Linux/SSD one doesn't apply.)

 

[cyberjock]

I can't vouch for the two entries for the changelog, but I'd go with the phase 16 driver and firmware before I ever ever consider mis-matching. LSI won't even support mismatched configurations because it is *expected* to cause problems.

 

[Ericloewe]

Two comments:

As Cyberjock said, P16 is the way to go. The bug fixed in P17 is trivial (Disks don't show up in the boot ROM during POST - it's not in the changelog, it's in the P16 README) and mismatched drivers and firmware have caused some people a lot of pain.

 

[demon]

Okay, I'll downgrade it back to the Phase 16 firmware once some replacement fans come in on Tuesday. Thanks.