本記事にはアフィリエイト広告（Amazon アソシエイト）が含まれます。
実測日: Mon Oct 12 2026 09:00:00 GMT+0900 (Japan Standard Time)
GPD DUO を自宅の計算機として常時稼働させると、使っていない時間の電力が無駄になる。
寝かせておいて必要なときだけ起こせれば、2 画面のノート PC を小型サーバーとして扱える。
本記事では、GPD DUO を遠隔でスリープさせ、Wake on LAN で起こすまでに踏んだ落とし穴と、確立した手順を示す。
S3 が無い機械で「寝ている」をどう判定するか
GPD DUO は Modern Standby（S0 低電力アイドル）の機械で、powercfg /a は S1 から S3 を利用不可と返す。
Modern Standby には、従来の S3 と違って「寝ていても網につながったまま」という性質がある。
実際、自然に Modern Standby へ入った状態では SSH がつながり、PowerShell も動き、監視の収集も通る。
監視画面に CPU やメモリの値が出ているからといって、起きているとは限らない。
ところが、意図して寝かせた場合は事情が変わる。
SetSuspendState で明示的に寝かせると、port 2222 も 22 も応答しなくなり、IPv6 の近隣表でも FAILED になる。
L2 でも応答しないので、到達性で「寝ている」と判定してよいのはこの場合だけである。
判定にイベントログを使うときは、注意が要る。
System ログの Kernel-Power で 42（スリープ入り）と 107（復帰）が続けて出ていても、網から外れたままのことがある。
実測では 42 の 6 秒後に 107 が出たのに、その 1 分半後も網から見えなかった。
SetSuspendState が True を返したのは、呼び出しから 3 分 37 秒後だった。
判定は ssh の応答と ip -6 neigh で行い、イベントだけを見て判断しないほうがよい。
Wake on LAN は既定では効かない
寝かせた GPD DUO に magic packet を撃っても、既定の設定では起きなかった。
NIC の詳細設定を見ると、関係しそうな項目が 4 つある。
Get-NetAdapterAdvancedProperty -Name 'イーサネット 3'
*ModernStandbyWoLMagicPacket 0 <- これが効く鍵。既定は 0
*WakeOnMagicPacket 1 （S3 用。Modern Standby では効かない）
*WakeOnPattern 1
S5WakeOnLan 1 （S5 用。同じく効かない）
*WakeOnMagicPacket が 1 でも Modern Standby からは起きない。
効くのは *ModernStandbyWoLMagicPacket で、これを 1 にしてアダプタを再初期化すると起きるようになった。
Set-NetAdapterAdvancedProperty -Name 'イーサネット 3' -RegistryKeyword '*ModernStandbyWoLMagicPacket' -RegistryValue 1 -NoRestart
Restart-NetAdapter -Name 'イーサネット 3'
もう 1 つ、誤った判断を誘う点がある。
powercfg /devicequery wake_armed と wake_programmable の一覧に、この NIC は現れない。
この一覧は S3 と S4 向けのもので、Modern Standby 機では NIC が出ないまま WoL が効く。
「一覧に無いから WoL は効かない」と結論しないほうがよい。
起こす手順と所要時間
同じ LAN の Rock 5B から、有線 LAN の MAC アドレスへ magic packet を撃つ。
wakeonlan -i 192.168.0.255 xx:xx:xx:xx:xx:xx
撃ってから約 54 秒で port 2222 と 22 の両方が戻り、近隣表は FAILED から REACHABLE に変わった。
magic packet が起こしたと言えるのは、陰性対照があるからである。
その前後に SSH を合計 10 回叩いたが、いずれも無応答のままだった。
ただし powercfg /lastwake は解除元を記録しないので、厳密な証明にはならない。
休止状態への自動移行という罠
Modern Standby に入ってから 4 時間後に、休止状態へ落ちる設定が既定で入っている。
HIBERNATEIDLE の既定値が 0x3840（14400 秒）だからである。
休止状態では網が落ち、NIC が復帰の経路に無いので、遠隔で起こす手段が無くなる。
寝かせる前に、この値を 0 にしておく。
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP HIBERNATEIDLE 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP HIBERNATEIDLE 0
powercfg /setactive SCHEME_CURRENT
RTCWAKE も無効なので、時刻で自動復帰させる仕掛けは使えない。
戻すときの値は 14400 である。
遠隔で寝かせる手順
ssh 越しに直接 SetSuspendState を撃つと、自分の接続が落ちた時点で中断されることがある。
確実なのは、スケジュールタスクに分離して実行する形である。
schtasks /create で /ru SYSTEM /sc once のタスクとして登録し、schtasks /run で起動する。
/tr は 261 文字までなので、本体はファイルに置く。
中身は .NET の SetSuspendState で、第 3 引数の disableWakeEvent は false にする。
true にすると WoL を受けられなくなる。
Add-Type -AssemblyName System.Windows.Forms
[System.Windows.Forms.Application]::SetSuspendState([System.Windows.Forms.PowerState]::Suspend, $false, $false)
rundll32 powrprof.dll,SetSuspendState は使わない。
引数を無視して休止状態に入るので、起こせなくなる。
WSL2 の VM は凍結されて生き返る
スリープ中、WSL2 の VM は止まる。
/proc/uptime の進みが壁時計より約 204 秒少なく、スリープの窓 225 秒とほぼ一致した。
走行中だった 20 コアの量子化処理（RSS 10.5 GB）は、復帰後も STAT=R のまま CPU を積み続けた。
長い処理を抱えたまま寝かせても、復帰さえできれば処理は失われない。
遠隔運用に必要な設定
GPD DUO を遠隔運用するための設定は 3 つである。
*ModernStandbyWoLMagicPacket を 1 にする、HIBERNATEIDLE を 0 にする、寝かせるときは .NET の SetSuspendState を disableWakeEvent=false で呼ぶ。
この 3 つで、magic packet から 54 秒で戻る小型サーバーになる。