X9SCM-IIF-O IPMI NIC Interface Lockup

[ecleese]

I'm having trouble finding an answer to this problem so I thought I'd try here. I have several of Supermicro X9SCM-IIF-O motherboards in various systems. The one system system in question has a dedicated instance of Windows 7 x64 (no virtualization) running on a SSD. The IPMI NIC interface drops connection after a random number of hours. I can no longer ping it, log in via IPMIView or access the web interface. The solution is to actually reboot the operating system (Windows 7), not power cycling the hardware.

Any thoughts on what might be causing this? I've check the obvious things like cable tests, switch ports, etc. Could Windows somehow be causing this port to lock up? Why would rebooting the OS fix what appears to be a hardware issue? That NIC isn't even seen in Windows since it's a dedicated IPMI NIC.

 

[supermacro]

IPMI Firmware 1.6 came out. Perhaps you might want to give that a try. If it's happening on this particular board then it might as well be the faulty board.

 

[ecleese]

Yeah it's only this one board that has the issue. All the boards I have in production are all at the same bios revision and IPMI FW version. I'll give v1.6 a try though, thanks.

 

[Patrick]

Very strange issue especially with the dedicated NIC.

 

[TheBay]

Check the MAC of it has a C on the end, sometimes these boards can switch to A if failover or Shared has been selected.
Even if it's got the MAC of NIC1 which ends in A it will still work through the dedicated port, but when the OS loads it gets confused as there are 2 NICS with the same MAC, that can cause this issue.

Also if all the above fails, including the update, run the Supermicro IPMI Config too, I find it works better in dos than linux, first check the mac and IP with switch -m . Then use it to set the MAC again and if that fails it's also worth using the switches -fd or -fde to do a factory default reset if needed. You will have to wait a while for it to come online again, you will hear the sever make a few beeps then more beeps when it's online so don't think it's broken if it's taking ages when you use the switch -m while it's rebooting and it errors or pauses.

 

[ecleese]

The primary LAN interface MAC ends in C. The IPMI interface MAC ends in D. I just restarted the box remotely and logged into the IPMI web interface to check the type of interface. I had it set to failover. I've now changed it to dedicated. Hopefully this resolves any confusion the system may be having. Thanks for this suggestion. I'll report back here on what happens.

 

[TheBay]

That's strange going all the way up to D, it must be because you have 2 Intel 82574L's and the chipset has a 82574LM built in which isn't obviously being used but Supermicro have taken that in to account I guess.

 

[ecleese]

Just a quick update. It's been close to a week now with no dropouts. Before the change the IPMI interface wouldn't make it longer than 24 hours so I think I can say the issue has been resolved.

As an FYI, I logged into another production X9SCM-IIF-O and noted the MAC address of that IPMI interface. It does in fact end in "B", not "D" like this board. Any idea why the two would be different?

 

[TheBay]

Just a quick update. It's been close to a week now with no dropouts. Before the change the IPMI interface wouldn't make it longer than 24 hours so I think I can say the issue has been resolved.

As an FYI, I logged into another production X9SCM-IIF-O and noted the MAC address of that IPMI interface. It does in fact end in "B", not "D" like this board. Any idea why the two would be different?

IPMI MAC can be set to anything, but it should always be set to the last MAC octet of the onboard NIC's if using it as dedicated (best practice imho), changing settings i.e failover and shared can end up setting it to the same as one of the onboard NIC's.