RK3588 PCIe 压测：从崩溃到排障的全流程解析

 

 

 

 

 

 

在RK3588平台上进行PCIe设备（如NVMe SSD）压测时，不少开发者遇到过这样的“噩梦”：高负载下系统突然失去响应，日志里满是异常信息，甚至直接崩溃重启。今天我们就结合关键日志和代码，拆解问题根源，分享一套可复用的排障思路。

 

 

一、问题现场：从日志看崩溃链条

 

 

我们先看两张关键日志截图：

NVMe驱动层的“超时风暴”

 

 

•  
•  
•  
•  
•  

[2026-01-08 1623.487] nvme nvme0: I/O 124 QID 4 timeout, aborting[2026-01-08 1623.487] nvme nvme0: I/O 125 QID 4 timeout, aborting[2026-01-08 1623.487] nvme nvme0: I/O 127 QID 4 timeout, aborting[2026-01-08 1623.487] nvme nvme0: I/O 128 QID 4 timeout, aborting[2026-01-08 1624.483] nvme nvme0: I/O 20 QID 0 timeout, reset controller

文件系统的“自我保护”

 

 

•  

[2026-01-08 1613.852] systemd-journald[258]: Failed to write entry (21 items, 734 bytes), ignoring: Read-only file system

从日志可以清晰看到事件链条：

 

 

1.NVMe I/O超时：驱动层频繁触发I/O请求超时，尝试abort操作。

 

 

2.控制器重置：超时后驱动尝试重置NVMe控制器，但问题持续。

 

 

3.只读文件系统：内核为保护数据，强制将文件系统设为只读，导致日志服务无法写入，系统陷入瘫痪。

 

 

二、根因剖析：三层拆解崩溃本质

 

 

要理解为什么超时会导致系统崩溃，需要从硬件能力、驱动配置、内核机制三个层面拆解：

 

 

1. 硬件层面：RK3588的PCIe性能瓶颈

 

 

RK3588作为边缘计算平台，其PCIe控制器的带宽和并发处理能力有限。高负载压测下，PCIe总线吞吐量和延迟急剧上升，导致NVMe设备I/O请求排队时间过长，无法在预设时间内完成。

 

 

2. 驱动层面：默认超时参数过于“激进”

 

 

从图三的内核代码可以看到，NVMe驱动的默认超时参数是为通用PC平台设计的：

 

 

•  
•  

unsigned int admin_timeout = 60;  // 管理命令超时60秒unsigned int nvme_io_timeout = 30; // I/O命令超时30秒

对于RK3588这类嵌入式平台，30秒的I/O超时时间在高负载下显得过于“苛刻”，极易触发超时机制。

 

 

3. 内核机制：数据保护的“双刃剑”

 

 

当NVMe驱动频繁触发超时和重置时，内核会判定存储设备不可靠，为避免数据损坏，自动执行mount -o remount,ro /操作，将根文件系统设为只读。这一机制虽保护了数据，但直接导致系统无法正常运行，表现为“崩溃”。

 

 

三、对症下药：超时参数调优方案

 

 

核心解决思路是延长NVMe驱动的超时时间，让I/O请求有足够时间完成，避免触发保护机制。

 

 

1. 内核代码修改

直接修改NVMe驱动的超时参数定义，将admin_timeout从60秒增至120秒，nvme_io_timeout从30秒增至120秒：

 

 

•  
•  
•  
•  
•  
•  

// 修改前unsigned int admin_timeout = 60;unsigned int nvme_io_timeout = 30;// 修改后unsigned int admin_timeout = 120;unsigned int nvme_io_timeout = 120;

修改后重新编译内核或NVMe驱动模块，使参数生效。

 

 

 

2. 调优建议

 

 

•渐进式调整：先将超时参数翻倍（30→60→120），观察压测表现，避免一次性设置过大隐藏问题。

 

 

•适配硬件能力：结合RK3588的PCIe带宽和NVMe设备性能，找到最适合的超时阈值，而非盲目增大参数。

 

 

四、排障心法：嵌入式压测的通用技巧

 

 

在RK3588这类嵌入式平台上进行性能压测，掌握以下技巧可大幅提升排障效率：

 

 

1.日志优先原则：始终从系统日志（dmesg、journalctl）入手，定位关键错误信息，避免盲目排查硬件。

 

 

2.分层排查法：

 

 

￮驱动层：检查设备驱动日志（如NVMe、PCIe），确认超时、错误码。

 

 

￮总线层：用lspci -vvv检查PCIe设备带宽、链路状态，确认是否降速或错误。

 

 

￮硬件层：检查设备供电、散热，避免因过热导致性能下降。

 

 

3.渐进式压测：从低负载到高负载逐步压测，记录系统表现，找到触发问题的阈值，针对性优化。

 

 

4.数据保护前置：压测前做好数据备份，可临时关闭文件系统只读保护（mount -o remount,rw /），但这只是临时手段，根本解决需处理超时问题。

 

 

五、总结：嵌入式性能调优的“慢思考”

 

 

RK3588 PCIe压测导致系统崩溃的问题，本质是通用驱动配置与嵌入式平台硬件能力不匹配的典型案例。默认的NVMe超时参数是为PC平台设计的，直接套用到嵌入式平台，就会在高负载下触发保护机制。

 

 

解决这类问题的核心，不是“硬扛”硬件性能，而是通过驱动参数调优适配平台能力，同时遵循“日志分析→分层定位→参数调优→渐进验证”的排障流程，才能高效、稳妥地解决问题。

---

审核编辑 黄宇