记录一次 Arch Linux 故障的排错过程

2023-04-01 更新，不是愚人节玩笑

我今天又尝试了下使用最新主线版本的内核，发现这个休眠问题似乎已经被修复了，但是又没完全修复，系统可以正常进入休眠状态，然而休眠后键盘指示灯一直亮着，说明机器没有完全断电，需要再长按电源键断电，不过系统是可以正常从休眠中恢复的，即使添加回了 kms 钩子也没问题。

休眠后系统没有完全断电貌似是个相对常见的问题，修复也比较容易，根据 wiki，只需新建 /etc/systemd/sleep.conf.d/hibernatemode.conf 配置文件，若目录不存在就手动创建一个，添加如下内容：

[Sleep]
HibernateMode=shutdown

重启后系统应该就能正常休眠了。

问题出现

就在昨天，我发现我的 Arch Linux 休眠至硬盘的功能出现了问题，而这个功能就在半个多月前我测试的时候还是可以正常工作的。具体的故障表现为可以正常进入休眠状态，但从休眠状态恢复时屏幕黑屏完全无反应，或是直接卡在开机 logo 状态，只能长按电源键重启。我经过一番排查，终于确认并修复了这个问题，以下是我排查的过程。

TLDR

问题出在 AMDGPU 驱动上面，在最新的主线内核（测试过官方库中的 linux 和 linux-zen 包，版本 6.2.2）上面，休眠几乎完全不可用，在从休眠中恢复时甚至都不能记录下日志；在长期支持版本的内核上面，系统可以成功从休眠中恢复，但恢复时 AMDGPU 驱动不能正确加载，导致不能使用图形界面，只能使用 tty。

我在 Arch 论坛上面找到一个比较玄学的解决方案，虽然不太明白原理，但是确确实实解决了问题。

所以解决方案是：

前提是正确配置好休眠功能，参考这里；

更换长期支持版本的内核，比如官方库中的 linux-lts，若想要比较好的性能，可以尝试其他非官方的内核，我目前使用的是 linux-xanmod-lts，从第三方软件源 Chaotic-AUR 获取；

编辑 /etc/mkinitcpio.conf 文件，找到 HOOKS 一行，删除括号里的 kms 内核模块，比如本来是这样的：

HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems resume fsck)

修改成这样：

HOOKS=(base udev autodetect modconf keyboard keymap consolefont block filesystems resume fsck)

再重新生成 initramfs，运行 sudo mkinitcpio -P。

问题排查

我首先想到的是内核版本，毕竟在 ArchWiki 中也提到更换到较旧的内核版本，比如长期支持版本，有可能解决问题。

于是我安装了 linux-lts 内核，版本 6.1.15，要记得更换内核后要重新生成 grub 配置文件才可以在开机时找到对应的启动选项：sudo grub-mkconfig -o /boot/grub/grub.cfg，重启使用 lts 内核启动系统，进入系统后运行 systemctl hibernate 进入休眠状态，再按电源键唤醒电脑。这次没有出现黑屏或卡在开机 logo 的现象了，但是画面卡在休眠前的状态，一动不能动，还是有问题。

我又试了更换好几个不同版本的 lts 内核，都有一样的问题。但是我发现，在画面卡住时，有时我可以通过盲打 sudo reboot 来实现重启系统，这说明系统还是在运行，只是图形界面卡住了。于是我开机后不进入图形界面，在 tty 界面再进行休眠并恢复，这次系统成功恢复到了 tty 的状态，但是在这时当我想要尝试进入图形界面就不行了，感觉大概是显卡驱动的问题。

于是我重启后查看系统日志，运行 journalctl -b -1 可以查看上一次系统启动后产生的所有日志，我发现在从休眠中恢复过程中有如下这样的错误报告：

3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: RAS: optional ras ta ucode is not available
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: RAP: optional rap ta ucode is not available
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
3月 08 11:38:39 liu kernel: amdgpu: restore the fine grain parameters
3月 08 11:38:39 liu kernel: usb 3-2: reset full-speed USB device number 3 using xhci_hcd
3月 08 11:38:39 liu kernel: usb 1-2: reset full-speed USB device number 2 using xhci_hcd
3月 08 11:38:39 liu kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
3月 08 11:38:39 liu kernel: ata2.00: configured for UDMA/133
3月 08 11:38:39 liu kernel: usb 3-1: reset high-speed USB device number 2 using xhci_hcd
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:222 vmid:1 pasid:0, for process  pid 0 thread  pid 0)
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:   in page starting at address 0x0000800000020000 from IH client 0x1b (UTCL2)
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x001009BC
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          Faulty UTCL2 client ID: CPF (0x4)
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          MORE_FAULTS: 0x0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          WALKER_ERROR: 0x6
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          PERMISSION_FAULTS: 0xb
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          MAPPING_ERROR: 0x1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu:          RW: 0x0
3月 08 11:38:39 liu kernel: [drm] kiq ring mec 2 pipe 1 q 0
3月 08 11:38:39 liu kernel: [drm] VCN decode and encode initialized successfully(under SPG Mode).
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 1
3月 08 11:38:39 liu kernel: amdgpu 0000:02:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110).
3月 08 11:38:39 liu kernel: [drm:process_one_work] *ERROR* ib ring test failed (-110).

这几乎就可以确定是 AMDGPU 驱动的问题了。在 Arch 的论坛里，通过关键字 “AMDGPU” 和 “hibernate” 搜了一下，还真找到了相关的帖子，这个帖子是 21 年开的，直到前几天还有人在讨论，说明遇到这个问题还是挺多人遇到的，最后有人提出了一个可能的解决方法：编辑 /etc/mkinitcpio.conf，找到 HOOKS 一行，将括号里的 kms 模块删掉，然后运行 sudo mkinitcpio -P 重新生成 initramfs，重启之后，再尝试进行休眠并恢复，系统就能正常恢复休眠前的状态了。

既然在 LTS 内核上解决了问题，那么在主线内核上可不可以呢，我又试了试切换回了主线内核，发现问题还是一样，查看日志，发现系统根本没有记录下休眠恢复过程中的日志，说明系统根本没有成功恢复，而且在系统早期启动过程中内核有一堆 AMDGPU 相关的警告信息，觉得这大概是其他的问题了，当前我还是留在 lts 内核吧。

问题分析

仔细看了 ArchWiki 上 KMS 相关的页面，按照我的理解，简单来说 KMS 负责自动启用部分显卡驱动，AMDGPU 就是其中之一，/etc/mkinitcpio.conf 中 HOOKS 一行中的 kms 可以让 KMS 在系统启动早期阶段就启用。而对于本文的故障，AMDGPU 就是在启动阶段出现了问题，所以禁用 KMS 早启动，就可以避免这个问题，而没有了 KMS 早启动，系统会自动在启动阶段较晚的时候启用 KMS，所以显卡驱动仍然能正常工作。

总结

关于 Linux 系统的故障排查，有时可能会十分恼人，因为很难找到具体的故障源头，我总结了以下的经验，在排查故障时也许会有帮助：

要懂得查看日志，对于 systemd 的系统，可以用 journalctl 命令，journalctl -b 可以查看最近一次启动所产生的日志，journalctl -b -1 可以查看上一次启动的日志，更多用法可以看这里，仔细阅读日志，便有可能找到问题的大致方向，从而缩小排查范围。

善用搜索引擎，你所遇到的问题，大概率别人也遇到过，并且发在了互联网上，自然也很有可能找到解决方案；

一旦找到可能的问题原因，排查时先从最简单的开始，运气好的话可以节省很多时间；

多看 wiki，对于很多常见问题，很有可能在相关的文档中说明过了，仔细阅读文档，也许能少走很多弯路；

对于 Linux 系统，如果不是为了新的内核特性，使用 lts 内核可能是更稳定的方案。