IT老兵2025-CSDN博客

原创 ubuntu22.04安装NVIDIA显卡驱动出错“Warning: Compiler version check failed”

基于ubuntu22.04安装NVIDIA显卡驱动中碰到问题，其失败日志提示“Warning: Compiler version check failed”。原因是系统默认安装的gcc版本为11.4.0，而近期系统进行了内核版本升级，新版本内核是基于gcc-12.3.0编译的，二者编译器版本不一致导致了显卡驱动编译失败。对应的解决方案就是升级gcc版本到gcc-12.3.0，完成gcc的版本升级和链接切换后，重新执行前述显卡驱动安装的最后一步就可以了。

2025-06-04 10:42:24 1077

原创几个网卡接交换机工作不正常的案例

本文分享了两个网卡与交换机兼容性问题的案例及解决方案。1）网讯WX1860Ax千兆网卡与H3C-S1280交换机存在物理兼容性问题，更换任意一方后恢复正常；2）古老的RTL-8139百兆网卡与千兆交换机存在兼容性问题导致断联丢包，改用TPLINK百兆交换机后问题解决。通过这两个案例可以看出，在遇到网卡工作异常时，需考虑设备间的兼容性因素，老旧的网络设备建议搭配同速率级别的交换机使用。

2025-05-28 17:12:01 535

原创 RK3588部署Zipformer模型问题总结

本文分享了在RK3588嵌入式设备上部署小米Zipformer语音识别模型时遇到的问题及解决方法。主要遇到两个问题：1）在rknn_model_zoo例程编译时出现静态库版本不兼容，通过重新编译kaldi-native-fbank库并修改链接路径解决；2）sherpa-onnx编译时提示缺少portaudio库，通过修改编译脚本启用相关宏定义后成功编译。最终成功在RK3588上运行Zipformer模型，测试结果显示该模型具有较好的识别效果和实时性（RTF=0.22），验证了其在边缘设备上的适用性。

2025-05-28 12:01:10 1016

原创鲲鹏服务器PCIE加速卡驱动异常问题

摘要：本文分析了某PCIE加速卡在鲲鹏服务器上出现性能异常的问题。系统日志显示list队列存在重复分配和释放的节点错误，问题仅出现在ARM64架构的鲲鹏服务器。经分析，这是由于ARM64的弱内存一致性模型和编译器优化导致指令乱序执行，使得驱动层与加速卡间队列操作不同步。通过在关键函数xx_doMsgReq和xx_instan_read中添加内存屏障mb()指令，解决了队列移位与寄存器操作间的乱序问题。该问题体现了不同CPU架构在内存模型上的差异，为ARM64平台驱动开发提供了重要参考。

2025-05-24 19:16:57 1223

原创实时linux系统中的异常告警BUG: scheduling while atomic

实时linux系统日志中偶尔出现“BUG: scheduling while atomic...”异常。经过分析，发现问题源于percpu_up_read函数的不可抢占设计与实时补丁中可抢占锁机制的冲突。解决方案包括：1）局部性方案通过改造__percpu_up_read函数；2）全局性改造实时补丁中rt_spin_lock实时自旋锁函数，增加对当前cpu的抢占值preempt_count的检查。

2025-05-22 15:35:53 899

原创利用gdb定位线程栈被破坏场景: Backtrace stopped

在调试RK3399模块时，开发人员遇到程序启动时小概率异常的问题。使用gdb调试时，发现主线程被挂死，且线程栈信息被破坏，无法完整查看。通过gdb的x命令分析寄存器信息和内存信息，最终定位到问题根源：公共日志函数Kb_LogStr中的日志长度判断不足，导致vfprintf内存溢出，进而引发系统异常和死锁。解决方案包括修复Kb_LogStr中的日志长度判断问题，并修改信号量处理回调函数ITP_Handle_Sig中的日志调用逻辑，避免死锁。

2025-05-18 12:28:29 1147

原创参数类型定义不当导致的内存分配失败

问题出现在一个LDPC解码仿真程序中，当输入校验矩阵的维度较大时，程序启动时会因内存分配失败而闪退。通过调试日志，作者发现内存分配失败的原因是变量类型定义溢出，具体是使用了2字节的short类型，当矩阵节点数量超过该类型表示的最大值时，相关变量会溢出变为负数，导致内存分配失败。解决办法是将相关变量的类型改为范围更长的int或long类型，并同步修订全局的INX宏定义。此外，作者建议在定位问题时，可以通过gdb对函数加断点进行启动调试，以提高定位效率

2025-05-16 11:21:27 383

原创 dpdk20.02.1 kni虚拟网卡bonding问题“BUG: scheduling while atomic“

在高性能云机项目中，使用dpdk20.02.1版本时，尝试将多个kni虚拟网卡bonding生成一个对外业务IP时，遇到了“BUG: scheduling while atomic”异常。系统日志显示，在设置kni虚拟网卡的“promiscuous”属性时，触发了内核函数调用链，导致在RCU读取临界区内尝试调度，违反了内核的原子上下文规则。解决方案有两种：一是修改dpdk kni代码，在kni_net_process_request中增加禁用抢占的判断；二是升级dpdk到21.11以上版本。

2025-05-15 18:31:07 796

原创驱动压测中报错watchdog: BUG: soft lockup - CPU#5 stuck for 22s

由于上述两次原子锁调用是同一把锁（用锁保护同一个消息队列），导致了系统死锁，系统watchdog在死锁超时（这里是20s）后发出系统告警“watchdog: BUG: soft lockup - CPU#5 stuck for 22s”，同时死锁也会导致被锁"CPU#5 stuck"，最终系统异常。分析清楚原因之后，对应的解决办法也很明了：将来自两个方向的请求报文分别保存到两个不同的驱动工作队列分别处理，每个队列对应一把独立的原子锁，避免前述系统日志中出现的单个原子锁因系统中断导致的重入死锁问题。

2025-05-14 17:14:57 542

原创 RK3588成功部署 Qwen3-1.7B模型

1 选定Qwen3-1.7B模型。综合考虑rknn-llm官网支持Qwen3模型的种类和手头RK3588测试板资源情况（只有4G内存），决定选用Qwen3-1.7B模型进行部署测试2 模型转换；rknn-llm运行库一定要下载最新版本，直接在 DeepSeek-R1-Distill-Qwen-1.5B_Demo目录下，通过将原来的export_rkllm.py简单改造成export_rkllm-qwen3.py脚本。3 RK3588上部署测试。

2025-05-12 18:19:08 879

原创 RK3588部署DeepSeek-R1-Distill-Qwen-1.5B问题总结

模型部署过程中碰到几个耗时费力的棘手问题：1）从huggingface.co下载DeepSeek-R1-Distill-Qwen-1.5B 权重文件失败。2）使用rkllm工具转换生成 DeepSeek-R1-Distill-Qwen-1.5B.rkllm 模型时出现“CUDA out of memory”错误。3）从 ModelScope 下载预编译好的 rkllm文件时出现异常的DeepSeek-R1-Distill-Qwen-1.5B.rkllm文件。

2025-05-11 16:51:35 451

原创高性能云机系统实践4-性能优化问题分享

问题1：出现某个核心ksoftirqd线程CPU占用率100%问题。问题2：驱动算法与网卡中断的CPU核心绑定策略。问题3：双通道内存配置问题。两条DDR插在了槽位1和2（主板有4个DDR槽位），不是按双通道配置规则的1/3槽位或2/4槽位间隔配置的，实际还是单通道配置。

2025-05-10 22:03:51 313

原创高性能云机系统实践3-内核旁路技术

一种基于内核旁路技术的高性能密码服务方案，其数据流路径如下：外部请求报文（网络）=>主机网卡驱动（收）=》内核业务逻辑驱动=》请求密码卡驱动=》密码卡=》密码卡驱动响应=》内核业务逻辑驱动回调=》主机网卡驱动（发）=》（网络）响应报文。实施内核旁路技术还有一个关键技术点：利用linux内核中netfilter框架hook点对来自该网卡的特定IP端口的skb报文（sk_buff）进行拦截处理，比如在5个hook点中的NF_INET_PRE_ROUTING或者NF_INET_LOCAL_IN设置hook回调。

2025-05-10 14:35:25 255