4

厄介な問題が発生し、デバッグしようとしている会社の多くのエンジニアが一時的に困惑しました。

C++ プログラムは通常、MPI を備えたマルチコア コンピューターのクラスターで実行されます。

非常に長い時間 (おそらく数日) 実行された後、突然失敗します。

それに取り組んでいるほとんどのエンジニアは、プログラム自体にバグがある可能性を排除したため、ハードウェアの問題の可能性を非難し始めていますが、Linux カーネル モジュールまたはデバイスのいずれかにソフトウェアの問題があるに違いないと思います。運転者。

疑わしいのは、カーネル モジュールまたはデバイス ドライバーが、いくつかの浮動小数点計算を行うために、SMP システムでは安全でない方法で FXSAVE/FXRSTOR を実行していることです。これは、再入可能にする必要があるカーネル ルーチンの静的バッファに対して FXSAVE を実行するのと同じくらい簡単なことかもしれません。これにより、競合状態のバグが発生し、スレッドの浮動小数点コンテキストがほとんど破損しなくなります。

アプリケーション レベルでは、FXSAVE/FXRSTOR コンテキストの一部である MXCSR の 1 つまたは複数のビットが突然変更されているように見えますが、それを変更するアプリケーション コードはありません。

何年も前に Windows で似たようなことがありましたが、最終的にはビデオ ドライバーのバグであることが判明しました。アプリケーション コードがオペレーティング システムによってプリエンプトされたときに、そのスレッドのコンテキストの一部の MXCSR ビットが破損していました。

私は Linux カーネルのハッキングやデバイス ドライバーの開発の専門家ではありませんが、再入可能性の規則が大幅に変更されていることを読んでいます。非 SMP システムと SMP (マルチコア) システムの間。カーネル バージョン間。など。したがって、競合状態のバグの可能性は妥当と思われます。

私の質問は次のとおりです。その説明に当てはまる既知の Linux ドライバー (またはカーネル) のバグはありますか?

同様の症状があった場合、私が引用できる前例があれば参考になります。この時点で、関係者の多くは (IMHO) 「私のコードにはバグがないので、ハードウェアが悪いに違いない」と考えて時間を無駄にしています。それを超えて、本当の原因である可能性が高いものを探したいと思います.

4

1 に答える 1

0

カーネルのソースは、通常 src.rpm として入手できます。これ (および内部の .tgz) を抽出し、fxsave asm 命令などのすべてを grep することができます。何かを見つけたらとても驚かれると思いますが、誰が知っていますか? バイナリ ビデオ ドライバを実行している場合は、それらをロードしなくても問題が解決しないかどうかを確認してください。

  1. kernel-2-whatever.src.rpm をダウンロード
  2. mkdir temp; cd温度
  3. rpm2cpio ../kernel*rpm | cpio-id
  4. tar xvf linux-*.tgz
  5. grep -ri fxsave *
于 2009-10-29T03:04:22.777 に答える