web-dev-qa-db-ja.com

Ubuntu 18.04-蓋を閉じたときにDell XPS13 9370が一時停止しなくなりました

これは17.10では完全に機能していましたが、昨日18.04にアップグレードした後、ふたを閉じると画面がオフになりますが、適切に一時停止しません。

よく旅行しますが、トラベルケースから取り出すとすぐに熱(およびバッテリーの消耗)に気付きました。

/etc/systemd/logind.confでこれらの行のコメントを外してみました

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

再起動しましたが、違いはありませんでした。

52
Murray

次の2つのソースのおかげで、何が起こっているのかを把握できたと思います: Dell XPS 13(9370)ArchLinuxインストールノート および Arch Linuxフォーラム

何らかの理由で、ラップトップはディープスリープ状態ではなく、単に[スクリーンオフ]タイプのサスペンドであるs2idleモードになります。

問題の診断

これがシステムに当てはまるかどうかを確認するには、お好みの方法でラップトップをサスペンドします(蓋を閉じ、Fn + Endを押し、pm-suspendを端末に書き込んでくださいpm-utilsがインストールされているか、Windowsキータイプsuspendを押してEnterキーを押します。

サスペンドモードからウェイクアップし、ターミナルに入力します:Sudo journalctl | grep "PM: suspend" | tail -2。出力が

May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit

その後、あなたは深い眠りに入りません。 cat /sys/power/mem_sleepも確認できます。

[s2idle] deep

デフォルトのサスペンドモードがs2idleであることを確認します(括弧で強調表示されているため)。

一時的な修正

一時的な修正を試すには、echo deep > /sys/power/mem_sleepをrootユーザーとして実行します。 cat /sys/power/mem_sleepの出力を見て、成功したことを確認します。

s2idle [deep]

その後、ラップトップをサスペンドし、再び起動します。 Sudo journalctl | grep "PM: suspend" | tail -2が返される場合

May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit

その後、問題を修正する必要があります。コンピューターを数時間スリープさせ、バッテリーの消耗が改善されたかどうかを確認できます。

永続的な修正

永続的にするには、ブートローダーのコマンドラインを編集する必要があります。そのためには、たとえばSudo -H gedit /etc/default/grubを実行して、rootユーザーとしてファイル/ etc/default/grubを編集します。行を置き換える

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

grub設定を再生成します(Sudo grub-mkconfig -o /boot/grub/grub.cfgを実行)。

68
monty47

/etc/systemd/sleep.confを作成してみてください:

[Sleep]
SuspendMode=
SuspendState=mem

そして再起動します。これは私にとってはうまくいっているようですが、最初に行った/etc/systemd/logind.confの変更でも改善が得られなかったのは確かではありません。いずれの場合でも、ふたを閉じた状態で吊り下げられている間は熱やファンのノイズは観察されず、wifi経由のpingにも応答しません。これはIhad前に断続的に取得しています。

おそらくサスペンドの作業方法は、明らかに適切に動作していないデフォルトの理想的な方法よりも効率が低いため、バッテリー寿命は一時停止中に低下しますが、デフォルトの動作よりも優れているようです。

XPS 13 9370を試してみましたが、古いモデルについては知りませんが、類似しているようです。

pm-utilsをインストールしてpm-suspendを使用してみましたが、それはかなり効果的に中断しているようだったので、systemd-suspendを同じようにできるかどうか確認したかったのです。

pm-utilsのスクリプトを調べて、実際に何をしていたのかを調べました。この状況では、echo -n "mem" > /sys/power/stateを実行していたように見えます。そこで、上記の/etc/systemd/sleep.confファイルを作成して、それに一致させました。

デフォルトの動作が完全に明確ではありません。 systemd-sleep.confのマンページには、ディストリビューションに/etc/systemd/sleep.confが含まれ、コンパイル済みのデフォルトがコメントアウトされているため、この情報を確認できますが、ubuntuではこのファイルがありません。 cat /sys/power/stateを取得すると次のようになります:

freeze mem

だから私はguessingであり、これがデフォルトで何をしているのかということです。私の推測では、freezeが受け入れられている可能性があります。エラーをスローしないため、そうでなければsystemdはmemに移動しますが、実際にはそうではありませんwork複雑な理由により、適切に、または確実に、判断できないようです。そのため、代わりにmemを送信することは、それを回避し、pm-suspendが行うことを実行する上で期待できる刺し傷です。

SuspendMode設定は実際には不要であり、とにかく何もしません。 cat /sys/power/diskが単にあなたを取得するので、私はこれを疑います:

[disabled]

新しいユーザーであるため、意見をコメントすることができず、私はそれに自信があるかのように答えとして提示することを余儀なくされました!しかし、私はそれが働いていると思います。

8
StrangeNoises

ここでの他の答えは、優れた、詳細で、よく研究されています。

残念ながら、特定のマシンでは動作しませんでした:(

NVidiaグラフィックをお持ちの場合は、この質問に対する回答でcascagrossaが提供してくれた多くの人々のために機能する修正があるようです: サスペンドから再開するとUbuntu 18.04がクラッシュします

バグのあるnouveauドライバーであると疑われており、nouveau.modeset = をgrubに追加することで中断の問題を整理でき、問題の修正を支援するためのコメントで確認されています。その他も。

問題のあるマシンにIntelグラフィックスを搭載しており、不思議なことに、少なくとも3つの他のマシン(私の友人と自分のマシン)でUbuntuまたはKubuntu 18.04の問題を一時停止していないので、この特定のマシンがどうしてそんなに圧倒されているのか不明です。

この種の問題が発生した場合は、次の手順に従って問題を特定することをお勧めします:

  1. nVidiaグラフィックはありますか?その場合、nouveau.modeset = 0grubトリックを試してください。

  2. サスペンドがまったく機能することを確認します。ふたを閉じてから開いて、目が覚めない場合、「再開」に失敗しているように見える場合があります。

    • どのデスクトップでもサスペンドを手動で選択できるはずですが、Gnomeシェルでは少し非表示になっています-画面の右上のメニューから電源ボタンを長押しするか、そのボタンをクリックしますAltキーを押すか、スーパーキーを押して「suspend」と入力します

    • サスペンドを選択すると、画面がオフになっていることを確認できます電源LEDが点滅する、そして実行中のファンも停止するこれがすべて起こるが、thenマシンをウェイクアップできない場合は、「サスペンド」問題ではなく「レジューム」問題のように見えます。

    • 私の問題は、actuallyが中断されず、衝突によって尋ねられたときに元の質問をしたマレーがこれを確認することで、手動で中断したときに問題が発生していることを認識しました。

    • 私の場合、(問題のあるラップトップで)、画面はブランクになりますが、電源LEDは点灯したままで、ファンが作動している場合は作動し続けます。マシンは、キーの押下、タッチパッドの移動、クリック、または電源ボタンの押下には応答しません。できることは、シャットダウンすることだけです。

    • サスペンド中に音楽を再生しようとしました(画面が空白になるだけではないことを確認するため)が、音楽が停止し、マシンが基本的に停止しました。

  3. 18.04のライブUSBでマシンを試し、同様のサスペンド問題があるかどうかを確認します。

    • これは、サスペンドの問題が、インストールした追加のプログラムと関係がないことを確認するだけです。

    • 私の場合、tlpをインストールしたので、何らかの理由でサスペンドモードに干渉する可能性がありましたが、Ubuntu 18.04とKubuntu 18.04

  4. monty47とStrangeNoisesが提供する他の2つのよく研究されたソリューションを試して、良い結果が得られるかどうかを確認してください。

    • 彼らは多くの人々が18.04にサスペンドを再開して適切に動作するのを助けたようで、マシンが/ではなくs2idle状態になることに関係があるかもしれませんsleep(deep)通常の「サスペンド」のモード。
  5. 18.04でサスペンドの問題を解決するための解決策がない場合は、サスペンドから再開するとUbuntu 18.04がクラッシュします

    • Matalak(提供者も質問)が提供した解決策は、UKUUを使用して古い4.14カーネルを試すことでした。

    • Ubuntu 17.10およびKubuntu 17.10では問題のマシンにサスペンドの問題がなかったため、17.10は4.14カーネルを使用しているので理にかなっています。現在、Ubuntu 18.04とKubuntu 18.04の両方で4.14カーネルを使用して正常に一時停止します。

  6. 他のソリューションを試して、4.14カーネルに戻ることによってのみサスペンドの問題を修正できる場合は、バグレポートに興味があるかもしれません。https://bugs.launchpad.net/ubuntu/+source/linux/+ bug/1774950

    • 特定のハードウェアの組み合わせを備えた少数のマシンにのみ影響を与えているようであり、他のヌーボー関連の問題やs2idleの問題を特定するのは困難です。

    • Bay Trail Atom Celeron/Pentiumを実行している人にはより一般的ですが、他のマシンでも同様の問題が報告されています。

    • このサスペンドに失敗した後にkern.logを確認できる場合(つまり、マシンをシャットダウンして再起動する必要がある場合)と表示される場合がありますPM:エントリを一時停止(深い)すると、再度起動する多くの行を除いて、エントリがなくなります。

    • 現在、問題を解決しているように見えるパッチがあります。

    • バグレポートに自分の声を追加したいと思うなら、どの特定のマシンが影響を受けているかを見るのは興味深いでしょう(そして、パッチが全員の問題を修正することを確認してください)。

また、このスレッドで「18.04の問題の一時停止」をまとめようとしています: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

4
pHeLiOn

このカーネルのバグは関連していると思います:

https://bugzilla.kernel.org/show_bug.cgi?id=199689

特にコメント#3を参照してください。

[…]実際には、このマシンで最新のアップストリームカーネルを使用してs2idleを使用することを意図しています。

2
Chris Lamb

同様の症状、つまり、入っていないことによって引き起こされる中断中のバッテリーの消耗があるThinkpad X1 Carbon 6th Genのユーザーに答えを追加したいだけですdeepスリープモード。

この問題は、Lenovoのフォーラムの このスレッド で説明されています。要するに、X1C6はWindowsモダンスタンバイのサポートを選択しています。そのスレッドを注意深く読むと、症状が共有されているにもかかわらず、根本原因はXPS 13 9370とX1C6の間で大きく異なることがわかります。例えばX1C6でのcat /sys/power/mem_sleepの出力は[s2idle]のみで、deep sleepのサポートがないことを示します。

この質問に対してこれまでに投稿されたソリューションは、XPS 13のみに適用され、X1C6には適用されません。私の知る限り、X1C6のサスペンドモードの問題に対する最善の解決策は、最初に by Delta Xi を指定してDSDTパッチを適用し、続いて by PombeirP を適用することです。 この投稿 では、パッチの適用方法を説明していますが、アクションの前に投稿とその更新をすべて読んでください。

a Gist を書きました。LVMによるスローブートの問題と this deepに関する解決策を含む、Thinkpad X1 Carbon 6th GenへのUbuntu 18.04のインストールに関する問題を文書化しました。スリープの問題

1
B.Gao

この質問を終わらせるために(願わくば...)、私はちょうど(2019年7月)HWEを搭載した18.04 LTSをアップデートしました。 )

0
B.Tanner

Lenovo ThinkPad Edge E531を使用していますが、マシンがディープスリープに入ることができないという同様の問題が発生しました。動作は断続的であり、再開すると、タッチパッドがWiFiでの動作を停止して切断することがありました。

オンラインで提案された十数個の修正を試みましたが、私のために働いた唯一の解決策は KUUのインストール であり、カーネルを4.19.11-041911-genericにアップグレードすることでした。

0
emagdne