「Hibernate-script」の版間の差分
ナビゲーションに移動
検索に移動
Kusakata.bot (トーク | 投稿記録) (Pkg/AUR テンプレートの更新) |
Kusanaginoturugi (トーク | 投稿記録) (アーカイブ) タグ: 新規リダイレクト |
||
1行目: | 1行目: | ||
+ | #redirect [[ArchWiki:アーカイブ]] |
||
− | {{Lowercase title}} |
||
− | [[Category: |
+ | [[Category:アーカイブ]] |
− | [[en:Hibernate-script]] |
||
− | {{Related articles start}} |
||
− | {{Related|pm-utils}} |
||
− | {{Related|ノートパソコン}} |
||
− | {{Related articles end}} |
||
− | ハイバネート (suspend to disk) は実行中の全てのプロセスをディスク (通常はスワップパーティション) に書き込んで、マシンの電源を完全に切ります。メモリへのサスペンドと似ていますが、サスペンドではマシンは僅かながら電力を消費するのに対して、ハイバネートされたマシンは電力が要らないため半永久的にハイバネートし続けられます。その代わり、ディスクの書き込み速度はメモリと比べて遅いため (特にスワップパーティションが HDD 上にある場合)、ハイバネートしたり復帰するときに時間がかかります。 |
||
− | |||
− | このガイドではハイバネートバックエンドである [[uswsusp]] ("userspace suspension") と [[TuxOnIce]] (旧名 suspend2) のフロントエンドとして使用する hibernate-script を扱っています。代替フロントエンドについては [[pm-utils]] のページを見てください。Uswsusp は基本的にカーネルにパッチをあてなくても機能しますが initrd/initramfs が必要です。Tuxonice はカーネルを改造する必要がありますが、initrd/initramfs がなくても動作し、スワップパーティションがない場合でもスワップファイルを使ってハイバネートできます。 |
||
− | |||
− | == インストール == |
||
− | |||
− | [[AUR]] から {{AUR|hibernate-script}}{{Broken package link|パッケージが存在しません}} パッケージをインストールしてください。 |
||
− | |||
− | == バックエンドの設定 == |
||
− | バックエンドのインストールと設定については以下のページを見てください: |
||
− | * Tuxonice を使用する方法: [[TuxOnIce]] |
||
− | * Uswsusp を使用する方法: [[Uswsusp]] |
||
− | |||
− | === 直接実行 === |
||
− | 以下のコマンドでハイバネートを実行できます。 |
||
− | |||
− | uswsusp を使用: |
||
− | # hibernate -F /etc/hibernate/ususpend-disk.conf |
||
− | |||
− | TuxOnIce を使用: |
||
− | # hibernate -F /etc/hibernate/tuxonice.conf |
||
− | |||
− | === サスペンド方法の設定 === |
||
− | {{Ic|/etc/hibernate/hibernate.conf}} ファイルで hibernate-script が使用するサスペンド・ハイバネートの方法を設定できます。複数の方法を書いた場合、最初の方法が使われます。''hibernate'' は[[サスペンドとハイバネート|サスペンド]]や標準の uswsusp でも使うことができます。 |
||
− | |||
− | Uswsusp を使用する場合: |
||
− | TryMethod ususpend-disk.conf |
||
− | |||
− | TuxOnIce を使用する場合: |
||
− | TryMethod tuxonice.conf |
||
− | |||
− | == hibernate.script の設定 == |
||
− | ここではハイバネートスクリプトの概要を説明します。細かく調整したい場合、{{Ic|common.conf}} や {{Ic|suspend2.conf}} ファイルを確認してハイバネートや {{Ic|hibernate.conf}} の man ページを読んでください。 |
||
− | |||
− | === /etc/hibernate/common.conf の編集 === |
||
− | このファイルのオプションはハイバネートの方法によらず使用され (各方法の設定ファイルから読み込まれます)、hibernate-script で[[サスペンド]]する場合も使われます。ファイルの中身は複雑ですがコメントが豊富に付けられています。{{Ic|hibernate.conf}} の man ページでは全てのオプションについて十分な説明があります。ここでは最も重要な部分だけを抜粋します。 |
||
− | |||
− | Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems. |
||
− | ### filesystems |
||
− | # Unmount /nfsshare /windows /mnt/sambaserver |
||
− | # UnmountFSTypes smbfs nfs |
||
− | # UnmountGraceTime 1 |
||
− | # Mount /windows |
||
− | |||
− | If you do not explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for: |
||
− | ### services |
||
− | in {{Ic|/etc/hibernate/common.conf}} and change the line just below to: |
||
− | RestartServices alsa |
||
− | |||
− | The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before. |
||
− | You may want to restart other problematic services here. |
||
− | |||
− | A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. |
||
− | In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unloads some problematic modules, listed in {{Ic|/etc/hibernate/blacklisted-modules}}, so you can also add the modules in that file. |
||
− | |||
− | To re-connect to networks after rebooting, you may want to add: |
||
− | OnSuspend 25 netcfg2 -a |
||
− | OnResume 20 netcfg-auto-wireless <your-network-interface> |
||
− | This will disconnect from all networks, then should automatically choose the correct one. If you use another way to connect to a network (such as netcfg2 <profile-name> then of-course, put that there instead. |
||
− | |||
− | One 'gotcha' to watch out for is the priority level you put on your user-commands, this won't work: |
||
− | OnSuspend 5 netcfg -a |
||
− | You'll need to set the priority as 05 instead. Its normally best to use something within the range of 20-50 for your user scripts. |
||
− | |||
− | If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in {{Ic|common.conf}}: |
||
− | ### pcmcia |
||
− | EjectCards yes |
||
− | |||
− | This is necessary on some laptops, if the pccards stop working after resume. |
||
− | |||
− | Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console. |
||
− | The following options in {{Ic|/etc/hibernate/common.conf}} will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming): |
||
− | ### vbetool |
||
− | #EnableVbetool yes |
||
− | #RestoreVbeStateFrom /var/lib/vbetool/vbestate |
||
− | #VbetoolPost yes |
||
− | # RestoreVCSAData yes |
||
− | |||
− | ### xhacks |
||
− | #SwitchToTextMode yes |
||
− | #UseDummyXServer yes |
||
− | #DummyXServerConfig xorg-dummy.conf |
||
− | |||
− | You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man {{Ic|hibernate.conf}}. |
||
− | Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle. |
||
− | |||
− | === NVIDIA 固有の設定 === |
||
− | [[NVIDIA]] のグラフィックカードを使っていてドライバーのバージョンが177以上の場合、以下の行を {{Ic|/etc/hibernate/tuxonice.conf}} に追加してください: |
||
− | ProcSetting extra_pages_allowance 7500 |
||
− | |||
− | 7500がデフォルトですが、システムによっては7500よりも低い値が必要な場合があります。上記のオプションを設定することで X に特別なハックを追加しなくてもハイバネートと復帰ができるようになります。また、{{Ic|/etc/hibernate/blacklisted-modules}} で nvidia モジュールをコメントアウトしてください。 |
||
− | |||
− | ドライバーのバージョンが177未満の場合は extra_pages_allowance は0にすることが推奨されます: |
||
− | ProcSetting extra_pages_allowance 0 |
||
− | |||
− | 上記の設定は ATI のバイナリドライバーでも使えるという報告があります。 |
||
− | |||
− | AGP Nvidia カードでバイナリドライバーを使っている場合、以下の行を {{Ic|/etc/X11/xorg.conf}} に追加してください: |
||
− | Option "NvAGP" "1" |
||
− | |||
− | === fglrx でサスペンド === |
||
− | 以下を {{Ic|/etc/hibernate/suspend2.conf}} に追加してください: |
||
− | # For fglrx |
||
− | ProcSetting extra_pages_allowance 20000 |
||
− | |||
− | === ディスクキャッシュの消去 === |
||
− | As a way to speed up suspending, you can free the memory used for disk caches so there will be less to write to the disk. Just add something like this to the {{Ic|common.conf}} [http://www.linuxinsight.com/proc_sys_vm_drop_caches.html]: |
||
− | OnSuspend 00 sync; echo 3 > /proc/sys/vm/drop_caches |
||
− | |||
− | === TuxOnIce 固有の設定 === |
||
− | TuxOnIce の固有設定は {{Ic|/etc/hibernate/tuxonice.conf}} にあります。以下の行をアンコメントして適切な設定を行ってください: |
||
− | |||
− | UseTuxOnIce yes |
||
− | Compressor lzo |
||
− | |||
− | {{Ic|/etc/hibernate/tuxonice.conf}} と {{Ic|/etc/hibernate/common.conf}} では他にも設定ができます。詳しくは [http://www.tuxonice.net/HOWTO-4.html TuxOnIce] のウェブサイトや[[ハイバネート]]を見てください。 |
||
− | |||
− | You can abort a suspend cycle if you press the escape key. If you press a capital R, you will force the system to reboot after hibernation. |
||
− | |||
− | If all goes well, you should be able to resume using the same GRUB menu selection. If you make that option the default for GRUB, you will always default to resuming if a resume image is available. It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X. |
||
− | {{Warning|Never use a different kernel to resume than you used to suspend! If pacman updates your kernel, do not suspend before you have rebooted properly.}} |
||
− | |||
− | You can make this practice safer adding the hibernate-cleanup daemon to your DAEMONS array in {{Ic|/etc/rc.conf}}. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the GRUB prompt. The hibernate-cleanup service is included in the hibernate-script package. |
||
− | |||
− | == サスペンドとハイバネートのハイブリッド == |
||
− | 使用しているマザーボードやノートパソコンが[[サスペンド]]をサポートしている場合、suspend2 と組み合わせることができます。以下のような操作になります: |
||
− | |||
− | * ハイバネートを実行した時、ディスクにサスペンドしてから電源を切るのではなくメモリにサスペンドします。 |
||
− | * システムをオンにしたら、メモリから直接復帰します (数秒でマシンが立ち上がります)。 |
||
− | * バッテリーが切れたら (メモリ内のイメージが消失したら)、ディスクから復帰します。 |
||
− | |||
− | uswsusp と tuxonice の組み合わせでも同じことができます。 |
||
− | |||
− | uswsusp では、s2both を使ってください。ハイバネートスクリプトから s2both を呼び出すことで、{{Ic|ususpend-both.conf}} を使用することもできます。s2both は s2ram が機能する場合にのみ使えるので注意してください ([[サスペンド]]を参照)。s2ram のホワイトリストにあなたの使用しているノートパソコンが記載されていない場合に強制的に使用する方法はありません。s2ram のローカルコピーを使ってノートパソコンをホワイトリストに入れてサスペンドが問題なく動作することを報告すれば、次の uswsusp のリリースでホワイトリストに記載されます。 |
||
− | |||
− | To do it with tuxonice, edit {{Ic|/etc/hibernate/suspend2.conf}}: |
||
− | ## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff |
||
− | PowerdownMethod 3 |
||
− | |||
− | For this to work, your computer must be able to use suspend to RAM also without s2ram. |
||
− | |||
− | == イベント時にアクションを実行 == |
||
− | Tuning hibernate-script for context sensitive modal operation. You need to have {{Pkg|acpid}} installed. |
||
− | |||
− | === 電源ボタンを押下した時 === |
||
− | Edit the following file {{Ic|/etc/acpi/events/power}} |
||
− | # This is called when the user presses the power button |
||
− | event=button/power (PWR.||PBTN) |
||
− | # To Hibernate uncomment the following line |
||
− | #action=hibernate |
||
− | # To Suspend uncomment the following line |
||
− | #action=suspend |
||
− | |||
− | === フタを閉じた時 === |
||
− | Edit the following file {{Ic|/etc/acpi/events/lid}} |
||
− | # This is called when the user closes the lid |
||
− | event=button/lid |
||
− | # To Hibernate uncomment the following line |
||
− | #action=hibernate |
||
− | # To Suspend uncomment the following line |
||
− | #action=suspend |
||
− | |||
− | You can also install {{AUR|lidsleep}}{{Broken package link|{{aur-mirror|lidsleep}}}} which includes the file altered to use pm-utils and suspend to RAM. |
||
− | |||
− | Alternatively you can edit {{Ic|/etc/acpi/actions/lm_lid.sh}} this is the file that is executed when the lid state is changed |
||
− | |||
− | Example: |
||
− | <pre> |
||
− | #!/bin/bash |
||
− | # lid button pressed/released event handler |
||
− | #laptop mode helps minimized hdd activity |
||
− | test -x /usr/sbin/laptop_mode && /usr/sbin/laptop_mode auto |
||
− | # get the -xauth variable so we can access the display |
||
− | XAUTH="$( ps -C X f | sed -n 's/.*-auth \(.*\)/\1/p' )" |
||
− | if [[ -z $XAUTH ]]; then |
||
− | # if XAUTH is blank try another way to get it |
||
− | XAUTH="$( ps -C xinit f | sed -n 's/.*-auth \(.*\)serverauth.*/\1Xauthority/p' )" |
||
− | fi |
||
− | #Find out if the lid is open or closed |
||
− | if grep -q open /proc/acpi/button/lid/LID/state; then |
||
− | # the screen is on, forces it to be on |
||
− | ACTION="on" |
||
− | XAUTHORITY=$XAUTH /usr/bin/xset -display :0.0 dpms force $ACTION |
||
− | else |
||
− | # screen is off, forces off |
||
− | ACTION="off" |
||
− | XAUTHORITY=$XAUTH /usr/bin/xset -display :0.0 dpms force $ACTION |
||
− | # script waits for 10 minutes |
||
− | sleep 10m |
||
− | # checks to make sure screen is still closed |
||
− | if grep -q closed /proc/acpi/button/lid/LID/state; then |
||
− | # if it is, then it suspends to disk |
||
− | s2disk |
||
− | else |
||
− | # or it turns it back on |
||
− | XAUTHORITY=$XAUTH /usr/bin/xset -display :0.0 dpms force on |
||
− | fi |
||
− | fi |
||
− | </pre> |
||
− | |||
− | The script turns the monitor off or on. But if the screen is left shut for 10 minutes, it will suspend to the disk automatically. <code> man sleep</code> for more info on the sleep command. |
||
− | |||
− | == 別の方法によるサスペンド == |
||
− | |||
− | There is an application, called {{ic|s2ram}}, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use {{ic|s2ram}} to suspend to RAM "out of the box". Non-whitelisted laptops need to try different command line options of {{ic|s2ram}} in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the {{ic|s2ram}} developers, will contribute to whitelist your machine in the next release of {{ic|s2ram}}. |
||
− | |||
− | ただし {{ic|s2ram}} だけでなく、([[ハイバネート]]をするのに使用される) hibernate-script もサスペンドをサポートしています。さらに、hibernate-script ではサスペンドの前後に実行したい操作を自動化することができます。 |
||
− | |||
− | Thus, the first part of this article will be devoted to {{ic|s2ram}}. The second will discuss the use of the hibernate-script in suspension to RAM. In particular, we will see how the hibernate-script can be used to suspend to RAM your system just with the {{ic|s2ram}}, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to RAM and to disk. |
||
− | |||
− | === hibernate-script とサスペンド === |
||
− | The hibernate-script, developed in the field of the tuxonice project for suspend-to-disk method, can be used also to suspend your machine to RAM. Actually, you can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the {{ic|s2ram}} seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to RAM without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to RAM is to use it to call {{ic|s2ram}}. |
||
− | |||
− | You can edit {{ic|/etc/hibernate/hibernate.conf}} to select {{ic|ususpend-ram.conf}} as the default action called by: |
||
− | # hibernate |
||
− | |||
− | Just put the following as the first uncommented line: |
||
− | TryMethod ususpend-ram.conf |
||
− | |||
− | However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line: |
||
− | # hibernate -F /etc/hibernate/ususpend-ram.conf |
||
− | |||
− | Now you should configure the script. Please note that the options that you put in {{ic|/etc/hibernate/common.conf}} will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in {{ic|/etc/hibernate/ususpend-ram.conf}} will be used only when you suspend to RAM with the {{ic|s2ram}} method. |
||
− | |||
− | The hibernate-script options are exhaustively described in the man page {{ic|hibernate.conf}}. |
||
− | |||
− | First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is {{ic|/etc/hibernate/blacklisted-modules}}. |
||
− | |||
− | If you discover that a module is guilty, you should report this to the suspend-devel@lists.sourceforge.net, so that the bad behaviour of the module can be fixed. |
||
− | |||
− | May be also that your display is the guilty and that the tricks provided by {{ic|s2ram}} are not enough. The hibernate-script has some further tricks: |
||
− | |||
− | The relevant block of options is the following: |
||
− | ### vbetool |
||
− | #EnableVbetool yes |
||
− | #RestoreVbeStateFrom /var/lib/vbetool/vbestate |
||
− | #VbetoolPost yes |
||
− | # RestoreVCSAData yes |
||
− | |||
− | ### xhacks |
||
− | #SwitchToTextMode yes |
||
− | #UseDummyXServer yes |
||
− | #DummyXServerConfig xorg-dummy.conf |
||
− | |||
− | However, most of these tricks are already attempted by {{ic|s2ram}} and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines: |
||
− | EnableVbetool yes |
||
− | RestoreVbeStateFrom /var/lib/vbetool/vbestate |
||
− | |||
− | Please note that, while {{ic|s2ram}} uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the {{ic|--vbe_save}} {{ic|s2ram}} option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command: |
||
− | # vbetool vbestate save > /var/lib/vbetool/vbestate |
||
− | |||
− | The second peculiar trick (very often required!) is to uncomment the following line: |
||
− | SwitchToTextMode yes |
||
− | |||
− | The script will switch from X to console before suspension and back to X after a successful resuming. |
||
− | |||
− | Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems. |
||
− | |||
− | The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages. |
||
− | |||
− | ===サウンド=== |
||
− | If you do not explicitly restore the volume level, ALSA may have the sound channels muted after resuming. If this happens, you can edit {{ic|/etc/suspend.conf}} by adding |
||
− | RestartServices alsa |
||
− | |||
− | ===自動サスペンドと復帰=== |
||
− | Once you have suspend to RAM working, you will probably want it to happend automatically e.g., when you close the laptop lid. |
||
− | |||
− | There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts. |
||
− | |||
− | ===自動サスペンド (難しい方法) === |
||
− | ACPI events are managed by configuration files in {{ic|/etc/acpi/events/}}. (The laptop-mode-tools package contains some examples). A default configuration file called 'anything' is provided by the acpid package, which runs {{ic|/etc/acpi/handler.sh}} on every event. |
||
− | |||
− | An simple event configuration file to manage the opening and closing of a laptop lid (that could be called {{ic|/etc/acpi/events/lid}}) looks like this: |
||
− | event=button[ /]lid |
||
− | action=/etc/acpi/actions/lid_handler.sh %e |
||
− | |||
− | The first line specifies the names of the events applicable to this file with a regexp. You can get the names of events by enabling event logging in acpid and looking at {{ic|/var/log/acpid}}. |
||
− | |||
− | The second line specifies an executable to be run when an applicable event occurs. The {{ic|%e}} is a variable containing arguments that the event provides. It's a good idea to provide them to the program. |
||
− | |||
− | It's customary to put handling programs in {{ic|/etc/acpi/actions/}}. A possible implementation of {{ic|lid_handler.sh}} in the previous example could be: |
||
− | #!/bin/sh |
||
− | # check if the lid is open or closed, using the /proc file |
||
− | if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then |
||
− | # if the lid is now closed, save the network state and suspend to RAM |
||
− | netcfg all-suspend |
||
− | pm-suspend |
||
− | else |
||
− | # if the lid is now open, restore the network state. |
||
− | # (if we are running, a wakeup has already occured!) |
||
− | netcfg all-resume |
||
− | fi |
||
− | |||
− | The same example, adapted for wicd instead of netcfg: |
||
− | #!/bin/sh |
||
− | # check if the lid is open or closed, using the /proc file |
||
− | if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then |
||
− | # if the lid is now closed, save the network state and suspend to RAM |
||
− | /usr/lib/wicd/suspend.py |
||
− | pm-suspend |
||
− | else |
||
− | # if the lid is now open, restore the network state. |
||
− | # (if we are running, a wakeup has already occured!) |
||
− | /usr/lib/wicd/autoconnect.py |
||
− | fi |
||
− | |||
− | Remember to make it executable. With some basic knowledge of shell scripting, you have a lot of possibilities. |
||
− | |||
− | === 復帰の制御 === |
||
− | The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is: |
||
− | root@hex in /proc/acpi $ cat wakeup |
||
− | Device S-state Status Sysfs node |
||
− | LID S3 *enabled |
||
− | PBTN S4 *enabled |
||
− | MBTN S5 enabled |
||
− | PCI0 S3 disabled no-bus:pci0000:00 |
||
− | USB0 S0 disabled pci:0000:00:1d.0 |
||
− | USB1 S0 disabled pci:0000:00:1d.1 |
||
− | USB2 S0 disabled pci:0000:00:1d.2 |
||
− | USB3 S0 disabled pci:0000:00:1d.3 |
||
− | EHCI S0 disabled pci:0000:00:1d.7 |
||
− | AZAL S3 disabled pci:0000:00:1b.0 |
||
− | PCIE S4 disabled pci:0000:00:1e.0 |
||
− | RP01 S4 disabled pci:0000:00:1c.0 |
||
− | RP02 S3 disabled |
||
− | RP03 S3 disabled |
||
− | RP04 S3 disabled pci:0000:00:1c.3 |
||
− | RP05 S3 disabled |
||
− | RP06 S3 disabled |
||
− | |||
− | To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces). So to prevent opening the laptop lid from triggering a wakeup, you could do: |
||
− | root@hex in /proc/acpi $ echo " LID" > wakeup |
||
− | root@hex in /proc/acpi $ cat wakeup |
||
− | Device S-state Status Sysfs node |
||
− | LID S3 *disabled |
||
− | PBTN S4 *disabled |
||
− | MBTN S5 disabled |
||
− | PCI0 S3 disabled no-bus:pci0000:00 |
||
− | ... |
||
− | |||
− | Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this: |
||
− | root@hex in /proc/acpi $ dmesg |
||
− | ... |
||
− | ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one separately |
||
− | ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one separately |
||
− | |||
− | This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary. |
||
− | |||
− | None of this will persist between boots, so you might want to add the echo command to {{ic|/etc/rc.local}} so it is executed on every boot: |
||
− | # disable the laptop lid switch |
||
− | echo " LID" > /proc/acpi/wakeup |
2024年9月8日 (日) 17:15時点における最新版
転送先: