Linux电源管理(3)_Generic PM之Reboot过程

1. 前言

在使用计算机的过程中,关机和重启是最先学会的两个操作。同样,这两个操作在Linux中也存在,称作shutdown和restart。这就是本文要描述的对象。

在Linux Kernel中,主流的shutdown和restart都是通过“reboot”系统调用(具体可参考kernel/sys.c)来实现的,这也是本文使用“Generic PM之Reboot过程”作为标题的原因。另外,除了我们常用的shutdown和restart两类操作之外,该系统调用也提供了其它的reboot方式,也会在这里一一说明。

2. Kernel支持的reboot方式

也许你会奇怪,reboot是重启的意思,所以用它实现Restart是合理的,但怎么用它实现关机操作呢?答案是这样的:关机之后,早晚也会开机啊!所以关机是一种特殊的Restart过程,只不过持续的时间有点长而已。所以,内核根据不同的表现方式,将reboot分为如下的几种方式:

   1: /*      
   2:  * Commands accepted by the _reboot() system call.
   3:  *
   4:  * RESTART     Restart system using default command and mode.
   5:  * HALT        Stop OS and give system control to ROM monitor, if any.
   6:  * CAD_ON      Ctrl-Alt-Del sequence causes RESTART command.
   7:  * CAD_OFF     Ctrl-Alt-Del sequence sends SIGINT to init task.
   8:  * POWER_OFF   Stop OS and remove all power from system, if possible.
   9:  * RESTART2    Restart system using given command string.
  10:  * SW_SUSPEND  Suspend system using software suspend if compiled in.
  11:  * KEXEC       Restart system using a previously loaded Linux kernel
  12:  */
  13:         
  14: #define LINUX_REBOOT_CMD_RESTART        0x01234567
  15: #define LINUX_REBOOT_CMD_HALT           0xCDEF0123
  16: #define LINUX_REBOOT_CMD_CAD_ON         0x89ABCDEF
  17: #define LINUX_REBOOT_CMD_CAD_OFF        0x00000000
  18: #define LINUX_REBOOT_CMD_POWER_OFF      0x4321FEDC
  19: #define LINUX_REBOOT_CMD_RESTART2       0xA1B2C3D4
  20: #define LINUX_REBOOT_CMD_SW_SUSPEND     0xD000FCE2
  21: #define LINUX_REBOOT_CMD_KEXEC          0x4558454

RESTART,正常的重启,也是我们平时使用的重启。执行该动作后,系统会重新启动。

HALT,停止操作系统,然后把控制权交给其它代码(如果有的话)。具体的表现形式,依赖于系统的具体实现。

CAD_ON/CAD_OFF,允许/禁止通过Ctrl-Alt-Del组合按键触发重启(RESTART)动作。 
注1:Ctrl-Alt-Del组合按键的响应是由具体的Driver(如Keypad)实现的。

POWER_OFF,正常的关机。执行该动作后,系统会停止操作系统,并去除所有的供电。

RESTART2,重启的另一种方式。可以在重启时,携带一个字符串类型的cmd,该cmd会在重启前,发送给任意一个关心重启事件的进程,同时会传递给最终执行重启动作的machine相关的代码。内核并没有规定该cmd的形式,完全由具体的machine自行定义。

SW_SUSPEND,即前一篇文章中描述的Hibernate操作,会在下一篇文章描述,这里就暂不涉及。

KEXEC,重启并执行已经加载好的其它Kernel Image(需要CONFIG_KEXEC的支持),暂不涉及。

3. Reboot相关的操作流程

在Linux操作系统中,可以通过reboot、halt、poweroff等命令,发起reboot,具体的操作流程如下:

Reboot相关的操作流程

  • 一般的Linux操作系统,在用户空间都提供了一些工具集合(如常在嵌入式系统使用的Busybox),这些工具集合包含了reboot、halt和poweroff三个和Reboot相关的命令。读者可以参考man帮助文档,了解这些命令的解释和使用说明
  • 用户空间程序通过reboot系统调用,进入内核空间
  • 内核空间根据执行路径的不同,提供了kernel_restart、kernel_halt和kernel_power_off三个处理函数,响应用空间的reboot请求
  • 这三个处理函数的处理流程大致相同,主要包括:向关心reboot过程的进程发送Notify事件;调用drivers核心模块提供的接口,关闭所有的外部设备;调用drivers syscore模块提供的接口,关闭system core;调用Architecture相关的处理函数,进行后续的处理;最后,调用machine相关的接口,实现真正意义上的Reboot
  • 另外,借助TTY模块提供的Sysreq机制,内核提供了其它途径的关机方法,如某些按键组合、向/proc文件写入命令等,后面会详细介绍
4. Reboot过程的内部动作和代码分析
4.1 Reboot系统调用

Reboot系统调用的实现位于“kernel/sys.c”,其函数原型如下:

   1: SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
   2:                 void __user *, arg)

该函数的参数解释如下:

reboot,该系统调用的名称。

magic1、magic2,两个int类型的“魔力数”,用于防止误操作。具体在“include/uapi/linux/reboot.h”中定义,感兴趣的同学可以去看看(话说这些数字还是蛮有意思的,例如Linus同学及其家人的生日就在里面,猜出来的可以在文章下面留言)。

cmd,第2章所讲述的reboot方式。

arg,其它的额外参数。

reboot系统调用的内部动作比较简单:

1)判断调用者的用户权限,如果不是超级用户(superuser),则直接返回错误(这也是我们再用户空间执行reboot、halt、poweroff等命令时,必须是root用户的原因);

2)判断传入的magic number是否匹配,如果不匹配,直接返回错误。这样就可以尽可能的防止误动作发生;

3)调用reboot_pid_ns接口,检查是否需要由该接口处理reboot请求。这是一个有关pid namespaces的新特性,也是Linux内核重要的知识点,我们会在其它文章中描述,这里就不多说了;

4)如果是POWER_OFF命令,且没有注册power off的machine处理函数(pm_power_off),把该命令转换为HALT命令;

5)根据具体的cmd命令,执行具体的处理,包括, 
      如果是RESTART或者RESTART2命令,调用kernel_restart。 
      如果是CAD_ON或CAD_OFF命令,更新C_A_D的值,表示是否允许通过Ctrl+Alt+Del组合键重启系统。 
      如果是HALT命令,调用kernel_halt。 
      如果是POWER_OFF命令,调用kernel_power_off。 
      如果是KEXEC命令,调用kernel_kexec接口(暂不在本文涉及)。 
      如果是SW_SUSPEND,调用hibernate接口(会在下一章描述);

6)返回上述的处理结果,系统调用结束。

4.2 kernel_restart、kernel_halt和kernel_power_off

这三个接口也位于“kernel/sys.c”,实现比较类似,具体动作包括:

1)调用kernel_xxx_prepare函数,进行restart/halt/power_off前的准备工作,包括, 
      调用blocking_notifier_call_chain接口,向关心reboot事件的进程,发送SYS_RESTART、SYS_HALT或者SYS_POWER_OFF事件。对RESTART来说,还好将cmd参数一并发送出去。 
      将系统状态设置为相应的状态(SYS_RESTART、SYS_HALT或SYS_POWER_OFF)。 
      调用usermodehelper_disable接口,禁止User mode helper(可参考“Linux设备模型(3)_Uevent”相关的描述)。 
      调用device_shutdown,关闭所有的设备(具体内容会在下一节讲述);

2)如果是power_off,且存在PM相关的power off prepare函数(pm_power_off_prepare),则调用该回调函数;

3)调用migrate_to_reboot_cpu接口,将当前的进程(task)移到一个CPU上; 
注2:对于多CPU的机器,无论哪个CPU触发了当前的系统调用,代码都可以运行在任意的CPU上。这个接口将代码分派到一个特定的CPU上,并禁止调度器分派代码到其它CPU上。也就是说,这个接口被执行后,只有一个CPU在运行,用于完成后续的reboot动作。

4)调用syscore_shutdown接口,将系统核心器件关闭(例如中断等);

5)调用printk以及kmsg_dump,向这个世界发出最后的声音(打印日志);

6)最后,由machine-core的代码,接管后续的处理。

4.3 device_shutdown

在理解device_shutdown之前,我们需要回忆一下前几篇有关Linux设备模型的文章。同时,借助对电源管理的解析,我们会把在Linux设备模型系列文章中没有描述的部分补回来。设备模型中和device_shutdown有关的逻辑包括:

  • 每个设备(struct device)都会保存该设备的驱动(struct device_driver)指针,以及该设备所在总线(struct bus_type)的指针(具体参考“Linux设备模型(5)_device和device driver”)
  • 设备驱动中有一个名称为“shutdown”的回调函数,用于在device_shutdown时,关闭该设备(具体参考“Linux设备模型(5)_device和device driver”)
  • 总线中也有一个名称为“shutdown”的回调函数,用于在device_shutdown时,关闭该设备(具体参考“Linux设备模型(6)_Bus”)
  • 系统的所有设备,都存在于“/sys/devices/”目录下,而该目录由名称为“devices_kset”的kset表示。而由“Linux设备模型(2)_Kobject”的描述可知,kset中会使用一个链表保存其下所有的kobject(也即“/sys/devices/”目录下的所有设备)。最终的结果就是,以“devices_kset”为root节点,将内核中所有的设备(以相应的kobject为代表),组织成一个树状结构

介绍完以上的背景知识,我们来看device_shutdown的实现,就非常容易了。该接口位于“drivers/base/core.c”中,执行逻辑如下。

   1: /**
   2:  * device_shutdown - call ->shutdown() on each device to shutdown.
   3:  */
   4: void device_shutdown(void)
   5: {
   6:         struct device *dev, *parent;
   7:         
   8:         spin_lock(&devices_kset->list_lock);
   9:         /*
  10:          * Walk the devices list backward, shutting down each in turn.
  11:          * Beware that device unplug events may also start pulling
  12:          * devices offline, even as the system is shutting down.
  13:          */
  14:         while (!list_empty(&devices_kset->list)) {
  15:                 dev = list_entry(devices_kset->list.prev, struct device,
  16:                                 kobj.entry);
  17:  
  18:                 /*
  19:                  * hold reference count of device's parent to
  20:                  * prevent it from being freed because parent's
  21:                  * lock is to be held
  22:                  */
  23:                 parent = get_device(dev->parent);
  24:                 get_device(dev);
  25:                 /*
  26:                  * Make sure the device is off the kset list, in the
  27:                  * event that dev->*->shutdown() doesn't remove it.
  28:                  */
  29:                 list_del_init(&dev->kobj.entry);
  30:                 spin_unlock(&devices_kset->list_lock);
  31:  
  32:                 /* hold lock to avoid race with probe/release */
  33:                 if (parent)
  34:                         device_lock(parent);
  35:                 device_lock(dev);
  36:  
  37:                 /* Don't allow any more runtime suspends */
  38:                 pm_runtime_get_noresume(dev);
  39:                 pm_runtime_barrier(dev);
  40:  
  41:                 if (dev->bus && dev->bus->shutdown) {
  42:                         if (initcall_debug)
  43:                                 dev_info(dev, "shutdown\n");
  44:                         dev->bus->shutdown(dev);
  45:                 } else if (dev->driver && dev->driver->shutdown) {
  46:                         if (initcall_debug)
  47:                                 dev_info(dev, "shutdown\n");
  48:                         dev->driver->shutdown(dev);
  49:                 }
  50:  
  51:                 device_unlock(dev);
  52:                 if (parent)
  53:                         device_unlock(parent);
  54:  
  55:                 put_device(dev);
  56:                 put_device(parent);
  57:  
  58:                 spin_lock(&devices_kset->list_lock);
  59:         }
  60:         spin_unlock(&devices_kset->list_lock);
  61:         async_synchronize_full();
  62: }

1)遍历devices_kset的链表,取出所有的设备(struct device);

2)将该设备从链表中删除;

3)调用pm_runtime_get_noresume和pm_runtime_barrier接口,停止所有的Runtime相关的电源管理动作(后续的文章会详细描述有关Runtime PM的逻辑);

4)如果该设备的bus提供了shutdown函数,优先调用bus的shutdown,关闭设备;

5)如果bus没有提供shutdown函数,检测设备driver是否提供,如果提供,调用设备driver的shutdown,关闭设备;

6)直至处理完毕所有的设备。

4.4 system_core_shutdown

system core的shutdown和设备的shutdown类似,也是从一个链表中,遍历所有的system core,并调用它的shutdown接口。后续蜗蜗会专门写一篇文章介绍syscore,这里暂不描述。

4.5 machine_restart、machine_halt和machine_power_off

虽然以machine_为前缀命名,这三个接口却是属于Architecture相关的处理函数,如ARM。以ARM为例,它们在“arch/arm/kernel/process.c”中实现,具体如下。

4.5.1 machine_restart
   1: /*
   2:  * Restart requires that the secondary CPUs stop performing any activity
   3:  * while the primary CPU resets the system. Systems with a single CPU can
   4:  * use soft_restart() as their machine descriptor's .restart hook, since that
   5:  * will cause the only available CPU to reset. Systems with multiple CPUs must
   6:  * provide a HW restart implementation, to ensure that all CPUs reset at once.
   7:  * This is required so that any code running after reset on the primary CPU
   8:  * doesn't have to co-ordinate with other CPUs to ensure they aren't still
   9:  * executing pre-reset code, and using RAM that the primary CPU's code wishes
  10:  * to use. Implementing such co-ordination would be essentially impossible.
  11:  */
  12: void machine_restart(char *cmd)
  13: {
  14:         smp_send_stop();
  15:  
  16:         arm_pm_restart(reboot_mode, cmd);
  17:  
  18:         /* Give a grace period for failure to restart of 1s */
  19:         mdelay(1000);
  20:  
  21:         /* Whoops - the platform was unable to reboot. Tell the user! */
  22:         printk("Reboot failed -- System halted\n");
  23:         local_irq_disable();
  24:         while (1);
  25: }

0)先转述一下该接口的注释; 
对于多CPU的机器来说,Restart之前必须保证其它的CPU处于非活动状态,由其中的一个主CPU负责Restart动作。并且,必须实现一个基于硬件的Restart操作,以保证所有CPU同步Restart,这是设计的重点! 
对于单CPU机器来说,就相对简单了,可以直接用软件reset的方式实现Restart。

1)调用smp_send_stop接口,确保其它CPU处于非活动状态;

2)调用machine-dependent的restart接口,实现真正的restart。该接口是一个回调函数,由“arch/arm/kernel/process.c”声明,由具体的machine代码实现。格式如下: 
      void (*arm_pm_restart)(char str, const char *cmd) = null_restart; 
      EXPORT_SYMBOL_GPL(arm_pm_restart);

3)等待1s;

4)如果没有返回,则restart成功,否则失败,打印错误信息。

4.5.2 machine_halt

ARM的halt很简单,就是将其它CPU停下来,并禁止当前CPU的中断后,死循环!确实,中断被禁止了,又死循环了,不halt才怪。代码如下:

   1: /*
   2:  * Halting simply requires that the secondary CPUs stop performing any
   3:  * activity (executing tasks, handling interrupts). smp_send_stop()
   4:  * achieves this.
   5:  */
   6: void machine_halt(void)
   7: {
   8:         smp_send_stop();
   9:  
  10:         local_irq_disable();
  11:         while (1);
  12: }
4.5.3 machine_power_off

power off动作和restart类似,即停止其它CPU,调用回调函数。power off的回调函数和restart类似,就不再说明了。

5. 总结与思考
5.1 Architecture和Machine的概念

本文是我们在分析Linux内核时第一次遇到Architecture和Machine的概念,顺便解释一下。内核代码中最常见的目录结构就是:arch/xxx/mach-xxx/(例如arch/arm/mach-bcm/)。由该目录结构可知,Architecture(简称arch)是指具体的体系结构,如ARM、X86等等。Machine呢,是指具体体系结构下的一个或一系列的SOC,如bcm等。

5.2 电源管理驱动(和reboot有关的部分)需要实现内容

由上面的分析可知,在Reboot的过程中,大部分的逻辑是否内核处理的,具体的driver需要关注2点即可:

1)实现各自的shutdown接口,以正确关闭对应的设备

2)实现machine-dependent的接口,以确保底层的Machine可以正确restart或者power off

看来还是很简单的。

<think>嗯,用户现在遇到了一个Ubuntu的问题,报错是“pm: failed to resume async: error -6”。首先,我需要理解这个错误的具体含义。看起来这个错误和电源管理Power Management,PM)有关,特别是系统在恢复或唤醒时出现了问题。错误代码-6可能对应某种内核错误,但需要进一步确认。 接下来,我应该回忆一下常见的Ubuntu电源管理问题。可能的诱因包括硬件兼容性问题、内核模块问题、驱动程序问题,或者是系统配置错误。用户可能是在挂起或休眠后尝试恢复时遇到了这个错误。需要分步骤来解决这个问题。 首先,检查系统日志是个好方法,可以通过journalctl或者dmesg来查看相关错误信息。用户可能不太熟悉这些命令,所以需要给出具体的指令,比如运行sudo journalctl -b -p err,或者dmesg | grep -i error,这样他们可以找到具体的错误线索。 然后,考虑升级内核。Ubuntu的旧内核可能不支持某些硬件,导致电源管理失败。建议用户升级到最新的稳定内核,或者安装硬件厂商推荐的内核版本。不过用户可能不知道如何操作,需要给出具体的命令,比如使用apt来安装linux-generic-hwe版本。 接下来是检查硬件兼容性。特别是对于较新的硬件,可能需要特定的驱动或固件更新。用户可能需要访问硬件制造商的网站,或者使用fwupd来更新固件。这部分可能需要用户有一定的动手能力,但可以给出指导步骤。 然后是调整电源管理参数。比如在内核启动参数中添加acpi=off或nomodeset,这可以测试是否是ACPI或显卡驱动的问题。不过这样做可能会影响系统功能,需要提醒用户谨慎操作,并指导如何修改GRUB配置。 此外,显卡驱动问题也常见,尤其是NVIDIA或AMD的闭源驱动。建议用户检查驱动是否安装正确,或者尝试切换到开源驱动nouveau。用户可能需要运行ubuntu-drivers devices来查看可用驱动,并使用apt安装推荐的驱动。 还有,禁用休眠和挂起功能作为临时解决方案,可以避免问题发生。比如修改/etc/systemd/sleep.conf文件,或者调整GRUB参数。但需要告知用户这是临时措施,问题依然需要进一步排查。 最后,如果用户自己无法解决,建议在Ubuntu论坛或Ask Ubuntu提问,提供详细的日志和硬件信息,这样社区可以更有效地帮助解决问题。 需要确保给出的步骤清晰,避免使用过于专业的术语,让用户能够一步步跟随。同时提醒用户备份重要数据,防止操作中出现意外。可能用户对终端命令不熟悉,所以每个命令都要准确,并解释其作用。此外,需要考虑到不同用户的硬件环境不同,解决方案可能需要个性化调整,但这里给出的是通用步骤。</think>以下是针对Ubuntu系统出现`pm: failed to resume async: error -6`问题的详细解决方案: --- ### **问题背景** 此错误通常与**电源管理Power Management)**相关,多发生在系统尝试从休眠(Hibernate)或挂起(Suspend)状态恢复时。错误代码`-6`可能指向内核级问题,常见原因包括: - 硬件兼容性问题(如ACPI配置冲突) - 内核模块加载失败 - 显卡驱动或固件异常 - 休眠镜像(swap分区)配置错误 --- ### **分步解决方案** #### **1. 检查系统日志定位根源** 运行以下命令查看详细错误日志: ```bash sudo journalctl -b -p err # 查看本次启动的错误日志 dmesg | grep -i "error\|fail" # 筛选内核错误信息 ``` 重点关注包含`PM`、`ACPI`、`resume`等关键词的报错,例如: ``` ACPI Error: No handler for Region [ECRM] (...) ``` --- #### **2. 升级内核和固件** 旧版本内核可能缺乏对硬件的支持: ```bash # 升级内核到最新HWE版本(适用于Ubuntu LTS) sudo apt install --install-recommends linux-generic-hwe-22.04 # 更新固件(需安装fwupd) sudo apt install fwupd sudo fwupdmgr refresh sudo fwupdmgr update ``` --- #### **3. 调整电源管理参数** 在GRUB启动配置中尝试禁用ACPI或修改电源管理选项: ```bash sudo nano /etc/default/grub ``` 修改以下行(以NVIDIA显卡为例): ```conf GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off nomodeset" ``` 保存后更新GRUB并重启: ```bash sudo update-grub && sudo reboot ``` --- #### **4. 检查显卡驱动** 显卡驱动冲突是常见诱因: ```bash # 检查当前驱动 ubuntu-drivers devices # 重新安装驱动(以NVIDIA为例) sudo apt purge nvidia* && sudo apt autoremove sudo apt install nvidia-driver-535 # 替换为推荐版本 ``` --- #### **5. 修复Swap分区配置** 若错误与休眠(Hibernate)相关,需确保Swap分区正确: ```bash # 检查Swap分区是否足够大(至少等于内存大小) free -h # 确认休眠配置指向正确Swap分区 sudo nano /etc/default/grub ``` 添加以下参数(替换`UUID`为实际Swap分区UUID): ```conf GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=your-swap-uuid" ``` 更新配置并重启: ```bash sudo update-grub && sudo reboot ``` --- #### **6. 临时禁用休眠/挂起** 若问题紧急,可暂时禁用相关功能: ```bash # 禁用休眠 sudo systemctl mask hibernate.target # 禁用挂起(需编辑配置文件) sudo nano /etc/systemd/sleep.conf ``` 修改为: ```conf AllowSuspend=no AllowHibernation=no ``` --- ### **附加建议** - **硬件兼容性排查**:尝试在另一台机器或Live USB中测试,确认是否为硬件问题。 - **内核参数调试**:尝试逐步添加/移除`acpi=ht`, `pci=noacpi`等参数。 - **社区支持**:在[Ask Ubuntu](https://askubuntu.com/)提交问题,附上完整日志和硬件信息(使用`lspci`、`lsusb`输出)。 --- ### **总结** 此错误通常需结合日志和硬件环境针对性解决。推荐顺序:**升级内核 → 检查驱动 → 调整ACPI参数 → 修复Swap配置**。若仍无法解决,建议提供完整日志以便进一步分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值