GPU 设备 kernel:BUG: soft lockup - CPU#8 stuck for 66s! 问题

最新推荐文章于 2025-05-14 17:14:57 发布
原创 最新推荐文章于 2025-05-14 17:14:57 发布 · 6.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#gpu

本文解决了一台运行Red Hat Enterprise Linux Server 6.4 (Santiago)的服务器遇到的软锁定问题，通过修改/boot/grub/menu.lst文件和将服务器UEFI升级到最新版本，并将intel_iommu参数从'on'改为'off'，成功解决了CPU长时间挂起的问题。
部署运行你感兴趣的模型镜像
操作系统版本：（RHEL 6.2 没有这个问题)

[root@ibm2e-215 ~]# more /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.4 (Santiago)
[root@ibm2e-215 ~]# uname -a
Linux ibm2e-215 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

报错信息：

Message from syslogd@ibm2e-215 at Jul 23 15:12:08 ...
kernel:BUG: soft lockup - CPU#8 stuck for 66s!

解决办法：

需要修改/boot/grub/menu.lst  同时将服务器UEFI升级到最新；




将intel_iommu=on 修改为intel_iommu=off  

重启系统问题可以解决；




您可能感兴趣的与本文相关的镜像

Wan2.2-I2V-A14B

Wan2.2-I2V-A14B

图生视频
Wan2.2

Wan2.2是由通义万相开源高效文本到视频生成模型，是有​50亿参数的轻量级视频生成模型，专为快速内容创作优化。支持480P视频生成，具备优秀的时序连贯性和运动推理能力

clwucn
关注
Linux系统报错NMI watchdog: BUG: soft lockup - CPU#5 stuck for 24s
邓邓子的博客
05-12 7747
目录一、问题描述二、解决方法1.将 watchlog_thresh 临时设置为 302.将 watchlog_thresh 永久设置为 303.将 watchlog_thresh 写入启动文件 一、问题描述 Linux 系统响应变慢，显示错误信息如下： May 9 14:43:05 localhost kernel: NMI watchdog: BUG: soft lockup - CPU#5 stuck for 24s! [watchdog/5:34] May 9 14:43:05 localhos
CentOS 7 - kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck
专注数据库、大数据领域干货分享，用严谨的数据技术广交天下朋友。
11-19 3006
Soft lockup就是内核软死锁，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。跑大量高负载程序，造成cpu soft lockup。遇到了 kernel 的问题，记录一下～
解决类似 BUG: soft lockup - CPU#2 stuck for 67s! 问题的思路
02-11 9003
编写内核程序，出现soft lockup错误是再常见不过了。 刚开始调试内核时，出现这样的错误，往往两眼一麻黑不知道该如何下手了。但其实，这样的问题解决多了，会发现基本就两种情况，死锁和死循环。 所以，在出现soft lockup错误时，不用慌张，只要分析相关代码是不是存在死循环，比如 for循环的退出条件弄错了导致循环无法退出，等等；或者就是分析是不是相关代码在使用锁不当导致了死锁。比如，s
kernel:NMI watchdog: BUG: soft lockup - CPU#8 stuck for 23s!
weixin_44455388的博客
10-25 1万+
问题描述： 最近服务器总是莫名其妙弹出类似以下的信息： 问题原因： 通过查找资料，得知是因为系统一直处在高负载的状态，出现了内核软死锁（soft lockup）。 参考：https://blog.csdn.net/jiangganwu/article/details/89711354 关于内核死锁（soft lockup）： 所谓soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用
kernel:NMI watchdog: BUG: soft lockup - CPU
luyanpingya的博客
03-11 3380
如果由于某种原因计时器达到了预定的阈值而没有被重置（意味着系统可能卡住或无响应），看门狗就会生成NMI中断，以引起系统的注意。软死锁通常发生在CPU长时间占用内核模式，没有释放给其他进程或线程运行的机会，但系统并没有完全崩溃，仍有一定的响应能力。进程名称可以给出一些关于进程功能或来源的线索，但具体含义可能需要结合使用该进程的软件或系统文档来理解。这可以帮助你判断该进程是由你启动的，还是由系统的其他用户或服务启动的。（对于给定的进程ID）可以查看更多关于该进程的信息，如启动命令、启动时间等。
【实战】磁盘IO导致的Linux 内核错误 soft lockup-CPU 3 stuck for 22s!
美好源于自律
04-29 9693
一、背景 公司生产环境某应用程序所在的CENTOS虚拟主机的系统日志了同现如下日志提示： kernel: BUG: soft lockup - CPU#3 stuck for 22s! [xxxx:48] 其中xxxx部分有多个不同类型的程序，如ksoftirqd,khugepaged,kworker,nginx,java等。 因为出现此错误提示时，相应的java应用服务通常也会出现访问不了的情况，于是公司的运维同事直接粗暴认为是相应的java程序代码写了死循环导致，但通过排查代码，并未有发现明显会
报错 watcgdog: BUG； soft lockup -CPU#0 stuck for 26s! [swapper/0:1]
qq_54947566的博客
03-06 2047
这样的错误信息，通常表示系统遇到了“软锁定”（soft lockup）问题。软锁定是指某个 CPU 核心在指定的时间内没有响应内核的调度请求，导致系统认为该 CPU 核心被“卡住”了。
报错 kernel:NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [insmod:55902]处理
墨染锦年的博客
03-16 1万+
运行之前说的tcrypt.c的修改程序（只跑摘要算法md5，sha1） insmod tcrypt.ko sec=2 mode=400 报错 kernel:NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [insmod:55902] 并且有堆栈 [106091.127829] testing speed of async md5 (md...
活久见 kernel:NMI watchdog: BUG: soft lockup - CPU#8 stuck for 28s! [xsoftdd/12:0]
ybdesire的专栏
05-08 3749
1. 引入 在一台linux机器上工作，没敲入任何命令，但命令行里突然出现 “kernel:NMI watchdog: BUG: soft lockup - CPU#8 stuck for 28s! [xsoftdd/12:0]” 这样的报错，如下图所示： 报错后，又能正常在命令行里运行命令了。 这是怎么回事呢？ 2. soft lockup 在google上查到soft lockup相关的解释（参考3）： A soft lockup is the symptom of a task or kernel
watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [swapper/0:1]
无线互联&网络介绍
09-03 1829
这里没有在kernel 添加lockdep配置，打印的calltrace信息，测试代码逻辑比较简单，所以能一眼看出来lockdep_test_init中有问题。Linux内核中打开lockdep功能，需要打开。
解决bug：kernel:NMI watchdog: BUG: soft lockup - CPU#8 stuck for 23s!
kayotin的博客
08-31 5656
解决虚拟机出现的watchdog lockup问题
centos7：watchdog bug :soft lockup -cpu#3 stuck for 30s
ayychiguoguo的博客
01-05 9846
问题：CPU资源长期使用率过高导致系统内核软死锁 服务器跑大量高负载程序，会造成cpu soft lockup kernel watchdog是用来检测Lockup 的，所谓lockup，是指某段内核代码占着CPU不放，Lookup严重的时候会导致整个系统失去响应 Soft lockup是指CPU被内核代码占据，以至于无法执行其它进程 解决方法： 重启，账号密码登录系统 查看/proc/sys/kernel/watchdog_thresh中的参数 #tail -1 /proc/sys/kernel/wat
BUG: soft lockup - CPU#0 stuck for 61s!
热门推荐
Rain的专栏
10-10 2万+
BUG: soft lockup - CPU#0 stuck for 61s! 目前看来就是内核中有死循环！ 解决BUG: soft lockup - CPU#0 stuck for 61s!问题 1 在网上看到很多软死锁的问题，经过对自己程序的理解，结合网上一些相关资料，基本上可以确定是由于内核bug造成的，这个问题基本上在内核模块加载或者卸载的时候发生，对我的模块而言，每
报错：　watchdog: BUG: soft lockup - CPU#0 stuck for 23s
Top_xiao的博客
06-28 1万+
转载：https://www.cnblogs.com/nulige/p/8000490.html 解决办法: #追加到配置文件中 echo 30 > /proc/sys/kernel/watchdog_thresh #查看 [root@git-node1 data]# tail -1 /proc/sys/kernel/watchdog_thresh 30 #临时生效 sysc...
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
咸鱼的梦想专栏
08-27 1万+
报错现象 系统或者网络占用过多CPU，造成内核软死锁（soft lockup）。Soft lockup名称解释：所谓，soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。 ...
解决BUG: soft lockup - CPU#0 stuck for 61s!
Yonx
08-30 6062
目前看来就是内核中有死循环！ 一、问题简述 在网上看到很多软死锁的问题，经过对自己程序的理解，结合网上一些相关资料，基本上可以确定是由于内核bug造成的，这个问题基本上在内核模块加载或卸载的时候发生，对我的模块而言，每次卸载时候发生，其他一切情况均正常，而且在2.6.28和3.0.0内核下均有问题。 二、问题过程 2.1 系统由两个模块:cpu模块和mem模块构成，每个模块由若干个故障检测对象组成，对象由单链表相互连接并由一个结构体作为头部head； 2.2 加载模块时，先对每个模块的每一个故障检测对象初
BUG: soft lockup - CPU#0 stuck for 22s!
kevinyu998的博客
05-08 3291
有个vmware上的数据库虚拟机，message日志报错BUG: soft lockup - CPU#0 stuck for 22s!卡死后必须在管理平台重启该机器，机器重启正常后，直接做如下操作。观察3天多已不再报错cpu了。
驱动压测中报错watchdog: BUG: soft lockup - CPU#5 stuck for 22s
pkyang2004的博客
05-14 1254
由于上述两次原子锁调用是同一把锁（用锁保护同一个消息队列），导致了系统死锁，系统watchdog在死锁超时（这里是20s）后发出系统告警“watchdog: BUG: soft lockup - CPU#5 stuck for 22s”，同时死锁也会导致被锁"CPU#5 stuck"，最终系统异常。分析清楚原因之后，对应的解决办法也很明了：将来自两个方向的请求报文分别保存到两个不同的驱动工作队列分别处理，每个队列对应一把独立的原子锁，避免前述系统日志中出现的单个原子锁因系统中断导致的重入死锁问题。
kernel:watchdog: BUG: soft lockup - CPU#31 stuck for 22s! [nfsd:4100197]
最新发布
12-08
<think>首先，用户的问题是关于解决内核中的"soft lockup"问题，具体是CPU#31被卡住22秒，进程为nfsd:4100197。错误信息是："kernel:watchdog: BUG: soft lockup - CPU#31 stuck for 22s! [nfsd:4100197]"。 从系统级指令中，我有一些引用： - 引用[1]提到类似错误："kernel:BUG: soft lockup - CPU#11 stuck for 22s! [java:99405]"，并说明这是一个内核死锁问题，没有让系统完全死机，但进程被锁死在内核区域。 - 引用[2]进一步解释：soft lockup意味着内核线程被锁死在某个状态，通常是由于内核锁的使用问题。解决方案建议先排查程序问题。 用户提供的引用不是直接针对nfsd进程的，但原理类似。我需要基于这些信息，结合一般知识，构建一个解决方案。 关键点： - **Soft Lockup**：这是Linux内核的watchdog机制检测到的，当一个CPU核心在中断处理中停留太久而没有调度其他任务时触发。它表明内核代码路径中有一个循环或锁没有被释放。 - **进程nfsd**：这指的是Network File System daemon，用于处理NFS请求。问题可能出在NFS相关的内核代码上。 解决方案步骤： 1. **理解错误**：Soft lockup通常是由于CPU在内核模式中忙碌太久而没有响应中断。watchdog超时时间默认为20秒（可配置），所以22秒超时触发了错误。 2. **常见原因**： - 内核bug或驱动程序问题。 - 高负载或死锁在同步原语中（如自旋锁）。 - 针对nfsd，可能涉及文件系统操作、网络问题或资源争用。 3. **诊断步骤**： - **检查日志**：查看完整的dmesg输出或/var/log/messages，获取更多上下文。 - **收集信息**：使用工具如sysrq（Magic SysRq key）来获取堆栈跟踪。 - 例如，触发SysRq：`echo t > /proc/sysrq-trigger` 来dump所有CPU的堆栈。 - **分析堆栈**：找出nfsd进程在CPU#31上卡住时的调用堆栈。 - **更新内核**：确保系统使用最新稳定内核，因为可能有相关修复。 - **监控负载**：检查系统负载、CPU使用率、I/O等待时间等。 4. **针对nfsd的特定建议**： - 检查NFS配置：服务器和客户端设置。 - 网络问题：延迟或丢包可能导致操作超时。 - 文件系统问题：如磁盘故障或文件系统错误。 5. **临时缓解**： - 增加watchdog超时时间：通过`/proc/sys/kernel/watchdog_thresh`（但不推荐，只是临时）。 - 重启nfs服务或系统。 6. **长期修复**： - 报告bug给内核社区。 - 应用补丁或升级内核。 结构化回答： - 开头解释问题。 - 分步骤提供解决方案。 - 使用中文。 - 添加引用标识：[^1]和[^2]来自用户提供的引用。 - 生成相关问题。 确保LaTeX格式：用户提到行内数学表达式用$...$，独立公式用$$...$$，但在这个上下文中，可能不需要数学公式，除非涉及计算。所以，我可以避免使用，除非必要。 回答结构： 1. 解释soft lockup问题。 2. 提供诊断步骤。 3. 给出解决方案建议。 4. 添加相关问题。 引用标识： - 在回答中，引用用户提供的引用：[^1]和。 相关问题： - 基于主题生成几个问题。 最终输出： - 用户可见层：结构清晰的回答。 - 结尾：§§相关问题§§ 列表。 </think> ### 解决内核Soft Lockup问题：CPU#31卡住22秒（进程nfsd:4100197） Soft lockup（软死锁）是Linux内核的一种保护机制，当某个CPU核心在内核态执行时间过长（超过watchdog阈值，默认为20秒）且未响应中断时触发。错误信息`kernel:watchdog: BUG: soft lockup - CPU#31 stuck for 22s! [nfsd:4100197]`表明CPU#31上的`nfsd`进程（NFS守护进程）卡死在内核代码路径中，通常由内核锁争用、资源阻塞或驱动程序问题引起[^2]。以下是系统化的解决方案，按步骤执行以诊断和修复问题。 --- ### 诊断与解决步骤 1. **确认日志和上下文** - 使用`dmesg`或`journalctl`查看完整内核日志，过滤相关错误： ```bash dmesg | grep "soft lockup" # 或 journalctl -k --since "1 hour ago" | grep "CPU#31" ``` - 查找堆栈跟踪信息（如`Call Trace`部分），确定`nfsd`进程卡死的具体内核函数或模块。 - **关键点**：NFS相关错误常由网络延迟、文件系统挂载问题或磁盘I/O阻塞导致[^2]。 2. **收集CPU和进程信息** - 使用`sysrq`触发内核堆栈dump（需启用SysRq）： ```bash echo t > /proc/sysrq-trigger # 输出所有CPU的堆栈到dmesg ``` - 分析`nfsd`进程状态： ```bash ps aux | grep nfsd # 检查nfsd进程状态 top -H -p 4100197 # 监控特定进程的线程和CPU占用 ``` - 检查系统负载：`vmstat 1`或`sar -u`观察CPU使用率、I/O等待（`%iowait`高可能表示磁盘瓶颈）[^1]。 3. **临时缓解措施** - **增加watchdog阈值**（临时方案，不治本）： ```bash echo 30 > /proc/sys/kernel/watchdog_thresh # 将超时时间从20秒增至30秒 ``` - **重启NFS服务**： ```bash systemctl restart nfs-server # 或 service nfs-kernel-server restart ``` - 如果问题频发，可临时禁用NFS： ```bash systemctl stop nfs-server ``` 4. **根本原因分析与修复** - **检查NFS配置**： - 验证`/etc/exports`文件，确保共享路径无权限冲突。 - 测试网络延迟：`ping`或`mtr`检查NFS客户端到服务器的连通性。 - 调整NFS参数（例如增大超时）： ```bash echo "options sunrpc tcp_slot_table_entries=128" > /etc/modprobe.d/sunrpc.conf modprobe -r sunrpc && modprobe sunrpc # 重载模块 ``` - **内核与驱动更新**： - 升级到最新稳定内核（已知旧版本有NFS死锁bug）： ```bash apt update && apt upgrade linux-image-$(uname -r) # Debian/Ubuntu ``` - 更新NFS相关驱动（如网络卡驱动）。 - **检测硬件/文件系统问题**： - 运行`smartctl -a /dev/sdX`检查磁盘健康。 - 使用`fsck`修复文件系统错误（需卸载分区）。 - **锁定分析**： - 安装`perf`工具记录性能事件： ```bash perf record -g -p 4100197 # 抓取nfsd进程的调用栈 ``` - 分析输出，查找自旋锁（`spinlock`）或信号量（`semaphore`）争用点。 5. **高级调试** - 启用内核debug选项重新编译内核： ```config CONFIG_DEBUG_KERNEL=y CONFIG_LOCKUP_DETECTOR=y ``` - 如果问题可复现，报告bug至Linux内核邮件列表（LKML），附带完整日志和堆栈。 --- ### 注意事项 - **预防措施**：定期更新内核，监控系统负载，避免NFS共享过大文件或高并发请求。 - **风险提示**：直接修改内核参数可能引发不稳定，建议在测试环境验证。 - 若以上步骤无效，可能是硬件故障（如内存或CPU缺陷），运行`memtester`进行检测[^1]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值