# FreeBSD 8.2-RELEASE-p2 + IPMI



## g0098 (Jul 14, 2011)

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.


----------



## Fravadona (Sep 13, 2011)

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.


----------



## g0098 (Sep 14, 2011)

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.


----------



## Fravadona (Sep 15, 2011)

I got it working yesterday, and I have an 82573E NIC too. 
There are several difficulties, but it is not a lost cause 

http://www.mail-archive.com/freebsd-questions@freebsd.org/msg249882.html (the reply to this post is ongoing)


----------



## Fravadona (Sep 15, 2011)

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


```
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


----------



## g0098 (Sep 20, 2011)

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.


----------



## Fravadona (Sep 20, 2011)

Actually I don't know where to ask for committing it. Nobody in freebsd-questions@freebsd.org replied to me about that ...


----------



## ondra_knezour (Sep 20, 2011)

Fravadona said:
			
		

> Actually I don't know where to ask for committing it.



You can fill problem report with patch attached. Writing FreeBSD Problem Reports may help.


----------



## Fravadona (Oct 4, 2011)

Ok thank you, I just submited the PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=161277


----------



## Fravadona (Oct 14, 2011)

g0098, You marked this thread as "solved" so I guess you did try the patch on your box successfully ?


----------



## g0098 (Oct 16, 2011)

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.


----------

