ASRock Z690 Steel Legendで、スリープからすぐ目覚めてしまう現象が発生してましたが、これを止めることができました。USB関係の問題でした。他のCPU世代の自作でもよく見かける現象ですので、参考になると思います。以下の記事の続きです。OSはMonterey 12.1です。
Intelの第12世代CPUになるAlder Lake-Sシリーズが発売されました。今までになく高性能になったと評判です。macOSではサポートされていないCPUですが、Montereyで安定して稼働しました。Radeon RX 6600XTと組み合わせると、M1 Maxをちょっとだけ超える性能が得られます。ASRock Z690 Steel Legend WiFi 6EZ690マザーボードにはASRock Z690 Steel Legend WiFi 6Eを選びました。WiFiの付いていないASRock Z690 Steel Legendも同様に使用できます。違いはE key M.2に802.11ax Wi-Fi 6E モジュールIntel AX210NGWが搭載されているかどうか、... ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす - Boot macOS |
Table of Contents
スリープからすぐに目覚める問題
Appleメニューから、もしくは、無操作のタイムアウトからスリープに入ると、以下のような現象が発生してました。
- スリープに入る
- 画面が暗くなる。でもCPUファンは動いている。
- 1分ほどそのままの後、画面が復帰してログイン画面に戻る。
という現象です。スリープ復帰後は、引き続き正常に使用できます。また、シャットダウンは正常に行えます。
いろいろ試してみたところ、バックパネルのUSB Type-Aコネクタに接続されたデバイス(接続していたのはキーボード用無線USBアダプタとUSBメモリーです)を全部外すと、スリープから目覚めなくなることがわかりました。何かがUSB Type-Aコネクタに挿さっていると、1分ほどでスリープから目覚めてしまいます。
また、バックパネルのUSB Type-Cに同じキーボードとUSBメモリを接続したところ、この場合は正常にスリープし、そのキーボードを押すと復帰します。Type-Cには直接接続できないので、この確認には、MacBookで使うType-Cハブを使いました。
さらには、マザーボード搭載のM.2 E KeyコネクタのUSBも問題ないようで、そこに取り付けたBCM94360NGにBluetooth接続するApple Magic Keyboardなどは問題を起こしません。接続していてもスリープに入りますし、キーを押すとスリープから復帰します。
どうも、バックパネルのType-Aコネクタが問題を起こしている様子です。
USBがスリープを阻害する問題は、hackintoshでよく経験します。昔の記事ですが、こちらではZ390ボードが目覚める原因がUSBハブでした。
スリープするとすぐに目覚めてしまうマシンがありました。ずっと諦めていたのですがようやく原因がわかりました。5インチベイに取り付けたUSBハブでした。取り外したら正しくスリープし続けるようになりました。スリープからすぐに目覚めるこちらで紹介したコンピュータ(ASUSのZ390チップセットマザーボードを使用)が、ここのところずっと、スリープからすぐに目覚めてしまう問題を抱えていました。一旦はスリープに入るのですが、2~3秒で目覚めてしまいます。上の記事を書いた時点では、ケースに入れない状態で仮組をして動かしてい... USB機器がスリープを阻害することがあります - Boot macOS |
OpenCoreのバニラガイドを見ると、macOSのUSBドライバに不備があって、スリープ時の電力管理に問題があるらしいです。おそらく、Macの実機で動けば良いので、標準仕様を満たした設計にはなっていないのでしょう。それでパッチを当てて修正する手法が考えられているようです。まずはそれを試しました。
方法1:USB機能にパッチする
USB機器がスリープを邪魔しないようにするパッチがいくつか考えられています。tonymacx86のZ690ビルドのスレッド
- https://www.tonymacx86.com/threads/z690-chipset-and-alder-lake-cpus.316618/
- https://www.tonymacx86.com/threads/gigabyte-z690-aero-g-i5-12600k-amd-rx-6800-xt.317179/
で配布されているZ690用のEFIファイル類を見ると、二つの方法が試みられていました。一つは、
- SSDT-USBW.amlを使い、
- USBWakeFixup.kextを使う
方法です。上記のバニラガイドでも紹介されている方法です。USBデバイスがスリープを妨げることを防ぐための措置らしいです。でも効果がありませんでした。カスタマイズする必要があったのかもしれないです。
もう一つは、
- SSDT-GPRW.amlを使い、
- Method(GPRW,2,N)にパッチを当てる
方法です。パッチは、config.plistのACPI/Patchに、以下のように書いておきます。USBとBluetoothがスリープを妨げないようにする処置のようです。
生のplistの部分は、以下になります。
<dict> <key>Comment</key> <string>change Method(GPRW,2,N) to XPRW, pair with SSDT-GPRW.aml</string> <key>Enabled</key> <true/> <key>Find</key> <data>R1BSVwI=</data> <key>Replace</key> <data>WFBSVwI=</data> </dict>
こちらは機能しました。これはUSBデバイスをスリープ解除に使えなくする力技のパッチです。なので、どんなUSBデバイスが挿さっていても、スリープから目覚めなくなりましたが、一方で、USBキーボードやBluetoothキーボードを操作しても、スリープから復帰しなくなります。電源スイッチを押して初めて復帰します。電源スイッチが遠いとちょっと不便なので、なんとかしたいところです。
方法2:USBPort.kextを書き換える
そこでこの方法を考えました。まずは気になったところが、Type-Aコネクタが使用されている時だけ、スリープから目覚めてしまうという現象です。Type-CやM.2コネクタのUSBデバイスは問題を起こしません。
USBコネクタの種類は、EFIの中で設定してmacOSに知らせています。現在使っている方法は、USBPorts.kextを作って、その中のInfo.plistで設定する方法です。
macOSのUSB 15個制限を解決するために、使用する15個未満のUSBポートを決定し、macOSに伝えます。以前の記事でいくつかの方法を紹介しましたが、今回はHackintoolを使ってkextを作ります。作業が楽で、作ったkextを1個インストールするだけなので簡単でした。USBポート個数対処の方法今までの記事では、USBポート個数制限に対処する方法として、 AppleUSBXHCIPCI.kextにパッチを当てる OpenCoreのconfig.plistでXhciPortLimitをtrueにする DSDTを書き換えて使用する15個のUSBポートを指定する USBInjectAll.kextとブートオプション... 15個制限のためのUSBPorts.kextをHackintoolで作る - Boot macOS |
Hackintool.appを使う場合は、以下のようにしてConnectorの種類を設定します。
Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。それぞれの選択で、Info.plistのUsbConnectorキーに0, 3, 9, 10, 255が割り当てられます。hackintoolのソースによると、この5種類を含めて、以下の数値が用意されています。
kTypeA = 0x00, // Type ‘A’ connector kMiniAB = 0x01, // Mini-AB connector kExpressCard = 0x02, // ExpressCard kUSB3StandardA = 0x03, // USB 3 Standard-A connector kUSB3StandardB = 0x04, // USB 3 Standard-B connector kUSB3MicroB = 0x05, // USB 3 Micro-B connector kUSB3MicroAB = 0x06, // USB 3 Micro-AB connector kUSB3PowerB = 0x07, // USB 3 Power-B connector kTypeCUSB2Only = 0x08, // Type C connector - USB2-only // These only implement the USB2 signal pair, and do not implement the SS signal pairs kTypeCSSSw = 0x09, // Type C connector - USB2 and SS with Switch // These implement the USB2 signal pair, and a Functional Switch with a physical // Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed // signal pairs to a single USB Host Controller port as function of the Type-C plug // orientation. kTypeCSS = 0x0A, // Type C connector - USB2 and SS without Switch // These implement the USB2 signal pair and a Functional Switch by connecting each // receptacle SuperSpeed signal pair to a separate USB Host Controller port. // 0x0B – 0xFE: Reserved kInternal = 0xFF // Proprietary connector
どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistoryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。コネクタ設定の違いが、スリープ時の電流管理にも影響していて、意図しない復帰を誘発している可能性がるかと思います。実際に先の記事にも書きましたが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。
今回の不具合も、Type-Aに対するスリープ時の電力管理がうまく働かないのが原因とも考えられます。それで、Type-Aに設定していた部分:
を、以下のように、全てInternalに設定しました。
この結果、Type-AのコネクタにUSBデバイスを接続していても正しくスリープするようになりました。Internal (255) 以外の設定値のうち、一般的なUSB 2.0 (0)とTypeC+Sw (9)も試しましたが、それらでは解決しませんでした。上の実験でType-Cで正しくスリープ動作したのは、ハブのおかげだったのかも知れないです。
スリープ動作の確認
ということで、USBPorts.kextでコネクタをInternalに設定する方法で、問題はほぼ解決しました。以下のaml, kext, パッチ:
- SSDT-USBW.aml
- USBWakeFixup.kext
- SSDT-GPRW.aml
- Method(GPRW,2,N)パッチ
は、どれも不要でした。
この方法で正しくスリープに入り、CPUファンが停止した状態が何時間も継続します。その一方で、Bluetooth接続したApple Magic Keyboard, Magic Trackpad, LogicoolのBTマウスなどから目覚めさせることが可能です。また、Type-Cにハブ経由で接続したノーブランドのキーボードからも目覚めます。
ただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができない問題があります。こちらで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。また、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できるようです。いずれにしてもBluetooth入力デバイスをメインに使っていく予定なので、このことはほとんど気になりません。
macOSの「システム環境設定・省エネルギー」のデフォルトでは、「ネットワークアクセスによるスリープ解除」が有効になっています。これを有効にしておくと、手元の環境では頻繁に目覚めてしまいます。色々な機器が接続されているので、アクセスが多いのかも知れないです。ネットワークがもっと静かな環境なら有効に設定しても良いのかも知れませんが、これを無効にしました。
一方で、「Power Napを有効にする」は、有効にしておいてもそれほど問題はありません。約1時間に1回ほど目覚める程度でした。それが気になるような環境でしたら、無効にしておくと良いと思います。
まとめ
スリープから自動的に目覚めてしまう現象に、USBPorts.kextの設定で対応しました。正しくスリープして、キーボードやポインティングデバイスの操作でスリープ復帰するようになりました。Z690は、性能が良くて安定しているので、すぐにメインマシンにしても良いくらいです。