Max's Blog

bnx2x lastest driver version 1.714.22 dkms deb for debian

今天牛一，苦逼编译驱动ing…遇上bnx2x这种N百年没更新的驱动，折腾了一下。

从联想的网站找到比较新鲜的驱动，RHEL的可以自取：

Qlogic BNX2 RHEL7 Driver for 2019A

https://support.lenovo.com/us/en/downloads/ds539514

问题是我的系统是debian，都是linux，拿过来看看Makefile，里面写了ubuntu的逻辑，替换一下，补一个标准的dkms.conf，默认编译参数，做了一个dkms包。

https://ssmax.net/bnx2x-dkms_1.714.22_all.deb

在debian jessie backport的 4.9.0-0.bpo.11-amd64 内核上测试通过，用着没啥问题，如果还死机的话我看厂家还赖啥，tnnd。

modinfo

filename:       /lib/modules/4.9.0-0.bpo.11-amd64/updates/dkms/bnx2x.ko
 version:        1.714.22
 license:        GPL
 description:    QLogic BCM57710/57711/57711E/57712/57712_MF/57800/57800_MF/57810/57810_MF/57840/57840_MF Driver
 author:         Eliezer Tamir
 srcversion:     661EA2727311E076D455A13
 alias:          pci:v000014E4d0000163Fsvsdbcsci*
 alias:          pci:v000014E4d0000163Esvsdbcsci*
 alias:          pci:v000014E4d0000163Dsvsdbcsci*
 alias:          pci:v00001077d000016ADsvsdbcsci*
 alias:          pci:v000014E4d000016ADsvsdbcsci*
 alias:          pci:v00001077d000016A4svsdbcsci*
 alias:          pci:v000014E4d000016A4svsdbcsci*
 alias:          pci:v000014E4d000016ABsvsdbcsci*
 alias:          pci:v000014E4d000016AFsvsdbcsci*
 alias:          pci:v000014E4d000016A2svsdbcsci*
 alias:          pci:v00001077d000016A1svsdbcsci*
 alias:          pci:v000014E4d000016A1svsdbcsci*
 alias:          pci:v000014E4d0000168Dsvsdbcsci*
 alias:          pci:v000014E4d000016AEsvsdbcsci*
 alias:          pci:v000014E4d0000168Esvsdbcsci*
 alias:          pci:v000014E4d000016A9svsdbcsci*
 alias:          pci:v000014E4d000016A5svsdbcsci*
 alias:          pci:v000014E4d0000168Asvsdbcsci*
 alias:          pci:v000014E4d0000166Fsvsdbcsci*
 alias:          pci:v000014E4d00001663svsdbcsci*
 alias:          pci:v000014E4d00001662svsdbcsci*
 alias:          pci:v000014E4d00001650svsdbcsci*
 alias:          pci:v000014E4d0000164Fsvsdbcsci*
 alias:          pci:v000014E4d0000164Esvsdbcsci*
 depends:        mdio,libcrc32c,ptp
 retpoline:      Y
 vermagic:       4.9.0-0.bpo.11-amd64 SMP mod_unload modversions 
 parm:           pri_map: Priority to HW queue mapping (uint)
 parm:           full_promiscous: Accept unmatched unicast packets (Disabled default) (uint)
 parm:           num_queues: Set number of queues (default is as a number of CPUs) (int)
 parm:           disable_iscsi_ooo: Disable iSCSI OOO support (uint)
 parm:           disable_tpa: Disable the TPA (LRO) feature (uint)
 parm:           int_mode: Force interrupt mode other than MSI-X (1 INT#x; 2 MSI) (uint)
 parm:           dropless_fc: Pause on exhausted host ring (uint)
 parm:           poll: Use polling (for debug) (uint)
 parm:           mrrs: Force Max Read Req Size (0..3) (for debug) (int)
 parm:           debug: Default debug msglevel (uint)
 parm:           num_vfs: Number of supported virtual functions (0 means SR-IOV is disabled) (uint)
 parm:           autogreeen: Set autoGrEEEn (0:HW default; 1:force on; 2:force off) (uint)
 parm:           native_eee:int
 parm:           eee:set EEE Tx LPI timer with this value; 0: HW default; -1: Force disable EEE.
 parm:           tx_switching: Enable tx-switching (uint)
 parm:           use_random_vf_mac:When set, all VFs would be configured with a default immutable MAC (uint)
 parm:           allow_vf_mac_change_mode:Allow VF to change MAC address despite PF sets force MAC (0 Disable (default); 1 Enable)) (uint)
 parm:           fairness_threshold:When set to '1' will enable the fairness threshold; 0 by Default (uint)
 parm:           intr_mitigation:When set to '1' will enable the interrupt mitigation; 0 by Default (uint)

由于Office 2016 实现了OSX新的sanbox api，所以导致直接更改邮件存放路径，然后使用软链接link回来的做法失效

下面就是一个小日本琢磨出来的解决方案，试过有效，共享一下：

sudo su
cd "/Applications/Microsoft Outlook.app/Contents/MacOS/"
hexdump -ve '1/1 "%.2X"' "Microsoft Outlook" | \
sed "s/73616E64626F783C2F6B65793E0A093C747275652F3E/73616E64626F783C2F6B65793E0A093C66616C732F3E/g" | \
xxd -r -p > "Microsoft Outlook.patched"
# search com.apple.security.app-sandbox
# change the value to false
chown YOURUSER "Microsoft Outlook.patched"
chmod `stat -f %A "Microsoft Outlook"` "Microsoft Outlook.patched"
mv "Microsoft Outlook" ~/Desktop/Microsoft\ Outlook.bak
mv "Microsoft Outlook.patched" "Microsoft Outlook"
ln -s "/Volumes/TarDisk/Outlook" "/Users//Library/Group Containers/UBF8T346G9.Office/Outlook"

其实就是关掉了sanbox，false没有完整拼写是为了保留字节数不变，不需要重新编译。
这样就可以把目录链接到别的盘了
另外一个解决方案是实用hdiutil attch 一个mountpoint，这个比较简单一点，但是我没有闲心慢慢看下去，比较喜欢粗暴一点，哈哈。

更改之后，如果你有多个邮箱，用户名密码会保存不下来，这是因为程序签名破坏了，要对程序进行重签
先在钥匙串里面新建一个自签名证书，然后信任它，最后重签，–no-strict 这个是个坑（遇到报错 main executable failed strict validation 的话）

codesign -f -s "YOUR SELF-SIGNED CERT NAME" --no-strict --deep "/Applications/Microsoft Outlook.app/"

3月份提了一个mysql的bug，现在是11月了，终于确认了。。。

http://bugs.mysql.com/bug.php?id=68568

被oracle收购了之后果然就不是想继续开发下去的节奏了，唉，可惜了好好的一个免费产品。

今天继续折腾内核了，升级到 3.2.50

查了一下资料 ， ubuntu 12.04 和 debian 7 都是使用3.2版本的内核了。

找了debian的kernel deb包，在pool的linux下面，解压获得debian最新的config文件，基本该有的都有了，比ubuntu的靠谱一点，编译了以后资源占用不高。

这个版本应该可以稳定了。不错不错。

CONFIG_DEBUG_INFO 记得设置为n，要不编译出来的文件那就一个大啊，所有模块都支持gdb，大10倍。。。

前两天升级内核到3.0.90，用的是centos 5.9的 oldconfig，但是由于2.6.18的config文件实在是太老了，用它来做oldconfig，发现很多新内核的特性没有编译进来，最简单的哦iptalbes NAT模块都没有。。。

所以这几天都在折腾内核，折腾了几次之后，决定用centos 6.4的config文件做基础，来进行oldconfig，6.4的config文件从对应的rpm里面提取，编译的过程中遇到不少坑，现记录如下：

1、坑一
新config的scsi_mod会默认编译进内核，而不是作为模块存在了

CONFIG_SCSI_MOD=y
CONFIG_SCSI=y

但是CONFIG_BLK_DEV_SD依旧是m，那样导致scsi_mod编译到内核了，而sa_mod 依然在外面，最后mkinitrd的时候，由于scsi_mod 没有了，所以sa_mod 也不会带到initrd引导里面，导致我在vmware测试的时候老是说找不到盘。。。

调试了非常久的时间，中间还学会了一招，在内核启动崩溃的时候，虚拟机有个很方便的设置，配置一个串行接口，输出到文件，然后
kernel后面加参数 console=ttyS0 就会输出到这个文件，调试内核就方便很多。

所以，编译的时候记得要不就把三个都编译进内核，要不三个都m，要不就自己解压initrd把module加上去。

CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y

#当然不要忘记这两个
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y

2、坑二
hwclock在新内核里面无法使用，这个问题是由于新内核已经使用了新的RTC设计

CONFIG_RTC_CLASS=y

当这个参数存在的时候，无法再使用CONFIG_RTC这个参数来支持旧的RTC设置，这两个模块是互斥的，但是在说明文档里面没有详细说明
CONFIG_RTC_CLASS 会生成一个 /dev/rtc0 的设备，大小类分别是 254 0 ， 而不是原来的10 135，这个大小类的char设备在CONFIG_RTC_CLASS配置里面不再存在了。

但是mkinitrd命令生成initrd的时候，还是会在init脚本里面加上一句

mknod /dev/rtc c 10 135

所以如果你要想hwclock可用，要不就升级hwclock版本，新版本支持读取rtc0设备
要不就解压initrd，自己修改init脚本，如下操作：

mkdir /root/init
cd /root/init
zcat /boot/initrd-3.0.91.img | cpio -di

#编辑init文件，找到rtc，改为
mknod /dev/rtc c 254 0

#保存退出，当然现在可以在启动时加上你自己喜欢的模块，或者去掉你不想要的模块了
#这里也要检查下和旧版本的区别，以防启动不了

find . | cpio -c -o | gzip -9 -c > /boot/initrd-3.0.91.img 

这样重新引导之后，就可以直接使用hwclock来同步系统和主板的时间了

3、坑三
网卡顺序在不同内核里面，会由于MSI的读取和udev的版本而呈现不同的顺序，我在服务器上面启动内核的时候，eth0和eth1的模块都是bnx2
在旧的内核里面mac0对应eth0， mac1对应eth1，但是在新版本的读取里面，就反过来了，mac1对应eth0， mac0对应eth1
导致原来的配置文件出问题了，网卡没有启动。。。
在网上查了很久，总结了好几个解决办法
第一个，启动加参数pci=nomsi，没有测试过，但是觉得既然系统引入了这个功能，总有它的用处，所以没改
第二个，改udev规则，在udev启动网卡的时候，设定具体的mac地址，/etc/udev/rules.d/60-net.rules，写死在这里，个人觉得也没有这个必要吧
第三个，自己琢磨出来的，在看udev规则的时候，看到这样一句

cat /etc/udev/rules.d/60-net.rules
ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="/lib/udev/rename_device"
SUBSYSTEM=="net", RUN+="/etc/sysconfig/network-scripts/net.hotplug"

怎么有个rename的程序。。。看样子有戏，查资料
rename_device, which searches the ifcfg-* files for a HWADDR that matches the new device and uses the DEVICE setting from that file to give a name to the new interface.

看到这里，恍然大悟，centos为了这种情况，已经出来应对方案了，只要在
/etc/sysconfig/network-scripts/ifcfg-eth*
网卡的配置文件里面，写好了HWADDR 和DEVICE ，就会自动按照这个参数重命名

如下：

BOOTPROTO=static
ONBOOT=yes
DEVICE=eth0
TYPE=Ethernet
IPADDR=123.123.123.123
NETMASK=255.255.255.0
GATEWAY=123.123.123.1
HWADDR=00:12:34:56:78:23

记得两个网卡都设置下HWADDR，就行了，重启之后，udev启动网卡的时候，就会按照这个配置里面的设置，重命名网卡。

4、不知算不算坑
新内核启动之后，一切正常，但是几个kworker的进程，时不时的占用着一些cpu资源（在vmware里面），我记得以前在kvm和vmware的vps里面安装centos 6，也碰到过类似问题。
这个kworker好像是响应bios事件的，网上说了一堆，但暂时没有发现什么好办法。。。

在服务器上面，就有一个kimpi0的进程，也是类似的占用，该死dell服务器带有ipmi模块，刚好新内核把impi_si 也编译到内核中了。。。
但是我们的ipmi没有使用，所以还是把这个禁用掉吧，由于已经编译到内核，没办法不加载。。
在kernel加上参数：

kernel /vmlinuz-3.0.91 ro root=LABEL=/ ipmi_si.force_kipmid=0

先应付着吧，再观察几天看看，自己编译内核真是一个体力+技术活，没有测试好的config不敢放到服务器上面跑，但是服务器环境毕竟和vmware的不一样，来回折腾啊。
以后有水平了再针对服务器做精简内核吧，现在还是参考别人的成熟经验，适合多数服务器的配置。

希望这次编译的稳定，就可以开启ssd的TRIM了！估计也是这些原因，最后centos还是不支持从5直接升级到6。。。