スリープからの復帰時のUbuntu 18.04エラー：スワップデバイスの読み取りエラー

ラップトップが数時間スリープモードに入った後、セッションを再開しようとすると、次のエラーが表示されます。

スワップデバイスの読み取りエラー

ログイン画面がポストこの出来事をロードするのに約30秒かかります。ログインすると、画面が1〜2回空白になり、プログラムが開かなくなります。「システムの問題が検出されました」というプロンプトが表示されます。「レポートを送信」をクリックすると、別の通知がポップアップ表示されます。

「Xorg」プログラムが突然終了しました。計算機には、問題を自動的に分析してレポートを開発者に送信するための十分な空きメモリがありません。

私がこれまでに試したのは、使用可能なスワップスペースを増やすことです。最初は約2 GBでしたが、9 GBの別のスワップファイルを作成しました。これは役に立たなかった。クラッシュ後の占有スワップ領域（swaponコマンドによる）は常に約170MBです。

セッションを再開するときのDMESGは、スワップデバイスの読み取りエラーまでは次のとおりです。

    
[64046.474054] ACPI：低レベルの再開が完了しました
[64046.474162] ACPI：EC：ECが開始されました
[64046.474162] PM：プラットフォームNVSメモリの復元
[64046.475139]非ブートCPUの有効化...
[64046.475196] x86：SMP構成の起動：
[64046.475196] smpboot：ノード0プロセッサー1 APIC 0x2の起動
[64046.475663]キャッシュ：親CPU1がスリープ状態であってはなりません
[64046.475859] CPU1が起動しています
[64046.475910] smpboot：ノード0プロセッサー2 APIC 0x4の起動
[64046.476330]キャッシュ：親cpu2はスリープ状態ではありません
[64046.476506] CPU2が起動しています
[64046.476539] smpboot：ノード0プロセッサー3 APIC 0x6の起動
[64046.477071]キャッシュ：親cpu3がスリープ状態であってはなりません
[64046.477255] CPU3が起動しています
[64046.477274] smpboot：ノード0プロセッサ4 APIC 0x1の起動
[64046.477721]キャッシュ：親cpu4はスリープ状態であってはなりません
[64046.477922] CPU4が起動しています
[64046.477947] smpboot：ノード0プロセッサー5 APIC 0x3の起動
[64046.478371]キャッシュ：親CPU5がスリープ状態であってはなりません
[64046.478571] CPU5が起動しています
[64046.478591] smpboot：ノード0プロセッサー6 APIC 0x5の起動
[64046.479018]キャッシュ：親cpu6はスリープ状態ではありません
[64046.479229] CPU6が起動しています
[64046.479247] smpboot：ノード0プロセッサー7 APIC 0x7の起動
[64046.479675]キャッシュ：親cpu7はスリープ状態ではありません
[64046.479899] CPU7は起動しています
[64046.485913] ACPI：システムのスリープ状態S3からの復帰
[64046.639206] ACPI：EC：イベントのブロックが解除されました
[64046.639711] sd 2：0：0：0：[sda]起動ディスク
[64046.873289] usb 1-11：xhci_hcdを使用してフルスピードUSBデバイス番号2をリセット
[64046.976869] ata4：SATAリンクダウン（SStatus 4 SControl 300）
[64046.976892] ata2：SATAリンクダウン（SStatus 4 SControl 300）
[64047.149289] usb 1-6：xhci_hcdを使用して高速USBデバイス番号40をリセット
[64047.437370] psmouse serio1：シナプス：照会された最大座標：x [..5660]、y [..4570]
[64047.476302] psmouse serio1：シナプス：クエリされた最小座標：x [1364 ..]、y [1284 ..]
[64047.922603] OOMキラーが有効になりました。
[64047.922605]タスクを再起動しています...完了。
[64047.928727] thermal thermal_zone1：サーマルゾーンの読み出しに失敗しました（-61）
[64047.930036] Bluetooth：hci0：ブートローダーリビジョン0.0ビルド2週52 2014
[64047.935036] Bluetooth：hci0：デバイスリビジョンは5
[64047.935037] Bluetooth：hci0：セキュアブートが有効になっています
[64047.935038] Bluetooth：hci0：OTPロックが有効になっています
[64047.935038] Bluetooth：hci0：APIロックが有効になっています
[64047.935039] Bluetooth：hci0：デバッグロックは無効です
[64047.935040] Bluetooth：hci0：最小ファームウェアビルド1週間10 2014
[64047.935042] Bluetooth：hci0：デバイスファームウェアが見つかりました：intel / ibt-11-5.sfi
[64047.944372] PM：出口を一時停止
[64048.050329]スワップデバイスの読み取りエラー（8：0：1543400288）
[64048.460888] [drm] RC6オン

他の情報が必要な場合はお知らせください。

現在使用しているUbuntu 18.04カーネルには、かなり重要なバグ修正がありません。

この修正は、アップストリームLinuxカーネルバージョン4.16.8にすでに存在します。（サスペンドバグはカーネルバージョン4.15で事実上発生し始めました）。Ubuntuは、この小さなパッチをアップストリームから選択するだけです。このバグにより、サスペンド直後にXorgが頻繁にクラッシュします。つまり、グラフィカルログインセッション全体がクラッシュします。

このバグはしばしば表示されずに発生することに注意してくださいRead-error on swap device。ほとんどの場合、カーネルログにエラーはありませんでした。（数回、それが表示されEXT4-fs error、Buffer I/O error代わりに）。また、これらのエラーメッセージは、代わりにハードウェア障害が原因である可能性があります。この問題を診断するときは、他のより明確な詳細に注目してください。

テストカーネルは、このUbuntuバグの最後、つまり次のコメントで入手できます：https : //bugs.launchpad.net/ubuntu/+source/linux/+bug/1776887/comments/5

これまでのところ、Ubuntuのテストカーネルで中断した結果を誰も報告していません。 誰かが成功を報告できれば、Ubuntu開発者がバグ修正を最終的に含めることを奨励するかもしれません。私は間違っているかもしれませんが、何がこれを支えているのか100％はわかりません。

既知の回避策もあります。オプションを含めるようにカーネルコマンドラインを設定すると、クラッシュを回避できますscsi_mod.scan=sync。

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776887

このアップストリームのバグは、Ubuntuユーザーに影響することが確認されています[1]。修正コミット（下記）によると、最も頻繁に起こる症状はXorg / Xwaylandのクラッシュです。つまり、ラップトップがシステムスリープから復帰したときにGUI全体を強制終了します。バグの発生頻度は、数日ごとに1回と説明されています[2]。

[1]例えば、このユーザーはバグと非常に具体的な回避策を確認します：https : //bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1760450/comments/11

[2]たとえば、クラッシュのログ：https : //bugzilla.redhat.com/show_bug.cgi?id=1553979#c23

これはblk-core.cのバグです。これは特定のハードウェアドライバーに固有のものではありません。技術的には、サスペンドバグはすべてのSATAデバイスで使用されるSCSIコアによってトリガーされます。

コミットには、恐ろしいバグの存在を迅速かつ確実に証明するテストも含まれています。

NVMeにrootがいる場合にのみ、このバグを回避できると思います。Xorgのクラッシュを発生させないもう1つの方法は、RAMをすべて使用しない場合です。したがって、Xorgのコールドページがスワップされるようなプレッシャーはありません。また、すぐにサスペンド+再開すると、Xorgのクラッシュを再現できません。（これは、ある時点で私のテストをイライラさせ、昼食中にシステムを中断した後にのみトリガーされました:)。

修正：「ブロック：どこでも割り込み可能な待機を使用しない」

カーネル4.17：https : //github.com/torvalds/linux/commit/1dc3039bc87ae7d19a990c3ee71cfd8a9068f428

カーネル4.16.8の場合：https ://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.16.y&id=7859056bc73dea2c3714b00c83b253d4c22bf7b6

4.15.0-24.26（ubuntu 18.04）の修正の欠如：https ://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic/tree/block/blk-core.c ？id = Ubuntu-4.15.0-24.26＃n856

つまり、このバグはUbuntuソースパッケージlinux-4.15.0-24.26（および4.15.0-23.25）にまだ存在しています。このバグが発生することがわかっているシステムのハードウェアの詳細（lspci-vnvn.log）を添付します。

よろしくアラン

回避策：カーネルパラメーターscsi_mod.scan = syncを使用します