1.问题现象

某运营商国产服务器操作系统项目，部署Kylin-Server-0524-aarch64服务器系统，内核从4.19.90-24.4升级到4.19.90-25.14。在grub中配置huagepages大页内存后，系统在内核启动阶段黑屏，只显示一个光标。grub配置如下图：

黑屏状态如下图：

2.问题分析

1.重启系统，在grub里面添加启动参数：console=tty0 loglevel=7 systemd.log_level=debug调高日志级别后，看到系统启动后卡住的时候报错：systemd-journald[1693]：Failed to open runtime journal:No space left on device，由于journald 生成的日志文件默认不是持久的，日志文件只存储在内存或/run/log/journal/目录中的一个小环形缓冲区中，可知，系统是由于内存不够，没法启动。提示信息如下图：

2.于是将grub里面设置的819个大页改为600个大页，也就是将default_hugepagesz=512M hugepagesz=512M hugepages=819改为default_hugepagesz=512M hugepagesz=512M hugepages=600，改完后可以正常进入系统，从而可以进一步确定系统启动不了的原因是由于内存不够引起的。

3.查看系统所保留空闲内存的最低限，sysctl -a | grep min_free_kbytes，发现min_free_kbytes的值为25G，如下图：

为了保证客户现场在hugepages=819的情况下能够正常进系统，我们将min_free_kbytes系统所保留空闲内存的最低限从25G调整为了128M，改完后如下图：

此时在hugepages=819的情况下，能够正常进入系统。

4.进入系统后，发现系统在没有启动任何业务系统的情况下（ps aux 也没有看到内存占用高的进程），内存使用了479G，而hugepages配置的只有409.5G，也就是说有大约70G的内存不知道是被什么进程占用的,free命令结果如下图：

ps aux没有发现内存占用高的进程，如下图：

5.重启系统，在grub界面继续增加启动参数：systemd.unit=emergence.target，让系统进入紧急模式，如下图：

在紧急模式中通过free查看内存占用，发现used为411G，由此怀疑是加载了某系驱动或者某些服务引起的问题。优先考虑到和磁盘缓存队列以及网卡缓存队列。

尝试在emergency模式中将正常系统启动后的驱动模块加载上来以及将正常系统的服务启动，发现当NetworkManager成功启动后，内存上升到了476G，由此可知该问题和NetworkManager服务强相关。

6.对比以4.19.90-24.4内核启动的系统以及以4.19.90-25.14内核启动的系统分别的ip信息，发现4.19.90-25.14的内核要比4.19.90-24.4的内核多识别了四张网卡：ens2f0、ens2f1、enP1s5f0、enP1s5f1。

4.19.90-25.14-kernel识别的网卡如下：

4.19.90-25.14-kernel识别的网卡如下：

查看ens2f0、ens2f1、enP1s5f0、enP1s5f1网卡对应的驱动，发现均为：ice，如下图：

所以不难推断，4.19.90-24.4的内核没有成功加载ice驱动，所以少识别了ens2f0、ens2f1、enP1s5f0、enP1s5f1这四张网卡。

7.为了验证第6点，对比启动4.19.90-24.4内核以及启动4.19.90-25.14内核后的lsmod信息，发现4.19.90-24.4内核没有成功加载ice驱动，而4.19.90-25.14内核已经成功加载了ice驱动。

4.19.90-24.4-kernel加载的ice驱动信息如下图：

4.19.90-25.14-kernel加载的ice驱动信息如下图：

于是将4.19.90-25.14内核的系统卸载ice驱动后，发现内存恢复正常。所以可以进一步定位该问题与ice驱动强相关。

8.继续在4.19.90-24.4内核的系统，执行insmod /usr/lib/modules/4.19.90-25.14.v2101.ky10.aarch64/kernel/drivers/net/ethernet/intel/ice/ice.ko.xz（加载4.19.90-25.14的ice驱动），发现ice驱动被成功加载，但是内存却使用正常，由此可知，4.19.90-25.14系统内核默认的ice驱动没有问题。怀疑有问题的时候加载的ice驱动并非系统自带。

9.于是执行find / | grep ice.ko | xargs md5sum，发现在/root/ice-1.5.8/src/目录下有客户自己编译的ice.ko驱动，并且加载到了系统的/usr/lib/modules/4.19.90-25.14.v2101.ky10.aarch64/updates/drivers/net/ethernet/intel/ice/目录下。

10.为了验证现场启动的4.19.90-25.14内核系统使用的是客户自己编译的ice.ko，我们重启系统，选择4.19.90-25.14内核进入系统，执行modinfo ice，发现当前系统使用的驱动版本为1.5.8，正好是现场自己编译的ice驱动，并非系统自带的ice驱动。继续modprobe -r ice卸载驱动，然后insmod 4.19.90-25.14内核自带的驱动，发现内存恢复正常。

11.为了进一步定位现场自己编译的ice驱动为什么会引起used增加，我们发现如下区别：

a.ice版本不一样：现场自己编的是1.5.8，而4.19.90-25.14内核自带的版本是0.7.2-k

b.由于ice版本的不一样，导致了ice驱动对与网卡的ring buffer值设置不一致。现场编译的ice驱动默认设置的网卡rx 为2048，而系统自带的ice驱动默认设置的网卡rx 为128

现场ice-1.5.8版本如下：

麒麟操作系统4.19.90-25.14内核自带的驱动版本如下：

现场ice-1.5.8对网卡默认rx设置如下：

麒麟操作系统4.19.90-25.14内核自带的驱动对网卡默认rx设置如下：

12.在加载现场编译的ice-1.5.8的驱动前提下，我们将网卡的rx队列调小，发现used也跟着变小了。

由此可知，由于ice驱动版本的不一样，导致网卡默认rx队列设置的值也就不一样，而网卡rx队列值调高会占用系统的内存，从而导致了内存的升高。

3.解决方案（结论）

结论：

1. 现场系统起不来的原因是由于可用内存不够引起的。
2. 内存不够的主要原因是因为系统加载了现场自己编译的ice驱动，该驱动默认将ens2f0、ens2f1、enP1s5f0、enP1s5f1这四张网卡的rx队列值设置为了2048，从而导致了开机就占用了较高的内存使用。

建议：

1. 删除现场自己编译的ice驱动，使用麒麟操作系统4.19.90-25.14内核自带的ice驱动。
2. 调小min_free_kbytes的值。