12.16 使用和调试 FreeBSD ACPI

12.16.3.1 鼠标问题

　　某些时候， 唤醒操作会导致鼠标不再正常工作。 已知的绕过这一问题的方法， 是在 /boot/loader.conf 文件中添加 hint.psm.0.flags="0x3000" 设置。 如果这样做不能解决问题， 请考虑按前面介绍的方法提交问题报告。

12.16.3.2 休眠/唤醒

　　ACPI 提供了三种休眠到 RAM (STR) 的状态， S1-S3， 以及一个休眠到磁盘的状态 (STD)， 称作 S4。 S5 是 “软关机” 同时也是系统接好电源但没有开机时的正常状态。 S4 实际上可以用两种不同的方法来实现。 S4BIOS 是一种由 BIOS 辅助的挂起到磁盘方法， 而 S4OS 则是完全由操作系统实现的。

　　可以使用 sysctl hw.acpi 来查看与休眠有关的项目。 这里是我的 Thinkpad 上得到的结果。

hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0

　　这表示我可以使用 acpiconf -s 来测试 S3， S4OS， 以及 S5。 如果 s4bios 是一 (1)， 则可以使用 S4BIOS 来代替 S4 OS。

　　当测试休眠/唤醒时， 从 S1 开始， 如果它被支持的话。 这个状态是最可能正常工作的状态， 因为它不需要太多的驱动支持。 没有人实现 S2 但如果您有它的支持， 则应该和 S1 类似。 下一件值得尝试的是 S3。 这是最深的 STR 状态， 并需要一系列驱动的支持才能够正常地重新初始化您的硬件。 如果您在唤醒系统时遇到问题， 请不要吝惜发邮件给 freebsd-acpi 邮件列表， 尽管不要指望问题一定会很快解决， 因为有许多驱动程序/硬件需要进行更多的测试和改进。

　　休眠和唤醒操作最常见的问题是某些设备驱动程序不会保存、 恢复或正确地重新初始化其固件、 寄存器或设备内存。 尝试调试这些问题时， 首先可以尝试：

# sysctl debug.bootverbose=1
# sysctl debug.acpi.suspend_bounce=1
# acpiconf -s 3

　　这个测试会模拟休眠和恢复过程而不真的进入 S3 状态。 有时， 您会用这种方式很容易地抓住问题 (例如， 丢失固件状态、 设备 watchdog 超时， 以及一直重试等)。 注意系统不会真的进入 S3 状态， 这意味着这些设备可能不会掉电， 而许多设备在完全不提供休眠和恢复方法时仍可正常工作， 而不像使用真的 S3 状态那样。

　　较难的情况则需要更多的硬件， 例如用于串口控制台的串口/线， 以及用于 dcons(4) 的火线口/线和内核调试技能。

　　为了帮助隔离问题， 请在内核中删去尽可能多的驱动。 如果这样做能够解决问题， 请尝试逐个加载驱动直到问题再次出现。 通常预编译的驱动程序如 nvidia.ko、 X11 显示驱动， 以及 USB 的问题最多， 而以太网卡的驱动则通常工作的很好。 如果您能够通过加载和卸载驱动使系统正常工作， 您可以通过将适当的命令放到 /etc/rc.suspend 和 /etc/rc.resume 来将这个过程自动化。 在这两个文件中有一个注释掉的卸载和加载驱动程序的例子供您参考。 另外您还可以将 hw.acpi.reset_video 设置为零 (0)， 如果您的显示在唤醒之后显得很混乱。 此外您还可以尝试更长或更短的 hw.acpi.sleep_delay 值看看是否有所助益。

　　另一件值得一试的事情是使用一个比较新的包含 ACPI 支持的 Linux 发行版来试试看他们的 休眠/唤醒 功能是否在同样的硬件上能够正常工作。 如果在 Linux 下正常， 则很可能是 FreeBSD 驱动程序的问题， 而隔离问题并找到存在问题的驱动有助于解决它。 需要注意的是 ACPI 的维护人员通常并不维护其他驱动 (例如 声音、 ATA， 等等) 因此如果最终发现是驱动的问题最好还是发到 freebsd-current 邮件列表并发给驱动程序的维护者。 如果您喜欢冒险， 则可以加一些 printf(3) 到有问题的驱动中， 以找到它的恢复功能发生问题的位置。

　　最后， 试试看禁用 ACPI 并代之以启用 APM。 如果 休眠/唤醒 能够在 APM 下正常工作， 使用 APM 可能会更好， 特别是对于较老的硬件 (2000年以前)。 硬件制造商需要一些时间来让老硬件的 ACPI 工作正常， 而 ACPI 的问题十之八九是 BIOS 中的毛病引发的。

12.16.3.3 系统停止响应 (暂时或永久性地)

　　绝大多数系统停止响应是由于未能及时响应中断或发生了中断风暴导致的。 芯片组有很多问题最终会溯源到 BIOS 如何在引导系统之前配置中断， APIC (MADT) 表的正确性， 以及 系统控制中断 (SCI) 如何路由。

　　通过察看 vmstat -i 的输出中包括 acpi0 的那一行可以区分中断风暴和未能及时响应中断。 如果每秒计数器增长的速度多于一两个， 则您是遇到了中断风暴。 如果系统停止了响应， 您可以尝试停止内核并进入 DDB (在控制台上按 CTRL+ALT+ESC) 并输入 show interrupts。

　　处理中断问题的救命稻草是尝试禁用 APIC 支持， 这是通过在 loader.conf 中加入 hint.apic.0.disabled="1" 完成的。

12.16.3.4 崩溃

　　崩溃对于 ACPI 是比较罕见的情况， 如果发现， 我们将会非常重视并很快修复它。 您要做的第一件事是设法隔离出能够重现崩溃 (如果可能的话) 的操作并获取一份调用堆栈。 请启用 options DDB 并设置串行控制台 (参见 第 27.6.5.3 节) 或配置一个 dump(8) 分区。 您将在 DDB 中通过 tr 得到调用堆栈。 如果您只能用手抄的方法记录它， 一定要记下头五 (5) 行和最后五 (5) 行。

　　然后， 尝试通过在启动时禁用 ACPI 来隔离故障。 如果这样做能够正常工作， 请通过设置 debug.acpi.disable 的那组数值来隔离具体是哪个 ACPI 子系统的问题。 请参见 acpi(4) 联机手册中给出的那些例子。

12.16.3.5 系统在休眠或关机之后又启动了

　　首先请尝试在 loader.conf(5) 中设置 hw.acpi.disable_on_poweroff=“0”。 这将让 ACPI 不再在关机过程中禁用一些事件。 基于同样的原因， 一些系统需要把这个值设置为 “1” (这是默认值)。 这通常能够修复在休眠或关机时立即再次启动的问题。

12.16.3.6 其他问题

　　如果您有 ACPI 的其他问题 (同 docking station 协同工作、 无法检测设备， 等等)， 请把描述发给邮件列表； 不过， 这些问题也有可能和 ACPI 中尚未完成的部分有关， 它们可能需要时间才能被实现。 请给点耐心， 并准备测试我们可能会发给您的补丁。

12.16.5.1 _OS dependencies (_OS 依赖)

　　某些 AML 假定世界是由不同版本的 Windows 组成的。 您可以让 FreeBSD 声称自己是任意 OS 来看一看是否能够修正问题。 比较简单的办法是设置 hw.acpi.osname="Windows 2001" 到 /boot/loader.conf 中， 或使用您在 ASL 中找到的其他字符串。

12.16.5.2 Missing Return statements (缺少返回语句)

　　一些方法可能没按照标准要求的那样显式地返回值。 尽管 ACPI-CA 无法处理它， 但 FreeBSD 提供了一个绕过它并允许其暗含地返回值的方法。 您也可以增加一个显式的 Return 语句， 如果您知道那里需要返回一个值的话。 要强制 iasl 编译 ASL， 需要使用 -f 标志。

12.16.5.3 替换默认的 AML

　　在定制 your.asl 之后， 您可以通过下面的命令编译它：

# iasl your.asl

　　可以使用 -f 标志来强制创建 AML， 即使在编译过程中发生了错误。 请注意某些错误 (例如， 缺少 Return 语句) 会自动被解释器忽略掉。

　　DSDT.aml 是 iasl 命令的默认输出文件名。 可以加载它来取代您 BIOS 中存在问题的副本 (它仍然存在于闪存中)， 其方法是按下面的说明编辑 /boot/loader.conf：

acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"

　　一定要把您的 DSDT.aml 复制到 /boot 目录中。