X9scm-f Firmware

[Evelio Olivo]

Thisis another one of those things that I see a lot of queries about and there is a lot of information around various posts/forums etc going through this. This is an effort to consolidate all of that into one useful download that you can put onto a bootable USB stick and use immediately. I will keep it up to date with new firmware revisions as they happen.

NB: X9SCM-iiF users, do NOT use the BIOS files here to upgrade your motherboard. You can replace the ones in the archive with the correct ones from the Supermicro site if you really want to. I don't have a iiF, so I don't intend including those files in the archive.

Disclaimer - ALL firmware flashing has the potential to go wrong. You can brick your devices (make them unuseable) if you are not careful and follow the steps EXACTLY. Also note that a power outage will also typically cause your hardware to be bricked, so wherever possible use a UPS!

NB: If you try the below procedure on a X9SCM motherboard, it will likely not work and you'll get a "PAL" error. You can still use your X9SCM to flash, but I would recommend updating the X9SCM BIOS to the latest version first prior to doing this. You will need to boot into your motherboard's EFI Shell as per the instructions in the next post.

When multiple adapters are present, you can either attempt to flash all of them at once (I don't recommend this - grab the LSI SAS2Flash Utility reference guide from their site if you want to try it) or flash them individually by telling the utility which card you want to flash. Some commands to assist with this follow:

Once you have the card number, you need to alter the previous commands slightly to select the controller you want to flash. The alteration involves adding in "-c x" where x is the controller number. Note that the sequence of parameters is important as this tells the utility what sequence to run the commands in.

Some motherboards, including the popular Supermicro X9SCM-F and X9SCM-IIF, require flashing to be done in the built-in EFI shell. All switches and parameters are identical to the dos-based SAS2FLSH.EXE, but instead you need to call SAS2FLASH.EFI (note the 'A' is included in the EFI version.)

Were you able to find a changelog anywhere for what changed in the P16 version of the firmware? I looked through the LSI zip file and the only changelog I could find was the SAS2FLASH changelog and they only changed the copyright display date from 2012 to 2013.

piece in order to get the card to boot faster at start. Seems kind of handy to me. Not that you will start your ESXi server very often, but it might be interesting to some, especially native unRAID installs.

Thanks for the informative thread, unfortunately, I have the most terrible luck with these things and none of it is working, I'm hoping I can get some help, or get a recommendation for an alternative card that is plug and play and will simply pass the drives to the OS.

You're at a point where you're not even able to write the empty flash file to the card, and getting a page fault error. Could be a motherboard issue... might also be worth trying one card at a time and making sure it is in the slot closest to the CPU (top 8x slot). Ensure no other cards are present when you do this (HBA's or otherwise.)

Page faults could also be because of memory-related issues. Is that a single stick you have? If you have the option, try another stick (or pull one out if you have 2.) Also probably worth running memtest86 to check your memory is 100%.

Never thought of ram... suppose it's a possibility. Memtest86+ just locks up, but the old memtest runs.... so I wonder if it's indeed that. I have the worse luck with computer builds and everything always points to ram but no matter how many times I change it it's not that. But maybe I'll get lucky.

The following steps show the update of the IPMI firmware under Linux. Copy both the Flash Utility and the firmware file to the server on which you want to update the IPMI firmware. The files lUpdate and lUpdate.sh must be executable:

Werner Fischer, working in the Knowledge Transfer team at Thomas-Krenn, completed his studies of Computer and Media Security at FH Hagenberg in Austria. He is a regular speaker at many conferences like LinuxTag, OSMC, OSDC, LinuxCon, and author for various IT magazines. In his spare time he enjoys playing the piano and training for a good result at the annual Linz marathon relay.

I've just flashed the BIOS of 3 different X9SCD motherboards, all housed within different MicroCloud chassis. I've done this hundreds of times, with this exact BIOS version (x9scd8.612), with no issues. I have my own custom made FreeDOS ISO which I boot up on the IPMI KVM and run a batch file which simply executes:

The systems appears to work fine other than not being able to get into the BIOS. I was able to install Windows 2019 on one of the systems via the IPMI/KVM and boot an existing Linux OS on another. It's just entering the BIOS that seems to fail.

I noticed today that for some reason, Java wasn't allowing me to load the KVM without adding a security exception. This was only on servers running IPMI firmware 3.50. The ones on 3.54 continued to work fine. So I wonder if this is actually BMC/IPMI related? I updated the IPMI firmware on them anyway but that didn't fix it.

In addition, I've just tested another X9SCD server that hasn't been touched at all recently. It was already running IPMI 3.54 and I can't get into the BIOS on that! I'm completely puzzled as to what's going on. Anyone else finding this on X9 generation boards?

It seems like SuperMicro X9 boards with E3v1/v2 CPUs (X9SCL-F,X9SCL+-F, X9SCI-LN4F, X9SCA-F, X9SCM-F, X9SCM-IIF, etc) will not allowyou to enter BIOS if the system date is past December 31, 2020. Whenattempting to enter BIOS, it comes up with a blue screen, and in thebottom right the error code "AB", which apparently means "Setup InputWait" per SuperMicro documentation. If you clear CMOS, you can getinto BIOS. We've tried with the latest BIOS (v2.3) and also olderBIOSes with the same results.

Basically what's happening is that the network interface will lock up. The machine stops responding, when logging in through the dedicated IPMI or console the network interface shows 99% usage in task manager but does not have a connection to the internet. It doesn't show a red disconnect X it just say's no internet access. If we try to run diagnostics it fails. If we try to disable the network interface it takes a long time, sometimes it disables, sometimes it doesn't. The only way we have found to fix this problem is by power cycling the machine. If we try to restart the machine properly it just hangs at shutting down. However the next day or some other random time the network interface will lock up again.

We recently deployed 11 of these machines with identical specs, 9 of them have Windows Web Server 2008 R2 64-bit and 2 of them have CentOS 6x 64-bit. We've primarily seen this problem occurring on 2-3 specific machines with Windows but it has happened on several other machines less often as well. It has occurred on one of the CentOS machines 2-3 times but not recently. The machines all had Bios 1.0c when deployed but we have since updated to 1.1a which made no difference.

We originally had a Dell Powerconnect 6248 switch but it was quite old so we replaced it with a brand new Dell Powerconnect 5548 switch with latest firmware. The problem occurred with both switches so we don't think it's that unless it has something to do with auto-negotiating or the power saving features.

I also am having the exact same issue with an X9SCM-F-0. The server was just recently built & everything worked fine for about 4 days after & then all the sudden it started. At first, the 82574L NIC just kept disconnecting & reconnecting over & over & I wasn't even able to connect via IPMI. Eventually I had to power cycle the server. Ever since I've been getting random issues where filesharing just stops on the server as well as the NIC randomly disconnected (not at the same time though). I can connect to shares on the server via \\localhost but I cannot connect to them remotely until the server is power cycled.

I just removed the newest Intel drivers (I think they are from June 2012) & installed the default MS drivers from 2009. After this, I'm going to exclusively use the 82574LM driver if the MS drivers do not work. I don't really want to do that though since the LM NIC is bound to a virtual machine in Hyper-V.

Sorry to flog a dead horse but I am having an issue with a supermicro server of the same vintage (2013) but my problem is simply that I am unable to set either LAN1 or LAN2 to use gigabit speed (100Mb is fine) or set the MTU to 9000 without any network transfers choking.

The support we offer on this forum is exclusive for Intel Server Systems& Boards reason why we recommend contacting the OEM (Original Equipment Manufacturers) directly in this case Supermicro* for further assistance on your inquiries.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

3a8082e126