适用机型： NanoPi R5S (及其他可能的 RK3588/RK3568 架构设备)
系统版本： fnOS 1.1.18 (从 1.0.0 内置升级)
内核版本： Linux 6.12.x
故障描述
最近将 R5S 上的 fnOS 从 1.0.0 升级到 1.1.18 后，遇到了两个比较严重的问题：
- 无法软重启：在 WebUI 或 App 点击“重启”，或者 SSH 执行
reboot 命令后，系统会关机但无法重新启动，必须手动断 电再插电才能开机。
- UPnP 服务异常：后台日志显示
upnp.service 无限重启，导致局域网 UPnP 功能失效。
经过排查日志，确定了原因并成功修复，分享给遇到同样问题的机友。
问题一：软重启卡死（必须拔电）
1. 日志分析
查看 dmesg 或 journalctl -b -1，发现系统在启动或关机阶段出现 NPU（神经网络处理器）电源域握手失败，随后触发内核恐慌（Kernel Panic）：
rockchip-pm-domain ... power-controller: failed to get ack on domain npu, val=0x1fe
Internal error: synchronous external abort: ...
...
pc : rk_iommu_enable+0x...
lr : rk_iommu_enable+0x...
原因判定： 新版内核（6.12）的 NPU 驱动在电源管理上存在 Bug。系统在软重启（Reboot）尝试关闭硬件时，NPU 模块无响应导致总线锁死，卡在关机流程的最后一步，无法完成复位指令。
2. 修复方案（屏蔽 NPU）
对于 NAS 也就是存储和网络应用来说，NPU 通常用不到。通过屏蔽 NPU 驱动可以完美解决重启卡死问题。
SSH 登录终端，执行以下操作：
-
创建驱动黑名单文件：
sudo nano /etc/modprobe.d/blacklist-npu.conf
-
粘贴以下内容：
blacklist rknpu
blacklist rockchip_rga
blacklist rockchip_npu
-
保存退出（Ctrl+O, Enter, Ctrl+X），然后手动断 电重启一次使配置生效。
结果： 再次测试 WebUI 点击重启，系统已能正常完成软重启流程。
问题二：UPnP 服务无限重启
1. 日志分析
查看 UPnP 服务日志 journalctl -u upnp -f，发现大量报错：
error while loading shared libraries: libupnp.so.13: cannot open shared object file
upnp_service[xxx]: signal_handler sig: 15, state: 0
原因判定： 升级后系统缺少 libupnp.so.13 动态链接库，导致 UPnP 服务启动失败并陷入死循环。
2. 修复方案（补全依赖库）
直接通过 apt 安装缺失的库即可：
sudo apt update
sudo apt install libupnp13 libixml10
安装完成后，重启服务并观察日志：
sudo systemctl restart upnp.service
sudo journalctl -f -u upnp
结果： 日志显示 Started upnp.service，且不再有报错循环，UPnP 功能恢复正常。
总结
经过上述修复，目前的 R5S 在 fnOS 1.1.18 下：
- ✅ 软重启功能：恢复正常（已验证多次）。
- ✅ UPnP 服务：运行稳定，端口监听正常。
- ✅ 其他硬件：NVMe、2.5G 网卡、Docker 等均未受 NPU 屏蔽影响。
希望官方在后续版本中修复 RK35xx 系列（也可能是R5S个例）的 NPU 驱动电源管理问题，并补全 libupnp 依赖库。
