Linux 内核调试篇7

最新推荐文章于 2025-06-10 20:08:25 发布
最新推荐文章于 2025-06-10 20:08:25 发布
阅读量957 收藏 22
点赞数 24
CC 4.0 BY-SA版权
分类专栏： Linux内核子系统 文章标签： linux 运维 服务器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zouhaicheng/article/details/144931427

Linux 内核调试篇7（基于Linux6.6）---内核卡死分析

一、概述

内核卡死（Kernel Hang）是指操作系统的内核无法继续执行，系统处于一种不可响应的状态，通常会导致整个计算机系统无法响应用户输入，无法执行任何进程，甚至无法进行正常的系统操作。这种情况常常与内核或硬件的严重问题有关，通常需要通过重启系统来恢复。

内核卡死的原因可以很多，通常涉及硬件故障、驱动程序问题、内核漏洞或资源的竞争等。不同于内核崩溃（Oops）或内核恐慌（Panic），卡死通常指的是内核没有完全崩溃，但因为某些原因导致系统无法继续正常工作。

1、内核卡死的表现

  1. 完全无响应：系统完全没有响应用户输入或任何外部命令。
  2. CPU 占用率异常：卡死时，系统可能出现 CPU 占用过高的情况，特别是处于等待状态的进程或内核线程。
  3. 无法进行进程调度：用户进程、内核线程都无法执行，通常表现为系统无法启动新的进程，也无法关闭现有进程。
  4. 无法登录：系统无法响应登录请求，无法进入命令行或图形界面。
  5. 设备不可访问：硬盘、网络接口等硬件可能无法响应，导致系统无法进行磁盘读写或网络操作。

2、常见的原因

  1. 死锁（Deadlock）： 死锁是内核中的多个线程或进程因相互等待资源而无法继续执行，导致系统无法做出响应。死锁通常发生在内核和驱动程序中的资源管理不当，尤其是在多线程或多进程环境下。

  2. 硬件故障：

    • 内存故障：损坏的内存条、内存泄漏、内存映射错误等，可能导致内核无法正常访问内存或执行指令，进而卡死。
    • 硬盘问题：硬盘故障（如坏道、硬盘控制器问题等）可能导致 I/O 操作长时间卡住，进而引起系统无响应。
    • CPU 故障：如果 CPU 发生硬件故障或者超频不稳定，也可能导致系统无法继续执行。

  3. 驱动程序或内核模块问题： 驱动程序或内核模块的错误、死锁或资源竞争可能导致内核卡死。例如，设备驱动程序未能处理完 I/O 请求，导致系统等待永久锁定。

  4. 系统资源耗尽：

    • 进程表溢出：如果系统中有大量进程被创建，而系统的进程表没有得到及时清理，可能导致进程管理崩溃，从而卡死。
    • 内存不足：当系统内存耗尽，内存管理子系统无法正常工作时，可能会导致系统卡死。尤其是内存的交换（swap）操作发生问题时，可能会导致长时间的等待。

  5. 内核中的 Bug 或设计缺陷：

    • 内核中未被及时发现的 Bug 也可能导致卡死，例如死循环、资源释放不当、错误的同步操作等。
    • 内核中的设计缺陷，尤其是多核处理器或 SMP（对称多处理）系统中的竞态条件，可能会导致部分进程或线程无法执行。

  6. I/O 阻塞： 当内核或某个设备的 I/O 操作发生阻塞时（比如等待磁盘、网络接口或外设响应），如果没有适当的超时处理，可能导致系统卡住。

3、卡死的调试方法

调试内核卡死的问题非常具有挑战性，因为卡死时系统无法响应外部命令。以下是一些常见的调试方法：

  1. 使用 Kernel Crash Dump（内核崩溃转储）： 配置 kdump 或 crash 工具，可以在系统卡死或崩溃时收集内存转储，并将转储信息用于分析。通过分析转储数据，您可以查看卡死时的内存状态、调用堆栈等，从而找出问题的根源。

  2. 查看日志文件：

    • 系统日志（如 /var/log/messages 或 dmesg）可以提供一些线索，尤其是在卡死前是否有硬件错误或驱动程序报错。
    • 如果是由于某个设备或驱动程序引起的卡死，日志中可能会包含相应的错误信息。

  3. 通过调试器（如 KGDB 或 GDB）调试： 如果系统支持内核调试，可以使用 KGDB（Kernel GNU Debugger）等调试工具，通过串口或网络与内核进行调试，实时查看内核执行过程，并捕获发生卡死时的状态。

  4. 配置内核调试选项： 在内核编译时启用 CONFIG_DEBUG_KERNEL、CONFIG_PROFILING 等调试选项，可以生成更详细的内核运行时日志，帮助查找卡死原因。

  5. 检查硬件：

    • 使用内存诊断工具（如 Memtest86）检查内存是否有故障。
    • 检查硬盘健康状况，使用 SMART 工具检查硬盘的健康状态。
    • 如果有可能，测试替换硬件以排除硬件故障的影响。

  6. 减少系统负载： 如果内核卡死与系统负载有关，可以通过调整系统配置、禁用一些不必要的服务或减少并发访问来减轻系统负载，观察卡死是否依然发生。

二、实例分析

内核卡死有很多种可能，

  • 驱动程序因为逻辑问题，出现死循环
  • 共享资源出现死锁
  • 系统跑飞等

一般情况下，系统跑飞内核会打印Oops信息。

有了Oops信息，我们就可以通过上一节的方法来推断出出错位置。

而死锁或者驱动程序死循环并不会打印Oops信息。

这个时候需要自己打印出来，出错位置的寄存器（ r0 ~ r15等）信息来反推出出错位置。

因为这个时候卡住的位置基本已经是死掉了，所以只能采用别的方式来打印出内核的寄存器信息或者oops信息。

那这个时候什么东西是还在正常运行的呢？

中断！

因为中断是是突发的，不受到其它驱动和应用程序的影响。

而且，如果某个程序执行死循环时，中断发生后，也会把这个死循环的程序的寄存器进行存储的。

无论是执行传统的中断函数

 .L__vectors_start:
	W(b)	vector_rst
	W(b)	vector_und
	W(ldr)	pc, .L__vectors_start + 0x1000
	W(b)	vector_pabt
	W(b)	vector_dabt
	W(b)	vector_addrexcptn
	W(b)	vector_irq        @----->>>>>>>>
	W(b)	vector_fiq
	vector_stub	irq, IRQ_MODE, 4
	.long	__irq_usr			@  0  (USR_26 / USR_32)    ------->
	.long	__irq_invalid			@  1  (FIQ_26 / FIQ_32)
	.long	__irq_invalid			@  2  (IRQ_26 / IRQ_32)
	.long	__irq_svc			@  3  (SVC_26 / SVC_32)   -------->
	.long	__irq_invalid			@  4
	.long	__irq_invalid			@  5
	.long	__irq_invalid			@  6
	.long	__irq_invalid			@  7
	.long	__irq_invalid			@  8
	.long	__irq_invalid			@  9
	.long	__irq_invalid			@  a
	.long	__irq_invalid			@  b
	.long	__irq_invalid			@  c
	.long	__irq_invalid			@  d
	.long	__irq_invalid			@  e
	.long	__irq_invalid			@  f
	.align	5
__irq_svc:
	svc_entry
	irq_handler            @-------->>>>>>>>>
#ifdef CONFIG_PREEMPT
	ldr	r8, [tsk, #TI_PREEMPT]		@ get preempt count
	ldr	r0, [tsk, #TI_FLAGS]		@ get flags
	teq	r8, #0				@ if preempt count != 0
	movne	r0, #0				@ force flags to 0
	tst	r0, #_TIF_NEED_RESCHED
	blne	svc_preempt
#endif
 
	svc_exit r5, irq = 1			@ return from exception
 UNWIND(.fnend		)
ENDPROC(__irq_svc)
 
 
 
 
 
 
/*
 * Interrupt handling.
 */
	.macro	irq_handler
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
	ldr	r1, =handle_arch_irq                @新的中断方式,分发中断
	mov	r0, sp
	badr	lr, 9997f
	ldr	pc, [r1]
#else
	arch_irq_handler_default                @老的传统中断方式
#endif
9997:
	.endm

先看老的传统中断方式

 /*
 * Interrupt handling.  Preserves r7, r8, r9
 */
	.macro	arch_irq_handler_default
	get_irqnr_preamble r6, lr
1:	get_irqnr_and_base r0, r2, r6, lr
	movne	r1, sp
	@
	@ routine called with r0 = irq number, r1 = struct pt_regs *
	@
	badrne	lr, 1b
	bne	asm_do_IRQ
 
 
 
asmlinkage void asm_do_IRQ(struct pt_regs *regs)
{
	irq_hw_number_t hwirq = get_intr_src();
	handle_domain_irq(root_domain, hwirq, regs);
}

接下来看新的中断处理

kernel/irq/handle.c 

 /*
 * 定义了函数指针
 */
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
void (*handle_arch_irq)(struct pt_regs *) __ro_after_init;
#endif
 
 
/* 
 * 运行期间可以更改这个指针,来改变中断处理函数
 */
 
#ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
int __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
{
	if (handle_arch_irq)
		return -EBUSY;
 
	handle_arch_irq = handle_irq;
	return 0;
}
#endif

下面是新的几种中断的处理当时，包括vic，gic等

drivers/irqchip/irq-vic.c 

 /*
 * Keep iterating over all registered VIC's until there are no pending
 * interrupts.
 */
static void __exception_irq_entry vic_handle_irq(struct pt_regs *regs)
{
	int i, handled;
 
	do {
		for (i = 0, handled = 0; i < vic_id; ++i)
			handled |= handle_one_vic(&vic_devices[i], regs);
	} while (handled);
}

drivers/irqchip/irq-gic.c

  
static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
{
	u32 irqnr;
 
	do {
		irqnr = gic_read_iar();
 
		if (likely(irqnr > 15 && irqnr < 1020) || irqnr >= 8192) {
			int err;
 
			if (static_branch_likely(&supports_deactivate_key))
				gic_write_eoir(irqnr);
			else
				isb();
 
			err = handle_domain_irq(gic_data.domain, irqnr, regs);
			if (err) {
				WARN_ONCE(true, "Unexpected interrupt received!\n");
				if (static_branch_likely(&supports_deactivate_key)) {
					if (irqnr < 8192)
						gic_write_dir(irqnr);
				} else {
					gic_write_eoir(irqnr);
				}
			}
			continue;
		}
		if (irqnr < 16) {
			gic_write_eoir(irqnr);
			if (static_branch_likely(&supports_deactivate_key))
				gic_write_dir(irqnr);
#ifdef CONFIG_SMP
			/*
			 * Unlike GICv2, we don't need an smp_rmb() here.
			 * The control dependency from gic_read_iar to
			 * the ISB in gic_write_eoir is enough to ensure
			 * that any shared data read by handle_IPI will
			 * be read after the ACK.
			 */
			handle_IPI(irqnr, regs);
#else
			WARN_ONCE(true, "Unexpected SGI received!\n");
#endif
			continue;
		}
	} while (irqnr != ICC_IAR1_EL1_SPURIOUS);
}

drivers/irqchip/irq-gic.c

  
static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
{
	u32 irqnr;
 
	do {
		irqnr = gic_read_iar();
 
		if (likely(irqnr > 15 && irqnr < 1020) || irqnr >= 8192) {
			int err;
 
			if (static_branch_likely(&supports_deactivate_key))
				gic_write_eoir(irqnr);
			else
				isb();
 
			err = handle_domain_irq(gic_data.domain, irqnr, regs);
			if (err) {
				WARN_ONCE(true, "Unexpected interrupt received!\n");
				if (static_branch_likely(&supports_deactivate_key)) {
					if (irqnr < 8192)
						gic_write_dir(irqnr);
				} else {
					gic_write_eoir(irqnr);
				}
			}
			continue;
		}
		if (irqnr < 16) {
			gic_write_eoir(irqnr);
			if (static_branch_likely(&supports_deactivate_key))
				gic_write_dir(irqnr);
#ifdef CONFIG_SMP
			/*
			 * Unlike GICv2, we don't need an smp_rmb() here.
			 * The control dependency from gic_read_iar to
			 * the ISB in gic_write_eoir is enough to ensure
			 * that any shared data read by handle_IPI will
			 * be read after the ACK.
			 */
			handle_IPI(irqnr, regs);
#else
			WARN_ONCE(true, "Unexpected SGI received!\n");
#endif
			continue;
		}
	} while (irqnr != ICC_IAR1_EL1_SPURIOUS);
}

上面看到一个共同点，就是这几个c函数的参数是一样的。

这里看一下他的定义，可以看到18个long，存放的也是中断调转前的那个程序的18个寄存器。

 struct pt_regs {
	unsigned long uregs[18];
};

这里看一下这十八个寄存分别是放的那个寄存器。

 arch/arm/include/uapi/asm/ptrace.h

#define ARM_cpsr	uregs[16]
#define ARM_pc		uregs[15]
#define ARM_lr		uregs[14]
#define ARM_sp		uregs[13]
#define ARM_ip		uregs[12]
#define ARM_fp		uregs[11]
#define ARM_r10		uregs[10]
#define ARM_r9		uregs[9]
#define ARM_r8		uregs[8]
#define ARM_r7		uregs[7]
#define ARM_r6		uregs[6]
#define ARM_r5		uregs[5]
#define ARM_r4		uregs[4]
#define ARM_r3		uregs[3]
#define ARM_r2		uregs[2]
#define ARM_r1		uregs[1]
#define ARM_r0		uregs[0]
#define ARM_ORIG_r0	uregs[17]

如果向要看pc的值，只需要在内核中C中断处理函数的入口添加打印即可。

比如vic：

 /*
 * Keep iterating over all registered VIC's until there are no pending
 * interrupts.
 */
static void __exception_irq_entry vic_handle_irq(struct pt_regs *regs)
{
	int i, handled;
 
        printk(KERN_ERR"vic_handle_irq entry pt_regs->pc = %x\n ",regs->ARM_pc);
 
	do {
		for (i = 0, handled = 0; i < vic_id; ++i)
			handled |= handle_one_vic(&vic_devices[i], regs);
	} while (handled);
}

上面这个是任何时候触发中断都会打印。一般不是想要的。

而且像内核心跳定时器是以ms级别都在触发的，不可能让不同的打印。

这个时候就要根据卡死时的现象来决定处理打印，中断执行前的pc。

比如假设，5s时间当前进程都没有进行切换，那就证明卡死，需要打印pc值（或者其他值）。

 /*
 * Keep iterating over all registered VIC's until there are no pending
 * interrupts.
 */
static void __exception_irq_entry vic_handle_irq(struct pt_regs *regs)
{
	int i, handled;
 
    static pid_t old_pid = 0;
    static unsigned int cnt = 0;
 
 
    /* 进程不一样,表示没卡死 */
    if(current->pid != old_pid )
    {
        old_pid  = current->pid;
        cnt  = 0;
    }
    else
    {
        /* 进程一样,且连续5s进程都一样,表示卡死,这是打印出我们需要的进中断前的寄存器信息 */
        if(cnt  >= 5* HZ)
        {
             printk(KERN_ERR"vic_handle_irq entry pt_regs->pc = %x\n ",regs->ARM_pc);
             cnt = 0;  
        }  
    }
  
 
	do {
		for (i = 0, handled = 0; i < vic_id; ++i)
			handled |= handle_one_vic(&vic_devices[i], regs);
	} while (handled);
}

打印出来后，根据pc值，知道对应位置的代码，进而找打卡死的原因。

Linux内核死机调试方法总结
weixin_30376083的博客
04-01 1078
使用空指针和缓冲区溢出是产生oops的两个最常见原因。 1、直接查看oops信息，首先查找源代码发生oops的位置，通过查看指令寄存器EIP的值，可以找到位置。再查找函数调用栈可以得到更多的信息。从函数调用栈可辨别出局部变量，全局变量和函数参数。较为重要的信息就是指令指针（EIP），即出错指令的地址。 例如：在函数faulty_read的oops信息的函数调用栈中，栈顶为ffffffff，栈顶...
linux 内核死机 堆栈,高通平台Linux kernel死机解题心得
weixin_29083649的博客
04-30 3367
1、前言1.1 目的能够借助相关调试工具，使用一般分析手段分析、定位解决项目过程中遇到的死机类系统稳定性问题，提升工作效率持续积累，拓宽知识深度和广度1.2 死机？指系统发生致命性异常导致主动或者被动进入系统完全不可用的状态，导致系统死机的问题原因有很多，排除硬件问题，还有这些大模块：Android、Linux kenrel、modem、TZ 等等，各个子系统都有可能导致系统死机重启，我们这里主要...
利用 KGDB 解决内核死锁问题—实战调试案例
最新发布
Interview_TC的博客
06-10 1285
本文通过一个音频驱动死锁案例，详细介绍了使用KGDB调试Linux内核问题的全流程。文章首先描述了开发环境中系统卡死的现象和常规排查手段的局限性，接着讲解了KGDB环境的配置方法，包括内核选项、启动参数和硬件连接。重点演示了如何通过GDB命令定位死锁位置、分析线程调用栈、检查锁状态，最终发现错误路径中遗漏解锁的代码问题。作者总结了实用的GDB调试命令和KGDB使用心得，强调其对解决多线程死锁问题的重要价值，建议内核开发者掌握这一强大工具。全文提供了从环境搭建到问题解决的完整指导，是内核调试的实战参考。
linux 内核死机 堆栈,rtlinux运动实时内核死机调试方法
weixin_28902341的博客
04-30 755
在Linux系统中提供实时内核死机调试方法，在系统中也给出了示例。示例存放路径是/usr/src/rtlinu-3.1/debugger目录，目录中的readme文件详细说明了实时内核死机调试方法。其调试方法的主要内容是：先加载实时调试模块rtl_debug.o，然后加载实时内核模块，当实时内核模块出现导致死机的条件时，rtl_debug.o模块将其挂起，再使用gdb进行调试。运动模块MillMo...
Linux内核崩溃 dump调试
lnwechag的博客
03-01 3091
linux crash core dump 调试方法
linux 内核出现CPU 死机
lbaihao的专栏
08-10 6022
linux 异常分析工具（一） linux 内核OOPS（二） linux 内核出现CPU stall
linux内核调试技术——进程上下文R状态死锁监测(LOCKUP_DETECTOR)
02-14 1871
目录 1 R转态死锁/死循环检测概述 2 lockup detector机制分析 3 示例演示 3.1 首先确认启用内核配置 3.2 然后确认内核调度策略配置 3.3 编写演示程序 4 总结 1 R转态死锁/死循环检测概述 前一篇博文介绍了内核监测D状态死锁的hung task机制，本文介绍另一种死锁状态的监测手段——R状态死锁监测。R状态死锁指的是某一任务一直处于TASK_RUNNING态且一直占用着CPU，从而导致其他进程得不到调度而饿死的情况。一般情况下，R状态死锁较可能是由于程序出
linux内核调试方法总结
08-02
十 使用SkyEye构建Linux内核调试环境 1 SkyEye的安装和μcLinux内核编译 2 使用SkyEye调试 3 使用SkyEye调试内核的特点和不足 十一 KDB 1 入门 2 初始化并设置环境变量 3 激活 KDB 4 KDB 命令 5 技巧和诀窍 6 结束语...
Linux内核调试新秀SystemTap.pdf
09-06
Linux内核调试新秀SystemTap.pdf
【Linux内核调试】基于KGDB的内核调试技术详解：从原理到实战案例
05-04
内容概要：本文详细介绍了使用KGDB（Kernel GNU Debugger）调试Linux内核的方法及其重要性。文章首先强调了Linux内核作为系统核心的重要性及其调试的必要性，随后介绍了KGDB的基本原理和优势，包括其基于调试stub和...
Linux内核调试：使用工具与技术进行有效内核和模块故障排除
10-28
内容概要：这本书主要介绍了如何有效地利用现有工具和高级技术来调试Linux内核以及内核模块。作者通过对多个真实世界中由软件缺陷导致的悲剧事故进行了简述，以此来强调软件质量的重要性。书中详细探讨了调试的艺术...
嵌入式Linux内核调试技术.pdf
09-06
嵌入式Linux内核调试技术.pdf
调试内核解决内核恐慌问题
远方雪的专栏
09-05 887
如果您需要更深入地调查内核的状态和行为，可以使用内核调试器。根据内核恐慌日志中提到的函数和模块，查看相应的源代码可以帮助理解问题的原因。如果您通过远程或者无法直接访问屏幕的方式连接到系统，使用串行控制台可以帮助捕获内核恐慌信息。内核恐慌信息通常会显示在控制台上，包括错误发生的函数、调用栈（Call Trace）等。利用 Linux 内核邮件列表、专门的论坛和社区，以及搜索引擎来查找类似的问题和解决方案。确保内核日志级别足够高，以便能够捕获详细的错误信息。通过这些步骤，您可以更系统地调试和解决内核恐慌问题。
Linux 系统死机：常见原因和定位方法
weixin_47711503的博客
03-18 2664
接debug口，复现死机现象，查看系统控制台消息。错误来生成core文件。这些日志可能包含崩溃前的最后几条消息。命令检查物理内存是否存在问题。目录下的日志文件，特别是。
linux系统运行死机,故障排除 Linux操作系统死机处理方法
weixin_29189363的博客
05-09 629
poll_controller只是模拟了来自指定设备的中断。一个最简单的判断一个网卡驱动是否这次支持netpoll功能的方法是安装内核源代码，然后在代码树 /usr/src/kernel-＜version＞中搜索HAVE_POLL_CONTROLLER的定义, grep -r "HAVE_POLL_CONTROLLER" /usr/src/linux-＜version＞/drivers/net示例...
Linux内核调试：kdump、vmcore、crash、kernel-debuginfo
热门推荐
kanguolaikanguolaik的专栏
02-24 3万+
一、简介       linux内核发送崩溃时，会生成一个内核转储文件vmcore。 可以通过分析vmcore分析出内核崩溃的原因。        crash是一个被广泛应用的内核奔溃转储文件分析工具。       使用crash调试内核转储文件，需要安装crash工具和内核调试工具kernel-debuginfo。 二、安装crash、kernel-debuginfo 2.1 安装cr
Kernel: hang: 手动编写内核模块触发hang的例子
mzhan017的博客
06-09 231
下面是在local-timer的中断和认为切换的地方添加了trace point，然后通过一个文件打开printk的开关。因为printk在使用的过程中会使用console-lock，如果是多个CPU的系统，可能导致争抢console-lock的情况。
Linux死机排查方法——内存日志
Dokin
02-06 3609
本文所描述的内存日志，并不是将内核的printk重定向到内存中，因为printk的打印太多了，如果将日志写入到内存中，那就比正常的串口printk快的多，对系统的影响最小。简而言之，这种方法就是将关键模块的日志保存在内存中，等到下一次启动时，再将这些日志全部dump出来。
在没有打印以及ICE无法连接的情况下，如何知道kernel hang的位置
Peter Chen的专栏
11-02 832
前提是reset板子不会照成memory被reset 方法一（已测试）： 1. 打开你的System.map文件，找到symbol： __log_buf 比如：806d6f88 b __log_buf 这里的地址0x806d6f88是虚拟地址，不过是和物理地址一一对应的， 一般双方只差一个最高4位的偏移。本例中__log_buf的物理地址是 0x106d6f88 2. boo
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值