0

数日間の実行後にランダムにハングするサーバーが6台あります。メッセージログを確認すると、すべて「clocksourcetscunstable」と「Time：acpi_pmclocksourcehasinstalled」であることがわかりました。これらのメッセージはすべて、サーバー時間をリモートシステムと時々同期させるアプリケーションの1つによるシステム時間調整の瞬間に発生しました。いずれの場合も、「acpi_am」クロックソースがインストールされてから数時間以内にサーバーがハングします。

stime（）関数を使用して、システム時刻を直接設定します。

私はこの種のデバッグの初心者ですが、tsc.cソースコードを読んでその意味を理解しようとしています。カーネルバージョンは2.6.23.8、CPUはIntel Core 2QuadQ9400です。

これはカーネルのバグですか？または、acpi_pm clocksourceに問題がありますか？

編集1：現在のLinuxカーネルツリーの「clocksource」に関連するすべての新しい変更をgit logで検索した後、clocksourcesに関して膨大な量の変更があることがわかりました。これは、私の問題に適用できる可能性のある既存の修正を追跡するのが難しいようです。

編集2：HPETを持っていないようです

cat /sys/devices/system/clocksource/clocksource0/available_clocksource  
tsc acpi_pm jiffies

編集3：@thkalaに感謝します。「ハング」の説明：サーバーにpingを実行できます。telnetを使用すると、21、80などの共通ポートがまだ開いていることを確認できます。ただし、SSH、VNCは「ハング」します（サーバーからの応答がありません）。モニターをサーバーに接続すると、GUIはマウスカーソルで表示されますが、画面が同じ画像でフリーズします。USB光学式マウスをサーバーに接続すると、赤いライトが1回点滅し、完全に暗くなります。USBキーボードを接続すると、caplocknumlockがすべて点灯しなくなります。

編集4：証拠について。@thkalaは本当に良い点を得ました。5台のサーバーすべてで、シャットダウンと再起動を強制した後、メッセージの「ハング」の問題を確認しました。「clocksourcetscnastable」以外の異常なメッセージはありません。「tsc」ログは特定のブートセッション中に1回発生し、いずれの場合も「acpi_pm」クロックソースがインストールされた後にハングが発生しました。一部のサーバーは約16日間稼働しており、「acpi_pm」をインストールしてから1〜13時間以内に、サーバーがハングします。他のサーバーはこのメッセージを表示せず、ハングしませんでした。確かにそれは決定的なものではありませんが、私は推測に基づいてこの方向を掘り下げてきました。

誰かがこれについて考えを持っていますか？

4

1 に答える 1

4

（私は水晶玉を介したデバッグはあまり好きではありませんが、試してみます...）

注意点：

  1. 質問の文脈で「ハング」の正確な意味を指定しません。カーネルは完全に停止しますか？それともアプリケーションだけですか？それは100％CPUに行き、そこにとどまりますか？それはどんな刺激にもまったく反応しますか？問題発生時に関連するコンソールメッセージはありますか？

  2. あなたはあなたの容疑者としてあなたがどれほど正確に時計とタイミングシステムにたどり着いたかについて言及していません- 「数時間以内」は正確に確かな証拠ではありません。ハードウェアの問題（電力変動を含む）を除外しましたか？他に何を除外しましたか、またその理由は何ですか？

  3. 不安定なクロックソースは、あなたが思っているよりも一般的です-私自身のシステムから：

    kernel: Marking TSC unstable due to TSC halts in idle

  4. 非常に古いカーネルを使用しています。現在有名な2012年6月30日のうるう秒の問題など、時間が調整されたときにカーネルがロックすることに関連するいくつかの修正があります。

  5. あなたはNIH症候群に苦しんでいるようです-NTPの代わりに時間同期のためのカスタムアプリケーションを使用することは災害のレシピのように聞こえます...

于 2012-12-10T09:54:58.833 に答える