私は長い間私自身のカーネルを構築し(時には)ConKolivasパッチだけを持つストックソースを使用し、-O2最適化の代わりに-O3を使用して(設定できる場合)、Core2 CPUファミリを対象とする習慣をもたらしました。 。構成はもともとUbuntu 14.04で利用可能な最新のカーネルの1つに基づいていました。デフォルトでは、無効にした唯一の項目はAppArmor、SELinux、およびスイートに関連する設定でした。
数年前に私が作成した最新のカーネルは4.14.23です。 1 日に 1 回以上一時停止したラップトップでは正常に動作し、実行時間が長くなりますが、一時停止プログラムが中断され、電源 LED が点灯し、コンピュータを再起動する必要があります。正確な症状は数多く報告されています。
今週、私は4.19.133(厳密に構築してテストを開始したときの現在のバージョン)にアップグレードしました。結局、すべてをテストしたと思って基本インストールをアップグレードしましたが、停止の問題が体系的に発生していることを発見しました。
少し古いDevuan Beowulf(Debian Busterとも呼ばれます)の4.19.0-9カーネルは影響を受けませんが、設定の違いが多すぎて重要な違いを見つけることができません。カーネルで同じXHCIを設定しようとしましたが、役に立ちませんでした。
この特定のカーネルバージョンで中断の問題についての報告が見つからなかったため、現在のバージョン(137)に対する修正があるとは予想しませんが、残しておきます。
ここで何が間違っている可能性があるのか、および/またはこれを防ぐ方法について実際に答えることができる人はいますか? 5.xカーネル修正に関するYouTube動画がありますが、この動画が私にどのように役立つのか疑問です。
注:私のメインシステムはまだKubuntu 14.04にあり、Devuan Beowulfを使用して2番目のシステムを設定しています。つまり、どちらも無料です。
答え1
4.19.0-9から4.19.0-10に切り替えました。私のコンピュータは4.19.0-10カーネルの中断のために正しく目覚めませんでした。起こるには電源ボタンを押す必要があります。 2つの間で再起動を切り替えると、バージョン4.19.0-10でのみハングアップの問題が発生することがわかります。一時的に作業システムにはさらにACPIエントリがあるように見えますが、SYSLOGで実際の問題を検出できませんでした。たぶん、この小さなバージョンの違いは、誰かが問題の範囲を絞り込むのに役立ちます。
答え2
私はちょうどいくつかの答えを偶然発見したか、少なくともCon Kolivas(ck1)パッチで構築されたカーネルに対する修正(5.7カーネル用)を見つけたと思います。それコアがオフラインの場合は Finish_cpu() を呼び出すべきではありません。。これは実際に私が見ている症状を考えると非常に合理的な説明のように聞こえます。もしそれがfinish_cpu()
私が思うように動作するならば、問題のCPUは関数を呼び出した後に何もできないことを意味します(そしてファームウェアが何かをすることができることを願っています)。
-ck1カーネルユーザーはコミットの適用を試みることができます。muqss: Revert invocation of "finish_cpu" when offlining core
。これは実際にパッチによる変更を元に戻さないので、おそらくパッチはベースカーネルにも適用できます。とても簡単です。