Linux内核睡眠唤醒调试

本文基于 RockPI 4A 单板 Debian 系统 Linux4.4 内核介绍下睡眠唤醒（ suspend/resume ）的一些调试方法。

1、关闭串口睡眠

在Linux内核睡眠过程中，会先调用 suspend_console() 函数使串口进入睡眠状态，这样会导致后续设备驱动的睡眠过程不可见。可以在boot启动参数中增加 no_console_suspend 参数，显示设备驱动睡眠日志。

2、修改串口日志等级

修改串口日志打印等级，显示更多调试信息。

3、打开设备睡眠唤醒时间

设置 pm_print_times 参数，可以显示设备驱动睡眠唤醒时间，方便调试时查看哪个函数处理占用时间过长。

在调试Linux内核睡眠唤醒功能时，可以使用 RTC 做唤醒源，在系统睡眠5秒后，自动唤醒系统。

在 arch/arm64/configs/rockchip_linux_defconfig 文件中配置宏 CONFIG_PM_TEST_SUSPEND 。

唤醒日志如下：

Linux内核支持四种系统睡眠状态即： mem、standby、freeze and disk 。

可通过文件 /sys/power/state 进行读写访问，区别如下：

在 RockPI 4A 单板 Debian 系统 Linux 4.4 内核中，查看电源状态，仅支持 freeze和mem 两种。

原因：

1、 Platform 驱动只实现了 mem 类型的 suspend

2、只有在 hibernation 可用时，才支持 STD

1、 psci 初始化流程

suspend_set_ops() 函数赋值数组 pm_states 实现如下：

2、power state显示

/sys/power/state 文件显示的内容，通过 state_show() 函数实现，该函数最终显示数组 pm_states 的内容。

参考：

Documentation/power/states.txt

以下是根据一些资料和个人理解总结的，如有错误希望指出。

首先需要明确的是，这里的中断指的是硬件中断。

从事实上说明 有下面这些理由。

硬件中断本身就是用来作为处理紧急事件的一种方法，所以硬件中断服务程序应该尽量的快。不应该睡眠

硬件中断服务程序会打断某个无辜的进程(甚至是另一个中断服务程序)。所以它应该尽量快(突然被打断运行已经够无辜了，总不能还让一直等待吧)

硬件中断是无法预测的，如果在中断服务程序中睡眠就会导致睡眠过程中该中断请求的丢失。(linux中一个中断处理程序在运行时，相应中断线会被屏蔽掉)

要理解为什么硬件中断处理程序中不能睡眠的内在机制。需要理解下面这些概念。

1 linux内核的工作模式 linux内核有两种工作模式，进程上下文和中断上下文。

1.1 进程上下文指内核代表进程执行

比如进程执行系统调用产生异常陷入内核后，内核就代表该进程执行 *** 作。可以通过current宏关联到当前进程，

因为陷入内核时进程造成的或需求的，所以内核的执行与当前进程相关。所以说他代表该进程执行

1.2 执行一个硬件中断处理程序时就处于中断上下文

中断上下中和进程没什么关系(虽然此时current指向被中断的进程)。这也容易理解，因为硬件中断随时

都有可能发生。不像上面提到的像系统调用之类的异常是由于程序执行某些指令造成的，所以陷入

内核后，因为要坐的工作基本都是和当前这个进程相关的(因为是他执行一些指令导致产生的异常)，

所以我们说内核代表进程执行。

但是硬件中断的产生完全无法预测，所以谁也不知道硬件中断将会打断哪个进程。所以硬件中断服务程序与进程无关

它处于中断上下文中

2 异常和硬件中断的区别

2.1 异常属于中断的一种，和硬件中断的区别在与它是"同步"，是由于执行一些指令造成的。如除0

或者执行过程中产生缺页，以及软中断实现的系统调用。(这也是叫“同步中断”的原因，因为指令的执行是要时钟同步的)。

当执行的指令会陷入内核时，就会运行在进程上下文中。内核代表进程

2.2 硬件中断时一种 异步中断，他随时都可能发生，无法预测。中断执行时处于中断上下文中。

综上，linux中硬件中断服务程序不能睡眠的原因在与。执行硬件中断服务程序时，内核处于中断上下文

中，此时内核与进程无关。如果睡眠后就不能调度回来了。因为调度程序调度的是进程，而之前的硬件中断服务程序却是和进程无关的

---