Documentation/power/s2ram.txt

Chinese translated version of Documentation/power/s2ram.txt

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer: 徐红 1534342777@qq.com
---------------------------------------------------------------------
Documentation/power/s2ram.txt的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 徐红 1534342777@qq.com
中文版翻译者： 徐红 1534342777@qq.com

以下为正文

---------------------------------------------------------------------
How to get s2ram working
~~~~~~~~~~~~~~~~~~~~~~~~
2006 Linus Torvalds
2006 Pavel Machek
 如何使s2ram工作
2006 林纳斯 托瓦兹
2006 帕维尔 迈克
1) Check suspend.sf.net, program s2ram there has long whitelist of
   "known ok" machines, along with tricks to use on each one.

2) If that does not help, try reading tricks.txt and
   video.txt. Perhaps problem is as simple as broken module, and
   simple module unload can fix it.

3) You can use Linus' TRACE_RESUME infrastructure, described below.

1）检查suspend.sf.net、s2ram程序，每个好的机器都有很长的白名单以及
使用技巧。

2）如果白名单和技巧不起作用，可以试着去阅读tricks.txt and video.txt
文档。可能问题就如同模块损坏一样简单，简单的模块卸载就能修复。

3）你可以使用下面描述的林纳斯的跟踪-恢复模式

     Using TRACE_RESUME
     ~~~~~~~~~~~~~~~~~~
       使用跟踪-恢复模式
 
I've been working at making the machines I have able to STR, and almost
always it's a driver that is buggy. Thank God for the suspend/resume
debugging - the thing that Chuck tried to disable. That's often the _only_
way to debug these things, and it's actually pretty powerful (but
time-consuming - having to insert TRACE_RESUME() markers into the device
driver that doesn't resume and recompile and reboot).
我一直努力使机器能够同步收发，他经常就像一个发疯的司机。感谢挂起/恢复
调试——查克试图禁用的东西。那通常是唯一可以调试这些东西的方法。而且非常
强大（但是很耗时，必须向未恢复、重新编译和重新引导的设备驱动插入
TRACE_RESUME()标记，）。


Anyway, the way to debug this for people who are interested (have a
machine that doesn't boot) is:


 - enable PM_DEBUG, and PM_TRACE
 
 - use a script like this:


#!/bin/sh
sync
echo 1 > /sys/power/pm_trace
echo mem > /sys/power/state


   to suspend
有兴趣的人（有一个没有引导的机器）调试的方法是：
-启用PM_DEBUG和PM_TRACE
用下面的脚本挂起：
#!/bin/sh
sync
echo 1 > /sys/power/pm_trace
echo mem > /sys/power/state

 - if it doesn't come back up (which is usually the problem), reboot by
   holding the power button down, and look at the dmesg output for things
   like


Magic number: 4:156:725
hash matches drivers/base/power/resume.c:28
hash matches device 0000:01:00.0


   which means that the last trace event was just before trying to resume
   device 0000:01:00.0. Then figure out what driver is controlling that
   device (lspci and /sys/devices/pci* is your friend), and see if you can
   fix it, disable it, or trace into its resume function.


   If no device matches the hash (or any matches appear to be false positives),
   the culprit may be a device from a loadable kernel module that is not loaded
   until after the hash is checked. You can check the hash against the current
   devices again after more modules are loaded using sysfs:


cat /sys/power/pm_trace_dev_match
如果不能恢复（这通常是问题所在），关掉电源重新引导，并查看下面的设备输出信息：
幻数：4:156:725
哈希匹配drivers/base/power/resume.c：28
哈希匹配设备0000:01:00.0
这表明最后一次追踪事件恰好在试图恢复设备0000:01:00.0之前。然后指出哪个驱动
正在控制设备（lspci and /sys/devices/pci* 是你的朋友），看你是否能够修复、禁用
或跟踪到它的恢复功能。
如果没有设备匹配哈希表（或者所有的机器都显示假阳性），罪魁祸首可能是来自哈
希查询之前不会加载的内核可加载设备。当很多模块用系统文件
cat /sys/power/pm_trace_dev_match加载之后，你可以在当前设备再次查询哈希表。


For example, the above happens to be the VGA device on my EVO, which I
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
that "radeonfb" simply cannot resume that device - it tries to set the
PLL's, and it just _hangs_. Using the regular VGA console and letting X
resume it instead works fine.
例如，上面的恰好是我的EVO上的VGA装置，是我用来运行"radeonfb"的（这是一个ATI Radeon
移动显卡）。这表明"radeonfb"无法恢复他试图设置锁相环的设备，他只是挂起。用常规的VGA控
制台让X回复而不是正常工作。


NOTE
====
pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
Reason for this is that the RTC is the only reliably available piece of
hardware during resume operations where a value can be set that will
survive a reboot.
注意
====
pm_trace使用系统的实时时钟（RTC）来保存幻数。因为实时时钟是在恢复操作期间
唯一可靠的硬件机构。它的数值设置将导致重启。


Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option.
结果是，恢复之后（即便是成功的），你的系统时间将会根据幻数矫正而不是而
不是正确的日期/时间！这就是为什么当你使用这种跟踪方式时建议你用一个
来自外部的时间源，像ntp-date or rdate程序，重置正确的日期/时间。


As the clock keeps ticking it is also essential that the reboot is done
quickly after the resume failure. The trace option does not use the seconds
or the low order bits of the minutes of the RTC, but a too long delay will
corrupt the magic value.
如同时钟运转，恢复失败后迅速重启也很重要。跟踪选项不会使用实时时钟的秒或
分钟的低阶位，但是较长的延时会损坏幻数。