背景
有一台arm服务器上面出现了nvme磁盘无法识别的情况,比较奇怪
- 硬件1+ 内核1+ debian系统可以识别
- 硬件1+ 内核1+ openeuler系统可以识别
- 硬件2+ 内核2+ debian系统可以识别
- 硬件2+ 内核2+ openeuler系统不能识别
从上面的组合来看,内核没有问题,操作系统只是软件层面的,识别的模块都在内核里面,系统也没有问题的,在组合一的时候也能正常识别
硬件2与硬件1的区别就是带的盘更多了,其它没什么变化
这里有个现象是
如果在启动好了以后,再重新加载一次pcie的nvme,又能够识别
排查过程
正常识别的有下面的驱动显示
1 2 3 4
| root@node118:~ 0001:11:00.0 Non-Volatile memory controller: Phison Electronics Corporation Device 5018 (rev 01) Subsystem: Phison Electronics Corporation Device 5018 Kernel driver in use: nvme
|
正常识别的日志
1 2 3 4 5
| Feb 14 08:42:21 linaro-alip kernel: [ 9.649140] nvme nvme0: pci function 0001:11:00.0 Feb 14 08:42:21 linaro-alip kernel: [ 9.659798] nvme 0001:11:00.0: enabling device (0000 -> 0002) Feb 14 08:42:21 linaro-alip kernel: [ 9.663384] nvme nvme0: Shutdown timeout set to 10 seconds Feb 14 08:42:21 linaro-alip kernel: [ 9.671126] nvme nvme0: 8/0/0 default/read/poll queues Feb 14 08:42:21 linaro-alip kernel: [ 9.673336] nvme0n1:
|
异常的情况日志
1 2 3
| Feb 17 15:31:57 openeuler kernel: [ 9.657886] nvme nvme0: pci function 0001:11:00.0 Feb 17 15:31:57 openeuler kernel: [ 9.664677] nvme 0001:11:00.0: enabling device (0000 -> 0002) Feb 17 15:31:57 openeuler kernel: [ 9.664733] nvme nvme0: Removing after probe failure status: -19
|
重新加载
1 2 3 4 5 6 7 8
| [root@openeuler ~] [root@openeuler ~] [ 779.433580] pci 0001:11:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0001:10:00.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link) [ 779.438205] pci 0001:11:00.0: BAR 0: assigned [mem 0xf1200000-0xf1203fff 64bit] [ 779.438562] nvme nvme0: pci function 0001:11:00.0 [ 779.442613] nvme nvme0: Shutdown timeout set to 10 seconds [ 779.450280] nvme nvme0: 8/0/0 default/read/poll queues [ 779.452607] nvme0n1: p1
|
这里可以看到设备能够识别,但是跟nvme通信的时候存在问题
搜索相关的资料发现了一个相关的问题
1 2
| cat /sys/module/pcie_aspm/parameters/policy 这个看到是powersave
|
这个是pcie的aspm管理,这个是电源管理相关的,上次碰到一个三星的nvmessd 使用比较长一段时间后出现离线的问题,就是这个类似的问题
这次不同的情况是,在启动加载的时候就出现了无法加载的情况
猜测可能默认节能模式,然后机器的电流不足
处理方式
在内核启动参数里面增加
检查设置的情况
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
| [root@openeuler log] 0001:11:00.0 Non-Volatile memory controller: Phison Electronics Corporation E18 PCIe4 NVMe Controller (rev 01) (prog-if 02 [NVM Express]) Subsystem: Phison Electronics Corporation E18 PCIe4 NVMe Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 149 Region 0: Memory at f1200000 (64-bit, non-prefetchable) [size=16K] Capabilities: [80] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
|
设置成功后,通过lscpi可以检查
这个就是关闭了
重启后验证识别了
总结
在低功耗的arm硬件下,nvme盘的电源相关的管理可能触发一些问题,内核的驱动适配问题,低版本内核并没有提供很好的驱动管理,而arm的内核一般更新没那么快,硬件上面的固件又比较新
出现问题的情况下,可以考虑关闭掉这个地方的aspm的功能