FreeBSD 8.2-RELEASE-p2 + IPMI

G

g0098

I have a SuperMicro 5015M-T 1U server (older PDSMi board built for the Pentium-D) with the AOC-IPMI20-E installed (IPMI 2.0 BMC). It has been running perfectly fine since mid 2006. I first had 6.1 or 6.2-RELEASE running on it back then. And the SuperMicro IPMIView app worked perfectly remotely or on the same subnet. I completely skipped over all of v7 and went to 8.0-RELEASE > 8.1 > 8.2 and all the patches in between the past however many months and didn't check that the IPMI was still working, stupidly.

The BMC shares the same MAC, IP address, mask, gateway and interface (em0). This has always worked fine through the various v6 releases. I was debugging today and found that if I cleanly power down the system, I can access the BMC, and then at startup, as soon as the em driver is loaded, I lose communication with the BMC. Even if I set a completely different IP, mask and gateway, still doesn't work, so it's not ARP or a subnet mask issue. When the OS is running and the driver has control of the NIC, all is fail.

IPMItool with the ipmi driver loaded works fine, I can access it from the console, but that does me no good remotely if the OS isn't responding.

So is this a bug with the em driver? I searched the forum and only found references to Broadcom driver/IPMI issues.
 
Hi g0098,

I have the same problem with FreeBSD 8.2 and a BMC on an Intel 82873 NIC. My setup is a little different from yours because the BMC has different MAC/IP than the host (I had tu use eeupdate.exe in DOS to acheive that).

When the "em" driver loads, the BMC is still responding to ipmiping. BUT as soon as I set an IP address (or DHCP) to the NIC, the BMC stop responding. I have to power off the system and disconnect the power cable to get the BMC work again.

Rafael.
 
The primary NIC in my box is an 82573E and the secondary, which I not using, is an 82573L. So I assume it's not NIC revision related, but driver related. I've also tried to do a BMC cold and warm reset from ipmitool on the console, but that didn't help. It's probably just a lost cause.
 
You can download the em driver provided by Intel and patch/install/configure it :

http://downloadcenter.intel.com/Detail_Desc.aspx?lang=eng&changeLang=true&DwnldId=17509

Code: 
bash# tar xzf em-7.1.7.tar.gz
bash# patch -p0 <<_EOF
--- em-7.1.7/src/if_em.c 2011-09-15 17:00:56.000000000 +0200
+++ em-7.1.7/src/if_em.disable_crc_stripping.c 2011-09-15 17:00:42.000000000 +0200
@@ -334,6 +334,12 @@
 #define CSUM_TSO 0
 #endif
 
+static int em_disable_crc_stripping = 0;
+TUNABLE_INT("hw.em.disable_crc_stripping", &em_disable_crc_stripping);
+
+SYSCTL_NODE(_hw, OID_AUTO, em, CTLFLAG_RD, 0, "EM driver parameters");
+SYSCTL_INT(_hw_em, OID_AUTO, disable_crc_stripping, CTLFLAG_RD, &em_disable_crc_stripping, 0, "Disable CRC Stripping");
+
 static int em_tx_int_delay_dflt = EM_TICKS_TO_USECS(EM_TIDV);
 static int em_rx_int_delay_dflt = EM_TICKS_TO_USECS(EM_RDTR);
 TUNABLE_INT("hw.em.tx_int_delay", &em_tx_int_delay_dflt);
@@ -4152,7 +4158,8 @@
 	    (hw->mac.mc_filter_type << E1000_RCTL_MO_SHIFT);
 
         /* Strip the CRC */
-        rctl |= E1000_RCTL_SECRC;
+        if (!em_disable_crc_stripping)
+            rctl |= E1000_RCTL_SECRC;
 
         /* Make sure VLAN Filters are off */
         rctl &= ~E1000_RCTL_VFE;
_EOF
bash# cd em-7.1.7/src/
bash# make
bash# make install
bash# echo "if_em_load=\"YES\"" >> /boot/loader.conf
bash# echo "hw.em.disable_crc_stripping=\"1\"" >> /boot/loader.conf
bash# shutdown -r now

It should fix the issue
 
It would be great if you could get this patch committed. Unfortunately, I cannot risk taking this machine down as it's a few hours drive.. and without the IPMI working, I'd be screwed.
 
No, I did not try to implement this patch, nor did I mark this thread as solved. The machine I'm running is critical to my network and must be operational. Hopefully your patch is committed and will come down via freebsd-update at some point. Crossing fingers.
 
You must log in or register to reply here.
Back
Top